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