Flugreservierungssysteme: Warum sie immer noch auf Großrechnern laufen

Wenn Sie 2026 einen Flug per Smartphone buchen, durchläuft Ihre Anfrage mehrere Schichten moderner Technologie – eine mobile App, einen Webdienst und einen Zahlungsabwickler –, bevor sie das System erreicht, das Ihren Sitzplatz reserviert. Dieses System basiert in den meisten Fällen auf Software aus den 1960er-Jahren und nutzt eine Infrastruktur, die die Reisebranche seit Jahrzehnten zu ersetzen versucht, bisher jedoch ohne Erfolg. Sabre, Amadeus und Travelport wickeln zusammen praktisch alle Flugbuchungen weltweit ab. Sie verarbeiten jährlich Milliarden von Transaktionen für Hunderte von Fluggesellschaften, Tausende von Reisebüros und greifen auf Echtzeit-Kontingente mit Millionen von Sitzplatzkombinationen zu. Das älteste dieser Systeme geht auf einen IBM-Großrechner von 1964 zurück, der die Reservierungszeiten von 90 Minuten auf wenige Sekunden verkürzte und die kommerzielle Luftfahrt nachhaltig veränderte.

Die Gründe, warum diese Systeme weiterhin bestehen, sind nicht auf organisatorische Trägheit oder konservative Ingenieurspraktiken zurückzuführen. Vielmehr geht es darum, was geschieht, wenn Software so tief in einen unternehmenskritischen Betriebsprozess integriert ist, dass die Kosten und Risiken einer Ablösung angesichts eines realistischen Zeitrahmens nicht zu rechtfertigen sind. Die Branche hat darauf reagiert, indem sie die Kernsysteme modernisiert hat, anstatt sie zu ersetzen. Für alle, die an der Modernisierung von Altsystemen im großen Stil arbeiten, sind Flugreservierungssysteme das beste Beispiel dafür, was „systemrelevant“ in der Praxis bedeutet.

Der Ursprung: Warum Mainframes das Problem der Fluggesellschaften gewonnen haben

Das ursprüngliche SABRE (Semi-Automated Business Research Environment) war kein Produkt, sondern eine maßgeschneiderte Lösung für eine spezifische operative Krise. Ende der 1950er-Jahre wuchs American Airlines schneller, als ihr manuelles Reservierungssystem bewältigen konnte. Die Buchung eines Sitzplatzes erforderte einen Anruf, die manuelle Prüfung einer physischen Inventarkarte, eine Reservierung, einen Rückruf und einen Papierbeleg – ein Prozess, der durchschnittlich 90 Minuten pro Buchung in Anspruch nahm und nicht skalierbar war.

Als SABRE 1964 vollständig in Betrieb ging – basierend auf zwei IBM 7090-Großrechnern und verbunden mit 1,500 Terminals in den USA und Kanada –, konnte es 7,500 Reservierungen pro Stunde nahezu fehlerfrei verarbeiten. Erstmals konnte eine Fluggesellschaft die Sitzplatzverfügbarkeit in Echtzeit verwalten, vollständige Passagierdatensätze speichern und Sofortbuchungen im gesamten Streckennetz ermöglichen. Die Reservierungszeiten sanken von 90 Minuten auf Sekunden.

Die Architekturwahl, die dies ermöglichte – die zentrale Transaktionsverarbeitung auf Großrechnerhardware –, wurde nicht aus philosophischen Gründen getroffen. Sie wurde gewählt, weil sie 1964 die einzige verfügbare Architektur war, die die Anforderungen an Latenz, Zuverlässigkeit und gleichzeitigen Zugriff für die Echtzeit-Bestandsverwaltung von Fluggesellschaften erfüllen konnte. Und sie funktionierte so gut, dass sie zur architektonischen Vorlage für alle nachfolgenden Flugreservierungssysteme wurde.

