بناء بنية تتيح للمُدمِج أن يدير عملاء كثيرين وفرقًا كثيرة ومشاريع كثيرة داخل منصة واحدة — مع ضمان ألا يرى أحد ما لا يحق له، وأن يجد الجميع من يحتاجون العمل معهم.
السياق
عملاء Cervello مُدمِجون وموردو برمجيات. وهم لا يستخدمون المنصة لإدارة مبنى واحد — بل لبناء حلول وتشغيلها لعملائهم هم، عدة حلول في وقت واحد.
فعميل واحد لـ Cervello قد يدير حل مواقف ذكية لمدينة، وحل مراقبة مرافق لمجموعة متاجر، وتجربة أولية لعميل محتمل — في آن واحد. فرق مختلفة، وعملاء مختلفون، وأشخاص يجب ألا يرى بعضهم عمل بعض.
والمشتري غالبًا ليس هو المستخدم. فمن يوقّع العقد ليس المهندس الذي يضبط الأجهزة في الثانية صباحًا. وبنية تفترض صاحب حساب واحدًا يرى كل شيء لا تصف هذا العمل إطلاقًا.
وهذا هو الجزء الذي أخذته بأكبر جدية في المشروع، والسبب بسيط: المعمار هو القرار الوحيد الذي لا يمكن التراجع عنه لاحقًا. فالبنية الخاطئة لا تُرقّع بإعادة تصميم الشاشات فوقها — وتغييرها لاحقًا يعني نقل النموذج الذهني لكل المستخدمين دفعةً واحدة. فكان يستحق أن أمنحه الوقت، وأن أغطي الحالات المربكة قبل أن يُبنى فوقه شيء.
القرار
أربع طبقات متداخلة
Instance ← Organisation ← Team ← Project. وكل طبقة تجيب عن سؤال مختلف: ولكل طبقة صفحة رئيسة خاصة بها، تعرض ما هو جارٍ عند ذلك المستوى — أحدث المشاريع والفرق والأعضاء مرتّبين بالنشاط. فالبنية لا تنفع إلا إذا كان كل مستوى يجيب عن سؤال «ماذا يحدث هنا؟» دون أن يضطر أحد للصعود أو النزول ليعرف. وصفحة الـ team تعرض مشاريعه قابلة للترتيب بالاسم أو بالنشاط أو بسعة الأجهزة — وتبويب ثانٍ يعرض أعضاءه، فتُدار الصلاحيات والنشاط في المكان نفسه الذي فيه العمل، لا في لوحة إدارة منفصلة.
القرار
مشكلة الرؤية، مصوغة بوضوح
من أحدّ ما خرج من البحث، وجاء على لسان مسؤول: وهنا الصعوبة الحقيقية في الصلاحيات المتداخلة. فالتقييد سهل البناء وسهل المبالغة فيه. وإذا أقفلت كل شيء، تتحول البنية إلى قفص: يعجز الناس عن أداء العمل الذي وُجدت أدوارهم من أجله. لذلك جُعلت رؤية الأعضاء محدودة بالطبقة التي أنت مسؤول عنها. فقائمة أعضاء الـ instance كاملة لا يراها إلا مالكه أو مسؤوله. وأعضاء الـ organisation يُرون عند مستواها. وأعضاء الـ team داخل الـ team. أي أن كل مسؤول يرى بالضبط الفئة التي يحق له أن يتصرف فيها — لا أكثر، والأهم لا أقل. وملف العضو يعرضه عبر الـ instance كله: الفرق والمشاريع التي يشارك فيها، ونشاطه الأخير. وهذا هو حل مشكلة التصادم — عدة أشخاص يعملون في المساحة نفسها دون معرفة من فعل ماذا. فالنشاط ليس سجلاً مدفونًا في الإعدادات؛ بل مرتبط بالشخص وبالطبقة.
القرار
الأصول، ونوعان من العلاقة
تحت بنية الصلاحيات تقع بنية ثانية، للعالم المادي. والمشكلة: الجهاز يُبلّغ عن نفسه منفردًا. قياساته وإنذاراته وأحداثه وموقعه — كلها فردية، ولكل جهاز سمات مختلفة. لكن لا أحد يدير مدينة ذكية جهازًا جهازًا. الناس تدير طابقًا، ومبنىً، وحيًا. لذلك تتيح الأصول (assets) للمستخدم أن يعكس بنيته الواقعية داخل النظام، وأن يتصرف في مجموعة كاملة بإجراء واحد — يطبّق على كل جهاز وكل أصل فرعي تحته. وللهرم نوعان من الروابط: belongs وrelates. وهذا التمييز هو الجزء المثير للاهتمام. فالبنية المادية متداخلة فعلًا — الحساس ينتمي لطابق ينتمي لمبنى. لكن البنية التحتية الحقيقية فيها أيضًا علاقات تقطع الشجرة عرضًا: معدات تخدم مبنيين، أو نظام يمتد عبر عدة مواقع. ونموذج أب-وابن وحيد كان سيجبر المستخدمين على الكذب على بنيتهم التحتية لتناسب الشكل الذي يتوقعه البرنامج. ووجود نوعين من الروابط يجعل البنية تصف الواقع بدل أن تبسّطه. والمبدأ نفسه يمتد إلى المراقبة: الإنذارات والأحداث تُعرض على خريطة حسب الموقع، مع درجة الخطورة، مجمّعة حسب الوحدات — لأن السؤال الذي يطرحه المشغّل ليس أبدًا «أي رقم جهاز أخفق؟» بل «ما الخلل، وأين، وما مداه؟»
النتيجة
البنية أُطلقت، وهي ما تعمل عليه المنصة في الإنتاج اليوم.
ولا يُدّعى أي رقم — فأنا لا أملك أرقام استخدام لهذا المنتج.
والذي يمكن ادعاؤه هو المعمار نفسه: أربع طبقات متداخلة برؤية محدودة عند كل منها، ونموذج نشاط يجيب عن من-فعل-ماذا داخل مساحة مشتركة، وهرم أصول يعترف بأن البنية التحتية لا تتخذ دائمًا شكل شجرة نظيفة.
Next chapter: Method — the principles, the design system, and the Feature Catalogue.