Kui broneerite 2026. aastal nutitelefoniga lennupileti, läbib teie päring mitu kihti moodsat tehnoloogiat – mobiilirakenduse, veebiteenuse ja makseprotsessori –, enne kui see jõuab süsteemi, mis teie istekohta broneerib. See süsteem on enamasti tarkvara, mille juured ulatuvad 1960. aastatesse ja mis töötab infrastruktuuril, mida reisitööstus on aastakümneid püüdnud asendada, kuid pole seda täielikult suutnud. Sabre, Amadeus ja Travelport tegelevad koos sisuliselt iga lennupiletite broneerimisega Maal. Nad töötlevad koos igal aastal miljardeid tehinguid sadade lennufirmade, tuhandete reisibüroode ja reaalajas inventuuri vahel, mis hõlmab miljoneid istekohtade kombinatsioone. Vanim neist pärineb 1964. aasta IBM-i suurarvutist, mis vähendas broneerimisaega 90 minutist sekunditeni ja muutis kommertslennundust jäädavalt.
Lugu sellest, miks need süsteemid on jäänud sinna, kus nad on, ei ole lugu organisatsioonilisest inertsist või insenerikonservatismist. See on lugu sellest, mis juhtub, kui tarkvara on missioonikriitilisse tegevusprotsessi nii sügavalt juurdunud, et selle asendamise kulusid ja riske ei saa ühegi realistliku ajakavaga õigustada, ning kuidas tööstusharu on reageerinud, moderniseerides põhikomponente, mitte püüdes neid asendada. Kõigile, kes tegelevad ulatusliku pärandmoderniseerimisega, on lennufirmade broneerimissüsteemid kõige selgem saadaolev juhtumiuuring selle kohta, mida praktikas tähendab „liiga oluline, et läbi kukkuda“.
Tööta sissepoole. Tunne sõltuvusgraafikut.
SMART TS XL ekstraheerib ärireegleid, sõltuvuskaarte ja surnud koodi COBOL-i ja pärandprogrammidest.
SAAGE LISATEAVET…Päritolu: miks suurarvutid võitsid lennufirmade probleemi
Algne SABRE (poolautomaatne äriuuringute keskkond) ei olnud toode, vaid kohandatud lahendus konkreetsele tegevuskriisile. 1950. aastate lõpus kasvas American Airlines kiiremini, kui selle käsitsi broneerimissüsteem hakkama sai. Istekoha broneerimiseks oli vaja telefonikõnet, füüsilise inventuuri kaardi käsitsi kontrollimist, broneeringu tegemist, tagasihelistamist ja paberkandjal registreerimist – protsess, mis kestis keskmiselt 90 minutit broneeringu kohta ja ei suutnud skaleerida.
Kui SABRE 1964. aastal kahele IBM 7090 suurarvutile ehitatud ja 1,500 terminaliga üle Ameerika Ühendriikide ja Kanada täielikult tööle hakkas, suutis see töödelda 7,500 broneeringut tunnis peaaegu nullveamääraga. Esmakordselt sai lennufirma hallata reaalajas istekohtade nimekirja, salvestada täielikke reisijate andmeid ja võimaldada kohest broneerimist kogu oma võrgus. Broneerimisajad lühenesid 90 minutilt sekunditele.
Selle võimalikuks teinud arhitektuuriline valik – tsentraliseeritud tehingute töötlemine suurarvuti riistvaral – ei valitud filosoofilistel põhjustel. See valiti seetõttu, et see oli 1964. aastal ainus saadaolev arhitektuur, mis suutis vastata reaalajas lennufirmade inventuuri haldamise latentsuse, töökindluse ja samaaegse juurdepääsu nõuetele. Ja see toimis nii hästi, et sellest sai arhitektuuriline mall, millele ehitati iga järgnev lennufirmade broneerimissüsteem.
IBM-i tehingute töötlemise keskus (TPF), mis algselt loodi SABRE jaoks, sai kogu kategooria tegevuskeskkonnaks. IBM-i andmetel kasutavad seda endiselt peaaegu kõik suurimad pangad, kindlustusandjad, jaemüüjad ja lennufirmad. Kui Amadeus 1987. aastal asutati, ehitati see TPF-ile. Kui Galileo (nüüd Travelport) oma GDS-i käivitas, ehitati see TPF-ile. Kaubanduslikus lennunduses eksisteerivad nüüd koos kolm põlvkonda reisijate teenindussüsteeme ja paljud töötavad endiselt TPF-i suurarvutitel, mitte sellepärast, et tehnoloogiat poleks kunagi kahtluse alla seatud, vaid seetõttu, et tehingute läbilaskevõime, töökindlus ja tõrketaluvus, mida TPF pakub suurarvuti riistvaral, on osutunud alternatiivsete arhitektuuride puhul samaväärses mahus tõeliselt keeruliseks korrata.
Mida need süsteemid tegelikult mastaabis teevad
Lennufirmade broneerimissüsteemide toimimise ulatust ei ole tarkvaratehnika vaatenurgast intuitiivselt võimalik mõista. Globaalne jaotussüsteem ei tegele ainult istekohtade saadavusega, vaid haldab ka hämmastavalt keerulist kombinatoorset inventuuriprobleemi.
Ühel transatlantilisel lennul on sadu piletiklasse. Igal piletiklassil on kindlad reeglid: ettetellimise nõuded, minimaalne peatumisaeg, piletite tühistamise kuupäevad, muutmistasud, lubatud või keelatud vahemaandumised, koodijagamislepingud partnerlennufirmadega. Kahte lennufirmat hõlmav broneering, ümberistumine ja edasi-tagasi lend loob potentsiaalselt tuhandete kehtivate piletikombinatsioonide maatriksi, mida tuleb enne vastuse tagastamist, tavaliselt vähem kui sekundi jooksul, kontrollida, hinnata ja võrrelda reaalajas laoseisuga.
Tipptundidel töötlevad Sabre ja Amadeus koos kümneid tuhandeid tehinguid sekundis. Mitte minutis. Sekundi kohta. Iga tehing hõlmab reaalajas laoseisu otsingut, hinnareeglite hindamist, PNR-i (reisija nimekirje) loomist või muutmist ning koordineerimist väljumiskontrolli, sagedase lendaja ja abiteenuste süsteemidega. Garanteeritud reageerimisaega mõõdetakse millisekundites, sest reisibüroo või broneerimismootor, mis ootab hinnakontrolli kauem kui paar sekundit, aegub ja kas proovib uuesti või katkestab tehingu.
Suurarvuti riistvara TPF pakub sellist läbilaskevõimet rikete määraga, mida teiste tööstusharude IT-spetsialistidel on raske uskuda. Suurarvuti rikketaluvus, koondatud protsessorid, vahetatavad komponendid ja aastakümnete pikkune karastatud operatsioonisüsteemi kood tagavad viie üheksa protsendipunkti käideldavuse standardse tööparameetrina, mitte eesmärgina. Selle kopeerimine samaväärsete kuludega pilveinfrastruktuuril on olnud iga lennufirma IT-moderniseerimisprogrammi keskne tehniline väljakutse alates 1990. aastatest.
Moderniseerimiskatsed: mida kümnendipikkused programmid tegelikult leidsid
Lennufirmade broneerimissüsteemide moderniseerimise ajalugu on ajalugu programmidest, mis seadsid eesmärgiks asendada põhisüsteem, kuid jõudsid aastaid hiljem hübriidsüsteemini, mis hoopis mässis põhisüsteemi endasse.
American Airlinesi Jetstreami projekt, mis käivitati 2000. aastatel selge eesmärgiga asendada Sabre suurarvuti PSS, lõppes uue Sabre toote kasutuselevõtuga alternatiivi loomise asemel. Esialgne ehitamise ja ostmise põhimõte, et asendaja ehitamine ettevõttesiseselt annab kiiremini parema süsteemi, põrkas kokku sama reaalsusega, millega seisab silmitsi peaaegu iga suuremahuline pärandsüsteemi asendamise programm: olemasolev süsteem sisaldas nõudeid, millest keegi ei teadnud enne, kui asendussüsteem neid enam täita ei suutnud.
Peame süsteemi sügavamale uurima, põhimootorit muutma ja reegleid lahti siduma, et saaksime neid kiiresti muuta. See avaldus, mille American Airlinesi IT-juhtkond tegi Jetstreami programmi ajal, kirjeldab probleemi täpselt. Pärandsüsteemi sisse ehitatud reeglid, piletihinna koostamise loogika, koodijagamislepingute rakendamised, regulatiivse vastavuse arvutused ja tulude haldamise integratsioonid olid kogunenud aastakümnete jooksul toimunud äritegevuse muutuste käigus ning neid ei dokumenteeritud mingil kujul, mis oleks teinud need eraldatavaks ilma olemasolevat süsteemi käivitamata ja selle käitumist jälgimata.
Sabre'i enda moderniseerimisprogramm, mis algas tõsiselt 2010. aastatel, võttis aega üle kümne aasta ja maksis miljardeid dollareid, et enamik koodist kohapealsest suurarvutite infrastruktuurist välja viia. 2019. aasta seisuga töötas umbes 11 protsenti Sabre'i koodist endiselt kohapealsetes andmekeskustes, ülejäänu oli migreeritud. 2026. aasta veebruaris pikendas Sabre oma pikaajalist PSS-lepingut WestJetiga, näidates, et isegi pärast kümme aastat kestnud moderniseerimispingutusi ja miljardeid investeeringuid on PSS endiselt ettevõtte äriline alus.
Amadeus saavutas suurarvutite täielikuma dekomisjoneerimise, jõudes verstapostini viimaste suurarvutite pensionile saatmisel pilveinfrastruktuuri kasuks. Kuid Amadeuse lähenemisviis, mis asendas järk-järgult funktsionaalseid komponente, säilitades samal ajal põhiandmemudeli ja tehingute arhitektuuri, säilitas tõhusalt suurarvutist alguse saanud arhitektuurilised otsused isegi riistvara muutudes. Tehingute semantika, PNR-struktuur, varude haldamise loogika: need viidi üle tänapäevasesse infrastruktuuri, säilitades samal ajal oma põhidisaini.
Miks asendamine on raskem, kui paistab: varjatud keerukus
Lennufirmade broneerimissüsteemide püsimise standardne seletus suurarvutites on hind ja risk. Mõlemad on reaalsed. Kuid need on sügavama tehnilise reaalsuse sümptomid, mida tasub täpselt mõista, sest see kehtib iga missioonikriitilise pärandsüsteemi moderniseerimisprogrammi kohta.
Ärireeglid, mis eksisteerivad ainult koodis. Globaalse jaotussüsteemi piletihinna koostamise loogika esindab aastakümneid regulatiivseid nõudeid, kahepoolseid lennufirmade lepinguid, IATA standardite muudatusi ja ärireeglite muudatusi, millest ükski pole dokumenteeritud mingil kujul, mis oleks sõltumatu neid rakendavast koodist. Spetsifikatsioon on implementatsioon. Implementatsiooni asendamine ilma spetsifikatsioonita tähendab olemasoleva süsteemi käitumise piisavalt ammendavat jälgimist, et rekonstrueerida spetsifikatsioonis öeldut – protsess, mis võtab aastaid ja pole kunagi täielik, sest vaatluste ulatus ei saa kunagi olla piisavalt ulatuslik, et tabada kõiki äärejuhtumeid.
Tehingute semantika, mida tänapäevastel arhitektuuridel on raskusi korrata. TPF pakub sünkroonset, aatomipõhist tehingute töötlemist garanteeritud järjepidevusega kogu PNR-is, istekoha broneerimist, reisijaandmete uuendamist, makse autoriseerimist ja kinnituskirjet, mis kõik kinnitatakse ühe aatomiühikuna või üldse mitte. Selle replikeerimine hajutatud mikroteenuste arhitektuurides nõuab hoolikat orkestreerimist, tehingute kompenseerimist ja hajutatud lukustushaldust, mis on nii keeruline kui ka potentsiaalselt aeglasem kui sünkroonne suurarvuti ekvivalent. Lennundustööstuse kogemus näitab, et „lõpuks järjepidev“ ei ole istekohtade inventuuri puhul talutav omadus, ülemüüdud lend on konkreetne, operatiivselt katastroofiline rike, mitte ajutine vastuolu, mis tuleb hiljem lahendada.
Integratsioonipind. Küps lennufirma PSS on ühendatud sadade väliste süsteemidega: väljumiste kontroll, tulude haldamine, sagedase lendaja süsteem, lennujaama süsteemid, kolmandate osapoolte GDS-ühendused, koodijagamispartnerid, regulatiivne aruandlus ja palju muud. Igal ühendusel on spetsiifilised liideselepingud, sõnumivormingud, ajastusnõuded, veakäsitluskäitumine, mida olemasolev süsteem on rakendanud ja mille ümber on üles ehitatud iga sõltuv süsteem. PSS-i asendamine nõuab kas kõigi olemasolevate liideselepingute samaaegset haldamist (mis piirab asendusarhitektuuri) või muudatuste koordineerimist iga sõltuva süsteemiga (mis laiendab ulatust üle selle, mida ükski programm suudab hallata).
Reaalajas andmete probleem. Lennupiletite broneeringud on reaalajas andmed – mitu kuud ette tehtud broneeringud, mis tuleb täpselt broneeringule vastavalt täita. Puudub kindel üleminekupunkt, kus vana süsteemi andmed saab alles jätta. Migratsioon peab kandma kõik reaalajas broneeringuinfo andmed vanast süsteemist uude koos kõigi seotud reeglite, hindade, piirangute ja lisateenustega. PNR-i migratsioon globaalsel skaalal ilma andmete kadumiseta ja identse käitumise garantiita on osutunud ettevõtete moderniseerimise üheks keerulisemaks tehniliseks probleemiks.
Arhitektuuriline vastus: moderniseeri ümber tuuma
Lähenemisviis, mis on tegelikult õnnestunud nii Amadeuses, Sabre'is kui ka üksikutes lennufirmades, ei ole asendamine, vaid strateegiline pakkimine ja järkjärguline väljavõtmine.
API mähkimine paljastab põhilised broneerimisfunktsioonid moodsate REST- või SOAP-API-dena, võimaldades uutel rakendustel suhelda pärandsüsteemiga moodsa liidese kaudu, ilma et see puudutaks põhilist tehinguloogikat. Lennufirmad on API kihtidele peale ehitanud mobiilirakendusi, veebibroneerimismootoreid ja klienditeeninduse tööriistu, mis tõlgivad moodsad päringud TPF-tehingukõnedeks ja tagastavad struktureeritud vastuseid. Rohelise ekraaniga terminal on asendatud moodsa graafilise kasutajaliidesega; aluseks olev tehingute töötlemine jääb samaks.
Mitte-põhifunktsioonide jaoks mõeldud kägistaja joonis. Põhifunktsioonidega külgnevad funktsioonid – tulude haldamine, lojaalsusprogrammide haldamine, aruandlus ja analüüs, meeskonna ajakava koostamine – ekstraheeritakse ükshaaval ja rakendatakse uuesti kaasaegsel infrastruktuuril. Iga ekstraheerimine vähendab pärandsüsteemi jalajälge, puudutamata seejuures suurima riskiga tehingute tuuma. Üle kümne aasta pikkuse järkjärgulise ekstraheerimise on pärandsüsteemi roll kitsenenud kõikehõlmavast rakendusplatvormist keskendunud tehingumootoriks.
Säilitatud arhitektuuriga pilveinfrastruktuur. Amadeuse suurarvutite dekomisjoneerimine viis töökoormused pilveinfrastruktuuri, säilitades samal ajal suurarvutist alguse saanud tehinguarhitektuuri. Riistvara muutus; tarkvara disain, andmemudel, tehingu semantika, PNR-struktuur säilitasid arhitektuurilised otsused, mis olid aastakümnete jooksul õigeks osutunud.
Uus pakkumiste ja tellimuste haldus koos pärand PNR-süsteemiga. Lennufirmad rakendavad IATA ONE Order standardit, mis asendab PNR-põhised andmed moodsa tellimuste haldusmudeliga, lisaks olemasolevale PNR-põhisele süsteemile. Sabre'i järgmise põlvkonna pakkumiste ja tellimuste tehnoloogiad, millele viidati 2026. aasta WestJeti uuenduslepingus, positsioneerivad seda edasiviiva teekonnana – mitte PSS-i asendamisena, vaid moodsa kommertskihi lisamisena, mis lõpuks kasvab, et hallata üha suuremat osa broneeringutest, samal ajal kui PNR-tuum haldab ülejäänu.
Mida see tähendab mis tahes missioonikriitilise pärandmoderniseerimise jaoks
Lennufirmade broneerimissüsteemide lugu pole ainuomane lennundusele. See on kõige nähtavam näide mustrist, mis ilmneb panganduse põhisüsteemides, kindlustuspoliiside haldamises, telekommunikatsiooniarvelduses ja valitsuse hüvitiste töötlemises: tarkvarast saab ärireeglite autoriteetne spetsifikatsioon, see toimib integratsioonikeskusena kümnetele sõltuvatele süsteemidele ning töötab sellises ulatuses ja usaldusväärsuse nõudmisel, et järsu asendamise teeb tõeliselt võimatuks.
Õppetunnid on igas valdkonnas ühesugused:
Ärireeglite eraldamine koodist enne mis tahes moderniseerimise algust ei ole valikuline. COBOL- ja TPF-programmid, mis rakendavad piletihinna koostamist, koodijagamislepingu loogikat ja regulatiivse vastavuse reegleid, on nende reeglite ainsad säilinud dokumendid. Moderniseerimine, mis seda loogikat kõigepealt ei eralda ja valideeri, ei saa luua asendust, mis toimiks kõigil juhtudel õigesti, sest see ei saa kõiki juhtumeid teada ilma kogu koodi analüüsimata.
Sõltuvuskaart määrab migratsioonijärjestuse. Ükski lennufirma pole oma PSS-i edukalt asendanud, alustades kõige kriitilisemast ja integreeritumast komponendist. Iga edukas moderniseerimine algas servadest – aruandlussüsteemidest, abiteenustest, mittekriitilistest haldusfunktsioonidest – ning liikus järk-järgult sissepoole. See järjestus tuletatakse sõltuvusgraafikust: komponente, millel on kõige vähem sissetulevaid sõltuvusi, on kõige turvalisem kõigepealt käsitleda.
Toimivuse valideerimine igal sammul on vältimatu. Kahekordne valideerimise meetod, kus uut süsteemi käitatakse paralleelselt vanaga, võrreldakse väljundeid ja valideeritakse samaväärsus enne liikluse suunamist, on ainus meetod, mis vastab süsteemide usaldusväärsuse nõuetele, mille puhul riketel on füüsilised, rahalised ja regulatiivsed tagajärjed.
Kuidas SMART TS XL Kehtib lennufirmaga külgneva pärandanalüüsi kohta
Lennufirmad, mis käitavad Sabre'i või Amadeuse PSS-i koos oma COBOL-programmide, tariifiarvestussüsteemide, tuluarvestuse, lojaalsuspunktide arvutamise ja regulatiivse aruandlusega, seisavad silmitsi täpselt sama analüütilise väljakutsega, millega iga ettevõtte suurarvutite moderniseerimisprogramm silmitsi seisab: enne otsuse langetamist, mida koodiga peale hakata, mõista, mida see tegelikult sisaldab.
SMART TS XL'S staatilise koodi analüüs See ekstraheerib COBOL-programmidesse sisseehitatud ärireeglite loogika, piletihinna valideerimise reeglid, tulude arvestuse arvutused ja lojaalsustaseme abikõlblikkuse loogika, mis eksisteerib ainult programmikoodis. Lennufirmade jaoks, kes plaanivad külgnevaid süsteeme moderniseerida ilma PSS-i tuuma puutumata, loob see ekstraheerimine spetsifikatsiooni, millele asendus peab vastama.
Rakenduse sõltuvuste kaardistamine loob sõltuvusgraafiku, mis määrab migratsioonijärjestuse: millised lennufirma poolel olevad programmid sõltuvad PSS-i andmevoogudest, millised aruandlusprogrammid sõltuvad COBOL-i partii väljunditest ja milliseid allavoolu süsteeme tuleb komponendi muutumisel värskendada. Sõltuvusgraafik võimaldab järkjärgulist ja ohutut moderniseerimist – sama lähenemisviisi, mida Sabre ja Amadeus on kasutanud põhisüsteemide jaoks, rakendades seda neid ümbritsevale lennufirma poolel olevale koodile.
Mõjuanalüüsi võimalus vastab küsimusele , mis eelneb igale moderniseerimisotsusele: kui see programm muutub, mida see veel mõjutab? Lennufirmade süsteemide puhul, kus tulude arvestusprogrammi arvutusmuudatus võib samaaegselt mõjutada regulatiivset aruandlust, partnerite arveldusi ja finantskonsolideerimist, on mõju ulatuse teadmine enne mis tahes muudatuse tegemist eeltingimus muudatuste kontrollimiseks, mis vastab lennufirma usaldusväärsuse nõuetele.
Vananenud moderniseerimise analüüs annab täieliku ülevaate moderniseerimiseelsest inventuurist: iga hõlmatud programmi, selle keerukusest, sõltuvustest, surnud koodi protsendist ja migratsiooniriski klassifikatsioonist. Iga lennufirma moderniseerimisprogrammi õppetund – alusta servadest, tööta sissepoole ja valideeri igal sammul – nõuab teadmist, kus servad asuvad ja milline sõltuvusstruktuur välja näeb. See teadmine pärineb tegeliku koodi struktuurianalüüsist, mitte dokumentatsioonist, mis kirjutati enne koodi sellest eraldi arenemist.
Missioonikriitilise tarkvara geoloogilised kihid
Kui broneerite 2026. aastal nutitelefoniga lennupileti, puutute kokku tarkvaraga, millel on mitu eraldiseisvat geoloogilist kihti. Moodne liides pinnal. Selle all olev API kiht. Selle all olev PSS-i tehingumootor, mis töötab infrastruktuuril, mis on 1960. aastatest saadik oluliselt muutunud, kuid säilitab tehingute semantika ja andmemudelid, mis olid õiged nende loomisel ja on osutunud liiga usaldusväärseteks, et neist loobuda.
Lennufirmade broneerimissüsteem ei ole moderniseerimise läbikukkumine. See on inseneride ja juhtide kuue aastakümne pikkuse ratsionaalse otsuse tulemus, kes iga kord, kui asendust pakuti, mõistsid, et valesti tegemise risk ületab toimiva säilitamise kulud. Süsteemid, mis nii kaua vastu peavad, on seda teinud, tehing tehingu, lend lennu ja broneerimishooaeg hooaja haaval.
Praktiline õppetund igale moderniseerimismeeskonnale ei ole see, et vanu süsteeme ei tohiks kunagi välja vahetada. Pigem tuleks otsus nende asendamise kohta teha täieliku teadmisega sellest, mida need sisaldavad, mis neist sõltub ja milline on muudatuste täielik ulatus, mitte optimistlike hinnangute põhjal, mis on tehtud enne keerukuse mõõtmist. Lennundustööstus õppis seda kallil viisil. Analüüsivahendid, mis loovad täieliku struktuurilise teadmise enne uue koodi esimese rea kirjutamist, võimaldavad seda õppida odavamal viisil.
