In Transport und Travel Tech starten Sie fast nie auf einem weißen Blatt. Sie betreiben bereits eine Plattform, die Tickets verkauft, Routen plant oder Reservierungen verbindet, und genau diese Plattform bringt das Geld. Die Aufgabe besteht also nicht darin, eine Anwendung von Grund auf zu schreiben, sondern Transport-Anwendungen so weiterzuentwickeln, dass sie rund um die Uhr laufen und trotzdem jedes Quartal neue Funktionen bekommen. Als CTO, Plattformverantwortliche oder IT-Leitung kennen Sie die Spannung: Das Business will es schneller, während technische Schulden und das Ausfallrisiko in die andere Richtung ziehen.
Aus unserer Erfahrung ist das Schwierigste, die Kontinuität zu wahren - Wert zu schaffen, ohne umzustoßen, was bereits funktioniert. Für einen Anbieter von Technologie für Luftfahrt und Reisen tun wir genau das: Wir entwickeln neue Funktionen seiner bestehenden Anwendungen, betreiben die Systeme und führen Cloud-zu-Cloud-Migrationen auf Java, Microservices und GCP durch. Im Folgenden schlüsseln wir das auf.
Warum sind Entwicklung und Betrieb von Transport-Anwendungen dasselbe?
Weil man sie in einem Produkt, das jahrelang lebt, nicht trennen kann, ohne etwas zu verlieren. Ein Team, das nur „Brände löscht”, begreift nie, wohin die Architektur läuft. Ein Team, das nur neue Funktionen liefert und den Bestand ignoriert, hinterlässt Ihnen ein Jahr später eine Plattform, die niemand mehr anfassen will.
Deshalb behandeln wir es als einen Arbeitsstrang: Entwicklung neuer Funktionen und Betrieb der Systeme laufen durch dasselbe Team, das den Code, die Abhängigkeiten und die Geschichte früherer Entscheidungen kennt. Jede neue Funktion fügt sich dann bewusst in die bestehende Architektur ein statt als Aufsatz, und kleine Wartungskorrekturen werden zu Gelegenheiten, technische Schulden abzutragen. Im Transport, wo Integrationen mit externen Systemen allgegenwärtig sind, ist diese Kontinuität besonders wertvoll.
Wie bauen wir neue Funktionen in bestehende Transportsysteme?
Wir schreiben das Produkt nicht neu, wir lassen es schrittweise wachsen. Wir steigen in laufenden Code ein, lesen seine Logik und ergänzen Funktionen so, dass der Rest der Plattform weiterläuft.
- wir lesen die bestehende Architektur und ihre Abhängigkeiten, bevor wir etwas ändern,
- wir entwerfen jede neue Funktion als Teil eines größeren Ganzen, nicht als Insel,
- wir sichern die Änderung mit Tests ab, damit Regressionen nicht zerstören, was bereits steht,
- wir rollen in kleinen Schritten aus, mit der Möglichkeit zurückzugehen.
Dieses Vorgehen passt zu Produkten, die echten Passagier- oder Buchungsverkehr tragen und nicht eine Woche lang „wegen Umbau” abgeschaltet werden können.
Wie bauen wir das Backend im Transport: Java, Spring und Microservices?
Das Herz der meisten Transportplattformen ist ein Java-Backend. Wir bauen es auf Spring und teilen es in Microservices, denn in dieser Branche entwickeln sich verschiedene Systemteile unterschiedlich schnell: Die Suchmaschine für Verbindungen ändert sich in einem anderen Takt als das Zahlungsmodul oder eine Lieferantenintegration.
Diese Teilung bringt unabhängige Deployments je Service, klare Verantwortungsgrenzen und die Möglichkeit, nur das zu skalieren, was tatsächlich unter Last steht. Darüber liegt die Datenschicht: Wir entwerfen und betreiben die ETL- und ELT-Prozesse, die Reporting, Analytics und Integrationen speisen. Im Transport sind Daten zu Strecken, Preisen und Verfügbarkeit selbst ein Produkt, deshalb nehmen wir ihren Fluss so ernst wie die Anwendungslogik.
Wie sieht ein Transport-Frontend in React und Angular aus?
Auf der Nutzerseite arbeiten wir vor allem mit React und Angular. Die Wahl richtet sich danach, worin das bestehende Produkt geschrieben ist - wir passen uns dem Stack des Kunden an, statt unseren eigenen zu verordnen.
Wir entwickeln Oberflächen, die echte Komplexität tragen müssen: Verbindungssuche, Verfügbarkeitskalender, Buchungspanels und operative Ansichten. Wir achten darauf, dass das Frontend unter einem wachsenden Stapel von Funktionen nicht auseinanderfällt - wir halten Komponenten sauber, beobachten die Rendering-Performance und wahren die Stimmigkeit mit dem übrigen Ökosystem. Hier übernimmt ein Team Frontend und Backend, sodass eine neue Funktion von der API bis zum Bildschirm zusammenwächst, ohne dass Verantwortung zwischen Dienstleistern hin und her geworfen wird.
Wann greifen wir im Transport zu C++-Komponenten?
Wenn es auf reine Performance ankommt. Manche Transportsysteme haben Abschnitte, in denen Millisekunden und Speicherverbrauch den Unterschied machen - die Verarbeitung großer Datenmengen, rechenintensive Algorithmen, Komponenten nah an Hardware oder Infrastruktur. Dort greifen wir zu C++ im Standard C++17.
Das ist nicht unsere Voreinstellung für eine ganze Anwendung, sondern ein Werkzeug für bestimmte, performancekritische Elemente, die wir dann in die übrige Plattform aus Java und Microservices einbinden. Das Produkt gewinnt genau dort Leistung, wo es sie braucht, ohne alles Übrige zu verkomplizieren.
Wie führen wir die Migration von Transport-Anwendungen in die Cloud durch (GCP, Cloud-zu-Cloud)?
Eine Cloud-Migration behandeln wir als Operation am lebenden Organismus und nicht als einmaliges „Dateien verschieben”. Für den Anbieter von Technologie für Luftfahrt und Reisen führen wir Cloud-zu-Cloud-Migrationen nach GCP durch und verschieben laufende Systeme zwischen Cloud-Umgebungen, ohne dass das Business es spürt.
- wir containerisieren Anwendungen (Docker) und orchestrieren sie in Kubernetes,
- wir beschreiben Infrastruktur als Code in Terraform, sodass Umgebungen wiederholbar sind,
- wir automatisieren Deployments mit CI/CD auf Jenkins,
- wir migrieren in Etappen und behalten die Kontrolle darüber, was wann umgeschaltet wird.
Diese Infrastruktur liefert später, wofür man migriert: schnellere, sicherere Deployments, vorhersehbare Umgebungen und Skalierung auf echten Verkehr.
Wie sichern wir die Qualität: QA und Testautomatisierung?
In einem System, das sich ständig ändert, kommt manuelles Testen nicht hinterher. Deshalb automatisieren wir, was sich automatisieren lässt. Wir bauen End-to-End-Tests der Oberfläche in Selenium und API-Tests in REST Assured und verdrahten sie in die CI/CD-Pipeline, sodass jede Änderung geprüft wird, bevor sie weitergeht.
Dadurch bedeutet die Entwicklung neuer Funktionen kein dauerndes Regressionsrisiko mehr - das Team kann schneller Wert schaffen, weil das Testnetz Fehler früh abfängt. Das ist eine der Bedingungen dafür, Entwicklung und Betrieb parallel zu führen statt abwechselnd.
Welche Kompetenzen stellen wir für ein Transportprojekt bereit?
Wir stellen das Team passend zum konkreten System und zu seiner Phase zusammen, nicht nach festem Muster. Meist verbinden wir mehrere Rollen:
- Backend-Entwickler (Java/Spring), die Microservices und Domänenlogik entwickeln,
- Frontend-Entwickler (React/Angular), die die Oberflächen verantworten,
- C++-Engineers dort, wo Performance zählt,
- DevOps- und Cloud-Engineers für Containerisierung, Kubernetes, Terraform und CI/CD,
- QA-Engineers, die Testautomatisierung aufbauen,
- Datenspezialisten, die die ETL- und ELT-Prozesse betreiben.
Wir besetzen das nicht alles vorsorglich - wir holen die Rollen, die das Projekt wirklich braucht.
Wie machen wir das bei RITS?
Wir machen das als Nearshore-Partner aus Polen, mit echter Erfahrung in Transport und Travel Tech. Für einen Anbieter von Technologie für Luftfahrt und Reisen entwickeln, betreiben und migrieren wir seine Anwendungen in die Cloud: Wir ergänzen neue Funktionen in bestehenden Systemen, halten sie am Laufen und führen Cloud-zu-Cloud-Migrationen nach GCP durch.
Darunter läuft ein stimmiger Stack: Java, Spring und Microservices im Backend, React und Angular im Frontend, C++17 in performancekritischen Komponenten, dazu Docker, Kubernetes, Terraform und Jenkins in der Cloud-Schicht und Selenium und REST Assured in der Testautomatisierung. Ein solches Team behandelt Entwicklung und Betrieb als eine Aufgabe, sodass die Plattform wächst statt zu bröckeln.
Womit fangen Sie bei Entwicklung und Migration von Transport-Anwendungen an?
Starten Sie mit einer ehrlichen Karte dessen, was Sie haben: welche Systeme Wert bringen, wo technische Schulden liegen und was Sie daran hindert, neue Funktionen zu ergänzen. Erst daraus ergibt sich, ob Entwicklung, Betrieb oder eine Cloud-Migration der dringendere Schritt ist - und welche Kompetenzen Sie brauchen. Die Unterschiede zwischen den Kooperationsmodellen haben wir in unserem Artikel zu IT-Kooperationsmodellen beschrieben.
Sie bauen, betreiben oder migrieren Transport-Anwendungen in die Cloud? Sprechen wir darüber - wir stellen Team und Stack passend zu Ihrem System zusammen.