أنظمة حجز تذاكر الطيران: لماذا لا تزال تعتمد على الحواسيب المركزية؟

عند حجز رحلة طيران عبر الهاتف الذكي في عام 2026، يمر طلبك عبر طبقات متعددة من التكنولوجيا الحديثة، بدءًا من تطبيق الهاتف المحمول، مرورًا بخدمة الويب، وصولًا إلى معالج الدفع، قبل أن يصل إلى النظام الذي يحجز مقعدك فعليًا. هذا النظام، في معظم الحالات، عبارة عن برنامج يعود تاريخه إلى ستينيات القرن الماضي، ويعمل على بنية تحتية تحاول صناعة السفر استبدالها منذ عقود دون جدوى. تتولى شركات Sabre وAmadeus وTravelport مجتمعةً إدارة جميع حجوزات الطيران تقريبًا في العالم. وتعالج هذه الشركات مليارات المعاملات سنويًا عبر مئات شركات الطيران، وآلاف وكالات السفر، وقاعدة بيانات فورية تضم ملايين خيارات المقاعد. يعود تاريخ أقدم هذه الشركات إلى حاسوب IBM المركزي عام 1964، والذي قلّص مدة الحجز من 90 دقيقة إلى ثوانٍ معدودة، مُحدثًا بذلك تغييرًا جذريًا في قطاع الطيران التجاري.

إن قصة بقاء هذه الأنظمة على حالها لا تُعزى إلى جمود تنظيمي أو تحفظ هندسي، بل إلى ما يحدث عندما يصبح البرنامج جزءًا لا يتجزأ من عملية تشغيلية بالغة الأهمية، بحيث لا يُمكن تبرير تكلفة استبداله ومخاطره ضمن أي جدول زمني واقعي. وكيف استجابت الصناعة بتحديث جوهر النظام بدلاً من محاولة استبداله. بالنسبة لأي شخص يعمل على تحديث الأنظمة القديمة على نطاق واسع، تُعد أنظمة حجز تذاكر الطيران أوضح دراسة حالة متاحة لما تعنيه عبارة "أهم من أن تُترك لتفشل" عمليًا.

الأصل: لماذا انتصرت الحواسيب المركزية في حل مشكلة شركات الطيران

لم يكن نظام SABRE (بيئة أبحاث الأعمال شبه الآلية) منتجًا في الأصل، بل كان حلًا مُصممًا خصيصًا لأزمة تشغيلية محددة. ففي أواخر خمسينيات القرن الماضي، كانت شركة الخطوط الجوية الأمريكية تنمو بوتيرة أسرع من قدرة نظام الحجز اليدوي لديها على استيعابها. وكان حجز مقعد يتطلب مكالمة هاتفية، وفحصًا يدويًا لبطاقة جرد ورقية، وانتظارًا، ثم معاودة الاتصال، وتسجيلًا ورقيًا، وهي عملية تستغرق في المتوسط ​​90 دقيقة لكل حجز، ولم تكن قابلة للتوسع.

عندما بدأ نظام SABRE العمل بكامل طاقته عام 1964، والذي بُني على جهازي حاسوب مركزيين من طراز IBM 7090 وارتبط بـ 1,500 محطة طرفية في جميع أنحاء الولايات المتحدة وكندا، كان بإمكانه معالجة 7,500 حجز في الساعة بمعدلات خطأ شبه معدومة. ولأول مرة، أصبح بإمكان شركات الطيران الاحتفاظ بمعلومات فورية عن المقاعد المتاحة، وتخزين سجلات الركاب كاملة، وتفعيل الحجوزات الفورية عبر شبكتها بأكملها. وانخفضت مدة الحجز من 90 دقيقة إلى ثوانٍ معدودة.

