Flyreservationssystemer: Hvorfor de stadig er på mainframes

Når du booker en flyrejse på en smartphone i 2026, passerer din anmodning gennem flere lag af moderne teknologi, en mobilapp, en webtjeneste og en betalingsprocessor, før den når frem til det system, der rent faktisk reserverer dit sæde. Dette system er i de fleste tilfælde software med rødder i 1960'erne, der kører på en infrastruktur, som rejsebranchen har forsøgt at erstatte i årtier uden fuldt ud at have formået at gøre det. Sabre, Amadeus og Travelport håndterer tilsammen stort set alle flybookinger på Jorden. Tilsammen behandler de milliarder af transaktioner årligt på tværs af hundredvis af flyselskaber, tusindvis af rejsebureauer og realtidsbeholdninger, der spænder over millioner af sædekombinationer. Den ældste af dem kan spores tilbage til en IBM-mainframe fra 1964, der reserverede fra 90 minutter til blot sekunder og ændrede den kommercielle luftfart permanent.

Historien om, hvorfor disse systemer forbliver, hvor de er, er ikke en historie om organisatorisk inerti eller ingeniørkonservatisme. Det er en historie om, hvad der sker, når software bliver så dybt forankret i en missionskritisk driftsproces, at omkostningerne og risikoen ved at erstatte den ikke kan retfærdiggøres ud fra nogen realistisk tidslinje, og hvordan branchen har reageret ved at modernisere omkring kernen i stedet for at forsøge at erstatte den. For alle, der arbejder med storstilet modernisering af ældre systemer, er flyreservationssystemer det klareste casestudie, der findes, for, hvad "too important to fail" betyder i praksis.

Oprindelsen: Hvorfor mainframes vandt flyselskabsproblemet

Det oprindelige SABRE (Semi-Automated Business Research Environment) var ikke et produkt, men en skræddersyet løsning på en specifik driftskrise. I slutningen af ​​1950'erne voksede American Airlines hurtigere, end deres manuelle reservationssystem kunne håndtere. Reservation af et sæde krævede et telefonopkald, en manuel kontrol af et fysisk lagerkort, en reservation, et tilbagekald og en papirregistrering, en proces, der i gennemsnit tog 90 minutter pr. booking og ikke kunne skaleres.

Da SABRE blev fuldt operationelt i 1964, bygget på to IBM 7090 mainframes og forbundet til 1,500 terminaler i USA og Canada, kunne det behandle 7,500 reservationer i timen med næsten nul fejlrater. For første gang kunne et flyselskab vedligeholde sædeoversigt i realtid, gemme komplette passagerregistre og muliggøre øjeblikkelige bookinger på tværs af hele sit netværk. Reservationstiderne faldt fra 90 minutter til sekunder.

Det arkitektoniske valg, der gjorde dette muligt, centraliseret transaktionsbehandling på mainframe-hardware, blev ikke valgt af filosofiske årsager. Det blev valgt, fordi det var den eneste arkitektur, der var tilgængelig i 1964, og som kunne opfylde kravene til latenstid, pålidelighed og samtidig adgang i realtidsstyring af flyselskabers lagerbeholdning. Og det fungerede så godt, at det blev den arkitektoniske skabelon, som alle efterfølgende flyreservationssystemer blev bygget på.

IBMs Transaction Processing Facility (TPF), oprindeligt designet til SABRE, blev driftsmiljøet for hele kategorien. Næsten alle de største banker, forsikringsselskaber, detailhandlere og flyselskaber bruger det stadig, ifølge IBM. Da Amadeus blev grundlagt i 1987, byggede de på TPF. Da Galileo (nu Travelport) lancerede deres GDS, byggede de på TPF. Tre generationer af passagerservicesystemer eksisterer nu side om side i kommerciel luftfart, og mange kører stadig på TPF-mainframes, ikke fordi teknologien aldrig er blevet sat spørgsmålstegn ved, men fordi den transaktionshastighed, pålidelighed og fejltolerance, som TPF leverer på mainframe-hardware, har vist sig at være virkelig vanskelig at replikere i tilsvarende skala på alternative arkitekturer.

Hvad disse systemer rent faktisk gør i stor skala

