SABRE'den PSS'e: bir mimari neden 60 yıl yaşadı

Manuel dönemde bir rezervasyonun işlenmesi ortalama 90 dakika sürüyordu. Kart dolapları, telefon, tekrar kart. 1964’te SABRE devreye girdi; süre saniyelere indi, hata payı %1’in altına çekildi. Bu bölüm o sıçramanın nasıl olduğunu değil, neden kalıcı olduğunu anlatıyor: bugünkü Yolcu Servis Sistemleri (PSS) hâlâ 1964’ün veri modelini taşıyor.

Darboğaz uçak değildi, kart dolabıydı

Kapasite sınırı kabinde değil, rezervasyon masasındaydı. Fiziksel kartlara ve telefon görüşmelerine dayalı süreç saatte belli sayıda işlemden fazlasını kaldıramıyordu; havayolu büyüdükçe masa büyümüyordu. Hedef baştan belliydi: envanterin otomatik güncellenmesi ve anında uygunluk kontrolü — bugün OLTP dediğimiz şey.

Standartlaşma ilk denemede kaçırıldı

American Airlines, Delta ve Pan Am için geliştirilen üç sistem — SABRE, Deltamatic, Panamac — farklı donanım üzerine kuruldu. SABRE IBM 7090’da ikili (binary), diğer ikisi IBM 7070 ve 7080’de ondalık (decimal) mimaride çalışıyordu. Yazılım taşınamadı; her havayolu kendi geliştirme maliyetini tek başına ödedi.

Sektörün sonradan çıkardığı ders net: daha pahalı ama ortak bir platformda (IBM 7090) birleşmek, üç ayrı ucuz platformdan daha ucuza geliyor. Bu cümle 1960’lardan; bugün “ortak stack” tartışmalarında aynen geçerli.

1964’te devrim hız değil, hata oranıydı

SABRE, Briarcliff Manor’daki iki IBM 7090 üzerinde açıldı. Kapasite saatte 7.500 işlem, yanıt süresi saniyeler, hata payı %1’in altında. Dönemin tanımıyla ABD hükümetinden sonra dünyadaki en büyük özel gerçek zamanlı veri işleme sistemiydi. Bilet işlemi yapılır yapılmaz yolcu kaydı (PNR) oluşuyordu; envanter ve kayıt aynı işlemin içinde güncelleniyordu.

Proje kolay gitmedi. Programcılardan Bill Elmore’un sözü, süreyi Sing Sing Hapishanesi’yle kıyaslıyor: “Mahkumlar ne zaman çıkacaklarını biliyorlardı.” Belirsiz bitiş tarihi, o günden bugüne büyük rezervasyon projelerinin değişmeyen özelliği.

Uçtaki ekran aptal, akıl merkezde

Acentelerin önündeki Raytheon CRT ekranlar sektörün deyimiyle “aptal terminal”di (dumb terminal): kendi işlem gücü yok, sadece veri gösterip klavye girdisi taşıyor. Envanter hesabı, iş mantığı, kayıt — hepsi ana bilgisayarda. Uç noktada zeka yoktu; bu bir eksiklik değil, tasarım kararıydı. Tek doğruluk kaynağı tek yerde duruyordu.

Tele-işlem bilmeyen tedarikçi seni rakibin yazılımına götürür

TWA ve United donanımı Burroughs ve Univac’tan aldı. İkisinin de ağ ve tele-işlem (teleprocessing) tecrübesi yoktu; projeler teknik krizlere saplandı. Sonuç: iki havayolu da rotayı değiştirip Eastern Airlines’ın IBM tabanlı PARS sistemini satın aldı. IBM’in avantajı ucuz donanım değildi; askeri SAGE projesinden gelen uzaktan erişim tecrübesiydi.

Rezervasyon sistemi doğası gereği uzaktan erişim sistemidir. Tedarikçi seçerken sorulacak soru “işlemci ne kadar hızlı” değil, “bu yükü ağ üzerinden daha önce taşıdı mı”.

PARS sektör standardı oldu: 1971’de 10 havayolundan 9’u

1960’ların sonunda IBM, Eastern Airlines için System/360 üzerinde PARS’ı (Programmed Airline Reservations System) yayınladı. 1971’de United, PARS tabanlı Apollo’yu tanıttı; SABRE de tamamen PARS mimarisine geçti. O yıldan sonra ABD’nin en büyük 10 havayolundan 9’u PARS altyapısı kullanıyordu. Uluslararası sürüm IPARS küresel standart oldu.

