تحديث الأنظمة القديمة: وكلاء للأنظمة المركزية (Mainframe)، تخطيط موارد المؤسسات (ERP)، واللغات المتخصصة

تحديث الأنظمة القديمة باستخدام وكلاء الذكاء الاصطناعي: الأنظمة المركزية، تخطيط موارد المؤسسات، والأكواد المتخصصة

غالبًا ما تعتمد الشركات الحديثة على برمجيات يعود تاريخها لعقود بلغات مثل COBOL (الأنظمة المركزية)، SAP ABAP، PL/SQL، أو VB6. هذه الأنظمة المتقادمة يصعب تغييرها ومكلفة في صيانتها. لحسن الحظ، أصبحت وكلاء البرمجة المدعومة بالذكاء الاصطناعي وأنماط التصميم الجديدة تمكننا الآن من تحديث المكدسات القديمة تدريجيًا. في هذه المقالة، نستكشف كيف تساعد الأدوات المدعومة بالذكاء الاصطناعي في تحليل وإعادة كتابة الأكواد القديمة، ونصف أنماطًا مجربة (واجهات الواجهة، نهج "الخنق"، الاختبار الآلي) لاستبدال الوظائف القديمة تدريجيًا. نغطي أيضًا سلالة البيانات، وضوابط المخاطر، وتخطيط التراجع، والعائد على الاستثمار الحقيقي مقابل المخاطر المحتملة. حتى المبتدئين يمكنهم تعلم كيفية البدء: الذكاء الاصطناعي الآن "يحرر" البرمجة بتحويل الكود القديم إلى وثائق مفهومة أو كود جديد، حتى يتمكن أي شخص من اتخاذ الخطوة الأولى نحو تحديث نظام قديم.

وكلاء البرمجة بالذكاء الاصطناعي للأكواد القديمة

وكلاء البرمجة بالذكاء الاصطناعي هي أدوات تستخدم التعلم الآلي (غالبًا نماذج اللغة الكبيرة) لقراءة وتحليل وحتى إعادة كتابة الكود. يمكنهم التعامل مع لغات قديمة لا يعرفها أي إنسان في الفريق جيدًا. على سبيل المثال، أداة Kozuchi AI الجديدة من Fujitsu يمكنها تحليل برامج COBOL وتوليد وثائق تصميم قابلة للقراءة البشرية على الفور (موقع فوجيتسو العالمي). يستخدم WatsonX Code Assistant من IBM لـ Z الذكاء الاصطناعي لتحويل وظائف COBOL إلى Java عالية الجودة، موجهًا المطورين خلال كل خطوة (موقع www.ibm.com). وتستخدم Legacy Modernization Agents مفتوحة المصدر من مايكروسوفت (على GitHub) Azure OpenAI و GitHub Copilot لتحليل COBOL وتوليد خدمات Java أو .NET مكافئة (موقع github.com). تستخلص هذه الوكلاء منطق الأعمال وتدفقات البيانات المخفية في الكود القديم وتساعد في بناء مكونات جديدة حولها.

الجاذبية الرئيسية لوكلاء الذكاء الاصطناعي هي أن أي شخص يمكنه البدء في استخدامهم. لا تحتاج إلى كتابة الكود يدويًا؛ بدلاً من ذلك، تصدر أوامر أو تستخدم أدوات متخصصة. على سبيل المثال، يمكن للمبتدئ نسخ إجراء صغير مكتوب بلغة COBOL أو VB6 إلى ChatGPT وطلب ملخص باللغة الإنجليزية البسيطة أو كود زائف. يفهم الوكيل بنية الكود ويمكنه اقتراح بدائل حديثة. هذا يضفي طابعًا ديمقراطيًا على التحديث – يمكن لغير الخبراء استكشاف منطق الأنظمة القديمة دون مراجعات يدوية للكود. يقوم العديد من البائعين الآن بدمج وكلاء الذكاء الاصطناعي في منصات سهلة الوصول: حل Capgemini لتحديث SAP يستخدم الذكاء الاصطناعي التوليدي لتوثيق كود ABAP تلقائيًا، مما يخفض الجهد المطلوب لسيناريوهات الاختبار والتحويلات إلى النصف (موقع www.sap.com). التحذير المهم هو الإشراف البشري: الوكلاء يسرعون الأمور، لكن المطورين لا يزالون يتحققون من المخرجات. باختصار، يسرع وكلاء البرمجة بالذكاء الاصطناعي اكتشاف ورسم خرائط الأنظمة القديمة، مما يقلص أسابيع من التحليل اليدوي إلى أيام أو دقائق (مدونة naitive.cloud) (موقع فوجيتسو العالمي).

