اتحاد الأنظمة دون دمجها

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

المنتجات التي تخدم جماهير مختلفة تختلف بطرق تبدو تكراراً وليست كذلك.

فأداة للمطورين وأداة لأصحاب منشآت صغيرة غير تقنيين قد ترسل كلتاهما رسائل واتساب. ودمجهما قد يُنتج منتجاً واحداً معقداً أكثر مما يحتمل الجمهور الثاني ومقيداً أكثر مما يحتمل الأول. فـ"التكرار" كان هو التكيّف مع كل جمهور.

والصيغة العامة: حين يتشارك نظامان آليةً ولا يتشاركان مستخدماً، فالآلية عَرَض والمستخدم جوهر. والتوحيد على الآلية يخاطر برمي الجوهر.

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

أربعة أمور، بهذا الترتيب.

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

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

3. أعراف متسقة لا قاعدة بيانات مشتركة. اتفقوا على كيفية تعريف جهة الاتصال، وصيغة التوقيتات، وشكل الأخطاء، وطريقة توقيع الاستدعاءات (webhooks). ولا تتفقوا على مخطط واحد: فذلك دمج بقبعة مختلفة.

4. اتجاه سلطة واحد لكل واقعة. فلكل قطعة بيانات نظام واحد بالضبط هو مصدر الحقيقة، ويحمل الباقون نسخاً يُسمح صراحةً بأن تتأخر قليلاً. ونظامان يعتقد كلاهما أنه يملك حالة الموافقة سيتباعدان، وقد تكتشف التباعدَ جهةٌ تنظيمية.

الاتحاد ليس "دع الأنظمة وشأنها". فالأنظمة التي لا تتشارك شيئاً ليست متحدة بل منفصلة فحسب. والاتحاد مجموعة محددة من الالتزامات المنشورة، والعمل في الالتزامات لا في الكود.

الشكل الأنفع غالباً أن يفوّض نظام إلى آخر بدل أن يكرره.

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

لا شيء ينتقل. ويحتفظ كلاهما بجمهوره. وتصبح القدرة متاحة عبر واجهة صُممت أصلاً لتُستدعى.

ليس مجانياً، والصدق في كلفته مهم:

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

وما تشتريه: لا تغيير منفرداً يُسقط كل شيء، ويتحرك كل منتج بوتيرته، ويحمل كلٌّ وزنه التنظيمي وحده، ويمكن استبدال أي منها أو بيعه أو إيقافه دون فكّ الآخرين.

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

قبل دمج نظامين، اسأل: هل لهما المستخدم نفسه؟

لا المشتري نفسه. ولا المؤسسة نفسها. بل الشخص نفسه، يؤدي العمل نفسه، في اليوم نفسه.

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

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

• الثغرة التي لا يملؤها أحد: الهوية بين الخدمات: طبقة الهوية التي يعتمد عليها الاتحاد.
• تقييم عقد منصة اتصال: بنود الخروج وقابلية النقل التي تحدد هل المزوّد جزء يمكنك استبداله.