Rezerwując lot za pomocą smartfona w 2026 roku, Twoje zapytanie przechodzi przez wiele warstw nowoczesnej technologii – aplikację mobilną, usługę internetową, procesor płatności – zanim trafi do systemu, który faktycznie rezerwuje Twoje miejsce. System ten, w większości przypadków, to oprogramowanie z lat 1960. XX wieku, działające w oparciu o infrastrukturę, którą branża turystyczna od dziesięcioleci próbuje zastąpić, ale bezskutecznie. Sabre, Amadeus i Travelport wspólnie obsługują praktycznie wszystkie rezerwacje lotnicze na świecie. Łącznie przetwarzają miliardy transakcji rocznie w setkach linii lotniczych, tysiącach biur podróży i w czasie rzeczywistym, obejmując miliony kombinacji miejsc. Najstarszy z nich ma swoje korzenie w komputerze mainframe IBM z 1964 roku, który skrócił czas rezerwacji z 90 minut do zaledwie sekund i na stałe odmienił lotnictwo komercyjne.
Historia o tym, dlaczego te systemy pozostają tam, gdzie są, nie jest historią bezwładności organizacyjnej ani konserwatyzmu inżynieryjnego. To historia o tym, co się dzieje, gdy oprogramowanie zostaje tak głęboko osadzone w krytycznym procesie operacyjnym, że kosztów i ryzyka związanego z jego wymianą nie da się uzasadnić w realistycznych ramach czasowych, oraz o tym, jak branża zareagowała, modernizując je wokół rdzenia, zamiast próbować je zastąpić. Dla każdego, kto pracuje nad modernizacją systemów na dużą skalę, systemy rezerwacji lotniczych są najwyraźniejszym dostępnym studium przypadku pokazującym, co w praktyce oznacza sformułowanie „zbyt ważne, by upaść”.
Pracuj do wewnątrz. Poznaj Graf Zależności.
SMART TS XL wyodrębnia reguły biznesowe, mapy zależności i martwy kod w programach COBOL i starszych wersjach.
DOWIEDZ SIĘ WIĘCEJ…Geneza: Dlaczego komputery mainframe wygrały problem linii lotniczych
Pierwotne SABRE (Semi-Automated Business Research Environment) nie było produktem, lecz rozwiązaniem dostosowanym do konkretnego kryzysu operacyjnego. Pod koniec lat 1950. linia lotnicza American Airlines rozwijała się szybciej, niż pozwalał na to jej manualny system rezerwacji. Rezerwacja miejsca wymagała rozmowy telefonicznej, ręcznego sprawdzenia karty inwentarza, wstrzymania lotu, oddzwonienia i sporządzenia dokumentacji papierowej – proces ten trwał średnio 90 minut na rezerwację i nie był skalowalny.
Kiedy w 1964 roku system SABRE osiągnął pełną operacyjność, zbudowany na dwóch komputerach mainframe IBM 7090 i połączony z 1,500 terminalami w Stanach Zjednoczonych i Kanadzie, mógł przetwarzać 7,500 rezerwacji na godzinę przy niemal zerowym wskaźniku błędów. Po raz pierwszy linia lotnicza mogła zarządzać rezerwacją miejsc w czasie rzeczywistym, przechowywać pełną dokumentację pasażerów i umożliwiać natychmiastowe rezerwacje w całej swojej sieci. Czas rezerwacji skrócił się z 90 minut do sekund.
Wybór architektury, który umożliwił scentralizowane przetwarzanie transakcji na komputerach mainframe, nie został podjęty z powodów filozoficznych. Wybrano go, ponieważ była to jedyna architektura dostępna w 1964 roku, która spełniała wymagania dotyczące opóźnień, niezawodności i równoczesnego dostępu w zarządzaniu zasobami lotniczymi w czasie rzeczywistym. Działała tak dobrze, że stała się architektonicznym wzorcem, na którym opierał się każdy kolejny system rezerwacji lotniczych.
Rozwiązanie IBM Transaction Processing Facility (TPF), pierwotnie zaprojektowane dla SABRE, stało się środowiskiem operacyjnym dla całej kategorii. Według IBM, nadal korzystają z niego niemal wszystkie największe banki, ubezpieczyciele, detaliści i linie lotnicze. Kiedy Amadeus został założony w 1987 roku, bazował na TPF. Kiedy Galileo (obecnie Travelport) uruchomił swój GDS, bazował na TPF. W lotnictwie komercyjnym współistnieją obecnie trzy generacje systemów obsługi pasażerów, a wiele z nich nadal działa na komputerach mainframe TPF, nie dlatego, że technologia ta nigdy nie była kwestionowana, ale dlatego, że przepustowość transakcji, niezawodność i odporność na awarie, które TPF zapewnia na komputerach mainframe, okazały się naprawdę trudne do powtórzenia w równoważnej skali na alternatywnych architekturach.
Co te systemy faktycznie robią na dużą skalę
Skala działania systemów rezerwacji lotniczych nie jest intuicyjna z perspektywy inżynierii oprogramowania. Globalny system dystrybucji zajmuje się nie tylko dostępnością miejsc, ale także zarządza kombinatorycznym problemem zapasów o oszałamiającej złożoności.
Pojedynczy lot transatlantycki ma setki klas taryfowych. Każda klasa taryfowa ma określone zasady: wymagania dotyczące wcześniejszego zakupu, minimalny pobyt, daty wyłączone z oferty, opłaty za zmianę, dozwolone lub niedozwolone przesiadki, umowy code-share z liniami partnerskimi. Rezerwacja obejmująca dwie linie lotnicze, przesiadkę i lot w obie strony tworzy macierz potencjalnie tysięcy prawidłowych kombinacji taryf, które muszą zostać sprawdzone, wycenione i porównane z aktualnym stanem magazynowym, zanim zostanie udzielona odpowiedź, zazwyczaj w ciągu sekundy.
W okresach szczytowego zapotrzebowania na rezerwacje Sabre i Amadeus wspólnie przetwarzają dziesiątki tysięcy transakcji na sekundę. Nie na minutę. Na sekundę. Każda transakcja obejmuje wyszukiwanie w czasie rzeczywistym, ocenę zasad taryfowych, tworzenie lub modyfikację rekordu PNR (Passenger Name Record) oraz koordynację z systemami kontroli odlotów, programami dla często podróżujących i systemami usług dodatkowych. Gwarantowany czas reakcji jest mierzony w milisekundach, ponieważ agent podróży lub system rezerwacyjny oczekujący na sprawdzenie ceny dłużej niż kilka sekund przekroczy limit czasu i podejmie ponowną próbę lub anuluje transakcję.
TPF w komputerach mainframe zapewnia taką przepustowość przy wskaźniku awaryjności, w który trudno uwierzyć specjalistom IT z innych branż. Odporność komputerów mainframe na błędy, redundantne procesory, komponenty z możliwością wymiany podczas pracy i dekady udoskonalonego kodu systemu operacyjnego sprawiają, że dostępność na poziomie pięciu dziewiątek jest standardowym parametrem operacyjnym, a nie celem samym w sobie. Odtworzenie tego przy porównywalnych kosztach w infrastrukturze chmurowej było głównym wyzwaniem technicznym każdego programu modernizacji IT w liniach lotniczych od lat 1990. XX wieku.
Próby modernizacji: co tak naprawdę odkryły trwające dekadę programy
Historia modernizacji systemów rezerwacji lotniczych to historia programów, które początkowo miały zastąpić rdzeń, a po latach doczekały się hybrydowego rozwiązania obejmującego rdzeń.
Projekt Jetstream linii American Airlines, rozpoczęty w latach 2000. z wyraźnym celem zastąpienia głównego systemu Sabre PSS, zakończył się wdrożeniem nowego produktu Sabre, zamiast budowy alternatywy. Początkowe założenie typu „zbuduj zamiast kupić”, że zbudowanie nowego systemu we własnym zakresie pozwoli szybciej stworzyć lepszy system, napotkało tę samą rzeczywistość, z którą zmaga się niemal każdy program wymiany starszego systemu na dużą skalę: istniejący system zawierał wymagania, o których nikt nie wiedział, dopóki nowy system nie był w stanie ich spełnić.
Musimy zagłębić się w stos, zmienić silnik bazowy i rozdzielić reguły, aby móc je szybko zmieniać. To stwierdzenie, wypowiedziane przez kierownictwo IT American Airlines podczas programu Jetstream, dokładnie opisuje problem. Reguły osadzone w starym systemie, logika konstruowania taryf, implementacje umów code-share, obliczenia zgodności z przepisami, integracje z zarządzaniem przychodami, narastały przez dekady zmian biznesowych i nie były udokumentowane w żadnej formie, która umożliwiałaby ich wyodrębnienie bez uruchomienia istniejącego systemu i obserwacji jego działania.
Własny program modernizacji Sabre, który rozpoczął się na dobre w latach 2010-2019, trwał ponad dekadę i kosztował miliardy dolarów, aby przenieść większość kodu z lokalnej infrastruktury mainframe. W 2019 roku około 11% kodu Sabre nadal działało w lokalnych centrach danych, a reszta została zmigrowana. W lutym 2026 roku Sabre odnowiło długoterminową umowę PSS z WestJet, co dowodzi, że nawet po dekadzie wysiłków modernizacyjnych i miliardowych inwestycjach, PSS pozostaje komercyjnym fundamentem firmy.
Amadeus osiągnął bardziej kompleksową likwidację komputerów mainframe, osiągając kamień milowy w postaci wycofania z eksploatacji ostatnich komputerów mainframe na rzecz infrastruktury chmurowej. Jednak podejście Amadeusa, polegające na stopniowej wymianie komponentów funkcjonalnych przy jednoczesnym zachowaniu podstawowego modelu danych i architektury transakcyjnej, skutecznie zachowało decyzje architektoniczne podjęte na komputerach mainframe, nawet po zmianie sprzętu. Semantyka transakcji, struktura PNR i logika zarządzania zapasami: wszystkie te elementy zostały przeniesione do nowoczesnej infrastruktury, zachowując jednocześnie ich fundamentalną konstrukcję.
Dlaczego wymiana jest trudniejsza, niż się wydaje: ukryta złożoność
Standardowym wyjaśnieniem, dlaczego systemy rezerwacji lotniczych nadal funkcjonują na komputerach mainframe, są koszty i ryzyko. Oba te czynniki są realne. Są one jednak symptomami głębszej rzeczywistości technicznej, którą warto dokładnie zrozumieć, ponieważ dotyczy ona każdego programu modernizacji starszych systemów o znaczeniu krytycznym.
Reguły biznesowe, które istnieją tylko w kodzie. Logika konstruowania taryf w globalnym systemie dystrybucji opiera się na dziesięcioleciach wymogów regulacyjnych, dwustronnych umów lotniczych, rewizji standardów IATA i zmian reguł biznesowych, z których żaden nie jest udokumentowany w formie niezależnej od kodu, który je implementuje. Specyfikacja to implementacja. Zastąpienie implementacji bez specyfikacji oznacza konieczność dogłębnej obserwacji zachowania istniejącego systemu, aby odtworzyć to, co wskazywałaby specyfikacja – proces ten trwa lata i nigdy się nie kończy, ponieważ zakres obserwacji nigdy nie jest wystarczająco kompleksowy, aby objąć każdy przypadek brzegowy.
Semantyka transakcji, której współczesne architektury mają problem z odtworzeniem. TPF zapewnia synchroniczne, atomowe przetwarzanie transakcji z gwarantowaną spójnością całego PNR, rezerwacji miejsca, aktualizacji rekordu pasażera, autoryzacji płatności i rekordu potwierdzenia – wszystkie zatwierdzone jako pojedyncza jednostka atomowa lub wcale. Replikacja tego w rozproszonych architekturach mikrousług wymaga starannej orkiestracji, kompensacji transakcji i rozproszonego zarządzania blokadami, co jest zarówno złożone, jak i potencjalnie wolniejsze niż w przypadku synchronicznych komputerów mainframe. Doświadczenie branży lotniczej pokazuje, że „ostateczna spójność” nie jest akceptowalną cechą w przypadku liczby miejsc, a przepełniony lot to konkretna, katastroficzna awaria operacyjna, a nie tymczasowa niespójność, którą można rozwiązać później.
Powierzchnia integracji. Dojrzały system PSS linii lotniczych jest połączony z setkami systemów zewnętrznych: kontrolą odlotów, zarządzaniem przychodami, programem Frequent Flyer, systemami lotniskowymi, zewnętrznymi połączeniami GDS, partnerami współdzielenia kodów, raportowaniem regulacyjnym i wieloma innymi. Każde połączenie ma specyficzne kontrakty interfejsowe, formaty wiadomości, wymagania czasowe i mechanizmy obsługi błędów, które zostały zaimplementowane w istniejącym systemie i wokół których zbudowano każdy system zależny. Wymiana systemu PSS wymaga jednoczesnego utrzymania wszystkich istniejących kontraktów interfejsowych (co ogranicza architekturę zastępczą) lub skoordynowania zmian z każdym systemem zależnym (co rozszerza zakres poza możliwości pojedynczego programu).
Problem z danymi na żywo. Rezerwacje lotnicze to dane na żywo, rezerwacje dokonywane z wielomiesięcznym wyprzedzeniem, które muszą być realizowane dokładnie tak, jak zostały zarezerwowane. Nie ma punktu przejścia, w którym dane ze starego systemu mogłyby zostać zachowane. Migracja musi przenieść wszystkie aktualne dane PNR ze starego systemu do nowego, z zachowaniem wszystkich powiązanych reguł, taryf, ograniczeń i usług dodatkowych. Migracja PNR w skali globalnej, z zerową utratą danych i gwarancją identycznego działania, okazała się jednym z najtrudniejszych problemów technicznych w modernizacji przedsiębiorstw.
Odpowiedź architektoniczna: modernizacja wokół rdzenia
Podejście, które faktycznie odniosło sukces w Amadeus, Sabre i poszczególnych liniach lotniczych, to nie wymiana, lecz strategiczne opakowanie i stopniowa ekstrakcja.
Opakowywanie API udostępnia podstawowe funkcje rezerwacji jako nowoczesne interfejsy API REST lub SOAP, umożliwiając nowym aplikacjom interakcję ze starszym systemem za pośrednictwem nowoczesnego interfejsu bez ingerencji w podstawową logikę transakcji. Linie lotnicze zbudowały aplikacje mobilne, internetowe systemy rezerwacji i narzędzia obsługi klienta w oparciu o warstwy API, które tłumaczą nowoczesne żądania na wywołania transakcji TPF i zwracają ustrukturyzowane odpowiedzi. Terminal z zielonym ekranem został zastąpiony nowoczesnym interfejsem graficznym (GUI); podstawowe przetwarzanie transakcji pozostało niezmienione.
Rysunek Stranglera dla funkcji niekluczowych. Funkcje sąsiadujące z podstawowymi, takie jak zarządzanie przychodami, zarządzanie programami lojalnościowymi, raportowanie i analityka, planowanie pracy załogi, są wyodrębniane pojedynczo i ponownie implementowane w nowoczesnej infrastrukturze. Każda ekstrakcja zmniejsza rozmiar istniejącego systemu bez ingerencji w rdzeń transakcji, który jest najbardziej ryzykowny. Po dekadzie stopniowej ekstrakcji, rola istniejącego systemu zawęża się z wszechstronnej platformy aplikacji do wyspecjalizowanego silnika transakcyjnego.
Infrastruktura chmurowa z zachowaną architekturą. Wycofanie komputerów mainframe firmy Amadeus z eksploatacji przeniosło obciążenia do infrastruktury chmurowej, zachowując jednocześnie architekturę transakcji, która pierwotnie znajdowała się na komputerach mainframe. Zmienił się sprzęt: projekt oprogramowania, model danych, semantyka transakcji i struktura PNR, zachowując decyzje architektoniczne, które przez dekady okazywały się trafne.
Nowe zarządzanie ofertami i zamówieniami obok dotychczasowego systemu PNR. Standard IATA ONE Order, który zastępuje rekordy oparte na PNR nowoczesnym modelem zarządzania zamówieniami, jest wdrażany przez linie lotnicze jako warstwa uzupełniająca istniejący system oparty na PNR. Technologie nowej generacji Offer and Order firmy Sabre, o których mowa w odnowionej wersji WestJet z 2026 roku, pozycjonują to jako drogę naprzód – nie chodzi o zastąpienie PSS, ale o dodanie nowoczesnej warstwy komercyjnej, która z czasem będzie obsługiwać coraz większą część rezerwacji, podczas gdy rdzeń PNR będzie obsługiwał pozostałą część.
Co to oznacza dla każdej modernizacji systemów o znaczeniu krytycznym
Historia systemu rezerwacji lotniczych nie jest wyjątkowa dla lotnictwa. Jest to najbardziej widoczny przykład wzorca, który pojawia się w podstawowych systemach bankowych, administrowaniu polisami ubezpieczeniowymi, rozliczeniach telekomunikacyjnych i przetwarzaniu świadczeń rządowych: oprogramowanie, które staje się autorytatywną specyfikacją reguł biznesowych, służy jako centrum integracji dla dziesiątek zależnych systemów i działa w skali i niezawodności, które sprawiają, że wymiana na dużą skalę jest praktycznie niemożliwa.
Lekcje te są spójne w każdej branży:
Wyodrębnienie reguł biznesowych z kodu przed rozpoczęciem modernizacji nie jest opcjonalne. Programy COBOL i TPF, które implementują konstrukcję taryf, logikę umów codeshare i zasady zgodności z przepisami, stanowią jedyną zachowaną dokumentację tych reguł. Modernizacja, która nie wyodrębnia i nie weryfikuje najpierw tej logiki, nie może wygenerować zamiennika, który zachowuje się poprawnie we wszystkich przypadkach, ponieważ nie jest w stanie poznać wszystkich przypadków bez analizy całego kodu.
Mapa zależności określa kolejność migracji. Żadna linia lotnicza nie zdołała pomyślnie wymienić swojego systemu PSS, zaczynając od najbardziej krytycznego i zintegrowanego komponentu. Każda udana modernizacja zaczynała się od krawędzi, systemów raportowania, usług pomocniczych, niekrytycznych funkcji administracyjnych i postępowała stopniowo w kierunku do wewnątrz. Kolejność ta wynika z grafu zależności: komponenty z najmniejszą liczbą zależności przychodzących są najbezpieczniejsze do rozwiązania w pierwszej kolejności.
Walidacja operacyjna na każdym etapie jest nieodzowna. Podejście do walidacji dwuetapowej, polegające na równoległym uruchamianiu nowego systemu ze starym, porównywaniu wyników i weryfikacji równoważności przed przeniesieniem ruchu, to jedyne podejście spełniające wymagania niezawodnościowe systemów, w których awarie pociągają za sobą konsekwencje fizyczne, finansowe i prawne.
W jaki sposób SMART TS XL Dotyczy analizy dziedzictwa związanego z liniami lotniczymi
Linie lotnicze, które korzystają z oprogramowania Sabre lub Amadeus PSS oprócz własnych programów COBOL, systemów obliczania stawek, rozliczania przychodów, obliczania punktów lojalnościowych i sprawozdawczości regulacyjnej, stają przed dokładnie tym samym wyzwaniem analitycznym, z jakim mierzy się każdy program modernizacji komputerów mainframe w przedsiębiorstwie: zrozumienie, co tak naprawdę zawiera kod, zanim zdecydujesz, co z nim zrobić.
SMART TS XL'S statyczna analiza kodu Wyodrębnia logikę reguł biznesowych osadzoną w programach COBOL, reguły walidacji taryf, obliczenia rozliczeń przychodów, logikę kwalifikowalności poziomów lojalnościowych, która nie istnieje nigdzie poza kodem programu. W przypadku linii lotniczych planujących modernizację sąsiednich systemów bez ingerencji w rdzeń PSS, ta ekstrakcja generuje specyfikację, którą musi spełniać zamiennik.
Mapowanie zależności aplikacji tworzy graf zależności, który określa kolejność migracji: które programy po stronie linii lotniczych zależą od danych z PSS, które programy raportujące zależą od danych z zadań wsadowych w języku COBOL, które systemy niższego rzędu muszą zostać zaktualizowane po zmianie dowolnego komponentu. Graf zależności umożliwia przyrostową, bezpieczną modernizację – to samo podejście, które Sabre i Amadeus zastosowały do systemów rdzeniowych, a które do otaczającego je kodu po stronie linii lotniczych.
Możliwość analizy wpływu odpowiada na pytanie poprzedzające każdą decyzję modernizacyjną: jeśli ten program ulegnie zmianie, co jeszcze zostanie naruszone? W przypadku systemów linii lotniczych, w których zmiana w kalkulacji w programie rozliczania przychodów może jednocześnie wpłynąć na raportowanie regulacyjne, rozliczenia z partnerami i konsolidację finansową, znajomość zakresu wpływu przed wprowadzeniem jakiejkolwiek zmiany jest warunkiem wstępnym kontroli zmian, która spełnia wymagania linii lotniczych dotyczące niezawodności.
Analiza modernizacji systemów legacy zapewnia kompletny inwentarz przed modernizacją: każdy program w swoim zakresie, jego złożoność, zależności, odsetek martwego kodu oraz klasyfikację ryzyka migracji. Lekcja płynąca z każdego programu modernizacji linii lotniczych: zaczynaj od krawędzi, pracuj do wewnątrz, waliduj na każdym kroku, wymaga znajomości lokalizacji krawędzi i struktury zależności. Ta wiedza pochodzi z analizy strukturalnej samego kodu, a nie z dokumentacji napisanej przed jego ewolucją.
Warstwy geologiczne oprogramowania o znaczeniu krytycznym
Rezerwując lot na smartfonie w 2026 roku, stykasz się z oprogramowaniem składającym się z wielu odrębnych warstw geologicznych. Nowoczesny interfejs na powierzchni. Pod nim warstwa API. Silnik transakcyjny PSS poniżej, działający w oparciu o infrastrukturę, która znacząco zmieniła się od lat 1960. XX wieku, ale zachowuje semantykę transakcji i modele danych, które były poprawne w momencie ich projektowania i okazały się zbyt niezawodne, by je porzucić.
System rezerwacji lotniczych nie jest porażką modernizacji. Jest wynikiem sześciu dekad racjonalnych decyzji inżynierów i kadry kierowniczej, którzy rozumieli, że za każdym razem, gdy proponowano nową wersję, ryzyko popełnienia błędu przewyższało koszt utrzymania tego, co działało. Systemy, które przetrwały tak długo, zawdzięczają to sobie, ponieważ na to zasługują – transakcja po transakcji, lot po locie, sezon po sezonie.
Praktyczną lekcją dla każdego zespołu modernizacyjnego nie jest to, że starych systemów nigdy nie należy wymieniać. Chodzi o to, że decyzję o ich wymianie należy podejmować z pełną wiedzą o ich zawartości, o tym, co od nich zależy i jaki jest rzeczywisty zakres zmian, a nie na podstawie optymistycznych szacunków dokonanych przed zmierzeniem złożoności. Branża lotnicza przekonała się o tym w kosztowny sposób. Narzędzia analityczne, które generują kompletną wiedzę strukturalną przed napisaniem pierwszej linijki nowego kodu, umożliwiają tańsze poznanie tej metody.