لم يُختر الخيار المعماري الذي مكّن من ذلك، وهو معالجة المعاملات المركزية على أجهزة الحاسوب المركزية، لأسباب فلسفية، بل لأنه كان الخيار المعماري الوحيد المتاح عام ١٩٦٤ القادر على تلبية متطلبات زمن الاستجابة والموثوقية والوصول المتزامن لإدارة مخزون شركات الطيران في الوقت الفعلي. وقد أثبت هذا الخيار نجاحًا باهرًا لدرجة أنه أصبح النموذج المعماري الذي بُنيت عليه جميع أنظمة حجز تذاكر الطيران اللاحقة.

أصبحت منصة معالجة المعاملات (TPF) من IBM، المصممة أصلاً لنظام SABRE، بيئة التشغيل الأساسية لهذا القطاع بأكمله. ولا تزال معظم البنوك وشركات التأمين وتجار التجزئة وشركات الطيران الكبرى تستخدمها، وفقًا لشركة IBM. فعندما تأسست شركة Amadeus عام 1987، اعتمدت على منصة TPF. وعندما أطلقت شركة Galileo (التي تُعرف الآن باسم Travelport) نظام التوزيع العالمي (GDS)، اعتمدت أيضًا على منصة TPF. وتتعايش اليوم ثلاثة أجيال من أنظمة خدمات الركاب في قطاع الطيران التجاري، ولا يزال العديد منها يعمل على أجهزة TPF المركزية، ليس لأن هذه التقنية لم تُشكك فيها قط، بل لأن إنتاجية المعاملات والموثوقية وتحمل الأعطال التي توفرها منصة TPF على أجهزة الحواسيب المركزية أثبتت صعوبة تكرارها على نطاق مماثل على بنى بديلة.

ما تفعله هذه الأنظمة فعلياً على نطاق واسع

إن النطاق الذي تعمل به أنظمة حجز تذاكر الطيران ليس بديهياً من منظور هندسة البرمجيات. فنظام التوزيع العالمي لا يقتصر على التعامل مع توفر المقاعد فحسب، بل يدير أيضاً مشكلة مخزون تركيبية بالغة التعقيد.

تتضمن الرحلة الواحدة عبر المحيط الأطلسي مئات فئات الأسعار. ولكل فئة قواعدها الخاصة: متطلبات الحجز المسبق، والحد الأدنى للإقامة، وتواريخ الحظر، ورسوم التغيير، وإمكانية التوقفات، واتفاقيات المشاركة بالرمز مع شركات الطيران الشريكة. يُنشئ الحجز الذي يشمل شركتي طيران، ورحلة ربط، ورحلة ذهاب وعودة، مصفوفة من آلاف تركيبات الأسعار المتاحة التي يجب فحصها وتسعيرها ومقارنتها بالمخزون المتاح في الوقت الفعلي قبل الحصول على رد، عادةً في أقل من ثانية.

خلال فترات ذروة الحجوزات، يُعالج نظاما Sabre وAmadeus معًا عشرات الآلاف من المعاملات في الثانية الواحدة، وليس في الدقيقة. تتضمن كل معاملة بحثًا فوريًا عن المخزون، وتقييمًا لقواعد الأسعار، وإنشاء أو تعديل سجل اسم الراكب (PNR)، والتنسيق مع أنظمة مراقبة المغادرة، وبرامج المسافر الدائم، والخدمات الإضافية. يُقاس وقت الاستجابة المضمون بالمللي ثانية، لأن أي وكيل سفر أو محرك حجز ينتظر أكثر من بضع ثوانٍ للتحقق من السعر سينتهي وقته، وسيُعيد المحاولة أو يتخلى عن المعاملة.

