أساليب تحديث الأنظمة القديمة: من النقل المباشر إلى الخوارزمية الخانقة

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

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

ما هو تحديث الأنظمة القديمة؟

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

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

لماذا لا يمكن للأنظمة القديمة أن تنتظر إلى أجل غير مسمى؟

هناك عدة عوامل متضافرة تجعل تكلفة التأجيل أعلى في عام 2026 مما كانت عليه قبل ثلاث سنوات:

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

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

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

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

المبادئ السبعة الأساسية: الإطار الجوهري لقرارات التحديث

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

الإستراتيجيات	ماذا تعني	متى تستخدمه	الجدول الزمني النموذجي	مستوى الخطر
تقاعد	إيقاف تشغيل النظام، لم يعد النظام مطلوبًا	الأنظمة الزائدة عن الحاجة، أو غير المستخدمة، أو التي تم استبدالها بالكامل	فوري	منخفض
احتفظ	احتفظ بها كما هي مع إجراء تغييرات طفيفة	النظام يعمل، وتكلفة التحديث تفوق الفائدة.	مستمرة	منخفض
إعادة الاستضافة	نقل البيانات إلى السحابة دون أي تغييرات في التعليمات البرمجية	أحمال العمل غير الحرجة، والنجاحات السريعة، وخفض تكاليف البنية التحتية	أشهر 1 - 3	منخفض
إعادة النظام الأساسي	قم بالتغيير مع إجراء تغييرات محددة على المنصة (مثل قاعدة البيانات المُدارة).	الحاجة إلى اقتران معتدل، أو تحسين الأداء المحدد، أو تحسين التكلفة	أشهر 2 - 6	متوسط
ريفاكتور	إعادة هيكلة الكود دون تغيير السلوك الخارجي	تقليل الديون التقنية، وتحسين قابلية الصيانة، وتغطية الاختبار	أشهر 3 - 12	متوسط
مهندس خلفي	إعادة تصميم لتناسب الحوسبة السحابية الأصلية، أو الخدمات المصغرة، أو بنية جديدة	متطلبات قابلية التوسع الكبيرة، وتغيير المنصة الاستراتيجي	أشهر 12 - 24	مرتفع
استبدل	استغنِ عن النظام المخصص، واعتمد البرمجيات كخدمة (SaaS) أو بديلاً حديثاً.	وظائف السلعة يتم تلبيتها بشكل أفضل من خلال المنتجات الحالية	أشهر 6 - 18	متوسطة عالية

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

ثمانية مناهج للتحديث بالتفصيل

1. إعادة الاستضافة (نقل الملفات)

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

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

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

2. إعادة بناء المنصة

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

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

3. إعادة البناء

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

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

4. إعادة تصميم الهندسة المعمارية

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

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

الأفضل لـ: الأنظمة التي لا يمكن فيها تلبية متطلبات قابلية التوسع أو المرونة أو المرونة المعمارية ضمن الهيكل الحالي، والتي تتمتع فيها المؤسسة بالنضج الهندسي اللازم لتشغيل الأنظمة الموزعة.

5. نمط التين الخانق

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

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

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

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

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

6. تغليف واجهة برمجة التطبيقات (التغليف)

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

الأفضل لـ: الأنظمة التي يجب أن تبقى قائمة بشكل دائم (بسبب المتطلبات التنظيمية أو التكلفة أو التعقيد) ولكنها تحتاج إلى المشاركة في أنماط التكامل الحديثة. يُعد تغليف واجهة برمجة التطبيقات (API) الطريقة التي تجعل بها العديد من المؤسسات برامج COBOL متاحة لتطبيقات الويب والهواتف المحمولة الحديثة دون الحاجة إلى تعديل كود COBOL.

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

7. إعادة البناء من الصفر

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

المخاطرة: كل مؤسسة حاولت إعادة بناء نظام حيوي بشكل جذري اكتشفت أن النظام الحالي يحتوي على منطق أعمال غير موثق لم يقم النظام الجديد بمحاكاته. ففي عام 2018، تسبب نقل تكنولوجيا المعلومات في بنك TSB البريطاني في حرمان 1.9 مليون عميل من الوصول إلى حساباتهم لأسابيع. كما تم التخلي عن مشروع ملف القضية الافتراضي لمكتب التحقيقات الفيدرالي بعد استثمار 170 مليون دولار في تطويره. وأدى استبدال نظام الرواتب في هيئة الصحة في كوينزلاند إلى حصول 35,000 ألف عامل في المستشفى على رواتب أقل أو أكثر من المستحقة لعدة أشهر. في كل حالة، تجاوز تعقيد النظام الحالي، وقواعد العمل المضمنة فيه، وحالاته الاستثنائية، وسلوكه التشغيلي في ظل ظروف لم يتم تحديدها صراحةً، ما كان فريق الاستبدال يفهمه قبل بدء المشروع.