تخطيط الواجهات: المحولات، الواجهات الوهمية (Facades)، والطبقات المتراكبة (Overlays)

أحد تحديات التحديث هو تخطيط الواجهات بين المكونات الجديدة والنواة القديمة. الحل الشائع هو محول الواجهة أو طبقة الواجهة الوهمية (Facade layer). على سبيل المثال، غالبًا ما تظل أنظمة تخطيط موارد المؤسسات (ERP) "نظام السجلات"، لذا يجب أن تتواصل واجهات المستخدم (UIs) أو الخدمات الجديدة معها عبر واجهات برمجة تطبيقات (APIs) نظيفة. تجلس بنية الطبقة المتراكبة (Overlay architecture) (أو "طبقة التجربة") بين المستخدمين ونظام تخطيط موارد المؤسسات القديم. تقوم بترجمة المكالمات الحديثة إلى واجهة النظام القديم والعكس صحيح (موقع sysgraft.com) (موقع sysgraft.com). تتعامل طبقة المحول هذه مع تخطيطات البيانات، وتحويل المصادقة، ومعالجة الأخطاء، والتخزين المؤقت. (على سبيل المثال، قد تقوم بربط أسماء الحقول القديمة بنموذج نطاق جديد، أو تصف عمليات الكتابة عندما يكون النظام القديم بطيئًا، أو توحيد رموز الأخطاء.) بعزل هذا الكود، يمكنك إعادة كتابة أو استبدال نظام تخطيط موارد المؤسسات خلف الواجهة الوهمية لاحقًا دون تغيير الواجهة الأمامية. يضمن هذا النمط أنه يمكنك طرح شاشات وخدمات محسنة تدريجيًا، مع قيام المحول بالترجمة بين العوالم المختلفة (موقع sysgraft.com) (موقع aws.amazon.com).

نهج آخر هو استخدام بوابة API أو واجهة وهمية (Facade) كنقطة دخول. توضح AWS هذا في نمط الخنق للأنظمة المحلية: يضعون بوابة API أمام التطبيق القديم، ثم ينشئون خدمات مصغرة جديدة خلفها. تمر جميع المكالمات عبر نفس واجهة API الوهمية، سواء كانت المعالجة لا تزال تتم بواسطة النظام القديم المتجانس أو بواسطة خدمة تم نشرها حديثًا (موقع aws.amazon.com) (موقع aws.amazon.com). يحافظ هذا على واجهة متسقة للعملاء بينما تقوم أجزاء من النظام "بخنق" النظام المتجانس القديم. بمرور الوقت، يتم إعادة توجيه المزيد من نقاط النهاية إلى تطبيقات جديدة (على سبيل المثال، قراءة البيانات من النظام القديم فقط في البداية، ثم كتابة بيانات جديدة في الخدمة الجديدة لاحقًا).

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

نمط ترحيل شجرة التين الخانقة (Strangler-Fig)

