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