IBMs Transaction Processing Facility (TPF), ursprünglich für SABRE entwickelt, wurde zur Betriebsumgebung für die gesamte Produktkategorie. Laut IBM nutzen fast alle großen Banken, Versicherungen, Einzelhändler und Fluggesellschaften sie noch immer. Als Amadeus 1987 gegründet wurde, baute das Unternehmen auf TPF auf. Auch Galileo (heute Travelport) nutzte TPF für sein GDS. Drei Generationen von Passagierservicesystemen sind heute in der kommerziellen Luftfahrt parallel im Einsatz, und viele laufen weiterhin auf TPF-Mainframes. Dies liegt nicht daran, dass die Technologie nie infrage gestellt wurde, sondern daran, dass sich der Transaktionsdurchsatz, die Zuverlässigkeit und die Fehlertoleranz, die TPF auf Mainframe-Hardware bietet, als äußerst schwer auf vergleichbaren alternativen Architekturen nachzubilden erwiesen haben.

Was diese Systeme im großen Maßstab tatsächlich leisten

Die Dimensionen, in denen Flugreservierungssysteme operieren, sind aus der Perspektive der Softwareentwicklung nicht intuitiv fassbar. Ein globales Distributionssystem verwaltet nicht nur die Sitzplatzverfügbarkeit, sondern bewältigt ein kombinatorisches Bestandsproblem von enormer Komplexität.

Ein einzelner Transatlantikflug umfasst Hunderte von Tarifklassen. Jede Tarifklasse hat spezifische Regeln: Vorausbuchungsfristen, Mindestaufenthaltsdauer, Sperrdaten, Umbuchungsgebühren, Zulässigkeit von Zwischenstopps und Codeshare-Abkommen mit Partnerfluggesellschaften. Eine Buchung mit zwei Fluggesellschaften, einem Anschlussflug und Hin- und Rückflug erzeugt eine Vielzahl von potenziell Tausenden gültigen Tarifkombinationen. Diese müssen geprüft, bewertet und mit dem Echtzeit-Verfügbarkeitsbestand abgeglichen werden, bevor eine Antwort – in der Regel innerhalb einer Sekunde – erfolgt.

In Spitzenzeiten verarbeiten Sabre und Amadeus gemeinsam Zehntausende Transaktionen pro Sekunde. Nicht pro Minute. Pro Sekunde. Jede Transaktion umfasst die Echtzeit-Abfrage des verfügbaren Platzes, die Prüfung der Tarifbestimmungen, die Erstellung oder Änderung des PNR (Passagierdatensatz) sowie die Koordination mit der Abflugkontrolle, dem Vielfliegerprogramm und den Systemen für Zusatzleistungen. Die garantierte Antwortzeit wird in Millisekunden gemessen, da ein Reisebüro oder Buchungssystem, das länger als einige Sekunden auf eine Tarifprüfung wartet, eine Zeitüberschreitung erleidet und die Transaktion entweder wiederholt oder abbricht.

TPF auf Mainframe-Hardware erreicht diesen Durchsatz mit einer Ausfallrate, die IT-Experten anderer Branchen kaum glauben können. Die Fehlertoleranz des Mainframes, redundante Prozessoren, Hot-Swap-fähige Komponenten und jahrzehntelang gehärteter Betriebssystemcode gewährleisten eine Verfügbarkeit von 99,9 .... Dies zu vergleichbaren Kosten in Cloud-Infrastrukturen zu replizieren, war die zentrale technische Herausforderung jedes IT-Modernisierungsprogramms einer Fluggesellschaft seit den 1990er Jahren.

Die Modernisierungsversuche: Was die jahrzehntelangen Programme tatsächlich ergaben

Die Geschichte der Modernisierung von Flugreservierungssystemen ist eine Geschichte von Programmen, die ursprünglich das Ziel verfolgten, den Kern zu ersetzen, und Jahre später bei einem Hybridmodell landeten, das den Kern lediglich umschloss.

Das Jetstream-Projekt von American Airlines, das in den 2000er-Jahren mit dem ausdrücklichen Ziel gestartet wurde, das Sabre-Mainframe-PSS zu ersetzen, führte letztendlich zur Einführung eines neuen Sabre-Produkts anstatt zur Entwicklung einer Alternative. Die anfängliche Annahme, dass die Eigenentwicklung eines Ersatzsystems schneller zu einem besseren System führen würde, stieß auf dieselbe Realität wie fast jedes groß angelegte Legacy-Ersatzprogramm: Das bestehende System wies Anforderungen auf, die erst dann bekannt wurden, als das Ersatzsystem diese nicht mehr erfüllen konnte.