يُحقق نظام TPF على أجهزة الحواسيب المركزية هذه الإنتاجية بمعدل فشل يصعب على متخصصي تكنولوجيا المعلومات في القطاعات الأخرى تصديقه. فميزة تحمل الأعطال في الحواسيب المركزية، والمعالجات الاحتياطية، والمكونات القابلة للاستبدال أثناء التشغيل، وعقود من تطوير أنظمة التشغيل المُحسّنة، تُنتج توافرًا بنسبة 1990% كمعيار تشغيلي قياسي، وليس هدفًا طموحًا. وقد شكّل تكرار هذا الأداء بتكلفة مماثلة على البنية التحتية السحابية التحدي التقني الرئيسي لكل برنامج لتحديث تكنولوجيا المعلومات في شركات الطيران منذ تسعينيات القرن الماضي.

محاولات التحديث: ما الذي توصلت إليه البرامج التي استمرت لعقد من الزمن فعلياً؟

إن تاريخ تحديث نظام حجز شركات الطيران هو تاريخ برامج انطلقت لاستبدال النظام الأساسي، ووصلت بعد سنوات إلى نظام هجين يغلف النظام الأساسي بدلاً من ذلك.

انتهى مشروع "جيت ستريم" التابع لشركة الخطوط الجوية الأمريكية، والذي انطلق في العقد الأول من الألفية الثانية بهدف واضح هو استبدال نظام "سيبر" المركزي، باعتماد منتج "سيبر" جديد بدلاً من بناء بديل. وقد واجه الافتراض الأولي، الذي كان يرجح كفة البناء الداخلي على الشراء، والذي مفاده أن بناء بديل داخلياً سينتج نظاماً أفضل وأسرع، نفس الواقع الذي تواجهه تقريباً كل برامج استبدال الأنظمة القديمة واسعة النطاق: احتوى النظام الحالي على متطلبات لم يكن أحد على دراية بها حتى عجز النظام البديل عن تلبيتها.

نحتاج إلى التعمق أكثر في بنية النظام وتغيير المحرك الأساسي وفصل القواعد لكي نتمكن من تعديلها بسرعة. هذا التصريح، الصادر عن قيادة قسم تقنية المعلومات في الخطوط الجوية الأمريكية خلال برنامج جيت ستريم، يصف المشكلة بدقة. فقد تراكمت القواعد المضمنة في النظام القديم، ومنطق حساب الأجرة، وتطبيقات اتفاقيات المشاركة بالرمز، وحسابات الامتثال التنظيمي، وتكاملات إدارة الإيرادات، على مدى عقود من التغيرات في بيئة العمل، ولم تكن موثقة بأي شكل من الأشكال يسمح باستخراجها دون تشغيل النظام الحالي ومراقبة سلوكه.

استغرق برنامج التحديث الخاص بشركة سيبر، الذي بدأ فعلياً في العقد الثاني من الألفية، أكثر من عقد من الزمن وكلف مليارات الدولارات لنقل غالبية برمجياتها من البنية التحتية المركزية المحلية. وبحلول عام 2019، كان ما يقرب من 11% من برمجيات سيبر لا يزال يعمل في مراكز البيانات المحلية، بينما تم نقل الباقي. وفي فبراير 2026، جددت سيبر اتفاقية نظام دعم العمليات (PSS) طويلة الأجل مع ويست جيت، مما يدل على أنه حتى بعد عقد من جهود التحديث واستثمار مليارات الدولارات، لا يزال نظام دعم العمليات (PSS) هو الركيزة التجارية للشركة.

حققت أماديوس إنجازًا هامًا في التخلص التدريجي من الحواسيب المركزية، حيث استبدلت آخر حواسيبها المركزية ببنية تحتية سحابية. وقد حافظ نهج أماديوس، الذي اعتمد على الاستبدال التدريجي للمكونات الوظيفية مع الحفاظ على نموذج البيانات الأساسي وبنية المعاملات، على القرارات المعمارية التي وُضعت في الأصل على الحواسيب المركزية حتى مع تغير الأجهزة. فقد نُقلت دلالات المعاملات، وبنية سجلات أسماء الركاب، ومنطق إدارة المخزون إلى بنية تحتية حديثة مع الحفاظ على تصميمها الأساسي.

