تكاد كل منشأة راسخة تعتمد على نظام واحد على الأقل لا غنى عنه ويصعب تغييره في الوقت ذاته؛ يحمل قواعد عمل تراكمت عبر سنوات، ويتكامل مع كل شيء، ولا يفهمه بالكامل إلا قلة. وحين تظهر احتياجات جديدة، كتطبيق جوال أو تكامل مع شريك أو مساعد ذكي أو تقرير تنظيمي جديد، يصبح هذا النظام عنق الزجاجة.
الاستجابة الغريزية هي إعادة كتابته بالكامل. ومخاطر هذا المسار معروفة لكل من خاضه: تجميد التطوير لفترة طويلة، ونظام قديم يستمر في التغير بينما يلاحقه النظام الجديد، وقواعد عمل غير موثقة لا تظهر إلا متأخرة، وأحيانًا في بيئة الإنتاج. أما النهج المرحلي القائم على مبدأ API أولًا، فشرحه أطول لكن تنفيذه أكثر أمانًا بكثير.
لماذا يكون نهج API أولًا هو الوجهة الصحيحة؟
يعني هذا النهج أن كل قدرة عمل، كالاستعلام عن حالة عميل أو إصدار فاتورة أو حجز موعد، تُتاح عبر واجهة برمجة تطبيقات (API) بعقد واضح ومرقّم الإصدارات قبل أن تستخدمها أي شاشة بعينها. فقنوات الويب والجوال، والشركاء، والأدوات الداخلية، والمساعدات الذكية، تستخدم جميعها العقود نفسها. وهذا الفصل هو ما يجعل الإحلال التدريجي ممكنًا: ما دام العقد ثابتًا، يمكن تغيير ما خلفه.
المرحلة 0: اكتشف ما يفعله النظام القديم فعلًا
- احصر الوحدات والتكاملات والمهام المجدولة والتقارير، ومنطق الأعمال المخبأ في الإجراءات المخزنة ومُشغّلات قاعدة البيانات.
- استخدم سجلات الوصول والمقابلات لمعرفة الوظائف المستخدمة فعلًا ومن يستخدمها؛ فبعض أجزاء النظام يمكن إيقافها ببساطة.
- حلّل جودة البيانات مبكرًا: التكرارات والرموز غير المتسقة والقيم المفقودة ستحدد شكل خطة الترحيل.
- حدّد نقاط الفصل الطبيعية، أي المواضع التي يمكن فيها فصل قدرة ما بأقل قدر من الترابط.
المرحلة 1: ضع طبقة واجهة أمام النظام
أضف بوابة API وطبقة واجهة (facade) بين المستهلكين والنظام القديم. عرّف العقود بمعيار OpenAPI، وابدأ بقدرات القراءة فقط التي تغلّف المنطق القائم. وأرسِ من اليوم الأول مصادقة موحدة عبر OAuth 2.0 وOpenID Connect، وتحديدًا لمعدل الطلبات، وقابلية للمراقبة. في هذه المرحلة لم يُستبدل شيء بعد، لكن صار بالإمكان بناء القنوات الجديدة على واجهات مستقرة بدل الاتصال المباشر بقاعدة البيانات القديمة.
المرحلة 2: الإحلال التدريجي، قدرةً بعد قدرة
يقوم نمط «التينة الخانقة» (Strangler Fig) على استبدال النظام القديم تدريجيًا: لكل قدرة تُبنى خدمة جديدة خلف العقد نفسه، وتُحوَّل إليها الحركة شيئًا فشيئًا.
- اختر المرشح الأول بعناية: ذو قيمة، ومفهوم جيدًا، وضعيف الترابط.
- استخدم طبقة عازلة (anti-corruption layer) تترجم بين نماذج البيانات القديمة ونموذج المجال الجديد، حتى لا تتسرب تنازلات الماضي إلى الشيفرة الجديدة.
- وجّه الحركة بمفاتيح الميزات، بدءًا بالمستخدمين الداخليين أو نسبة صغيرة من الطلبات.
- شغّل المسارين بالتوازي حيث تكون المخاطر عالية: أرسل الطلب إلى الاثنين، وقارن المخرجات، ولا تنتقل إلا بعد تفسير كل فرق.
المرحلة 3: ترحيل البيانات بلا مفاجآت
- حدّد مصدر الحقيقة لكل كيان في كل مرحلة، ودوّنه كتابةً.
- استخدم التقاط تغييرات البيانات (CDC) لمزامنة المخزنين القديم والجديد أثناء الانتقال، بدل الكتابة المزدوجة من شيفرة التطبيق.
- طبّق نمط صندوق الصادر (transactional outbox) حتى لا تفترق الأحداث عن تغييرات قاعدة البيانات.
- أصدر تقارير مطابقة يستطيع ملاك الأعمال قراءتها واعتمادها.
- تدرّب على كل عملية انتقال مسبقًا، مع مسار تراجع مُختبَر وقرار واضح بالمضي أو التوقف.
المرحلة 4: الإيقاف المدروس
لا يؤتي التحديث ثماره إلا حين تُطفأ المكونات القديمة فعلًا. أوقف الوحدات القديمة حين تصل حركتها إلى الصفر، وأرشف البيانات وفق متطلبات الاحتفاظ، وأزل التكاملات وبيانات الاعتماد التي لم تعد مستخدمة. وكثيرًا ما تتعثر البرامج في هذه المرحلة تحديدًا، لأن الوظائف الأخيرة نادرة الاستخدام هي الأصعب نقلًا؛ لذا خطط لها وخصص لها ميزانيتها من البداية.
أخطاء تعرقل التحديث بصمت
- اعتبار طبقة الواجهة خط النهاية: تغليف النظام القديم نقطة بداية، ودون خطة إيقاف يصبح مجرد طبقة إضافية.
- إعادة بناء نموذج البيانات القديم في الخدمات الجديدة، فتنتقل إليها القيود نفسها التي جاء البرنامج لإزالتها.
- نسيان المستهلكين الخفيين: التقارير وجداول البيانات وأدوات ذكاء الأعمال التي تقرأ مباشرة من قاعدة البيانات القديمة ستتعطل عند الانتقال ما لم تُكتشف وتُنقل أولًا.
- إغفال الجانب البشري: الشاشات والإجراءات الجديدة تحتاج إلى تدريب، وتحديث لأدلة العمل، ودعم مكثف في الأسابيع الأولى بعد كل انتقال.
حوكمة تحافظ على الزخم
- إرشادات لتصميم الواجهات ومراجعات تصميم خفيفة، لتبقى العقود متسقة بين الفرق.
- سياسة لإصدارات الواجهات مع فترات إيقاف معلنة مسبقًا.
- بوابة للمطورين أو فهرس يتيح للفرق الداخلية والشركاء اكتشاف الواجهات وتجربتها.
- اختبارات عقود يقودها المستهلك، تكشف التغييرات التي تُخل بالتوافق قبل الإطلاق.
- مالك أعمال لكل مجال يعتمد كل عملية انتقال.
ينجح التحديث حين لا تكاد الأعمال تشعر بحدوثه، سوى أن كل شيء يصبح أسهل.
كيف تختار الشريحة الأولى؟
الشريحة الأولى الجيدة غالبًا ما تكون قائمة على القراءة، ظاهرة للعملاء، ومنخفضة المخاطر: استعلام عن حالة طلب، أو كتالوج منتجات، أو ملخص حساب. فهي تُثبت جدوى طبقة الواجهة وخط النشر والمراقبة في بيئة الإنتاج، وتقدم قيمة ملموسة بسرعة، وتبني الثقة اللازمة للقدرات الأصعب القائمة على الكتابة التي تليها.