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

الغريزة حين تتداخل عدة أنظمة داخلية هي دمجها. وذلك خطأ عادةً، والسبب ليس عاطفياً.

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

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

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

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

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

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

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

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

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

الشكل الأنفع غالباً أن يقوم النظام صاحب الواجهة الأفضل بـالتفويض بدل التكرار.

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

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

ليس مجانياً، والكلف حقيقية:

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

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

الصدق في هذا مهم، لأن البديل تقديمه مجاناً وفقدان المصداقية عند أول فاتورة.

تدفع تكراراً — أنظمة عدة يفعل كل منها نسخته مما كانت خدمة مشتركة ستفعله مرة. وتدفع انضباط عقود: فالواجهة المنشورة لا تُغيَّر يوم جمعة. وتدفع تنسيقاً لكل ما هو عابر فعلاً.

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

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

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

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

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

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