Skalaen, hvorpå flyreservationssystemer fungerer, er ikke intuitivt forståelig fra et softwareudviklingsperspektiv. Et globalt distributionssystem håndterer ikke kun sædetilgængelighed, det styrer også et kombinatorisk lagerproblem af svimlende kompleksitet.

En enkelt transatlantisk flyvning har hundredvis af billetklasser. Hver billetklasse har specifikke regler: krav til forudbetaling, minimumsophold, datoer uden gyldighed, ændringsgebyrer, tilladte eller ej mellemlandinger, codeshare-aftaler med partnerflyselskaber. En booking, der involverer to flyselskaber, en forbindelse og en returflyvning, skaber en matrix af potentielt tusindvis af gyldige billetkombinationer, der skal kontrolleres, prissættes og holdes op mod realtidsbeholdningen, før der returneres et svar, typisk på under et sekund.

I perioder med spidsbelastning behandler Sabre og Amadeus tilsammen titusindvis af transaktioner i sekundet. Ikke i minuttet. I sekundet. Hver transaktion involverer opslag i realtid, evaluering af billetregler, oprettelse eller ændring af PNR (Passenger Name Record) og koordinering med afgangskontrol, frequent flyer og tilhørende servicesystemer. Den garanterede svartid måles i millisekunder, fordi et rejsebureau eller en bookingmotor, der venter mere end et par sekunder på en billetkontrol, vil få timeout og enten forsøge igen eller afbryde transaktionen.

TPF på mainframe-hardware leverer denne kapacitet med en fejlrate, som IT-professionelle fra andre brancher har svært ved at tro på. Mainframens fejltolerance, redundante processorer, hot-swap-komponenter og årtiers hærdede operativsystemkode producerer en tilgængelighed på fem ni som en standard driftsparameter, ikke et ambitiøst mål. At replikere dette til tilsvarende omkostninger på cloud-infrastruktur har været den centrale tekniske udfordring for ethvert IT-moderniseringsprogram for flyselskaber, der er blevet forsøgt siden 1990'erne.

Moderniseringsforsøgene: Hvad de årtilange programmer faktisk fandt ud af

Historien om moderniseringen af ​​flyreservationssystemer er en historie om programmer, der satte sig for at erstatte kernen og år senere nåede frem til en hybrid, der i stedet indkapslede kernen.

American Airlines' Jetstream-projekt, der blev lanceret i 2000'erne med det eksplicitte mål at erstatte Sabre-mainframe-PSS'en, blev afsluttet med en implementering af et nyt Sabre-produkt i stedet for at bygge et alternativ. Den oprindelige antagelse om at bygge en erstatning internt ville producere et bedre system hurtigere, stødte på den samme realitet, som næsten alle store, ældre udskiftningsprogrammer støder på: det eksisterende system indeholdt krav, som ingen kendte til, før erstatningen ikke kunne opfylde dem.

Vi er nødt til at komme dybere ned i stakken, ændre kernesystemet og afkoble reglerne, så vi kan ændre dem hurtigt. Denne udtalelse fra American Airlines' IT-ledelse under Jetstream-programmet beskriver problemet præcist. Reglerne, der er indlejret i det gamle system, billetpriskonstruktionslogikken, implementeringen af ​​codeshare-aftaler, beregningerne af overholdelse af regler og integrationen af ​​indtægtsstyring, var akkumuleret over årtiers forretningsændringer og var ikke dokumenteret i nogen form, der gjorde dem udtrækkelige uden at køre det eksisterende system og observere dets adfærd.

Sabres eget moderniseringsprogram, der for alvor begyndte i 2010'erne, tog mere end et årti og kostede milliarder af dollars at flytte størstedelen af ​​deres kode væk fra den lokale mainframe-infrastruktur. I 2019 kørte cirka 11 procent af Sabres kode stadig i lokale datacentre, mens resten var migreret. I februar 2026 fornyede Sabre sin langsigtede PSS-aftale med WestJet, hvilket demonstrerede, at selv efter et årtis moderniseringsindsats og milliardinvesteringer er PSS fortsat det kommercielle fundament for virksomheden.