لماذا يُعدّ الاستبدال أصعب مما يبدو: التعقيد الخفي

التفسير الشائع لاستمرار أنظمة حجز تذاكر الطيران على الحواسيب المركزية هو التكلفة والمخاطرة. كلاهما حقيقيان، لكنهما مجرد أعراض لحقيقة تقنية أعمق تستحق الفهم الدقيق، لأنها تنطبق على كل برنامج لتحديث الأنظمة القديمة ذات الأهمية البالغة.

قواعد العمل الموجودة فقط في الشيفرة البرمجية. يُمثل منطق حساب الأجرة في نظام التوزيع العالمي عقودًا من المتطلبات التنظيمية، واتفاقيات شركات الطيران الثنائية، ومراجعات معايير الاتحاد الدولي للنقل الجوي (IATA)، وتغييرات قواعد العمل، والتي لا يُوثق أي منها بشكل مستقل عن الشيفرة البرمجية التي تُنفذها. المواصفات هي التنفيذ. استبدال التنفيذ دون المواصفات يعني مراقبة سلوك النظام الحالي بشكل شامل بما يكفي لإعادة بناء ما كانت ستنص عليه المواصفات، وهي عملية تستغرق سنوات ولا تكتمل أبدًا، لأن نطاق المراقبة لا يمكن أن يكون شاملاً بما يكفي لرصد جميع الحالات الشاذة.

دلالات المعاملات التي تعجز البنى الحديثة عن محاكاتها. يوفر نظام TPF معالجة معاملات متزامنة وذرية مع ضمان اتساق كامل عبر سجل بيانات المسافر (PNR)، وحجز المقعد، وتحديث سجل المسافر، وتفويض الدفع، وسجل التأكيد، حيث يتم الالتزام بها كوحدة ذرية واحدة أو لا يتم الالتزام بها على الإطلاق. تتطلب محاكاة ذلك على بنى الخدمات المصغرة الموزعة تنسيقًا دقيقًا، ومعاملات تعويضية، وإدارة أقفال موزعة، وهو أمر معقد وقد يكون أبطأ من نظيره المتزامن في الحواسيب المركزية. تُظهر تجربة صناعة الطيران أن "الاتساق النهائي" ليس خاصية مقبولة لمخزون المقاعد، فالرحلة المباعة بالكامل تُعد فشلًا كارثيًا ملموسًا على مستوى العمليات، وليست مجرد تناقض مؤقت يمكن حله لاحقًا.

سطح التكامل. يرتبط نظام خدمات الركاب (PSS) المتطور لشركات الطيران بمئات الأنظمة الخارجية: مراقبة المغادرة، وإدارة الإيرادات، وبرامج المسافر الدائم، وأنظمة المطارات، وروابط أنظمة التوزيع العالمية (GDS) التابعة لجهات خارجية، وشركاء المشاركة بالرمز، والتقارير التنظيمية، وغيرها. لكل رابط اتفاقيات واجهة محددة، وتنسيقات رسائل، ومتطلبات توقيت، وآليات معالجة أخطاء، يطبقها النظام الحالي، وتعتمد عليها جميع الأنظمة التابعة. يتطلب استبدال نظام خدمات الركاب إما الحفاظ على جميع اتفاقيات الواجهة الحالية في آن واحد (مما يقيد بنية الاستبدال) أو تنسيق التغييرات مع كل نظام تابع (مما يوسع النطاق إلى ما يتجاوز قدرة أي برنامج منفرد على إدارته).

