تكامل الأنظمة

لماذا تتعثر مشاريع تكامل الأنظمة، وكيف يُخطَّط لها؟

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

فريق تقنية6 دقائق قراءة

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

فيما يلي الأسباب الخمسة الأكثر تكرارًا، وبعدها قائمة تحقق تُستخدم قبل البدء.

1. لم يُحسم أي نظام يملك البيانات

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

لكل كيان بيانات يعبر الحدود بين الأنظمة، اتفقوا على:

  • المصدر المرجعي (Source of truth): نظام واحد يُنشأ فيه السجل ويُعدَّل.
  • اتجاه التدفق: الأنظمة الأخرى تستلم نسخًا ولا تغيّرها، أو تغيّر حقولًا محددة متفقًا عليها فقط.
  • المالك من جهة الأعمال: شخص معيَّن بالاسم يفصل في الخلافات ويعتمد أي تغيير في التعريف.

والمزامنة في الاتجاهين للحقل نفسه مصدر لجزء كبير من المتاعب. تجنبوها ما لم يكن هناك سبب قوي، وإذا تعذّر تجنبها فضعوا قواعد صريحة لحسم التعارض.

وتوقعوا أن تختلف التعريفات نفسها. فقد يعني «العميل» في الإدارة المالية كيانًا قانونيًا، وفي المبيعات جهة اتصال في أحد الفروع. التوفيق بين هذه المعاني يستغرق وقتًا حقيقيًا، وهو عمل يخص جهة الأعمال ويجب إنجازه قبل العمل التقني.

2. الأنظمة القديمة غير موثقة

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

المعالجة العملية هي مرحلة استكشاف تسبق اعتماد أي تقدير نهائي:

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

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

3. تكاثر الروابط المباشرة بين الأنظمة

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

لا تحتاج كل منشأة إلى منصة تكامل متكاملة. لكن كل منشأة تحتاج إلى قرار مدروس عند النقطة التي يبدأ فيها عدد الأنظمة المترابطة بالتزايد:

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

وأيًّا كان الأسلوب، احتفظوا بسجل محدَّث لكل تكامل: ما الذي يربطه، وأي بيانات ينقلها، وبأي وتيرة، ومن المسؤول عنه. تحديث هذا السجل قليل التكلفة، ويوفّر وقتًا كبيرًا عند أي تغيير في أحد الأنظمة.

4. تأجيل معالجة الأخطاء والمراقبة

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

صمّموا مسارات الإخفاق مع مسارات النجاح في الوقت نفسه:

  • إعادة المحاولة عند الأعطال المؤقتة، بحدّ أقصى، حتى لا تدور الرسالة المتعثرة بلا نهاية.
  • إعادة المعالجة الآمنة، فلا ينشأ طلبان عن إرسال الرسالة نفسها مرتين.
  • منطقة احتجاز للرسائل التي تعذّرت معالجتها، مع وسيلة لفحصها وتصحيحها وإعادة إرسالها.
  • تنبيهات تصل إلى شخص أو فريق معيَّن عند تجاوز الإخفاقات حدًّا محددًا.
  • المطابقة الدورية، أي مقارنة أعداد السجلات أو الإجماليات بين الأنظمة لاكتشاف ما فات.

ولا يقل عن ذلك أهمية تحديد من يتصرف عند ورود التنبيهات. فالتكامل الذي يعمل عند الإطلاق وليس له مالك تشغيلي يتراجع دون أن ينتبه أحد.

5. الاستهانة بالاختبار على بيانات حقيقية

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

اجعلوا الاختبار جزءًا رئيسًا من خطة المشروع، لا خطوة أخيرة فيه:

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

قائمة تحقق للتخطيط

قبل الالتزام بجدول زمني، تأكدوا من قدرتكم على الإجابة عما يلي:

  1. ما المصدر المرجعي لكل كيان بيانات، ومن مالكه من جهة الأعمال؟
  2. هل استدعينا كل واجهة في بيئة اختبار وفحصنا عينة بيانات حقيقية؟
  3. هل تعريفات البيانات ومطابقة الحقول متفق عليها ومكتوبة؟
  4. هل اخترنا أسلوب تكامل يناسب عدد الأنظمة المتوقع خلال سنتين إلى ثلاث؟
  5. ماذا يحدث عند إخفاق رسالة، ومن يُبلَّغ؟
  6. كيف سنطابق البيانات بين الأنظمة؟
  7. هل لدينا بيانات اختبار واقعية ووقت في الخطة لعدة دورات اختبار؟
  8. من يشغّل التكامل ويصونه بعد الإطلاق؟
  9. هل نعتمد على مورّدين أو فرق أخرى، وهل التزموا بمواعيد محددة؟

البنود التي لا جواب عنها ليست سببًا لإلغاء المشروع. هي نفسها أعمال الاستكشاف، ومكانها بداية الخطة.

الخلاصة العملية

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

يمكن الاطلاع على طريقتنا في أعمال التكامل ضمن خدماتنا، وإذا كنتم تخططون لمشروع وتودّون مراجعته مع جهة مختصة، ففريق تقنية متاح للتواصل.

  • تكامل الأنظمة
  • واجهات برمجة التطبيقات
  • تخطيط المشاريع

لديكم مشروع أو تحدٍّ تقني؟ لنتحدث عنه.

أخبرونا بما تريدون بناءه أو تحسينه، ونعود إليكم بتصوّر واضح للخطوة التالية.