نمط ذو صلة على مستوى عالٍ هو نهج شجرة التين الخانقة (Strangler-Fig) للترحيل. صاغه مارتن فاولر، ويقارنه بنبتة متسلقة تنمو تدريجيًا حول شجرة وتستبدلها في النهاية (موقع martinfowler.com) (موقع aws.amazon.com). بدلاً من إعادة الكتابة الكبيرة دفعة واحدة، تقوم باستبدال ميزات النظام القديم تدريجيًا بميزات جديدة. في البداية، تضيف تحسينات صغيرة كخدمات منفصلة تعمل جنبًا إلى جنب (أو فوق) الكود القديم. بمرور الوقت، تستوعب تلك الخدمات الجديدة المزيد والمزيد من منطق الأعمال حتى يتعامل النظام القديم مع الاستثناءات فقط. أصبحت الوظائف الجديدة وحتى بعض الميزات القديمة الآن في الكود الجديد، ويمكن أخيرًا إخراج النظام المتجانس القديم من الخدمة (موقع martinfowler.com) (موقع martinfowler.com).

يحدد فاولر أربع خطوات لتحديث بنمط الخنق: (1) فهم النتائج المرجوة؛ (2) تقسيم المشكلة إلى أجزاء؛ (3) تسليم الأجزاء بنجاح؛ (4) تغيير المنظمة للحفاظ على ذلك (موقع martinfowler.com). من الناحية العملية، قد يعني هذا تحديد قدرة عمل رئيسية (مثل إدخال الطلبات)، وإعادة بنائها في خدمة جديدة (Node.js، .NET، إلخ)، ثم كتابة كود محول بحيث تذهب مكالمات الطلبات إلى الخدمة الجديدة بدلاً من البرنامج القديم. ولأنه يتم ذلك على أجزاء، يقل الخطر: يمكن لكل قطعة جديدة أن تدخل حيز التشغيل وتقدم قيمة على الفور (موقع martinfowler.com). على سبيل المثال، تضمنت دراسة حالة AWS تطبيقًا قام أولاً بمعالجة استعلامات "القراءة فقط" البسيطة عبر واجهة برمجة التطبيقات الجديدة، ثم أضاف لاحقًا عمليات الكتابة لمجموعة فرعية من المستخدمين (موقع sysgraft.com). في كل خطوة، استمر النظام في العمل للمستخدمين.

تساعد وكلاء البرمجة بالذكاء الاصطناعي في عمليات ترحيل بنمط الخنق من خلال إنشاء أو إعادة هيكلة تلك المكونات الجديدة بسرعة. على سبيل المثال، يمكن لوكيل قراءة منطق COBOL القديم حول "حساب مكافآت الموظفين" وتوليد وظيفة Java أو Python مكافئة. ثم تقوم بنشر ذلك كخدمة تحت نمط الخنق. مفتاح النجاح هو بناء واجهات انتقالية: كود موجود فقط حتى اكتمال الترحيل. ترفض العديد من الفرق الكود "الزائد" لربط القديم بالجديد، لكن هذا المنطق الانتقالي (التوجيه، مزامنة البيانات، إلخ) هو ما يجعل الترحيل التدريجي ممكنًا بمخاطر أقل (موقع martinfowler.com) (موقع aws.amazon.com).

نظام اختبار آلي للأكواد القديمة

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

