كانت شركة توزيع في عمّان تعمل على نظام كُتب عام 2009 على يد مطوّر هاجر عام 2014. ولم يكن أحد يعرف كيف تعمل أجزاء منه. وكان أيضاً يعالج كل طلب يستقبله العمل. وهذا المزيج — حرج وغير مفهوم — أصعب مشكلة في برمجيات المؤسسات، وهو شائع.
ترحيل الأنظمة القديمة كتحويل واحد يفشل بما يكفي ليصبح النمط موثّقاً جيداً. أما تنفيذه على مراحل فغير مبهر وينجح.
لماذا يفشل التحويل الشامل
يُستبدل كل شيء في عطلة نهاية أسبوع. ويأتي الاثنين، فلا يعمل شيء لم يتوقعه أحد، فيعجز العمل عن التشغيل. وقد أُوقف النظام القديم أصلاً أو تجاوزت البيانات نقطة اللاعودة.
والفشل ليس تقنياً عادةً، بل أن خمسة عشر عاماً من الحالات الخاصة المتراكمة — العميل ذو شروط الائتمان غير المعتادة، والمنتج المسعّر بشكل مختلف لفرع واحد، والاستثناء الضريبي الذي لم يوثّقه أحد — غير مرئية في الشيفرة وغائبة عن كل مواصفة. فتكتشفها في الإنتاج، دفعة واحدة، في أكثر الأيام ازدحاماً.
نمط الخنق في ترحيل الأنظمة القديمة
سُمّي على اسم نبات متسلق ينمو حول شجرة ويحل محلها في النهاية. فبدل استبدال النظام، تستبدل وظيفة واحدة في كل مرة بينما يستمر النظام القديم بالعمل.
- ضع طبقة توجيه أمام النظام القديم. ويبقى كل شيء يمرّ إلى الشيفرة القديمة.
- ابنِ وحدة جديدة واحدة — التقارير مثلاً، لأنها للقراءة فقط ومخاطرتها منخفضة.
- وجّه الموجِّه إلى الوحدة الجديدة لتلك الوظيفة وحدها.
- تحقق لبضعة أسابيع. فإن كانت خاطئة، أعد التوجيه خلال دقائق.
- كرّر مع الوظيفة التالية.
وفي النهاية لا يعالج النظام القديم شيئاً فيمكن إطفاؤه بلا مراسم. يستغرق وقتاً أطول إجمالاً، وكل خطوة فيه قابلة للتراجع، وهذا ما يجعله قابلاً للنجاة.
عالج جودة البيانات قبل كل شيء
كل نظام قديم يحوي بيانات خاطئة بطرق تكيّف معها العمل: سجلات عملاء مكررة، ومنتجات برمزين، وعناوين في حقل نص حر.
ولا تستطيع ترحيل هذا وإصلاحه لاحقاً. فترحيله يعني أن يرث النظام الجديد المشكلة، ومعها مشكلة جديدة: نظامان صارا يختلفان.
خصّص وقتاً حقيقياً للتنظيف. وفي مجموعة بيانات أردنية، توقّع أن تجد:
- العميل نفسه مسجّلاً ثلاث مرات بإملاءات مختلفة — نقل عربي ولاتيني لاسم واحد.
- أرقام هواتف بأربع صيغ.
- عناوين لا يفهمها إلا السائق الذي يوصّل إليها.
- حركات تاريخية بلا سجل عميل مطابق.
نظّف في النظام القديم إن استطعت. فالتنظيف أثناء الترحيل يعني فعله تحت ضغط الوقت، وهو حين تُرتكب الأخطاء.
شغّل الاثنين، عن قصد
لفترة محددة — شهر عادةً — يعالج النظامان الحركات نفسها وتقارن المخرجات يومياً. وهذا جهد مضاعف وسيشتكي الموظفون، ولهذا يجب شرحه كخطوة تحقق مقصودة لها تاريخ انتهاء.
وما تبحث عنه ليس هل يعمل النظام الجديد، بل هل ينتج الإجابات نفسها، بما فيها الحالات الشاذة التي تحدث مرتين شهرياً.
خطة التراجع
اكتبها قبل التحويل، في صفحة واحدة، وتأكد أن غير كبير المطوّرين يستطيع تنفيذها.
- ما الموعد النهائي لقرار التراجع؟
- من يتخذ ذلك القرار، ومن ينوب عنه إن تعذّر الوصول إليه؟
- ماذا يحدث للحركات المُدخلة في النظام الجديد خلال ذلك؟
- كم يستغرق التراجع، مُختبراً لا مُقدَّراً؟
معظم خطط التراجع لا تُستخدم أبداً. والخطط الموجودة تميل إلى ألا يُحتاج إليها، لأن كتابتها تكشف الثغرات التي كانت ستسبب الفشل.
أبقِ النظام القديم قابلاً للقراءة
لا تحذفه. أبقِ نسخة للقراءة فقط متاحة سنة على الأقل — وسنتين يفضَّل، لأن التدقيقات والنزاعات تظهر متأخرة.
التخزين رخيص. أما العجز عن الإجابة عن سؤال بشأن حركة من 2022 لأن النظام الذي حواها أُوقف، فليس رخيصاً.
كم يستغرق ترحيل الأنظمة القديمة
أطول من التقدير. فلنظام أعمال متوسط بخمسة عشر عاماً من السجلات، خطّط لتسعة إلى ثمانية عشر شهراً لترحيل مرحلي، مع قيمة حقيقية تُسلَّم من الشهر الثالث لا في النهاية.
وهذا أبطأ مما تَعِد به إعادة الكتابة، وأسرع مما تُسلّمه فعلاً.