مشكلة البيانات الحية. تُعدّ حجوزات الطيران بيانات حية، فهي حجوزات تتم قبل أشهر ويجب الالتزام بها تمامًا كما تم حجزها. لا توجد نقطة انتقال سلسة يمكن عندها ترك بيانات النظام القديم. يجب أن تشمل عملية الترحيل جميع سجلات أسماء الركاب الحية من النظام القديم إلى النظام الجديد، مع الحفاظ على جميع القواعد والأسعار والقيود والخدمات الإضافية المرتبطة بها. وقد أثبت ترحيل سجلات أسماء الركاب على نطاق عالمي، مع ضمان عدم فقدان أي بيانات والحفاظ على السلوك نفسه، أنه أحد أصعب التحديات التقنية في تحديث المؤسسات.

الاستجابة المعمارية: التحديث حول النواة

إن النهج الذي نجح بالفعل، في أماديوس، وفي سابر، وفي شركات الطيران الفردية، ليس الاستبدال بل التغليف الاستراتيجي والاستخراج التدريجي.

تُتيح واجهة برمجة التطبيقات (API) الوصول إلى وظائف الحجز الأساسية عبر واجهات برمجة تطبيقات REST أو SOAP الحديثة، مما يسمح للتطبيقات الجديدة بالتفاعل مع النظام القديم من خلال واجهة حديثة دون المساس بمنطق المعاملات الأساسي. وقد قامت شركات الطيران ببناء تطبيقات جوال، ومحركات حجز عبر الإنترنت، وأدوات خدمة عملاء بالاعتماد على طبقات واجهة برمجة التطبيقات التي تُترجم الطلبات الحديثة إلى استدعاءات معاملات TPF وتُعيد استجابات مُهيكلة. يتم استبدال شاشة الجهاز القديمة بواجهة مستخدم رسومية حديثة، بينما تبقى معالجة المعاملات الأساسية دون تغيير.

يُستخدم نموذج "الخنق" للوظائف غير الأساسية. تُستخرج الوظائف المجاورة للوظائف الأساسية، مثل إدارة الإيرادات، وإدارة برامج الولاء، وإعداد التقارير والتحليلات، وجدولة الطاقم، واحدة تلو الأخرى، ثم يُعاد تنفيذها على بنية تحتية حديثة. يُقلل كل استخراج من حجم النظام القديم دون المساس بجوهر المعاملات الذي ينطوي على أعلى المخاطر. على مدار عقد من الاستخراج التدريجي، يتقلص دور النظام القديم من منصة تطبيقات شاملة إلى محرك معاملات مُركز.

بنية تحتية سحابية مع الحفاظ على البنية الأصلية. نقلت عملية إيقاف تشغيل الحواسيب المركزية لشركة أماديوس أحمال العمل إلى البنية التحتية السحابية مع الحفاظ على بنية المعاملات التي نشأت على الحواسيب المركزية. تغيرت الأجهزة، لكن تصميم البرمجيات، ونموذج البيانات، ودلالات المعاملات، وبنية سجلات أسماء الركاب، حافظت على القرارات المعمارية التي أثبتت صحتها على مدى عقود.

إدارة جديدة للعروض والطلبات بالتوازي مع نظام سجلات بيانات المسافر (PNR) التقليدي. تُطبّق شركات الطيران معيار IATA ONE Order، الذي يستبدل سجلات بيانات المسافر (PNR) بنموذج حديث لإدارة الطلبات، كطبقة إضافية إلى جانب النظام الحالي القائم على سجلات بيانات المسافر (PNR). وتُشير تقنيات الجيل التالي للعروض والطلبات من Sabre، التي ورد ذكرها في تجديد WestJet لعام 2026، إلى أن هذا هو المسار الأمثل، ليس استبدال نظام دعم الركاب (PSS)، بل إضافة طبقة تجارية حديثة تتطور تدريجيًا لتستوعب نسبة متزايدة من الحجوزات، بينما يتولى نظام سجلات بيانات المسافر (PNR) الأساسي معالجة النسبة المتبقية.

ماذا يعني هذا بالنسبة لأي عملية تحديث للأنظمة القديمة ذات الأهمية البالغة؟