• اختبارات الوحدة (Unit tests): التحقق من الوظائف أو الوحدات النمطية الفردية. في الكود القديم، قد يكون منطق الأعمال مخفيًا في روتينات كبيرة. يمكن للوكلاء المساعدة باقتراح اختبارات الوحدة: على سبيل المثال، مطالبة وكيل ذكاء اصطناعي باقتراح أمثلة للإدخال والإخراج لوظيفة قديمة. يمكن للأدوات والأطر (مثل مشغلات اختبار COBOL أو PL/SQL الحديثة) تنفيذ الكود القديم مقابل هذه الاختبارات.
• اختبارات التكامل (Integration tests): التحقق من تفاعل الوحدات النمطية بشكل صحيح. على سبيل المثال، إذا كانت طبقتك المتراكبة الجديدة تكتب إلى قاعدة بيانات ERP، يضمن اختبار التكامل أن التدفق الشامل (الإدخال في واجهة المستخدم إلى التحديث في ERP) لا يزال يعمل. قد يساعد الوكلاء في توليد الطلبات تلقائيًا بناءً على تفسير تعريفات الواجهة.
• اختبارات شاملة (End-to-end (E2E) tests): محاكاة سير عمل المستخدم بالكامل. قبل الترحيل، تحدد تسلسلات ذهبية للعمليات (تسجيل الدخول، إنشاء فاتورة، إلخ). يمكن لبرامج الزحف أو أطر العمل مثل Cypress/Playwright أتمتة استدعاءات واجهة المستخدم الرسومية (GUI) أو واجهات برمجة التطبيقات (API) لتلك التدفقات. هذا أمر بالغ الأهمية: فهو يكتشف المشكلات التي لا يمكن لأي اختبار وحدة اكتشافها.
• اختبارات الانحدار (Regression tests): شبكة الأمان – في كل مرة تقوم فيها بإعادة هيكلة أو تفعيل ميزة، قم بتشغيل مجموعتك الكاملة للتأكد من عدم تعطل أي شيء آخر. اختبارات التوصيف (تقنية قديمة كلاسيكية) مفيدة بشكل خاص: فهي تسجل المخرجات الحالية للكود القديم لمدخلات معينة وتؤكد أن الكود الجديد يتطابق مع هذا السلوك (موقع eden-technologies.eu). بعبارة أخرى، تلتقط الاختبارات ما يفعله الكود فعليًا حتى لا تحتاج إلى معرفة سبب قيامه بذلك.

يؤكد الخبراء أن اختبار الانحدار هو الطبقة الأكثر أهمية (موقع polcode.com). قبل أي تغيير، تأكد من وجود اختبارات تغطي الوظائف الأساسية. ابدأ بحماية سير العمل الحيوي للمهام: الطلبات، الفواتير، الموافقات – أي شيء مرتبط مباشرة بالإيرادات أو الامتثال (موقع teamvoy.com). ثم وسّع الاختبارات لتشمل المناطق الهشة أو عالية التغيير (الوحدات النمطية التي تحتوي على العديد من الأخطاء السابقة). لا تحتاج إلى القيام بكل ذلك دفعة واحدة؛ قم ببناء مجموعتك بشكل متكرر. على سبيل المثال، عندما يجد المختبر خطأً، اكتب اختبارًا جديدًا حول هذا السيناريو. على مدار أشهر من الجهد المتواصل، يمكن حتى لمجموعة اختبارات هيكلية أن تنمو بما يكفي لاكتشاف الانحدارات الرئيسية (موقع polcode.com) (موقع eden-technologies.eu).

يمكن للذكاء الاصطناعي أتمتة جوانب الاختبار أيضًا. على سبيل المثال، يمكن لمنصات الاختبار بالذكاء الاصطناعي (مثل بعض أدوات CI/CD) توليد اختبارات شاملة قائمة على النوايا من مواصفات اللغة الطبيعية (موقع polcode.com). يمكن للوكيل مسح الكود القديم والوثائق، ثم اقتراح حالات الاختبار. في تحديث SAP، تعد أدوات Capgemini بأتمتة توليد نصوص الاختبار مع تقليل الجهد بنحو 40% (موقع www.sap.com). ووجد تحليل صناعة Naitive أن كتابة الاختبارات لا تزال تستغرق غالبًا 40-50% من مشروع قديم، لكن الذكاء الاصطناعي يمكن أن يقلل ذلك بشكل كبير (مدونة naitive.cloud). مفاهيميًا، يمكنك إدخال سجل وظائف COBOL أو تدفق واجهة مستخدم قديمة إلى نموذج لغوي كبير (LLM) للحصول على تسلسل عينة من الإجراءات للاختبار. بغض النظر، يجب على الإنسان التحقق من اقتراحات الذكاء الاصطناعي؛ الهدف هو الثقة بأن الكود الجديد يتطابق مع السلوك القديم قبل إعادة الدمج.