Wir müssen tiefer in die Systemarchitektur vordringen, den Kern der Technologie verändern und die Regeln entkoppeln, um sie schnell anpassen zu können. Diese Aussage der IT-Leitung von American Airlines während des Jetstream-Programms beschreibt das Problem präzise. Die im Altsystem verankerten Regeln – Tarifberechnungslogik, Implementierung von Codeshare-Abkommen, Berechnungen zur Einhaltung gesetzlicher Bestimmungen, Integrationen im Revenue Management – ​​hatten sich über Jahrzehnte durch Geschäftsveränderungen angesammelt und waren nicht so dokumentiert, dass sie ohne den Betrieb des bestehenden Systems und die Beobachtung seines Verhaltens extrahierbar gewesen wären.

Sabres eigenes Modernisierungsprogramm, das in den 2010er-Jahren richtig Fahrt aufnahm, dauerte über ein Jahrzehnt und kostete Milliarden von Dollar, um den Großteil des Codes von der On-Premise-Mainframe-Infrastruktur zu migrieren. Im Jahr 2019 liefen noch etwa 11 Prozent des Sabre-Codes in On-Premise-Rechenzentren, der Rest war migriert. Im Februar 2026 verlängerte Sabre seinen langfristigen PSS-Vertrag mit WestJet und demonstrierte damit, dass das PSS auch nach einem Jahrzehnt der Modernisierung und Milliardeninvestitionen weiterhin die kommerzielle Grundlage des Geschäfts bildet.

Amadeus hat die Mainframe-Abrüstung weitgehend abgeschlossen und mit der Stilllegung der letzten Mainframes zugunsten einer Cloud-Infrastruktur einen wichtigen Meilenstein erreicht. Der Ansatz von Amadeus, funktionale Komponenten schrittweise zu ersetzen und gleichzeitig das Kerndatenmodell und die Transaktionsarchitektur beizubehalten, bewahrte die ursprünglich auf dem Mainframe getroffenen Architekturentscheidungen trotz des Hardwarewechsels. Transaktionssemantik, PNR-Struktur und Bestandsverwaltungslogik wurden unter Beibehaltung ihres grundlegenden Designs in die moderne Infrastruktur übertragen.

Warum der Austausch schwieriger ist als er aussieht: Die verborgene Komplexität

Die gängige Erklärung dafür, warum Flugreservierungssysteme weiterhin auf Großrechnern laufen, sind Kosten und Risiken. Beides sind real. Sie sind jedoch Symptome einer tieferliegenden technischen Realität, die es genau zu verstehen gilt, da sie für jedes Modernisierungsprogramm geschäftskritischer Altsysteme relevant ist.

Geschäftsregeln existieren ausschließlich im Code. Die Logik der Tarifberechnung in einem globalen Distributionssystem spiegelt jahrzehntelange regulatorische Anforderungen, bilaterale Airline-Abkommen, IATA-Standardrevisionen und Änderungen der Geschäftsregeln wider – allesamt nicht unabhängig vom implementierenden Code dokumentiert. Die Spezifikation ist die Implementierung. Würde man die Implementierung ohne Spezifikation ersetzen, müsste man das Verhalten des bestehenden Systems so umfassend beobachten, dass man rekonstruieren könnte, was die Spezifikation vorgesehen hätte. Dieser Prozess dauert Jahre und ist nie abgeschlossen, da die Beobachtung nie alle Sonderfälle erfassen kann.

Transaktionssemantik, die moderne Architekturen nur schwer nachbilden können. TPF bietet synchrone, atomare Transaktionsverarbeitung mit garantierter Konsistenz über den gesamten PNR, eine Sitzplatzreservierung, eine Passagierdatensatzaktualisierung, eine Zahlungsautorisierung und einen Bestätigungsdatensatz hinweg – alles wird entweder als eine einzige atomare Einheit gespeichert oder gar nicht. Die Nachbildung dieser Funktionalität in verteilten Microservices-Architekturen erfordert sorgfältige Orchestrierung, kompensierende Transaktionen und ein verteiltes Sperrenmanagement, das sowohl komplex als auch potenziell langsamer als das synchrone Mainframe-Äquivalent ist. Die Erfahrung der Luftfahrtindustrie zeigt, dass „eventuelle Konsistenz“ keine tolerierbare Eigenschaft für Sitzplatzbestände ist; ein überbuchter Flug ist ein konkreter, betrieblich katastrophaler Fehler und keine vorübergehende Inkonsistenz, die später behoben werden kann.

