صياغة التميز في البرمجيات
دعنا نبني شيئاً استثنائياً معاً.
اعتمد على شركة Lasting Dynamics للحصول على جودة برمجيات لا مثيل لها.
ميشيل سيمينو
29 مايو 2026 • 15 دقيقة للقراءة
تتبع قرارات تحديث الأنظمة القديمة إطار عمل "6R" (إيقاف التشغيل، والاحتفاظ، وإعادة الاستضافة، وتغيير المنصة، وإعادة الهيكلة، وإعادة البناء). بالنسبة للتطبيقات الحيوية الخاضعة للتنظيم، يتراوح التكلفة بين 400 ألف يورو و1.2 مليون يورو وتستغرق من 12 إلى 24 شهراً؛ أما بالنسبة لإعادة بناء الأنظمة المصرفية أو التأمينية الأساسية، فتتراوح التكلفة بين 4 ملايين يورو و25 مليون يورو أو أكثر وتستغرق من 24 إلى 48 شهراً مع تشغيل مزدوج متوازي. يعد تغيير المنصة هو الخطوة الأولى الأقل استخداماً، ولكنها غالباً ما تكون الخطوة الصحيحة. تعد عمليات إعادة البناء الكبيرة دون الانتقال التدريجي من أسباب فشل البرنامج #1.
كان لدى أحد البنوك التي تعاملنا معها العام الماضي نظام أساسي لإدارة القروض تمت برمجته بلغة COBOL في عام 1996. وكان هذا النظام يعمل على حاسوب مركزي مستأجر من مورد لم يعد يقدم تدريبًا للمهندسين على هذه الأجهزة. وكان كل طلب تغيير يستغرق أربعة أشهر. وكانت كل عملية تدقيق تكلف ثروة. وكان مجلس الإدارة يتحدث عن "تحديث" هذا النظام منذ تسع سنوات.
هذا هو الشكل الحقيقي لتحديث الأنظمة القديمة في عام 2026. إنه ليس مجرد عرض تقديمي عن "التحول الرقمي". بل هو حساب دقيق لكيفية استبدال أنظمة لا تزال تدر أرباحًا، ولا تزال خاضعة للرقابة التنظيمية، ولا يفهمها سوى ثلاثة أشخاص على الأرجح في العالم - دون تعطيل سير العمل.
تم إعداد هذا الدليل خصيصًا لرؤساء قسم التكنولوجيا (CTO) ونواب الرئيس لشؤون الهندسة ومديري تكنولوجيا المعلومات الذين يتعين عليهم اتخاذ هذا القرار فعليًّا. ويغطي الدليل إطار عمل "الـ 6R" ونطاقات التكلفة الفعلية والأنماط التي نستخدمها لـ تحديث الحواسيب المركزية, تحديث لغة COBOLو من النظام المتكامل إلى الخدمات الصغيرة عمليات الترحيل، والضوابط التشغيلية المطلوبة في القطاعات الخاضعة للتنظيم. لا توجد هنا عبارات مبتذلة من قبيل "تقبل التغيير". بل مجرد هندسة بحتة.
هل بدأت بالفعل في دراسة برنامج التحديث؟ انتقل مباشرة إلى خطة عمل مدتها 12 شهراً, ، أو حجز تقييم للتحديث.
تحديث الأنظمة القديمة هو عملية منظمة تهدف إلى ترقية أنظمة البرمجيات المتقادمة — وعادةً ما تكون تطبيقات الحواسيب المركزية، أو قواعد البرمجة المتجانسة، أو المنصات التي انتهى عمرها الافتراضي — إلى بنى ونظم تشغيل ونماذج تشغيل حديثة. ويستخدم أطر عمل مثل 6R (التقاعد، والاحتفاظ، وإعادة الاستضافة، وإعادة التهيئة، وإعادة البناء) لتصنيف كل تطبيق وتطبيق المسار الأقل خطورة نحو مكدس حديث وقابل للصيانة ومتوافق.
عادةً ما تستغرق عملية نقل منصة تطبيق واحد غير حيوي ما بين 6 إلى 12 شهراً. أما إعادة هيكلة تطبيق حيوي في بيئة خاضعة للتنظيم فتستغرق ما بين 12 إلى 24 شهراً. تستغرق إعادة بناء النظام الأساسي بالكامل للبنوك أو شركات التأمين من 24 إلى 48 شهراً، بما في ذلك 6 إلى 18 شهراً من التسوية المزدوجة المتوازية قبل الانتقال. وعادةً ما تتأخر البرامج التي تحاول إجراء ترحيل شامل لمجموعة كاملة من الأصول بأكثر من 18 شهراً.
أقوى حجة لصالح تحديث الأنظمة القديمة - أو، إذا نظرنا إلى الأمر من منظور كل نظام على حدة،, تحديث التطبيقات القديمة - ليس دينًا تقنيًا. إنه التكلفة البديلة للاحتفاظ بأنظمة تعرقل كل مبادرة أخرى.
في جميع مشاريعنا في قطاعي البنوك والتأمين، تبدو الأعراض المتكررة متطابقة تقريبًا:
عندما نقوم بتقدير التكلفة الإجمالية للملكية على مدى خمس سنوات في حالة "عدم اتخاذ أي إجراء" مقارنةً بنهج منظم تحديث التطبيقات القديمة في المسار الصحيح، لا يكون سيناريو عدم اتخاذ أي إجراء أرخص تكلفةً أبدًا بعد السنة الثالثة. والاستثناء الوحيد هو النظام الذي يسير بالفعل على مسار واضح نحو التقاعد - وهو ما يمثل استراتيجيةً، وليس مصادفةً.
سترى عبارة "الخمسة أركان لتحديث التطبيقات" تتردد في كل مكان. وقد شاع هذا الإطار بفضل الـ«خمسة R» الأصلية لـ«غارتنر» وتوسعت لتشمل ستة من خلال تصنيف عمليات الترحيل المعروف لدى AWS. أما بالنسبة لمحافظ الاستثمار المؤسسية الفعلية، فإن النسخة الأكثر فائدة تتضمن ستة خيارات، وغالبًا ما يكون الخيار السادس، وهو «الاحتفاظ»، هو الذي يمنع أكبر قدر من التكاليف والمخاطر غير الضرورية.
| R | ماذا يعني ذلك | عندما يكون مناسبًا | الجهد المعتاد |
|---|---|---|---|
| التقاعد | إيقاف تشغيل النظام بالكامل؛ وإدماج وظائفه في لا شيء أو في نظام آخر. | لم تعد هذه الوظيفة قيد الاستخدام أو أنها مكررة في نظام آخر. | منخفض (لأغراض أرشفة البيانات فقط) |
| الاحتفاظ | الإبقاء على الوضع الحالي على المنصة الحالية؛ وإعادة التقييم بعد 12 إلى 24 شهراً. | نظام مستقر لا يشهد تغييرات كبيرة ولا يتعرض لضغوط الامتثال؛ وعائد الاستثمار في التحديث سلبي. | الحد الأدنى |
| إعادة الاستضافة | الانتقال المباشر إلى بنية تحتية جديدة (مثل الانتقال من الحاسوب المركزي إلى السحابة) دون تغيير في الكود. | تحتاج إلى إنهاء عقد مركز البيانات أو عقد الأجهزة بسرعة؛ ولا بأس بأن يظل الجهاز قيد التشغيل. | منخفض إلى متوسط |
| تغيير المنصة | الانتقال إلى بيئة تشغيل جديدة مع إجراء تغييرات بسيطة في الكود (على سبيل المثال: WebSphere → Spring Boot على Kubernetes). | الهيكلية مقبولة، لكن النظام الأساسي قد انتهى عمره الافتراضي أو أنه مكلف. | متوسط |
| إعادة هيكلة | إعادة هيكلة قاعدة الكود دون تغيير السلوك الخارجي؛ وإدخال مبدأ النمطية والاختبارات وقابلية المراقبة. | يمكن إنقاذ قاعدة الكود، لكنها متشابكة؛ لذا عليك التحلي بالمرونة قبل الشروع في إجراء تغييرات جذرية. | متوسط إلى مرتفع |
| إعادة البناء / الاستبدال | إعادة التنفيذ من الصفر (إعادة البناء) أو الاستعاضة عن المنتج بآخر تجاري (الاستبدال). | لا يستطيع النظام الحالي دعم نموذج العمل الجديد؛ أو أن هناك خيارًا قويًا لخدمات البرمجيات كخدمة (SaaS). | عالية |
إطار عمل 6R ليس سلسلة متسلسلة. إنه قرار يتعلق بمحفظة التطبيقات. يقوم برنامج التحديث الجاد بتصنيف كل تطبيق في الأصول - عادة ما يتراوح عددها بين 80 و400 تطبيق في المجموعات المالية متوسطة الحجم - ويطبق R مختلفًا على كل منها. إن التعامل مع الأصول بأكملها على أنها عملية إعادة بناء واحدة هو السبب الأكثر شيوعًا لفشل هذه البرامج.
دعنا نبني شيئاً استثنائياً معاً.
اعتمد على شركة Lasting Dynamics للحصول على جودة برمجيات لا مثيل لها.
الخطوات الخمس لتحديث التطبيقات هي إعادة الاستضافة, تغيير المنصة, إعادة هيكلة, إعادة البناء و استبدال. تضيف معظم فرق الهندسة الحديثة عنصرًا سادسًا - التقاعد - ويضيف الكثيرون سبعة،, الاحتفاظ. يتيح لك إطار العمل الكامل 6R أو 7R اتخاذ قرارات مختلفة حسب التطبيقات المختلفة، بدلاً من فرض استراتيجية واحدة على كامل البنية التحتية.
لا توجد إجابة موجزة وصادقة، ولكن هناك نطاقات معقولة. بعد تنفيذ مشاريع تحديث للبنوك وشركات التأمين ومقدمي خدمات الرعاية الصحية، فإن العوامل التي نلاحظ أنها تؤثر على التكلفة في أغلب الأحيان هي:
أرقام تقريبية نستخدمها كنقطة انطلاق لـ تحديث التطبيقات القديمة الميزانيات في أوروبا:
| النطاق | النطاق المعتاد على مدار 12 شهراً (يورو) |
|---|---|
| ترحيل تطبيق واحد غير حيوي إلى منصة جديدة | 120 ألف يورو - 400 ألف يورو |
| إعادة هيكلة التطبيقات الحيوية (في سياق خاضع للتنظيم) | 400 ألف يورو - 1.2 مليون يورو |
| نقل أحمال عمل الحاسوب المركزي (لكل حزمة تضم حوالي 500 ألف سطر من التعليمات البرمجية) | 800 ألف يورو – 2.5 مليون يورو |
| إعادة بناء النظام الأساسي (النظام الأساسي للخدمات المصرفية والتأمين) | 4 ملايين يورو – 25 مليون يورو فأكثر على مدى 24–48 شهراً |
من الناحية العملية، لا ينبغي تقدير تكلفة تحديث الأنظمة القديمة إلا بعد الانتهاء من مرحلة الاستكشاف، لأن التكلفة الفعلية تعتمد على حجم الكود، وتعقيد البيانات، ومساحة التكامل، ومتطلبات الامتثال، ونموذج التشغيل، ومدة التشغيل المزدوج. وهذه هي تكاليف البرنامج. وعادةً ما تعوض التكاليف التي تم تجنبها من صيانة الأنظمة القديمة، وتأجير الأجهزة، وتراخيص الموردين، ونفقات التدقيق الإدارية، ما بين 35 و60% من نفقات التحديث على مدى خمس سنوات.
تتراوح تكلفة تحديث الأنظمة القديمة في أوروبا عادةً بين 120 ألف يورو و400 ألف يورو لإعادة نشر تطبيق واحد غير حيوي، وبين 400 ألف يورو و1.2 مليون يورو لإعادة هيكلة تطبيق حيوي في بيئة خاضعة للتنظيم، بين 800 ألف يورو و2.5 مليون يورو لكل حزمة تبلغ حوالي 500 ألف سطر من التعليمات البرمجية لإعادة استضافة الحاسوب المركزي، وبين 4 ملايين يورو و25 مليون يورو أو أكثر على مدى 24 إلى 48 شهراً لإعادة بناء نظام أساسي في القطاع المصرفي أو التأمين. وعادةً ما تعوض التكاليف التي تم تجنبها من صيانة الأنظمة القديمة، وتأجير الأجهزة، وتراخيص الموردين، ونفقات التدقيق الإدارية ما بين 35 إلى 60% من نفقات البرنامج على مدى خمس سنوات.
تُعد الخيارات الثلاثة التي تتطلب إنفاقًا كبيرًا هي الموضع الذي تتعثر فيه معظم الفرق. وإليكم المنطق الذي نستند إليه في اتخاذ القرار.
في الواقع، نادرًا ما يتعلق القرار باختيار الخيار الأكثر حداثة. بل يتعلق باختيار التدخل الأقل مخاطرًا الذي يزيل العائق الحالي دون التسبب في مشكلة أكبر في التنفيذ.
تنطوي عملية "إعادة التهيئة" على نقل التطبيق إلى بيئة تشغيل جديدة — على سبيل المثال من حاسوب مركزي إلى خدمة Java تعمل في حاوية — مع إجراء تغييرات طفيفة على كود التطبيق. أما إعادة الهيكلة (Refactoring) فتحتفظ ببيئة التشغيل ولكنها تعيد هيكلة الكود نفسه: استخراج الوحدات النمطية، وإدخال الاختبارات، وإزالة الكود غير المستخدم، وتحسين نموذج البيانات. تغير إعادة الهيكلة (Replatforming) مكان تشغيل الكود؛ بينما تغير إعادة الهيكلة (Refactoring) طريقة تنظيم الكود.
يُعد "تغيير المنصة" الخيار الأقل استخدامًا. فغالبًا ما ينتقل العديد من مديري التكنولوجيا من القول "هذا أمر صعب" إلى «يجب أن نعيد البناء»، لأن إعادة البناء تبدو خطوة أكثر تأثيرًا. وغالبًا ما يكون «تغيير المنصة» هو الخطوة الأولى المسؤولة التي تمنحنا مهلة 18 شهرًا للتنفس، بينما يتم تحديد نطاق إعادة البناء بشكل صحيح.
بدءاً من الفكرة إلى الإطلاق، نقوم بتصميم برامج قابلة للتطوير مصممة خصيصاً لتلبية احتياجات عملك.
شارك معنا لتسريع نموك.
تحديث أنظمة الحواسيب المركزية تُعد فئةً مستقلة بذاتها. فهذه الأنظمة تعود إلى عقود مضت، والأجهزة مستأجرة بعقود تمتد لعدة سنوات، كما أن المهندسين الذين صمموها قد تقاعدوا في الغالب. ويشهد البحث عن تحديث لغة COBOL ارتفعت بنسبة 6 أضعاف تقريبًا في أوائل عام 2026 — من مستوى أساسي يبلغ حوالي 210 بحثًا شهريًا إلى حوالي 1300 بحث في فبراير (DataForSEO / Google Keyword Planner) — مع وصول موجة من المؤسسات الأوروبية والأمريكية الكبرى إلى مرحلة اتخاذ القرارات المتعلقة بانتهاء العقود.
لا يوجد نمط عام، ولكن هناك أربعة تحديث لغة COBOL تغطي مسارات الهجرة غالبية البرامج الفعلية:
تقوم أدوات مثل Micro Focus أو OpenFrame أو Heirloom بترجمة أو محاكاة بيئة التشغيل بحيث يتم تنفيذ أحمال عمل COBOL على نظام Linux. ويُعد هذا المسار الأكثر تكلفة والأقل مخاطرة، وغالبًا ما يكون الخيار الوحيد المعقول بالنسبة للأنظمة المالية الأساسية التي تتطلب دقة عالية في الأمان.
تحويل لغة COBOL إلى Java أو C# أو Go باستخدام أدوات التحليل الثابت. ويُعد هذا الحل فعالاً لأحمال العمل التي تعتمد على المعالجة الدفعية وتتميز بتفاعل محدود. وتكون النتيجة الناتجة آلية وتحتاج إلى إعادة هيكلة يدوية قبل أن تصبح قابلة للصيانة.
إنشاء طبقة خدمات جديدة حول الحاسوب المركزي، وتوجيه حركة المرور الجديدة إليها، ونقل نقاط النهاية تدريجيًا. وبذلك يتقلص حجم الحاسوب المركزي على مدار سنوات بدلاً من استبداله دفعة واحدة.
قم ببناء نظام جديد على منصة حديثة، وقم بتشغيل كلا النظامين بالتوازي لمدة تتراوح بين 6 و18 شهراً، وقم بمطابقة كل معاملة. هذا هو المسار الأعلى تكلفة والأقل مخاطرة، وغالباً ما يكون الخيار الوحيد المعقول بالنسبة للأنظمة المالية الأساسية التي تتطلب دقة عالية.
الاختيار بين هذين تحديث الحواسيب المركزية لا تتحدد مسارات التحول بالضرورة بالتكنولوجيا بقدر ما تتحدد بالرغبة في المخاطرة ومدى تقبل الجهة التنظيمية لفترة الانتقال. وفي الواقع، فإن معظم عمليات التحول الناجحة تحديث لغة COBOL تجمع هذه البرامج بين اثنين من هذه العناصر - عادةً ما يكون ذلك نبات التين الخانق بالإضافة إلى الاستبدال الموجه للمكونات الأكثر عرضة للخطر في المشاريع الجديدة.
يستحق استبدال النظام القديم العناء عندما تتجاوز تكلفة الاحتفاظ به — بما في ذلك الصيانة، ومخاطر فقدان الكفاءات، والارتباط بمورد واحد، وتكاليف الامتثال الإدارية، وفرص المنتجات الضائعة — تكلفة الاستبدال في غضون خمس سنوات. بالنسبة لمعظم الأنظمة الحيوية للإنتاج التي يزيد عمرها عن 15 عامًا وتخدم الصناعات الخاضعة للتنظيم، فإن هذا الشرط ينطبق بالفعل. والسؤال الأصعب هو ما إذا كان يجب استبدالها الآن أم تثبيتها أولاً من خلال إعادة الهيكلة أو إعادة البرمجة.
A من النظام المتكامل إلى الخدمات الصغيرة تعد عملية الترحيل نمطًا خاصًا بها من أنماط التحديث، وهي النمط الذي غالبًا ما يُنفَّذ بشكل سيئ. فقد شهدنا فرقًا تقوم بتحويل نظام متكامل يعمل بشكل جيد إلى 47 خدمة صغيرة تتشارك في نفس قاعدة البيانات، ونفس دورة الإصدار، ونفس نظام المناوبة - متحملةً بذلك كل تكاليف الأنظمة الموزعة دون أن تجني أيًا من مزاياها.
نحن نصمم ونبني منتجات رقمية عالية الجودة ومميزة.
الموثوقية والأداء والابتكار في كل خطوة.
نحن نستخدم مجموعة صغيرة من القواعد:
بالنسبة إلى الانتقال من الحواسيب المركزية إلى السحابة باعتبارها فئة فرعية من هذا النوع من العمل، نادراً ما تكون الخدمات الصغيرة هي الهدف الأولي المناسب. فالخطوة الأولى الواقعية هي بناء نظام أحادي متكامل ومُقسَّم إلى وحدات على منصة Kubernetes، مع حدود واضحة لواجهات برمجة التطبيقات (API)، ثم الاستخراج الموجه حيثما تبرر الحاجة التجارية ذلك.
وهنا تكمن نقطة الضعف في معظم النصائح العامة المتعلقة بالتحديث. ففي قطاعات مثل الخدمات المصرفية والتأمين والرعاية الصحية وغيرها من القطاعات الخاضعة للتنظيم، لا يقتصر التحديث على الجانب الهندسي فحسب، بل إنه عملية هندسية تجري ضمن إطار الامتثال الذي يفرض شروطًا على كل خطوة.
الأنماط المحددة التي ننفذها:
بالنسبة لأي نظام يتعامل مع الأموال أو المطالبات أو الوصفات الطبية أو القرارات السريرية، يعمل النظام الجديد في وضع "الظل" جنبًا إلى جنب مع النظام القديم. وتتم معالجة كل معاملة من قِبل كلا النظامين؛ حيث يتم تسوية الاختلافات والتحقيق فيها حتى ينخفض معدل الاختلاف إلى ما دون الحد المتفق عليه. ولا يتم الانتقال إلى النظام الجديد إلا عندئذٍ.
يتم توثيق كل قرار معماري، وكل نتيجة اختبار، وكل خطوة من خطوات الانتقال كدليل. دورا, معيار PCI DSS 4, ، فمدققي HIPAA وGDPR سيطلبون ذلك جميعًا. إن تسجيل هذه البيانات أثناء العمل أقل تكلفة بكثير من إعادة تجميعها لاحقًا.
من المتوقع أن توضح الأنظمة الحديثة مصدر كل معلومة، ومن تعامل معها، وكيف تم تحويلها. أما الأنظمة القديمة، فعادةً ما تعجز عن ذلك. لذا، يجب تضمين هذه الميزة في التصميم منذ اليوم الأول لأي عملية إعادة بناء.
وبموجب قانون DORA على وجه الخصوص، يُتوقع من موردي البرمجيات الذين يقدمون خدماتهم للمؤسسات المالية في الاتحاد الأوروبي إجراء اختبارات اختراق تستند إلى التهديدات وتوثيق سيناريوهات المرونة. يجب بناء البنية التحتية للاختبار كجزء من عملية التحديث، وليس كخطوة لاحقة.
كل عنصر تابع — سواء كان مكتبة مفتوحة المصدر أو خدمة SaaS أو قاعدة بيانات مستضافة — يحتاج إلى وثائق على مستوى قائمة مكونات البرمجيات (SBOM) وخطة طوارئ.
للاطلاع على مزيد من المعلومات حول الإطار التنظيمي، انظر تغطيتنا لـ التحول الرقمي في القطاع المصرفي و الخدمات المالية السحابية. وفي مجال الرعاية الصحية، فإن المعيار التنظيمي المكافئ هو معيار HL7 FHIR - راجع دليل التكامل مع FHIR لمعرفة كيف تؤثر متطلبات قابلية التشغيل البيني على تحديث قطاع الرعاية الصحية.
تحديث نظام خاضع للتنظيم؟ نقوم بتنفيذ مشاريع التحديث في قطاعات الخدمات المصرفية والتأمين والرعاية الصحية وفقًا لمعايير ISO 9001 وPCI DSS 4. احجز مكالمة تقييم مدتها 30 دقيقة →
بالنسبة لتطبيق حيوي — مثل نظام أساسي متوسط الحجم لإدارة القروض أو إدارة السياسات — فإن هذا هو الشكل الذي يجب أن يتخذه برنامج مدته 12 شهراً ليكون موثوقاً.
الشهران الأول والثاني: مرحلة الاكتشاف. التحليل الثابت للكود، وتحديد التبعيات، وجرد عمليات التكامل، وتحليل خصائص البيانات، وتحديد المتطلبات التنظيمية. من أجل الانتقال من الحواسيب المركزية إلى السحابة وتشمل هذه المرحلة أيضًا تحديد خصائص حجم العمل وتحديد منطقة هبوط مستهدفة محتملة. النتائج: تصنيف 6R لكل مكون ووثيقة خاصة بالبنية المستهدفة.
الشهران الثاني والثالث: التصميم الهيكلي وإعداد البنية التحتية للاختبار. تحديد المكدس المستهدف ونموذج النشر ومعايير القابلية للمراقبة والأمن. إنشاء نظام التكامل المستمر/التسليم المستمر (CI/CD). إنشاء مجموعة اختبارات التراجع استنادًا إلى حركة مرور الإنتاج.
الأشهر 3–6: اضغط على الشريحة الأولى. اختر الجزء الأصغر والأقل مخاطرة من الوظائف. قم بتطوير النسخة الجديدة. اربطها بعلامة ميزة. قم بتشغيل النسختين بالتوازي.
الأشهر 6–9: التوسع والتوفيق. قم بترحيل الشرائح الـ2–4 التالية. استمر في إجراء المطابقة المزدوجة. ابدأ في التخطيط لإيقاف تشغيل المكونات المقرر سحبها من الخدمة.
الأشهر 9–12: الانتقال إلى النظام الجديد وتحقيق الاستقرار. نقل كامل حركة المرور إلى النظام الجديد. إبقاء النظام القديم في وضع "للقراءة فقط" طوال فترة الاحتفاظ المتفق عليها. استخلاص الدروس المستفادة. التخطيط للـ 12 شهراً القادمة.
هذا هو الهيكل الذي يمكن أن يضمن وصول البرنامج إلى مرحلة الانتقال بشكل واقعي. أما البرامج التي تحاول نقل جميع البيانات دفعة واحدة في وقت واحد، فغالبًا ما تتأخر أكثر من 18 شهرًا وتفقد الدعم الإداري قبل أن تصل إلى مرحلة الانتقال.
نحن فريق هندسي، ولسنا شركة استشارات استراتيجية. نحن خدمات تحديث الأنظمة القديمة تستند إلى ثلاثة عناصر تهم أكثر من أي إطار عمل:
إذا كنت تفكر في تحديث الأنظمة القديمة أو تحديث التطبيقات القديمة يبدأ أي قرار - سواء كان ذلك تحويلًا إلى منصة واحدة، أو انتقالًا من الحاسوب المركزي إلى السحابة، أو إعادة بناء النظام الأساسي على مدى عدة سنوات - بتقييم. سنقوم بدراسة أصولك، وتصنيفها وفقًا لإطار عمل 6R، ونقدم لك ميزانية وجدولًا زمنيًا واقعيين. وإذا كانت الإجابة هي "الاحتفاظ بها لمدة 24 شهرًا أخرى وإعادة التقييم"، فسنخبرك بذلك أيضًا.
هل أنت مستعد لبدء عملية تحديث نظامك القديم؟ احصل على تقييم لتحديث الأنظمة القديمة →
كتب هذا المقال ميشيل سيمينو, ، الرئيس التنفيذي Lasting Dynamics - شركة لتطوير البرمجيات المخصصة مقرها الاتحاد الأوروبي، قامت منذ عام 2014 بتنفيذ برامج تحديث الأنظمة القديمة لصالح البنوك وشركات التأمين ومقدمي خدمات الرعاية الصحية وعملاء القطاع العام. نحن حاصلون على شهادتي ISO 9001 وPCI DSS 4، ولدينا حضور تشغيلي في إيطاليا وسويسرا وجميع أنحاء الاتحاد الأوروبي. الأطر المشار إليها في هذا المقال (6R، strangler fig، replatform/refactor/rebuild) هي تصنيفات قياسية في القطاع؛ وتعكس نطاقات التكلفة وخريطة الطريق بيانات مشاركتنا الخاصة، وليس معايير المقارنة الخاصة بالموردين.
تتمثل "الخمس خطوات" لتحديث التطبيقات في إعادة الاستضافة، وتغيير المنصة، وإعادة الهيكلة، وإعادة البناء، والاستبدال. وتضيف معظم فرق الهندسة الحديثة خطوة سادسة، وهي "التوقف عن الاستخدام"، كما يضيف الكثيرون خطوة سابعة، وهي "الاحتفاظ". ويتيح لك إطار العمل الكامل المكون من 6 أو 7 خطوات اتخاذ قرارات مختلفة لكل تطبيق على حدة، بدلاً من فرض استراتيجية واحدة على جميع التطبيقات.
تنطوي عملية "إعادة التهيئة" على نقل التطبيق إلى بيئة تشغيل جديدة — على سبيل المثال من حاسوب مركزي إلى خدمة Java تعمل في حاوية — مع إجراء تغييرات طفيفة على كود التطبيق. أما إعادة الهيكلة (Refactoring) فتحتفظ ببيئة التشغيل ولكنها تعيد هيكلة الكود نفسه: استخراج الوحدات النمطية، وإدخال الاختبارات، وإزالة الكود غير المستخدم، وتحسين نموذج البيانات. تغير إعادة الهيكلة (Replatforming) مكان تشغيل الكود؛ بينما تغير إعادة الهيكلة (Refactoring) طريقة تنظيم الكود.
يستحق استبدال النظام القديم العناء عندما تتجاوز تكلفة الاحتفاظ به — بما في ذلك الصيانة، ومخاطر فقدان الكفاءات، والارتباط بمورد واحد، وتكاليف الامتثال الإدارية، وفرص المنتجات الضائعة — تكلفة الاستبدال في غضون خمس سنوات. بالنسبة لمعظم الأنظمة الحيوية للإنتاج التي يزيد عمرها عن 15 عامًا وتخدم الصناعات الخاضعة للتنظيم، فإن هذا الشرط ينطبق بالفعل. والسؤال الأصعب هو ما إذا كان يجب استبدالها الآن أم تثبيتها أولاً من خلال إعادة الهيكلة أو إعادة البرمجة.
لا توجد إجابة موجزة وصادقة، ولكن هناك نطاقات تقديرية موثوقة. في أوروبا، تتراوح تكلفة نقل منصة تطبيق واحد غير حيوي عادةً بين 120 ألف يورو و400 ألف يورو على مدار 12 شهراً. أما إعادة هيكلة تطبيق حيوي في بيئة خاضعة للتنظيم فتتراوح تكلفتها بين 400 ألف يورو و1.2 مليون يورو. عادةً ما تتراوح تكلفة إعادة استضافة أحمال عمل الحاسوب المركزي بين 800 ألف يورو و2.5 مليون يورو لكل حزمة تضم حوالي 500 ألف سطر من التعليمات البرمجية. أما إعادة بناء نظام أساسي كامل في القطاع المصرفي أو التأميني فتتراوح تكلفتها بين 4 ملايين يورو و25 مليون يورو أو أكثر، موزعة على 24 إلى 48 شهراً. تغطي التكاليف التي تم تجنبها من صيانة الأنظمة القديمة، وتأجير الأجهزة، وتراخيص الموردين، ونفقات التدقيق الإدارية 35%-60% من نفقات التحديث على مدى خمس سنوات، وهذا هو السبب في أن خيار 'عدم القيام بأي شيء' لا يكون أرخص أبدًا بعد السنة الثالثة.
هناك أربعة مسارات تغطي غالبية برامج تحديث أنظمة الحاسوب المركزي (Mainframe) ولغة COBOL. (1) المحاكاة على منصات x86 أو السحابة باستخدام أدوات مثل Micro Focus أو OpenFrame أو Heirloom - وهو المسار الأرخص، حيث يزيل الاعتماد على الأجهزة ولكنه لا يحل مشكلة اللغة. (2) التحويل الآلي لـ COBOL إلى Java أو C# أو Go، وهو فعال لأحمال العمل الدفعية، لكن الناتج ميكانيكي ويحتاج إلى إعادة هيكلة بشرية قبل أن يصبح قابلاً للصيانة. (3) ترحيل Strangler fig، بناء طبقة خدمة جديدة حول الحاسوب المركزي ونقل النقاط النهائية تدريجيًا؛ يتقلص الحاسوب المركزي على مدار سنوات بدلاً من استبداله دفعة واحدة. (4) الاستبدال من الصفر مع التشغيل المتوازي - بناء نظام جديد على مكدس حديث، وتشغيل كلا النظامين بالتوازي لمدة 6-18 شهرًا، ومطابقة كل معاملة؛ أعلى تكلفة، وأقل مخاطر، والطريق الوحيد المعقول للنوى المالية الحساسة من حيث السلامة.
قم بتقسيم النظام المترابط فقط وفقًا للسياقات المحددة (تسجيل الحسابات، والمدفوعات، والمطالبات، والجدولة)، ولا تقم أبدًا بتقسيمه وفقًا للطبقات التقنية أو لكل جدول على حدة. الاختبار الحقيقي هو قابلية النشر المستقلة: إذا تعذر نشر خدمتين بشكل مستقل، فهما خدمة واحدة. غالبًا ما يستغرق تقسيم قاعدة البيانات وحده 30–50% من إجمالي جهد البرنامج، لذا فإن أي نظام مترابط يحتوي على قاعدة بيانات مشتركة واحدة لن يكون جاهزًا للخدمات الصغيرة حتى يتم تقسيم البيانات. تشمل متطلبات اليوم الأول التتبع الموزع والسجلات المنظمة واختبار العقود وقواطع الدائرة، وإضافتها لاحقًا تكون أكثر تكلفة بكثير. في عام 2026، عادت الاتجاهات نحو الكتل المتجانسة المعيارية مع خدمتين أو ثلاث خدمات مستخرجة بدلاً من أسراب الخدمات الصغيرة التي تشترك في قاعدة بيانات ودورة إصدار وتناوب على أهبة الاستعداد.
ابدأ بعملية تغيير المنصة عندما لا تزال المنطقية التجارية تخدم احتياجات العمل، وتكون المشكلات مركزة في مرحلة التشغيل (التكلفة، وقابلية التوسع، ودعم نهاية العمر الافتراضي)، وتحتاج إلى تحقيق نتائج في غضون 9 إلى 15 شهراً. انتقل إلى إعادة الهيكلة عندما تكون المنطقية صحيحة ولكن قاعدة الكود أصبحت غير آمنة للتغيير وتحتاج إلى اختبارات آلية وقابلية المراقبة وحدود واجهة برمجة التطبيقات (API) قبل أي عمل إضافي - خصص ميزانية تتراوح بين 12 و24 شهراً. التزم بإعادة البناء فقط عندما تتطلب خارطة طريق المنتج قدرات لا تستطيع البنية الحالية دعمها حقًا (البيانات في الوقت الفعلي، ميزات الذكاء الاصطناعي، سير العمل المدفوع بالأحداث، SaaS متعدد المستأجرين)، ولم يعد المورد الحالي قابلاً للاستمرار، ولدى القيادة رغبة في برنامج مزدوج التشغيل مدته 24 إلى 48 شهرًا. تعد إعادة الهيكلة الخيار الأقل استخدامًا؛ حيث ينتقل العديد من مديري التكنولوجيا من 'هذا أمر مؤلم' إلى 'يجب إعادة البناء' في حين أن إعادة الهيكلة هي الخطوة الأولى المسؤولة التي توفر 18 شهرًا بينما يتم تحديد نطاق إعادة البناء بشكل صحيح.
بالنسبة للتطبيقات الحيوية — على سبيل المثال نظام أساسي متوسط الحجم للإقراض أو إدارة السياسات — يستغرق البرنامج الموثوق حوالي 12 شهراً ويتبع هيكلاً ثابتاً. يتم تخصيص الشهرين الأولين لمرحلة الاستكشاف: تحليل الكود الثابت، ورسم خريطة التبعيات، وجرد عمليات التكامل، وتحديد خصائص البيانات، وتصنيف 6R لكل مكون. يتم خلال الشهرين الثاني والثالث إنشاء البنية المستهدفة، و CI/CD، ومجموعة اختبارات الانحدار المبنية من حركة المرور الإنتاجية. يتم خلال الأشهر من 3 إلى 6 عزل الشريحة الأولى منخفضة المخاطر خلف علامة ميزة مع تسوية التشغيل المزدوج. يتم خلال الأشهر من 6 إلى 9 التوسع إلى الشرائح التالية من 2 إلى 4 وبدء التخطيط لإيقاف المكونات التي تم سحبها من الخدمة. تقوم الأشهر 9-12 بتحويل حركة المرور بالكامل، وإبقاء النظام القديم في وضع القراءة فقط خلال فترة الاحتفاظ، والتخطيط للأشهر الـ 12 التالية. عادةً ما تتأخر البرامج التي تحاول إجراء ترحيل واحد كبير لمدة تزيد عن 18 شهرًا وتفقد الدعم التنفيذي قبل التحويل.
حوّل الأفكار الجريئة إلى تطبيقات قوية.
لنصنع معاً برمجيات تُحدث تأثيراً.
ميشيل سيمينو
أؤمن بالعمل الجاد والالتزام اليومي كوسيلة وحيدة للحصول على النتائج. أشعر بجاذبية لا يمكن تفسيرها للجودة وعندما يتعلق الأمر بالبرمجيات فهذا هو الدافع الذي يجعلني وفريقي نتمسك بشدة بممارسات أجايل والتقييمات المستمرة للعمليات. لديّ موقف تنافسي قوي تجاه كل ما أتناوله - بطريقة لا أتوقف فيها عن العمل، حتى أصل إلى القمة، وبمجرد أن أصل إلى القمة، أبدأ العمل للحفاظ على مكانتي.