سلالة البيانات وضوابط المخاطر

تحديث الأنظمة القديمة لا يتعلق فقط بالكود – يجب أن تنتقل البيانات أو تبقى متسقة أيضًا. تعني سلالة البيانات تتبع مصدر كل عنصر بيانات وكيف يتم تحويله. بدون سلالة واضحة، يكاد يكون من المستحيل ضمان دقة النظام المهاجر وامتثاله. على سبيل المثال، عندما يتم نقل بيانات الأنظمة المركزية (غالبًا بتنسيق EBCDIC) إلى منصة حديثة، تتطلب المؤسسات عمليات تعيين التجزئة الجنائي وسلسلة الحيازة (موقع www.solix.com) (موقع www.solix.com). من الناحية العملية، يعني هذا حساب تجزئات تشفيرية للبيانات في كل مرحلة حتى تتمكن من إثبات أنها لم يتم تغييرها. ويعني أيضًا تسجيل كل خطوة من خطوات ETL: كل عملية استخراج أو تحويل أو تحميل قابلة للتدقيق. بدون ذلك، قد لا يثق المدققون أو المنظمون بنظامك الجديد.

جودة البيانات هي منطقة مخاطر كبيرة. يحذر دليل حديث من أن معظم عمليات ترحيل البيانات القديمة الفاشلة لم تكن بسبب التكنولوجيا بل بسبب البيانات "المتسخة" التي تم نسخها مباشرة (موقع www.taleofdata.com). يمكن للسجلات المكررة، أو حذف الحقول الصامت، أو التنسيقات غير المتسقة التي تسللت إلى النظام القديم أن تسمم النظام الجديد إذا لم يتم معالجتها. من الضروري إجراء تحليل وتطهير البيانات قبل الترحيل، وليس مجرد الاعتماد على أداة ETL لنقل البايتات. يجب على الفرق أن تسأل: هل حددنا سجلات العملاء المكررة وقررنا كيفية دمجها؟ هل سيتم ربط كل حقل "مهم" (حتى تلك التي نادراً ما تستخدم) بالمخطط الجديد؟ هل هناك خطة تراجع واضحة إذا اكتشفنا لاحقًا أخطاء ترحيل؟ (موقع www.taleofdata.com).

تبدأ ضوابط المخاطر بـ التحقق من صحة البيانات في كل خطوة. رحّل البيانات على دفعات محكومة: على سبيل المثال، انقل سجل المعاملات لخمس سنوات أولاً، تحقق من دقة التقارير، ثم تابع مع الباقي. استخدم نصوص التسوية: بعد كل دفعة، تحقق من تطابق عدد الصفوف ومجاميع التحقق. إذا ظهرت تناقضات، توقف ونظف البيانات بدلاً من المضي قدمًا. حافظ على نسخة احتياطية (أو سجل معاملات) للبيانات المصدر حتى تتمكن من التراجع عن أي دفعة فاشلة دون إعادة تشغيل الترحيل بأكمله. في الحالات عالية المخاطر، قد تقوم حتى بتشغيل المصدر والهدف بالتوازي لفترة (كتابة مزدوجة) بحيث تذهب جميع التحديثات الجديدة إلى كلا النظامين حتى يتم تأكيد النظام الجديد بالكامل. في الأساس، ابنِ حواجز حماية كما تفعل في الإنتاج: مراقبة، تنبيهات، ومحفزات تراجع سريعة (موقع www.solix.com) (موقع www.taleofdata.com).

استراتيجيات التراجع

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

• النسخ المتماثل الآمن من الفشل (Fail-safe replication): حافظ على مزامنة قاعدة البيانات القديمة مع النظام الجديد. على سبيل المثال، استخدم التقاط البيانات المتغيرة (CDC) في كلا الاتجاهين. بعد التفعيل، استمر في النسخ المتماثل من النظام الجديد إلى القديم. إذا ساءت الأمور، يمكنك إعادة تشغيل النظام القديم على الفور دون فقدان أي عمليات كتابة (موقع www.cockroachlabs.com). يُستخدم هذا في عمليات الترحيل السحابية (مثل AWS DMS، CockroachDB failback).