Die Integrationsfläche. Ein ausgereiftes Airline-PSS ist mit Hunderten externer Systeme verbunden: Abflugkontrolle, Revenue Management, Vielfliegerprogramme, Flughafensysteme, GDS-Anbindungen von Drittanbietern, Code-Share-Partner, Meldewesen und vieles mehr. Jede Verbindung hat spezifische Schnittstellenverträge, Nachrichtenformate, Timing-Anforderungen und Fehlerbehandlungsmechanismen, die vom bestehenden System implementiert wurden und auf denen jedes abhängige System basiert. Die Ablösung des PSS erfordert entweder die gleichzeitige Aufrechterhaltung aller bestehenden Schnittstellenverträge (was die Architektur des Ersatzsystems einschränkt) oder die Koordination der Änderungen mit jedem abhängigen System (was den Umfang über die Möglichkeiten eines einzelnen Programms hinaus erweitert).

Das Problem mit Echtzeitdaten. Flugreservierungen sind Echtzeitdaten – Buchungen, die Monate im Voraus getätigt werden und exakt wie gebucht eingehalten werden müssen. Es gibt keinen sauberen Übergangspunkt, an dem die Daten des alten Systems einfach zurückgelassen werden können. Die Migration muss alle Echtzeit-Buchungsnummern (PNRs) vom alten ins neue System übertragen, inklusive aller zugehörigen Regeln, Tarife, Einschränkungen und Zusatzleistungen. Die PNR-Migration im globalen Maßstab, ohne Datenverlust und mit der Garantie identischen Verhaltens, hat sich als eine der größten technischen Herausforderungen bei der Modernisierung von Unternehmen erwiesen.

Die architektonische Antwort: Modernisierung rund um den Kern

Der Ansatz, der sich bei Amadeus, Sabre und einzelnen Fluggesellschaften tatsächlich bewährt hat, besteht nicht in der Ersetzung, sondern in der strategischen Integration und schrittweisen Extraktion.

Durch API-Wrapping werden die zentralen Reservierungsfunktionen als moderne REST- oder SOAP-APIs bereitgestellt. So können neue Anwendungen über eine moderne Schnittstelle mit dem bestehenden System interagieren, ohne die Transaktionslogik zu verändern. Fluggesellschaften haben mobile Apps, Web-Buchungssysteme und Kundenservice-Tools auf Basis von API-Schichten entwickelt, die moderne Anfragen in TPF-Transaktionsaufrufe übersetzen und strukturierte Antworten zurückgeben. Das Terminal mit dem grünen Bildschirm wird durch eine moderne grafische Benutzeroberfläche ersetzt; die zugrundeliegende Transaktionsverarbeitung bleibt unverändert.

Strangler Fig für Nicht-Kernfunktionen. Funktionen, die an den Kern angrenzen – Umsatzmanagement, Kundenbindungsprogramm-Management, Reporting und Analysen, Personaleinsatzplanung – werden einzeln extrahiert und auf moderner Infrastruktur neu implementiert. Jede Extraktion reduziert den Umfang des Altsystems, ohne den Transaktionskern mit dem höchsten Risiko zu beeinträchtigen. Im Laufe von über einem Jahrzehnt inkrementeller Extraktion wandelt sich die Rolle des Altsystems von einer umfassenden Anwendungsplattform zu einer fokussierten Transaktions-Engine.

Cloud-Infrastruktur mit erhaltener Architektur. Die Stilllegung der Mainframes von Amadeus verlagerte Workloads in die Cloud-Infrastruktur, wobei die ursprünglich auf dem Mainframe implementierte Transaktionsarchitektur erhalten blieb. Die Hardware wurde zwar verändert, aber das Software-Design, das Datenmodell, die Transaktionssemantik und die PNR-Struktur blieben auf den über Jahrzehnte bewährten Architekturentscheidungen basieren.