إن قصة نظام حجز تذاكر الطيران ليست حكراً على قطاع الطيران. إنها المثال الأبرز لنمط يظهر في الأنظمة المصرفية الأساسية، وإدارة وثائق التأمين، وفواتير الاتصالات، ومعالجة استحقاقات الحكومة: برمجيات تصبح المواصفات المرجعية لقواعد العمل، وتعمل كمركز تكامل لعشرات الأنظمة التابعة، وتعمل على نطاق واسع وبمستوى موثوقية يجعل الاستبدال الشامل أمراً غير عملي على الإطلاق.

الدروس متطابقة في جميع القطاعات:

إن استخلاص قواعد العمل من الشيفرة البرمجية، قبل البدء بأي عملية تحديث، ليس بالأمر الاختياري. فبرامج COBOL وTPF التي تُنفذ حسابات الأجرة، ومنطق اتفاقيات المشاركة بالرمز، وقواعد الامتثال التنظيمي، هي الوثائق الوحيدة المتبقية لتلك القواعد. ولا يمكن لأي عملية تحديث لا تستخلص هذا المنطق وتتحقق من صحته أولاً أن تُنتج بديلاً يعمل بشكل صحيح في جميع الحالات، لأنها لا تستطيع معرفة جميع الحالات دون تحليل الشيفرة البرمجية بأكملها.

تُحدد خريطة التبعية تسلسل عملية التحديث. لم تنجح أي شركة طيران في استبدال نظام خدمات الركاب (PSS) الخاص بها بالبدء بالمكون الأكثر أهمية وتكاملاً. كل عملية تحديث ناجحة بدأت من الأنظمة الطرفية، وأنظمة التقارير، والخدمات المساعدة، والوظائف الإدارية غير الأساسية، ثم انتقلت تدريجياً إلى الداخل. هذا التسلسل مُستمد من مخطط التبعية: فالمكونات التي لديها أقل عدد من التبعيات الواردة هي الأنسب للبدء بها.

يُعد التحقق التشغيلي في كل خطوة أمرًا لا غنى عنه. ويُعتبر نهج التحقق المزدوج، الذي يتم فيه تشغيل النظام الجديد بالتوازي مع النظام القديم، ومقارنة المخرجات، والتحقق من التكافؤ قبل تحويل أي حركة مرور، النهج الوحيد الذي يلبي متطلبات موثوقية الأنظمة التي تترتب على أعطالها عواقب مادية ومالية وتنظيمية.

كيفية SMART TS XL ينطبق على تحليل الإرث المرتبط بشركات الطيران

تواجه شركات الطيران التي تستخدم أنظمة Sabre أو Amadeus PSS جنبًا إلى جنب مع برامج COBOL الخاصة بها، وأنظمة حساب الأسعار، ومحاسبة الإيرادات، وحساب نقاط الولاء، والتقارير التنظيمية، نفس التحدي التحليلي الذي يواجهه كل برنامج تحديث للحاسوب المركزي للمؤسسات: فهم ما يحتويه الكود فعليًا قبل اتخاذ قرار بشأن ما يجب فعله به.

SMART TS XLالصورة تحليل الكود الثابت يستخلص هذا النظام منطق قواعد العمل المضمنة في برامج كوبول، وقواعد التحقق من صحة الأسعار، وحسابات إيرادات المحاسبة، ومنطق أهلية فئات الولاء، والتي لا توجد إلا في شفرة البرنامج. بالنسبة لشركات الطيران التي تخطط لتحديث الأنظمة المجاورة دون المساس بنظام إدارة خدمات الركاب (PSS) الأساسي، يوفر هذا الاستخلاص المواصفات التي يجب أن يتوافق معها النظام البديل.