8. التحديث بمساعدة الذكاء الاصطناعي

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

تستخدم أدوات ترجمة برامج COBOL إلى Java نماذج لغة مُحسّنة (LLMs) مُعدّة خصيصًا لكلتا اللغتين لإنتاج ترجمات أولية لبرامج COBOL، والتي يقوم مهندسو البرمجيات بمراجعتها وتحسينها. تُغني الترجمة عن معظم جهد التحويل الآلي، ولكنها لا تُغني عن الحاجة إلى فهم بشري لما يجب أن يفعله الكود المُترجم.

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

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

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

اختيار النهج الصحيح: إطار عمل لاتخاذ القرار

يعتمد النهج الصحيح لتحديث أي نظام على أربعة عوامل يتم تقييمها معًا: الأهمية التجارية، والتعقيد التقني، والقيمة الاستراتيجية، والميزانية والجدول الزمني المتاحين.

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

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

تحديات تحديث الأنظمة القديمة: ما الذي يعرقل البرامج؟

إن فهم أسباب فشل برامج التحديث لا يقل أهمية عن فهم المناهج المتاحة. وتتسم أسباب الفشل بالاتساق التالي:

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

محاولات التحديث الجذري. تفشل المؤسسات التي تحاول استبدال نظامها بالكامل دفعة واحدة في تاريخ محدد، فشلاً ذريعاً في التحديث. وتشترك جميع حالات الفشل الموثقة جيداً في التحديث، مثل بنك TSB، وصندوق FBI VCF، وهيئة الصحة في كوينزلاند، في هذا النمط. أما التحديث التدريجي مع التحقق المستمر في كل خطوة فهو النهج الأمثل للنجاح.

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

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

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

التقييم الذي يجب أن يسبق أي قرار بشأن النهج

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

يؤدي التقييم الهيكلي، الذي يقوم بتحليل الشفرة المصدرية الفعلية لكل تطبيق ضمن النطاق وبناء نموذج التبعية انطلاقاً مما تفعله الشفرة فعلياً، إلى إنتاج قاعدة الأدلة لكل قرار لاحق:

جرد البرامج. كم عدد البرامج الموجودة فعلياً، بما في ذلك تلك غير الموثقة. في بيئات الأنظمة القديمة الكبيرة، يتجاوز العدد الفعلي عادةً العدد الموثق بنسبة 20-30%.

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

تحديد التعليمات البرمجية غير المستخدمة. يمكن استبعاد البرامج التي لا يتم استدعاؤها مطلقًا من أي مسار تنفيذ إنتاجي من نطاق التحديث بشكل كامل. في محافظ الأنظمة القديمة النموذجية، تمثل التعليمات البرمجية غير المستخدمة ما بين 10% و25% من إجمالي التعليمات البرمجية، وهو ما يمثل تخفيضًا كبيرًا في النطاق يمكن تحقيقه في مرحلة التقييم.

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

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

كيفية SMART TS XL يدعم تحديث الأنظمة القديمة

إن التقييم الهيكلي الموصوف أعلاه هو بالضبط ما SMART TS XL يقوم النظام بالأتمتة. من خلال تحليل كل برنامج COBOL، وتدفق وظائف JCL، ودفتر النسخ، ووحدة PL/I، وبرنامج RPG، ومخطط SQL، والمكونات المرتبطة به في وقت واحد، فإنه يبني نموذج التبعية الكامل الذي يجعل تخطيط التحديث قائمًا على الأدلة بدلاً من أن يكون قائمًا على الافتراضات.

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

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

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

تتيح إمكانية البحث المؤسسي إمكانية الاستعلام عن النموذج الهيكلي طوال برنامج التحديث متعدد السنوات: العثور على كل برنامج يقرأ من مجموعة بيانات معينة، وكل ملف نسخ يحدد حقلاً معيناً، وكل مهمة JCL تستدعي برنامجاً معيناً، في ثوانٍ، عبر ملايين الأسطر من التعليمات البرمجية بأي مزيج من اللغات.

SMART TS XLالصورة تصور الكود يقوم بإنتاج مخططات التبعية ومخططات تدفق البرامج التي تجعل بنية النظام غير الموثقة قابلة للقراءة لفريق التحديث بأكمله، بما في ذلك المهندسين الذين لم يروا لغة COBOL من قبل ويحتاجون إلى فهم ما تفعله البرامج التي يحلون محلها بالفعل.

التحديث التدريجي: المبدأ الكامن وراء كل برنامج ناجح

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

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

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