كيف نخطّط البنية التقنية لنموّ بعشرة أضعاف

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

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

ابدؤوا من الهدف

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

ولا يُشترط أن تكون الأرقام دقيقة. جملة مثل «قرابة عشر شركات في المجموعة، في ثلاثة بلدان، بالعربية والفرنسية والإنجليزية، وبضعة آلاف من الموظفين» تكفي لاستبعاد تصاميم وترجيح أخرى. أما الأسئلة التي نطرحها فبسيطة:

• كم مؤسسة ستتشارك المنصة، وهل يجب فصل بياناتها فصلًا صارمًا؟
• ما اللغات واتجاهات الكتابة التي ستحتاجها الواجهة؟
• قوانين أي بلدان ستنطبق (الأجور، والجباية، ومكان تخزين البيانات)؟
• ماذا يحدث لعمل الشركة إن توقفت المنصة ساعة واحدة؟

النمو يُخطَّط له، ولا يُترك للصدفة.

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

صمّموا المفاصل أولًا

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

المَفصِل واجهة برمجية يعتمد عليها باقي الشيفرة، فلا يتعامل مباشرة مع التنفيذ الذي يقف خلفها:

// a seam today, a service tomorrow
export interface Billing {
  charge(order: Order): Promise<Receipt>
}

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

وهنا يكمن الفرق بين الاستعداد للتوسّع والمبالغة في البناء. فنحن لا نبدأ بعدد كبير من الخدمات المصغّرة (microservices) وناقل رسائل وثلاث قواعد بيانات. نبدأ بتطبيق واحد متين البنية، حدوده الداخلية مرسومة من الآن في المواضع التي ستقوم فيها الخدمات لاحقًا.

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

قيسوا قبل أن تتوسّعوا

كل منصة نطلقها تأتي مزوّدة بالمراقبة من يومها الأول، فيُبنى قرار التوسّع على البيانات بدل التخمين.

أي أن ثلاثة أمور تكون جاهزة قبل أن يسجّل أول مستخدم حقيقي دخوله:

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

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

كيف يبدو ذلك عمليًا

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

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