Amadeus opnåede en mere komplet nedlukning af mainframes og nåede en milepæl med at udfase sine sidste mainframes til fordel for cloud-infrastruktur. Men Amadeus' tilgang, hvor de trinvist udskiftede funktionelle komponenter, samtidig med at de opretholdt den centrale datamodel og transaktionsarkitektur, bevarede effektivt de arkitektoniske beslutninger, der opstod på mainframen, selvom hardwaren ændrede sig. Transaktionssemantikken, PNR-strukturen og lagerstyringslogikken: disse blev flyttet til moderne infrastruktur, mens de bevarede deres grundlæggende design.

Hvorfor udskiftning er sværere end det ser ud til: Den skjulte kompleksitet

Standardforklaringen på, hvorfor flyreservationssystemer fortsætter på mainframes, er omkostninger og risiko. Begge dele er reelle. Men de er symptomer på en dybere teknisk virkelighed, der er værd at forstå præcist, fordi den gælder for ethvert missionskritisk moderniseringsprogram for ældre systemer.

Forretningsregler, der kun findes i koden. Billetpriskonstruktionslogikken i et globalt distributionssystem repræsenterer årtiers regulatoriske krav, bilaterale luftfartsaftaler, revisioner af IATA-standarder og ændringer af forretningsregler, hvoraf ingen er dokumenteret i nogen form, der er uafhængig af den kode, der implementerer dem. Specifikationen er implementeringen. At erstatte implementeringen uden specifikationen betyder at observere det eksisterende systems adfærd udtømmende nok til at rekonstruere, hvad specifikationen ville have sagt, en proces, der tager år og aldrig er fuldstændig, fordi observationsdækningen aldrig kan være omfattende nok til at fange alle marginale tilfælde.

Transaktionssemantik, som moderne arkitekturer har svært ved at replikere. TPF leverer synkron, atomar transaktionsbehandling med garanteret konsistens på tværs af hele PNR, en sædereservation, en opdatering af passagerregistreringer, en betalingsautorisation og en bekræftelsesregistrering, der alle committes som en enkelt atomar enhed eller slet ikke. Replikering af dette på distribuerede mikroservicearkitekturer kræver omhyggelig orkestrering, kompenserende transaktioner og distribueret låsestyring, der er både kompleks og potentielt langsommere end den synkrone mainframe-ækvivalent. Flybranchens erfaring er, at "i sidste ende konsistent" ikke er en acceptabel egenskab for sædebeholdning. En oversolgt flyvning er en konkret, operationelt katastrofal fejl, ikke en midlertidig inkonsistens, der skal løses senere.

Integrationsoverfladen. Et modent flyselskabs PSS er forbundet til hundredvis af eksterne systemer: afgangskontrol, indtægtsstyring, frequent flyer, lufthavnssystemer, tredjeparts GDS-forbindelser, codeshare-partnere, regulatorisk rapportering og mere. Hver forbindelse har specifikke grænsefladekontrakter, meddelelsesformater, timingkrav, fejlhåndteringsadfærd, som det eksisterende system har implementeret, og som alle afhængige systemer er bygget op omkring. Udskiftning af PSS kræver enten samtidig vedligeholdelse af alle eksisterende grænsefladekontrakter (hvilket begrænser erstatningsarkitekturen) eller koordinering af ændringer med alle afhængige systemer (hvilket udvider omfanget ud over, hvad et enkelt program kan håndtere).

Problemet med live-data. Flyreservationer er live-data, bookinger foretaget måneder i forvejen, som skal respekteres præcis som booket. Der er intet rent overgangspunkt, hvor det gamle systems data kan efterlades. Migreringen skal overføre alle live PNR-oplysninger fra det gamle system til det nye, med alle tilhørende regler, priser, begrænsninger og tilhørende tjenester intakte. PNR-migrering på globalt plan, med nul datatab og garanti for identisk adfærd, har vist sig at være et af de sværeste tekniske problemer i moderniseringen af ​​virksomheder.

Det arkitektoniske svar: Moderniser omkring kernen

Den tilgang, der rent faktisk har haft succes hos Amadeus, Sabre og individuelle flyselskaber, er ikke erstatning, men strategisk indpakning og trinvis udvinding.