Neues Angebots- und Auftragsmanagement neben dem bestehenden PNR-System. Der IATA ONE Order-Standard, der PNR-basierte Datensätze durch ein modernes Auftragsmanagementmodell ersetzt, wird von Fluggesellschaften als zusätzliche Ebene neben dem bestehenden PNR-basierten System implementiert. Die Angebots- und Auftragstechnologien der nächsten Generation von Sabre, die in der Vertragsverlängerung mit WestJet für 2026 erwähnt werden, positionieren dies als zukunftsweisenden Weg – nicht als Ersatz für das PSS, sondern als Ergänzung um eine moderne, kommerzielle Ebene, die zukünftig einen zunehmenden Anteil der Buchungen verarbeiten soll, während das PNR-Kernsystem den Rest übernimmt.

Was dies für jede missionskritische Legacy-Modernisierung bedeutet

Die Geschichte des Flugreservierungssystems ist kein Einzelfall in der Luftfahrt. Sie ist das sichtbarste Beispiel für ein Muster, das sich auch in Kernsystemen von Banken, der Verwaltung von Versicherungspolicen, der Abrechnung von Telekommunikationsdiensten und der Bearbeitung staatlicher Leistungen zeigt: Software, die zur maßgeblichen Spezifikation von Geschäftsregeln wird, als Integrationsdrehscheibe für Dutzende abhängiger Systeme dient und einen Umfang und eine Zuverlässigkeit erfordert, die einen kompletten Systemaustausch praktisch unmöglich machen.

Die Lehren sind branchenübergreifend einheitlich:

Die Extraktion von Geschäftsregeln aus dem Code vor Beginn jeglicher Modernisierung ist unerlässlich. Die COBOL- und TPF-Programme, die die Tarifberechnung, die Logik von Codeshare-Abkommen und die Vorschriften zur Einhaltung gesetzlicher Bestimmungen implementieren, sind die einzige verbliebene Dokumentation dieser Regeln. Eine Modernisierung, die diese Logik nicht zuvor extrahiert und validiert, kann keinen Ersatz liefern, der in allen Fällen korrekt funktioniert, da sie ohne die Analyse des gesamten Codes nicht alle Fälle kennen kann.

Die Abhängigkeitsmatrix bestimmt die Migrationsreihenfolge. Keine Fluggesellschaft hat ihr PSS erfolgreich ersetzt, indem sie mit der kritischsten und am stärksten integrierten Komponente begonnen hat. Jede erfolgreiche Modernisierung startete an den Rändern – den Berichtssystemen, den Zusatzdiensten und den nicht kritischen Verwaltungsfunktionen – und arbeitete sich schrittweise nach innen vor. Diese Reihenfolge ergibt sich aus dem Abhängigkeitsdiagramm: Komponenten mit den wenigsten eingehenden Abhängigkeiten können am sichersten zuerst angegangen werden.

Die Validierung des Betriebs in jedem Schritt ist unerlässlich. Nur der Ansatz der Validierung im Doppelbetrieb, bei dem das neue System parallel zum alten betrieben, die Ergebnisse verglichen und die Gleichwertigkeit vor der Umstellung des Datenverkehrs überprüft wird, erfüllt die Zuverlässigkeitsanforderungen von Systemen, deren Ausfälle physische, finanzielle und regulatorische Konsequenzen haben.

Wie SMART TS XL Gilt für die Analyse von Altsystemen im Umfeld von Fluggesellschaften.

Fluggesellschaften, die Sabre oder Amadeus PSS neben ihren eigenen COBOL-Programmen, Tarifberechnungssystemen, Umsatzbuchhaltung, Treuepunktberechnung und Meldepflichten betreiben, stehen vor genau derselben analytischen Herausforderung wie jedes Mainframe-Modernisierungsprogramm in Unternehmen: zu verstehen, was der Code tatsächlich enthält, bevor man entscheidet, was damit geschehen soll.

SMART TS XL statische Code-Analyse Die Extraktion der in COBOL-Programmen eingebetteten Geschäftslogik, der Tarifvalidierungsregeln, der Umsatzberechnungen und der Logik zur Berechtigung für Treueprogramme, die ausschließlich im Programmcode existiert, ist für Fluggesellschaften, die angrenzende Systeme modernisieren möchten, ohne den PSS-Kern anzutasten, unerlässlich. Diese Extraktion liefert die Spezifikation, die das Ersatzsystem erfüllen muss.