تُنشئ خريطة تبعية التطبيقات مخطط التبعية الذي يُحدد تسلسل الترحيل: أي برامج جانب شركة الطيران تعتمد على أي مصادر بيانات من نظام دعم العمليات (PSS)، وأي برامج إعداد التقارير تعتمد على أي مخرجات دفعية بلغة كوبول، وأي الأنظمة اللاحقة يجب تحديثها عند تغيير أي مكون. مخطط التبعية هو ما يُتيح التحديث التدريجي والآمن، وهو نفس النهج الذي استخدمته شركتا سابر وأماديوس للأنظمة الأساسية، مُطبقًا على كود جانب شركة الطيران المُحيط بها.

تُجيب قدرة تحليل الأثر على السؤال الذي يسبق كل قرار تحديث: إذا تغير هذا البرنامج، فما هي البرامج الأخرى التي ستتأثر؟ بالنسبة لأنظمة شركات الطيران حيث قد يؤثر تغيير في حسابات برنامج محاسبة الإيرادات على التقارير التنظيمية، وتسوية الشركاء، والدمج المالي في آن واحد، فإن معرفة نطاق الأثر قبل إجراء أي تغيير هو شرط أساسي للتحكم في التغيير بما يلبي متطلبات موثوقية شركة الطيران.

يُقدّم تحليل تحديث الأنظمة القديمة جردًا شاملاً لما قبل التحديث: كل برنامج ضمن النطاق، وتعقيده، وتوابعه، ونسبة التعليمات البرمجية غير المستخدمة فيه، وتصنيف مخاطر الترحيل. ويكمن الدرس المستفاد من أي برنامج لتحديث أنظمة شركات الطيران، وهو البدء من الأطراف، والعمل نحو الداخل، والتحقق من صحة كل خطوة، في ضرورة معرفة مواقع الأطراف وبنية التوابع. وتأتي هذه المعرفة من التحليل الهيكلي للتعليمات البرمجية الفعلية، وليس من الوثائق التي كُتبت قبل تطور التعليمات البرمجية.

الطبقات الجيولوجية للبرمجيات ذات الأهمية البالغة

عندما تحجز رحلة طيران عبر هاتفك الذكي في عام 2026، فأنت تتعامل مع برنامج ذي طبقات جيولوجية متعددة ومتميزة. واجهة حديثة في السطح، وطبقة واجهة برمجة التطبيقات (API) تحتها، ومحرك معاملات نظام إدارة المدفوعات (PSS) أسفلها، يعمل على بنية تحتية تغيرت بشكل كبير منذ ستينيات القرن الماضي، لكنها لا تزال تحافظ على دلالات المعاملات ونماذج البيانات التي كانت صحيحة عند تصميمها، والتي أثبتت موثوقيتها العالية بحيث لا يمكن التخلي عنها.

إن نظام حجز تذاكر الطيران ليس فشلاً في التحديث، بل هو نتاج ستة عقود من القرارات الرشيدة التي اتخذها المهندسون والمديرون التنفيذيون الذين أدركوا، في كل مرة يُقترح فيها استبدال النظام، أن مخاطر الخطأ تفوق تكلفة الإبقاء على النظام الناجح. إن الأنظمة التي تصمد كل هذه المدة إنما تفعل ذلك لأنها تستحقه، معاملةً تلو الأخرى، ورحلةً تلو الأخرى، وموسم حجز تلو الآخر.

الدرس العملي لأي فريق تحديث ليس أن الأنظمة القديمة لا يجب استبدالها أبدًا، بل أن قرار استبدالها يجب أن يُتخذ بناءً على معرفة تامة بمحتوياتها، وما يعتمد عليها، والنطاق الكامل للتغيير، لا على تقديرات متفائلة تُجرى قبل قياس مدى تعقيدها. وقد تعلمت صناعة الطيران هذا الدرس بطريقة مكلفة. أما أدوات التحليل التي تُنتج معرفة هيكلية كاملة قبل كتابة أول سطر من التعليمات البرمجية الجديدة، فهي التي تُتيح تعلمها بطريقة أقل تكلفة.