API-indpakning eksponerer de centrale reservationsfunktioner som moderne REST- eller SOAP-API'er, hvilket giver nye applikationer mulighed for at interagere med det ældre system via en moderne brugerflade uden at røre den centrale transaktionslogik. Flyselskaber har bygget mobilapps, webbookingmotorer og kundeserviceværktøjer oven på API-lag, der oversætter moderne anmodninger til TPF-transaktionsopkald og returnerer strukturerede svar. Green-screen-terminalen er erstattet af en moderne GUI; den underliggende transaktionsbehandling er uændret.

Strangler Fig for ikke-kernefunktioner. Funktioner, der støder op til kernen, indtægtsstyring, loyalitetsprogramstyring, rapportering og analyse, bemandingsplanlægning, udtrækkes én ad gangen og genimplementeres på moderne infrastruktur. Hver udtrækning reducerer det ældre systems fodaftryk uden at røre den transaktionskerne, der har den højeste risiko. Over et årti med trinvis udtrækning indsnævres det ældre systems rolle fra en altomfattende applikationsplatform til en fokuseret transaktionsmotor.

Cloud-infrastruktur med bevaret arkitektur. Amadeus' mainframe-afvikling flyttede arbejdsbyrder til cloud-infrastruktur, samtidig med at den transaktionsarkitektur, der oprindeligt var på mainframen, blev bevaret. Hardwaren ændrede sig; softwaredesignet, datamodellen, transaktionssemantikken, PNR-strukturen, og de arkitektoniske beslutninger, der havde vist sig korrekte gennem årtier, blev bevaret.

Ny tilbuds- og ordrehåndtering sammen med den ældre PNR-løsning. IATA ONE Order-standarden, som erstatter PNR-baserede poster med en moderne ordrehåndteringsmodel, implementeres af flyselskaber som et lag sammen med det eksisterende PNR-baserede system. Sabres næste generations tilbuds- og ordreteknologier, som der henvises til i WestJet-fornyelsen i 2026, positionerer dette som vejen frem, ikke som en erstatning for PSS, men som en tilføjelse af et moderne kommercielt lag, der med tiden vokser til at håndtere en stigende andel af bookinger, mens PNR-kernen håndterer resten.

Hvad dette betyder for enhver missionskritisk modernisering af ældre systemer

Historien om flyreservationssystemer er ikke unik for luftfart. Det er det mest synlige eksempel på et mønster, der ses i bankkernesystemer, administration af forsikringspolicer, telekommunikationsfakturering og behandling af offentlige ydelser: software, der bliver den autoritative specifikation af forretningsregler, fungerer som integrationscenter for snesevis af afhængige systemer og opererer i en skala og et pålidelighedskrav, der gør en "big bang"-erstatning virkelig umulig.

Lektionerne er ensartede på tværs af alle brancher:

Det er ikke valgfrit at udtrække forretningsregler fra koden, før en eventuel modernisering påbegyndes. COBOL- og TPF-programmerne, der implementerer billetkonstruktion, logik for codeshare-aftaler og regler for overholdelse af regler, er den eneste overlevende dokumentation af disse regler. Modernisering, der ikke først udtrækker og validerer denne logik, kan ikke producere en erstatning, der opfører sig korrekt i alle tilfælde, fordi den ikke kan kende alle tilfælde uden at analysere al koden.

Afhængighedskortet bestemmer migreringssekvensen. Intet flyselskab har med succes erstattet sit PSS ved at starte med den mest kritiske og mest integrerede komponent. Enhver vellykket modernisering startede i kanterne, rapporteringssystemerne, hjælpetjenesterne, de ikke-kritiske administrative funktioner og arbejdede sig indad trinvist. Denne sekvens er afledt af afhængighedsgrafen: hvilke komponenter der har færrest indgående afhængigheder er sikrest at adressere først.

Operationel validering i hvert trin er ufravigelig. Den dobbelte valideringstilgang, hvor det nye system køres parallelt med det gamle, output sammenlignes og ækvivalens valideres, før trafik flyttes, er den eneste tilgang, der opfylder pålidelighedskravene i systemer, hvor fejl har fysiske, økonomiske og lovgivningsmæssige konsekvenser.

Hvordan SMART TS XL Gælder for analyse af ældre flyselskaber tilstødende