Die Abbildung der Anwendungsabhängigkeiten erstellt den Abhängigkeitsgraphen, der die Migrationsreihenfolge festlegt: Welche Programme der Fluggesellschaft hängen von welchen Datenfeeds des PSS ab, welche Reporting-Programme von welchen COBOL-Batch-Ausgaben und welche nachgelagerten Systeme müssen bei jeder Komponentenänderung aktualisiert werden. Dieser Abhängigkeitsgraph ermöglicht eine inkrementelle und sichere Modernisierung – denselben Ansatz, den Sabre und Amadeus für die Kernsysteme verwendet haben, nun aber auf den zugehörigen Code der Fluggesellschaft angewendet.

Die Auswirkungsanalyse beantwortet die Frage, die jeder Modernisierungsentscheidung vorausgeht: Wenn sich dieses Programm ändert, was wird sich sonst noch auswirken? Bei Airline-Systemen, bei denen eine Berechnungsänderung in einem Umsatzbuchhaltungsprogramm gleichzeitig Auswirkungen auf die Meldepflichten, die Partnerabrechnung und die Finanzkonsolidierung haben kann, ist die Kenntnis des Ausmaßes der Auswirkungen vor jeder Änderung die Voraussetzung für ein Änderungsmanagement, das die Zuverlässigkeitsanforderungen der Airline erfüllt.

Die Analyse der Legacy-Modernisierung liefert das vollständige Bestandsverzeichnis vor der Modernisierung: jedes Programm im Geltungsbereich, seine Komplexität, seine Abhängigkeiten, den Anteil an ungenutztem Code und die Risikoklassifizierung für die Migration. Die wichtigste Erkenntnis jedes Modernisierungsprogramms einer Fluggesellschaft – von den Rändern beginnen, sich nach innen vorarbeiten und jeden Schritt validieren – erfordert, dass man die Ränder und die Abhängigkeitsstruktur kennt. Dieses Wissen stammt aus der Strukturanalyse des tatsächlichen Codes, nicht aus Dokumentationen, die vor der Codeentwicklung erstellt wurden.

Die geologischen Schichten missionskritischer Software

Wenn Sie 2026 einen Flug mit Ihrem Smartphone buchen, interagieren Sie mit einer Software, die aus mehreren unterschiedlichen Schichten besteht. An der Oberfläche befindet sich die moderne Benutzeroberfläche. Darunter liegt die API-Schicht. Und darunter wiederum die PSS-Transaktions-Engine, die auf einer Infrastruktur läuft, die sich seit den 1960er-Jahren grundlegend verändert hat, aber Transaktionssemantik und Datenmodelle beibehält, die zum Zeitpunkt ihrer Entwicklung korrekt waren und sich als zu zuverlässig erwiesen haben, um sie aufzugeben.

Das Flugreservierungssystem ist kein Beispiel für gescheiterte Modernisierung. Es ist das Ergebnis von sechs Jahrzehnten rationaler Entscheidungen von Ingenieuren und Führungskräften, die bei jedem vorgeschlagenen Systemwechsel verstanden, dass das Risiko eines Fehlers die Kosten für den Erhalt des Bewährten überstieg. Die Systeme, die sich so lange bewährt haben, tun dies, weil sie sich Transaktion für Transaktion, Flug für Flug, Buchungssaison für Buchungssaison verdienen.

Die praktische Lehre für jedes Modernisierungsteam ist nicht, dass alte Systeme niemals ersetzt werden sollten. Vielmehr muss die Entscheidung für einen Austausch auf der Grundlage umfassender Kenntnisse über deren Inhalt, Abhängigkeiten und den tatsächlichen Umfang der Änderungen getroffen werden – nicht auf der Grundlage optimistischer Schätzungen, die vor der Komplexitätsanalyse erstellt wurden. Die Luftfahrtindustrie hat dies auf die teure Tour gelernt. Analysetools, die vollständiges Strukturwissen liefern, bevor die erste Zeile neuen Codes geschrieben wird, ermöglichen es, diese Lektion kostengünstiger zu lernen.