När du bokar ett flyg på en smartphone år 2026 passerar din förfrågan genom flera lager av modern teknik, en mobilapp, en webbtjänst och en betalningsprocessor innan den anländer till det system som faktiskt reserverar din plats. Det systemet är i de flesta fall programvara med rötter i 1960-talet, som körs på infrastruktur som resebranschen har försökt ersätta i årtionden utan att helt lyckas med det. Sabre, Amadeus och Travelport hanterar tillsammans i princip alla flygbokningar på jorden. Tillsammans bearbetar de miljarder transaktioner årligen över hundratals flygbolag, tusentals resebyråer och realtidsinventering som spänner över miljontals sittplatskombinationer. Den äldsta av dem kan spåras tillbaka till en IBM-stordator från 1964 som reserverar från 90 minuter till bara några sekunder och förändrade den kommersiella flygindustrin permanent.
Berättelsen om varför dessa system ligger kvar där de är är inte en berättelse om organisatorisk tröghet eller ingenjörskonservatism. Det är en berättelse om vad som händer när programvara blir så djupt inbäddad i en verksamhetskritisk operativ process att kostnaden och risken för att ersätta den inte kan motiveras mot någon realistisk tidslinje, och hur branschen har reagerat genom att modernisera runt kärnan snarare än att försöka ersätta den. För alla som arbetar med storskalig modernisering av äldre system är flygbokningssystem den tydligaste tillgängliga fallstudien för vad "för viktigt för att misslyckas" betyder i praktiken.
Arbeta inåt. Känn till beroendegrafen.
SMART TS XL extraherar affärsregler, beroendekartor och död kod över COBOL och äldre program.
TA REDA PÅ MER…Ursprunget: Varför stordatorer vann flygproblemet
Den ursprungliga SABRE (Semi-Automated Business Research Environment) var inte en produkt, det var en skräddarsydd lösning för en specifik operativ kris. I slutet av 1950-talet växte American Airlines snabbare än deras manuella bokningssystem kunde hantera. Att boka en plats krävde ett telefonsamtal, en manuell kontroll av en fysisk inventarielista, en reservation, en återuppringning och en pappersjournal, en process som i genomsnitt tog 90 minuter per bokning och som inte lyckades skalas upp.
När SABRE blev fullt operativt 1964, byggt på två IBM 7090-stordatorer och anslutet till 1 500 terminaler i USA och Kanada, kunde det behandla 7 500 bokningar per timme med nästan noll felfrekvens. För första gången kunde ett flygbolag hålla koll på sittplatserna i realtid, lagra fullständiga passagerarregister och möjliggöra omedelbara bokningar över hela sitt nätverk. Bokningstiderna minskade från 90 minuter till sekunder.
Det arkitekturval som gjorde detta möjligt, centraliserad transaktionsbehandling på stordatorhårdvara, valdes inte av filosofiska skäl. Det valdes eftersom det var den enda arkitekturen som var tillgänglig 1964 och som kunde uppfylla kraven på latens, tillförlitlighet och samtidig åtkomst för realtidshantering av flygbolagens lager. Och det fungerade så bra att det blev den arkitekturmall som alla efterföljande flygbokningssystem byggdes på.
IBMs Transaction Processing Facility (TPF), ursprungligen designad för SABRE, blev driftsmiljön för hela kategorin. Nästan alla de största bankerna, försäkringsbolagen, återförsäljarna och flygbolagen använder den fortfarande, enligt IBM. När Amadeus grundades 1987 byggde de på TPF. När Galileo (nu Travelport) lanserade sitt GDS byggde de på TPF. Tre generationer av passagerarservicesystem samexisterar nu inom kommersiell flygindustri, och många körs fortfarande på TPF-stordatorer, inte för att tekniken aldrig har ifrågasatts, utan för att transaktionsgenomströmningen, tillförlitligheten och feltoleransen som TPF levererar på stordatorhårdvara har visat sig vara genuint svår att replikera i motsvarande skala på alternativa arkitekturer.
Vad dessa system faktiskt gör i stor skala
Den skala i vilken flygbokningssystem fungerar är inte intuitivt begriplig ur ett mjukvaruutvecklingsperspektiv. Ett globalt distributionssystem hanterar inte bara sittplatstillgänglighet, det hanterar också ett kombinatoriskt lagerproblem av häpnadsväckande komplexitet.
En enskild transatlantisk flygning har hundratals biljettklasser. Varje biljettklass har specifika regler: krav på förköp, minimivistelse, avstängningsdatum, ändringsavgifter, tillåtna eller inte mellanlandningar, codeshare-avtal med partnerflygbolag. En bokning som involverar två flygbolag, en anslutning och en tur- och returresa skapar en matris av potentiellt tusentals giltiga biljettkombinationer som måste kontrolleras, prissättas och hållas mot realtidslager innan ett svar returneras, vanligtvis på under en sekund.
Under bokningstoppar behandlar Sabre och Amadeus tillsammans tiotusentals transaktioner per sekund. Inte per minut. Per sekund. Varje transaktion involverar realtidssökning av lager, utvärdering av biljettregler, skapande eller ändring av PNR (Passenger Name Record) och samordning med avgångskontroll, bonussystem och system för tilläggstjänster. Den garanterade svarstiden mäts i millisekunder, eftersom en resebyrå eller bokningsmotor som väntar i mer än några sekunder på en biljettkontroll kommer att få timeout och antingen försöka igen eller avbryta transaktionen.
TPF på stordatorer levererar denna dataflödeshastighet med en felfrekvens som IT-proffs från andra branscher har svårt att tro. Stordatorernas feltolerans, redundanta processorer, hot-swap-komponenter och årtionden av härdad operativsystemkod, producerar en tillgänglighet på fem nior som en standard driftsparameter, inte ett ambitiöst mål. Att replikera detta till motsvarande kostnad på molninfrastruktur har varit den centrala tekniska utmaningen för varje IT-moderniseringsprogram inom flygbolag som försökts sedan 1990-talet.
Moderniseringsförsöken: Vad de decennielånga programmen faktiskt fann
Historien om moderniseringen av flygbokningssystem är en historia av program som syftade till att ersätta kärnan och som, år senare, kom fram till en hybrid som istället omslöt kärnan.
American Airlines Jetstream-projekt, som lanserades på 2000-talet med det uttryckliga målet att ersätta Sabres stordatorsystem (PSS), avslutades med att man antog en ny Sabre-produkt snarare än att bygga ett alternativ. Det ursprungliga antagandet om att bygga kontra köpa, att bygga en ersättning internt skulle ge ett bättre system snabbare, stötte på samma verklighet som nästan alla storskaliga äldre ersättningsprogram möter: det befintliga systemet innehöll krav som ingen kände till förrän ersättningen inte kunde uppfylla dem.
Vi måste gå djupare in i stacken och ändra kärnmotorn och frikoppla reglerna så att vi kan ändra dem snabbt. Det uttalandet, från American Airlines IT-ledning under Jetstream-programmet, beskriver problemet exakt. Reglerna som är inbäddade i det gamla systemet, logiken för biljettkonstruktion, implementeringar av codeshare-avtal, beräkningar av regelefterlevnad och integrationer med intäktshantering, hade ackumulerats under årtionden av affärsförändringar och var inte dokumenterade i någon form som gjorde dem extraherbara utan att köra det befintliga systemet och observera dess beteende.
Sabres eget moderniseringsprogram, som på allvar började på 2010-talet, tog mer än ett decennium och kostade miljarder dollar att flytta majoriteten av sin kod från den lokala stordatorinfrastrukturen. Från och med 2019 kördes ungefär 11 procent av Sabres kod fortfarande i lokala datacenter, medan resten hade migrerat. I februari 2026 förnyade Sabre sitt långsiktiga PSS-avtal med WestJet, vilket visar att även efter ett decennium av moderniseringsinsatser och miljardinvesteringar är PSS fortfarande den kommersiella grunden för verksamheten.
Amadeus uppnådde en mer fullständig avveckling av stordatorer och nådde milstolpen att pensionera sina sista stordatorer till förmån för molninfrastruktur. Men Amadeus tillvägagångssätt, att stegvis ersätta funktionella komponenter samtidigt som den grundläggande datamodellen och transaktionsarkitekturen bibehölls, bevarade effektivt de arkitekturbeslut som ursprungligen togs på stordatorn även när hårdvaran ändrades. Transaktionssemantiken, PNR-strukturen, lagerhanteringslogiken: dessa flyttades till modern infrastruktur samtidigt som de behöll sin grundläggande design.
Varför ersättning är svårare än det ser ut: Den dolda komplexiteten
Standardförklaringen till varför flygbokningssystem finns kvar på stordatorer är kostnad och risk. Båda är verkliga. Men de är symptom på en djupare teknisk verklighet som är värd att förstå exakt, eftersom den gäller alla verksamhetskritiska moderniseringsprogram för äldre system.
Affärsregler som endast finns i koden. Logiken för biljettpriskonstruktionen i ett globalt distributionssystem representerar årtionden av myndighetskrav, bilaterala flygbolagsavtal, revideringar av IATA-standarder och ändringar av affärsregler, av vilka ingen är dokumenterad i någon form som är oberoende av koden som implementerar dem. Specifikationen är implementeringen. Att ersätta implementeringen utan specifikationen innebär att observera det befintliga systemets beteende tillräckligt uttömmande för att rekonstruera vad specifikationen skulle ha sagt, en process som tar år och aldrig är fullständig, eftersom observationstäckningen aldrig kan vara tillräckligt omfattande för att fånga varje marginalfall.
Transaktionssemantik som moderna arkitekturer kämpar med att replikera. TPF tillhandahåller synkron, atomär transaktionsbehandling med garanterad konsekvens över hela PNR, en platsreservation, en uppdatering av passagerarregister, en betalningsauktorisering och en bekräftelsepost, alla allokerade som en enda atomär enhet eller inte alls. Att replikera detta på distribuerade mikrotjänstarkitekturer kräver noggrann orkestrering, kompenserande transaktioner och distribuerad låshantering som är både komplex och potentiellt långsammare än den synkrona stordatormotsvarigheten. Flygbranschens erfarenhet är att "så småningom konsekvent" inte är en acceptabel egenskap för sittplatsinventering, en översåld flygning är ett konkret, operativt katastrofalt fel, inte en tillfällig inkonsekvens som ska lösas senare.
Integrationsytan. Ett moget flygbolags PSS är anslutet till hundratals externa system: avgångskontroll, intäktshantering, bonussystem, flygplatssystem, tredjeparts GDS-anslutningar, codeshare-partners, regulatorisk rapportering med mera. Varje anslutning har specifika gränssnittsavtal, meddelandeformat, tidskrav, felhanteringsbeteenden, som det befintliga systemet har implementerat och som varje beroende system har byggts kring. Att ersätta PSS kräver antingen att alla befintliga gränssnittsavtal underhålls samtidigt (vilket begränsar ersättningsarkitekturen) eller att ändringar koordineras med varje beroende system (vilket utökar omfattningen bortom vad ett enskilt program kan hantera).
Problemet med livedata. Flygbokningar är livedata, bokningar som görs månader i förväg och som måste uppfyllas exakt som de bokats. Det finns ingen enkel övergångspunkt där det gamla systemets data kan lämnas kvar. Migreringen måste överföra alla live-PNR-uppgifter från det gamla systemet till det nya, med alla tillhörande regler, biljettpriser, begränsningar och tilläggstjänster intakta. PNR-migrering på global skala, med noll dataförlust och garanti för identiskt beteende, har visat sig vara ett av de svåraste tekniska problemen vid modernisering av företag.
Det arkitektoniska svaret: Modernisera runt kärnan
Den strategi som faktiskt har lyckats, hos Amadeus, hos Sabre och hos enskilda flygbolag, är inte ersättning utan strategisk omslagning och stegvis utvinning.
API-omslag exponerar de centrala bokningsfunktionerna som moderna REST- eller SOAP-API:er, vilket gör att nya applikationer kan interagera med det äldre systemet via ett modernt gränssnitt utan att vidröra den centrala transaktionslogiken. Flygbolag har byggt mobilappar, webbbokningsmotorer och kundtjänstverktyg ovanpå API-lager som översätter moderna förfrågningar till TPF-transaktionsanrop och returnerar strukturerade svar. Grönskärmsterminalen har ersatts av ett modernt grafiskt gränssnitt; den underliggande transaktionsbehandlingen är oförändrad.
Strangler Fig för icke-kärnfunktioner. Funktioner som ligger intill kärnan, intäktshantering, lojalitetsprogramhantering, rapportering och analys, samt schemaläggning av personal, extraheras en i taget och implementeras på nytt i modern infrastruktur. Varje extraktion minskar det äldre systemets fotavtryck utan att vidröra den transaktionskärna som har högst risk. Under ett decennium av stegvis extraktion har det äldre systemets roll minskat från en heltäckande applikationsplattform till en fokuserad transaktionsmotor.
Molninfrastruktur med bevarad arkitektur. Amadeus avveckling av stordatorer flyttade arbetsbelastningar till molninfrastrukturen samtidigt som transaktionsarkitekturen som ursprungligen var stordatorn bevarades. Hårdvaran förändrades; programvarudesignen, datamodellen, transaktionssemantiken, PNR-strukturen, bevarade de arkitekturbeslut som hade visat sig vara korrekta under årtionden.
Ny erbjudande- och orderhantering vid sidan av äldre PNR-system. IATA ONE Order-standarden, som ersätter PNR-baserade register med en modern orderhanteringsmodell, implementeras av flygbolag som ett lager vid sidan av det befintliga PNR-baserade systemet. Sabres nästa generations erbjudande- och orderteknik, som refererades till i WestJet-förnyelsen 2026, positionerar detta som vägen framåt, inte en ersättning för PSS, utan ett tillägg av ett modernt kommersiellt lager som så småningom växer för att hantera en ökande andel bokningar medan PNR-kärnan hanterar resten.
Vad detta innebär för all affärskritisk modernisering av äldre system
Historien om flygbokningssystem är inte unik för flygbranschen. Det är det mest synliga exemplet på ett mönster som syns i banksystem, försäkringsadministration, telekommunikationsfakturering och hantering av statliga förmåner: programvara som blir den auktoritativa specifikationen för affärsregler, fungerar som integrationsnav för dussintals beroende system och drivs i en skala och tillförlitlighetskrav som gör en "big bang"-ersättning verkligt omöjlig.
Lärdomarna är konsekventa i alla branscher:
Att extrahera affärsregler från koden, innan någon modernisering påbörjas, är inte valfritt. COBOL- och TPF-programmen som implementerar biljettkonstruktion, logik för codeshare-avtal och regler för regelefterlevnad är den enda bevarade dokumentationen av dessa regler. Modernisering som inte först extraherar och validerar denna logik kan inte producera en ersättning som beter sig korrekt i alla fall, eftersom den inte kan känna till alla fall utan att analysera all kod.
Beroendekartan avgör migreringssekvensen. Inget flygbolag har framgångsrikt ersatt sitt PSS genom att börja med den mest kritiska och mest integrerade komponenten. Varje framgångsrik modernisering började i kanterna, rapporteringssystemen, stödtjänsterna, de icke-kritiska administrativa funktionerna och arbetade sig inåt stegvis. Den sekvensen härleds från beroendediagrammet: vilka komponenter som har minst antal inkommande beroenden är säkrast att åtgärda först.
Operativ validering i varje steg är inte förhandlingsbar. Den dubbla valideringsmetoden, där det nya systemet körs parallellt med det gamla, utdata jämförs och ekvivalensen valideras innan någon trafik flyttas, är den enda metoden som uppfyller tillförlitlighetskraven för system där fel har fysiska, ekonomiska och regulatoriska konsekvenser.
Hur SMART TS XL Gäller för analys av äldre företag i anslutning till flygbolag
Flygbolag som kör Sabre eller Amadeus PSS tillsammans med sina egna COBOL-program, prisberäkningssystem, intäktsredovisning, lojalitetspoängberäkning och regulatorisk rapportering har exakt samma analytiska utmaning som alla moderniseringsprogram för stordatorer i företag står inför: att förstå vad koden faktiskt innehåller innan man bestämmer sig för vad man ska göra med den.
SMART TS XLÄr statisk kodanalys extraherar den affärsregellogiken som är inbäddad i COBOL-program, biljettvalideringsreglerna, intäktsredovisningsberäkningarna och behörighetslogiken för lojalitetsnivåer, vilket inte finns någonstans förutom i programkoden. För flygbolag som planerar att modernisera angränsande system utan att vidröra PSS-kärnan producerar denna extrahering den specifikation som ersättningen måste matcha.
Mappningen av applikationsberoenden bygger beroendegrafen som bestämmer migreringssekvensen: vilka program på flygbolagets sida som är beroende av vilka dataflöden från PSS, vilka rapporteringsprogram som är beroende av vilka COBOL-batchutdata, vilka nedströmssystem som måste uppdateras när någon komponent ändras. Beroendegrafen är det som möjliggör stegvis, säker modernisering, samma tillvägagångssätt som Sabre och Amadeus har använt för kärnsystemen, tillämpat på den flygbolagssideskod som omger dem.
Effektanalysfunktionen besvarar frågan som föregår varje moderniseringsbeslut: om detta program ändras, vad mer kommer att påverkas? För flygbolagssystem där en beräkningsändring i ett intäktsredovisningsprogram kan påverka regulatorisk rapportering, partneravräkning och finansiell konsolidering samtidigt , är det en förutsättning för ändringskontroll som uppfyller flygbolagets tillförlitlighetskrav att känna till effektens omfattning innan någon ändring görs.
Analysen av den äldre moderniseringen ger en komplett inventering av tiden före moderniseringen: varje program inom ramen, dess komplexitet, dess beroenden, dess procentandel av död kod och dess migrationsriskklassificering. Lärdomen från varje moderniseringsprogram för flygbolag, att börja vid kanterna, arbeta inåt, validera i varje steg, kräver att man vet var kanterna finns och hur beroendestrukturen ser ut. Den kunskapen kommer från strukturell analys av den faktiska koden, inte från dokumentation som skrevs innan koden utvecklades bort från den.
De geologiska lagren av verksamhetskritisk programvara
När du bokar en flygresa på en smartphone år 2026, berör du programvara med flera distinkta geologiska lager. Det moderna gränssnittet på ytan. API-lagret under det. PSS-transaktionsmotorn nedanför, som körs på en infrastruktur som har förändrats avsevärt sedan 1960-talet men bibehåller transaktionssemantik och datamodeller som var rätt när de designades och har visat sig vara för tillförlitliga för att överge.
Flygbokningssystemet är inte ett misslyckande av moderniseringen. Det är resultatet av sex decennier av rationella beslut av ingenjörer och chefer som förstod, varje gång en ersättning föreslogs, att risken för att göra fel översteg kostnaden för att behålla det som fungerade. De system som överlever så länge gör det för att de förtjänar det, transaktion för transaktion, flyg för flyg, bokningssäsong för bokningssäsong.
Den praktiska lärdomen för alla moderniseringsteam är inte att gamla system aldrig ska ersättas. Det är att beslutet att ersätta dem bör fattas med fullständig kunskap om vad de innehåller, vad som är beroende av dem och vad den fulla omfattningen av förändringen faktiskt är, inte med optimistiska uppskattningar gjorda innan komplexiteten mättes. Flygbranschen lärde sig detta på det dyra sättet. Analysverktygen som producerar fullständig strukturell kunskap innan den första raden ny kod skrivs är det som gör det möjligt att lära sig det på det billigare sättet.