Flyselskaber, der kører Sabre eller Amadeus PSS sammen med deres egne COBOL-programmer, prisberegningssystemer, omsætningsregnskaber, loyalitetspointberegninger og lovgivningsmæssige rapporteringer, har præcis den samme analytiske udfordring, som alle moderne mainframe-programmer til virksomheder står over for: at forstå, hvad koden rent faktisk indeholder, før man beslutter, hvad man skal gøre med den.

SMART TS XL's statisk kodeanalyse udtrækker forretningsregellogikken, der er indlejret i COBOL-programmer, billetvalideringsreglerne, indtægtsregnskabsberegningerne og loyalitetsniveauberettigelseslogikken, som ikke findes andre steder end i programkoden. For flyselskaber, der planlægger at modernisere tilstødende systemer uden at røre PSS-kernen, producerer denne udtrækning den specifikation, som udskiftningen skal matche.

Applikationsafhængighedskortlægningen opbygger den afhængighedsgraf , der bestemmer migreringssekvensen: hvilke flyselskabsprogrammer afhænger af hvilke datafeeds fra PSS, hvilke rapporteringsprogrammer afhænger af hvilke COBOL-batchoutput, og hvilke downstream-systemer der skal opdateres, når en komponent ændres. Afhængighedsgrafen er det, der muliggør trinvis, sikker modernisering, den samme tilgang, som Sabre og Amadeus har brugt til kernesystemerne, anvendt på den flyselskabskode, der omgiver dem.

Effektanalysefunktionen besvarer det spørgsmål , der går forud for enhver moderniseringsbeslutning: Hvis dette program ændres, hvad vil så ellers blive påvirket? For flyselskabssystemer, hvor en beregningsændring i et indtægtsregnskabsprogram kan påvirke lovgivningsmæssig rapportering, partnerafregning og økonomisk konsolidering samtidig, er det en forudsætning for ændringskontrol, der opfylder flyselskabets pålidelighedskrav, at man kender effektens omfang, før der foretages ændringer.

Analysen af ​​den ældre modernisering giver den komplette opgørelse over tiden før moderniseringen: hvert program i sin omfang, dets kompleksitet, dets afhængigheder, dets procentdel af død kode og dets migrationsrisikoklassificering. Lærdommen fra ethvert moderniseringsprogram for luftfartsselskaber – start ved kanterne, arbejd indad, validér i hvert trin – kræver viden om, hvor kanterne er, og hvordan afhængighedsstrukturen ser ud. Denne viden kommer fra strukturel analyse af den faktiske kode, ikke fra dokumentation, der blev skrevet, før koden udviklede sig væk fra den.

De geologiske lag i missionskritisk software

Når du booker en flyrejse på en smartphone i 2026, rører du ved software med flere forskellige geologiske lag. Den moderne grænseflade på overfladen. API-laget nedenunder. PSS-transaktionsmotoren nedenunder, der kører på en infrastruktur, der har ændret sig væsentligt siden 1960'erne, men som bevarer transaktionssemantik og datamodeller, der var korrekte, da de blev designet, og som har vist sig at være for pålidelige til at opgive.

Flyreservationssystemet er ikke en fiasko ved modernisering. Det er resultatet af seks årtiers rationelle beslutninger foretaget af ingeniører og ledere, der hver gang en erstatning blev foreslået, forstod, at risikoen for at gøre det forkert oversteg omkostningerne ved at beholde det, der fungerede. De systemer, der overlever så længe, ​​gør det, fordi de fortjener det, transaktion for transaktion, flyvning for flyvning, bookingsæson for bookingsæson.

Den praktiske lektie for ethvert moderniseringsteam er ikke, at gamle systemer aldrig bør udskiftes. Det er, at beslutningen om at erstatte dem bør træffes med fuldstændig viden om, hvad de indeholder, hvad der afhænger af dem, og hvad det fulde omfang af forandringen faktisk er, ikke med optimistiske estimater foretaget, før kompleksiteten blev målt. Flybranchen lærte dette på den dyre måde. De analyseværktøjer, der producerer fuldstændig strukturel viden, før den første linje ny kode er skrevet, er det, der gør det muligt at lære det på den billigere måde.