• الكتابة المزدوجة أو التشغيل المتوازي (Dual-write or parallel run): قم بتعديل كود التطبيق (أو استخدم برمجيات وسيطة للتكامل) لكتابة كل معاملة إلى كل من النظامين القديم والجديد خلال فترة تجريبية (موقع www.cockroachlabs.com). ثم إذا فشل النظام الجديد، ما عليك سوى إعادة توجيه العملاء إلى البيئة القديمة. الكتابة المزدوجة تعني عدم فقدان أي بيانات جديدة عند التراجع، ولكنها تضاعف تكلفة الكتابة وتعقيدها.

• التفعيل اليدوي + لقطة (Manual cutover + snapshot): في الحالات ذات المخاطر المنخفضة جدًا، قم بأخذ لقطة نهائية لقاعدة البيانات القديمة، وحوّل المستخدمين إلى النظام الجديد، واعتمد على التسوية اليدوية للبيانات إذا ظهرت مشاكل. هذا مقبول فقط إذا كان بإمكانك تحمل بعض التناقضات المحتملة ولديك وقت لإصلاحها.

• علامات الميزات / التحويل الجزئي (Feature flags / partial switchover): في نهج الخنق، تحكم فيما يذهب إلى الجديد مقابل القديم عبر التكوين. إذا ظهرت مشكلة في مكون جديد، يمكنك إيقافه (إعادة توجيه الطلبات إلى النظام القديم) دون الحاجة إلى التراجع عن الكود. هذا يشبه تراجعًا دقيقًا جدًا على مستوى واجهة برمجة التطبيقات.

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

عائد الاستثمار من التحديث

من الطبيعي القلق بشأن تكلفة التحديث. ومع ذلك، تظهر الحالات الواقعية أن العائد على الاستثمار يمكن أن يكون مرتفعًا جدًا. غالبًا ما تستهلك الأنظمة القديمة 60-80% من ميزانية تكنولوجيا المعلومات لمجرد صيانة الكود القديم (مدونة naitive.cloud) (مدونة naitive.cloud). مقارنة بهذا العبء المستمر، يمكن أن يحقق التحديث لمرة واحدة عائدًا سريعًا. يشير تحليل الصناعة إلى أن التحديث بمساعدة الذكاء الاصطناعي يمكن أن يخفض تكاليف المشروع بنسبة حوالي 70-80%. على سبيل المثال، قد يكلف تحويل تطبيق مكون من 50,000 سطر يدويًا 240 ألف دولار؛ ومع أدوات الذكاء الاصطناعي يمكن أن ينخفض إلى 57 ألف دولار (حوالي 76% تخفيض) (مدونة naitive.cloud) (مدونة naitive.cloud). يشمل هذا الحساب العمالة، وضمان الجودة، ورسوم الأدوات. من الناحية العملية، تبلغ العديد من الشركات عن عائد استثمار لمدة 5 سنوات يتراوح بين 200-400%، وغالبًا ما تحقق نقطة التعادل في 1-2 سنة (مدونة naitive.cloud) (مدونة naitive.cloud).

تكثر قصص النجاح الملموسة. تصف ديلويت ولاية أمريكية تجنبت إعادة كتابة نظام دعم الأطفال بلغة COBOL بتكلفة 200 مليون دولار على مدار 10 سنوات باستخدام إعادة هيكلة آلية إلى Java على السحابة (موقع www2.deloitte.com). أكملوا ذلك في 18 شهرًا بدلاً من ذلك، مما حرر الميزانية للخدمات الحديثة. قامت شركة تأمين هولندية (NN Group) بتحويل أكثر من 10 ملايين سطر من COBOL إلى Java وخفضت تكاليف منصة تكنولوجيا المعلومات بنسبة 80%، واستردت الاستثمار في أقل من ثلاث سنوات (مدونة naitive.cloud). حتى على نطاقات أصغر، يمكن لمساعدي الذكاء الاصطناعي تسريع الاكتشاف والترميز: ذكر أحد المعايير أن ترحيل نظام قديم انتقل من 8-11 شهرًا إلى حوالي شهرين باستخدام الوكلاء، مع انخفاض تكاليف العمالة بحوالي 183 ألف دولار لقاعدة كود من 50 ألف سطر (مدونة naitive.cloud) (مدونة naitive.cloud).

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