1960’larda yazılan kod 21. yüzyıla nasıl çıktı

PARS’ın altındaki işletim sistemi ACP (Airline Control Program), sonra TPF (Transaction Processing Facility) adını aldı. Assembly ile yazıldı; soyutlama katmanı yok, doğrudan makineye konuşuyor. Bellek sabit bloklara bölünmüş — 128 byte, 381 byte, 4K — kod bloğa sığmazsa zincirleniyor (chaining). Bu yapı saniyede çok yüksek hacimde mesajı neredeyse saf I/O hızında işliyor.

Neden değişmedi? Çünkü işi tek: mesaj al, envanteri güncelle, cevap ver. Bu işi milisaniye altında yapan bir çekirdeği daha genel bir şeyle değiştirmenin getirisi, riskini hiç karşılamadı.

Rezervasyon için kurulan sistem şirketin omurgası oldu

Başlangıçta sadece rezervasyon için kurulan altyapı zamanla beş işlevi birden taşır oldu: envanter (koltuk uygunluğu ve kapasite), PNR kaydı (müşteri verisi ve rezervasyon takibi), fiyatlandırma ve alışveriş (rota, tarife, teklif), biletleme (finansal kayıt ve elektronik onay), kalkış kontrolü DCS (check-in, biniş, ağırlık). Havayolunun kârlılığını belirleyen her ticari süreç aynı işlem çekirdeğinden geçiyor.

Pazar konsolide oldu, ama üçte biri hâlâ kendi sistemini koşuyor

Bugün pazarın iki büyük hosting sağlayıcısı var: Amadeus (Altea) ve Sabre (SabreSonic). Konsolidasyon satın almayla ilerledi — Navitaire 2015’te Amadeus’a, Radixx 2019’da Sabre’ye geçti. Shares, SITA Horizon ve Hitit gibi sağlayıcılar ikinci halkada. Çin’de CAAC regülasyonu yerel barındırmayı zorunlu tutuyor; Çinli taşıyıcılar TravelSky ve UniSys Aircore üzerinde.

Konsolidasyon havayolu için risk mi avantaj mı? İkisi de. Standart PSS bakım maliyetini ve entegrasyon yükünü düşürüyor. Ama ürünüyle farklılaşmak isteyen havayolu, standardın sınırına hızlı çarpıyor; proprietary sistemde kalmak o durumda maliyet değil, tercih. Veri egemenliği (data residency) bu denklemi bir kez daha büküyor: Çin’e giren global sağlayıcı ya yerel ortak buluyor ya altyapısını o bölgeye özel kuruyor.

Arayüz değişti, veri modeli değişmedi

Raytheon ekranların yerini bulut ve mobil API’ler aldı. Sunucular, ağlar, istemciler tamamen yenilendi. Değişmeyen tek şey ortadaki blok: PNR ve envanter. 1964’te atılan veri temeli sabit; modern havacılık 60 yıl önce çizilen planın üzerinde uçuyor. Önceki bölümdeki “envanter ve yolcu kaydı ayrı doğdu” tespiti burada kapanıyor: ayrı doğdular ve ayrı kaldılar.

Yarın işe yarayacak dört çıkarım

1. Ortak stack, pahalı olsa bile ucuzdur. 1960’ta üç havayolu üç mimari seçti ve maliyeti üç kez ödedi. Departmanlar ya da şirketler arası sistem geçişinde tek platformda birleşmek başlangıç maliyetini uzun vadede amorti eder.
2. OLTP’de gecikme bütçesi milisaniyedir. Yüksek hacimli işlem çekirdeğinde düşük seviyeli mantık ya da yüksek performanslı mimari lüks değil, gereklilik. TPF’in 60 yıl yaşamasının sebebi bu.
3. Regülasyonu mimariye baştan koy. Çin gibi pazarlarda yerel barındırma ve stratejik ortaklık (TravelSky, UniSys) sonradan eklenen bir özellik değil, işin devam şartı.
4. Hedef hız değil, hata oranı. Manuelden dijitale geçişte SABRE’nin asıl kazanımı 90 dakikadan saniyeye inmek değil, hata payını %1’in altına çekmekti. Yeni sistemin başarı ölçütünü buna göre yaz.

Bu bölümde ne yok: PNR’ın iç yapısı ve neden “kayıt değil sözleşme” olduğu. O sıradaki bölümün konusu.