الأخطاء والدروس المستفادة

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

ثانيًا، يظل الاختبار عنق الزجاجة. حتى لو كان تحويل الكود سريعًا، فإن الاختبار غالبًا ما يستغرق 40-50% من الجدول الزمني (مدونة naitive.cloud). تستهين العديد من الفرق بهذا. يجب أن تخصص وقتًا لمسارات تكامل مستمر قوية وربما لتوليد الاختبارات بمساعدة الذكاء الاصطناعي. لا تقلل من تغطية الاختبار. الكود القديم هش بطبيعته، والاختبارات غير الكافية هي سبب شائع للفشل.

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

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

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

البدء: الخطوات الأولى

للقراء المتحمسين لتجربة التحديث بالذكاء الاصطناعي بأنفسهم، إليك طريقة عملية للبدء:

1. جرد وحدة صغيرة. اختر وظيفة محددة (على سبيل المثال، برنامج COBOL واحد، مجموعة وظائف ABAP، أو نموذج VB6). اجمع الكود المصدري الخاص بها وأي مدخلات عينة.
2. دع الذكاء الاصطناعي يشرحه. استخدم أداة مثل ChatGPT أو مساعد كود بالذكاء الاصطناعي. الصق الكود (أو مقتطفات رئيسية) واطلب ملخصًا أو كودًا زائفًا. على سبيل المثال: “اشرح منطق الأعمال لهذا الكود المكتوب بلغة COBOL: …”. سيسلط الوكيل الضوء على الحلقات، العمليات الحسابية، واستخدام البيانات بلغة بسيطة. هذا يربط الفهم البشري بالصياغة القديمة.
3. إنشاء اختبار أو وثيقة. اطلب من الوكيل إنتاج حالة اختبار لذلك الكود. أو اطلب منه إخراج رسم بياني أو مخطط واجهة برمجة تطبيقات (API) لما تفعله هذه الوحدة. قد تحصل على اختبار وحدة أولي أو وثيقة تصميم مجانًا.
4. بناء نظام اختبار. حتى نص برمجي بسيط يستدعي الكود القديم بمدخلات اختبار ويتحقق من المخرجات يحدد خط أساس. إذا قدم الوكيل مخرجات، تحقق من تطابقها مع البرنامج الفعلي (يساعد هذا التحقق أيضًا في تدريبك على اكتشاف أخطاء الذكاء الاصطناعي).
5. خطط الواجهة الجديدة. حدد كيف ستتواجد هذه الوظيفة في البنية الجديدة. هل ستصبح خدمة مصغرة (microservice) REST؟ وظيفة سحابية؟ ارسم عقود البيانات (يمكنك أن تطلب من الوكيل: “حوّل هذا الإخراج القديم إلى حقول JSON.”).
6. استخدم أداة ترحيل نموذجية. على سبيل المثال، يتضمن مستودع Legacy-Modernization-Agents من مايكروسوفت وكلاء تجريبيين لـ COBOL. أو جرب نسخة تجريبية من أداة مثل PhoenixCode (التي تدعم Delphi، PowerBuilder، VB6، إلخ) للاطلاع على التحويلات الآلية للغتك.
7. أشرك فريقك. شارك مخرجات الذكاء الاصطناعي مع الزملاء أو محللي الأعمال. تحقق مع خبير المجال: “هل هذه الترجمة صحيحة؟” استمر في التكرار.

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

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