معمارية المؤسسة Enterprise Architecture ببساطة

لنفرض أنك تعمل في شركة متوسطة الحجم، وجاء طلب من الإدارة بإيقاف نظام الموارد البشرية القديم HR والانتقال إلى نظام جديد قبل نهاية العقد، وسؤال المدير بسيط جداً: ما الذي سيتوقف إذا أطفأنا السيرفر القديم؟ وعند البحث عن الإجابة سوف تجد أن نظام الرواتب Payroll يقرأ منه بيانات الموظفين كل شهر، وأن الدليل الذي يعتمد عليه الدخول الموحد SSO يأخذ منه أسماء الموظفين الجدد، وأن أجهزة الحضور ترسل إليه السجلات، وأن تقريراً شهرياً في الإدارة المالية مبني على استعلام كتبه موظف غادر الشركة قبل سنتين، ولا أحد يعرف هذه القائمة كاملة، لأن كل جزء منها في ذاكرة شخص مختلف أو في رسالة بريد قديمة. وهذه هي المشكلة التي تحاول معمارية المؤسسة Enterprise Architecture حلها.

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

• المشكلة التي تحلها معمارية المؤسسة، ولماذا لا يكفي جدول بأسماء الأنظمة.
• تعريفها كما تكتبه جهة رسمية، والمجالات الأربعة: الأعمال Business والبيانات Data والتطبيقات Application والتقنية Technology.
• ما الذي ينتجه فريق المعمارية فعلاً: القوائم والمصفوفات والرسوم، والوضع الحالي والمستهدف وخارطة الطريق.
• إطار TOGAF ودورة ADM ببساطة، وإطار Zachman باختصار، ولغة النمذجة ArchiMate وأداة Archi المفتوحة المصدر.
• من يعمل في فريق معمارية المؤسسة، وكيف تجري مراجعة المعمارية Architecture Review.
• الفشل الأشهر، أي المعمارية المعزولة في البرج العاجي Ivory Tower، وكيف تبدأ مؤسسة صغيرة بمعمارية خفيفة.

المشكلة: مئات الأنظمة ولا أحد يعرف أثر التغيير

المؤسسة لا تبني أنظمتها في يوم واحد، فالإدارة المالية اشترت نظام تخطيط الموارد ERP قبل عشر سنوات، والمبيعات اشتركت في نظام لإدارة علاقات العملاء CRM لأنه أسرع من انتظار قسم التقنية، وخدمة العملاء طلبت من شركة خارجية بوابة صغيرة، وكل نظام منها يحتاج بيانات من نظام آخر، فيكتب فريق ما تكاملاً Integration سريعاً بملف يرسل كل ليلة أو باستعلام مباشر إلى قاعدة بيانات نظام آخر. وبعد سنوات تجد الصورة التي تعرفها أغلب المؤسسات: نظامان لنفس العمل لا يتفقان على الأرقام، وتقارير تجمع يدوياً من ثلاثة مصادر، وتكاملات لا يعرف أحد من يملكها، وعقود ترخيص تتجدد كل سنة لأنظمة لا يستخدمها إلا عدد قليل من الموظفين.

والحل البسيط الأول هو أن تطلب من كل إدارة قائمة بأنظمتها وتجمعها في جدول Excel واحد، وهذا أفضل من لا شيء، ولكنه يجيب عن سؤال «ماذا نملك؟» فقط، ولا يجيب عن «ماذا يعتمد على ماذا؟» ولا «أي خدمة تتأثر إذا تعطل هذا النظام؟» ولا «لماذا لدينا نظامان لإدارة العملاء؟»، والسبب أن الجدول لا يحفظ العلاقات، وأنه يتقادم في اليوم الذي ينتهي فيه المشروع الذي أنشأه. والحل البسيط الثاني هو أن تطلب من قسم التقنية أن يوافق على كل نظام جديد، وهذا يجعل القسم عنق زجاجة Bottleneck، فتلجأ الإدارات إلى الاشتراك في خدمات سحابية ببطاقة الشركة دون أن تمر على أحد.

والصورة التالية تبين الفرق بين أن تكون الإجابة في ذاكرة الناس، وأن تكون في خريطة محدثة تقرؤها قبل أن تقرر:

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

ما هي معمارية المؤسسة؟

من أوضح التعريفات المكتوبة بالعربية تعريف هيئة الحكومة الرقمية في الدليل الاسترشادي لتأسيس البنية المؤسسية في الجهات الحكومية (الإصدار 1.0، فبراير 2022، صفحة 5)، والهيئة تسميها «البنية المؤسسية»، فهي «ممارسات وضوابط لدراسة الوضع الحالي للجهة الحكومية، وبناء خارطة الطريق للتحول إلى الوضع المستقبلي لتحقيق المواءمة بين قطاع الأعمال (الخدمات والإجراءات) وتقنية المعلومات (البيانات، والتطبيقات، والبنية التحتية) والأهداف الاستراتيجية للجهة». ولاحظ أن التعريف فيه ثلاثة أجزاء: وضع حالي As-Is، ووضع مستقبلي To-Be، وطريق بينهما Roadmap، وأن الهدف هو المواءمة Alignment بين ما تفعله المؤسسة وما تملكه من تقنية وما تريد الوصول إليه، وهو تعريف يصلح للشركات أيضاً إذا وضعت كلمة «الشركة» مكان «الجهة».

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

المجالات الأربعة: من الخدمة إلى السيرفر

تقسم أغلب أطر معمارية المؤسسة الصورة إلى أربعة مجالات Domains، وهو نفس التقسيم الذي يستخدمه إطار TOGAF ودليل التأسيس الذي ذكرناه أعلاه (صفحة 19 من النسخة الإنجليزية في قائمة التعريفات)، وفيما يلي كل مجال وأمثلة على محتواه كما يذكرها الدليل:

• بنية الأعمال Business Architecture: الاستراتيجية والمبادرات وقائمة الخدمات وإجراءات العمل، ومعها القدرات Capabilities والإدارات والأدوار.
• بنية البيانات Data Architecture: تصنيف البيانات Data Classification، وقائمة البيانات التي تستخدمها المؤسسة ومصادرها وقواعد البيانات المرتبطة بها، وتبادل البيانات Data Exchange بين الأنظمة.
• بنية التطبيقات Application Architecture: قائمة التطبيقات والمنتجات الرقمية وخصائصها، ومعلومات التكامل بينها.
• البنية التقنية Technology Architecture: تراخيص البرمجيات والأجهزة، والبنية التحتية والشبكات والاتصالات ومراكز البيانات.

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

في الرسم أعلاه لاحظ التالي:

• إذا قررت الشركة ترقية قاعدة البيانات PostgreSQL، فالروابط تخبرك أن تطبيق التتبع يعتمد عليها، وأن خدمة التتبع للعملاء سوف تتأثر أثناء الترقية، وأن مالك الخدمة هو إدارة خدمة العملاء، فتعرف من يجب أن يوافق على موعد الإيقاف.
• إذا قررت إدارة العمليات تغيير تعريف «الشحنة» في بياناتها، فالروابط تخبرك أي تطبيقات تقرأ هذا الكيان Entity وأي واجهة API تنشره للعملاء.
• الأسماء في الرسم مثال افتراضي، ولكن نوع الأسئلة حقيقي، وهو ما يسأل عنه المدير والمدقق ومدير المشروع كل أسبوع.

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

ما الذي ينتجه فريق معمارية المؤسسة؟

المخرجات Artefacts التي ينتجها الفريق أنواع قليلة تتكرر في كل الأطر تقريباً، وهي ثلاثة أشكال للعرض: القائمة Catalog مثل قائمة التطبيقات مع مالك كل تطبيق، والمصفوفة Matrix مثل جدول يربط التطبيقات بالقدرات التي تخدمها، والرسم Diagram مثل مخطط التكامل بين الأنظمة. وهذا التقسيم نفسه تطلبه هيئة الحكومة الرقمية من الجهات عندما تطلب «تطوير مناظير البنية المؤسسية بأنواعها المختلفة (قائمة، ومصفوفة، ورسم مرئي)». وأهم هذه المخرجات ما يلي:

• المبادئ Architecture Principles: قواعد قصيرة يتفق عليها الجميع، مثل «نعيد استخدام المنصة المشتركة قبل شراء نظام جديد» أو «كل نظام له مالك من الأعمال ومالك تقني»، ولكل مبدأ سببه وتبعاته.
• سجل التطبيقات Application Catalog: كل نظام ومالكه ومستخدموه والقدرات التي يخدمها والبيانات التي يحفظها وتاريخ انتهاء عقده.
• خريطة القدرات Business Capability Map: ما تفعله المؤسسة بغض النظر عن الإدارات والأنظمة، وقد خصصنا لها مقالاً مستقلاً.
• الوضع الحالي As-Is والوضع المستهدف To-Be: نفس القوائم والرسوم مرتين، مرة لما هو موجود ومرة لما تريده المؤسسة بعد سنتين أو ثلاث.
• تحليل الفجوات Gap Analysis: الفرق بين الوضعين، مثل نظامين يجب دمجهما، أو قدرة لا يخدمها أي نظام، أو تقنية انتهى دعمها.
• خارطة الطريق Roadmap: المبادرات والمشاريع التي تسد الفجوات، بترتيبها وأولوياتها وجدولها الزمني.
• المعايير Standards وسجل القرارات: قائمة التقنيات المعتمدة، وقرارات المعمارية المهمة مع أسبابها، وهي نفس فكرة سجل القرارات المعمارية ADR التي شرحناها في مقال توثيق المعمارية ولكن على مستوى المؤسسة.

والصورة التالية تبين ترتيب هذه المخرجات، فكل خطوة تبنى على التي قبلها:

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

إطار TOGAF ببساطة

الإطار Framework في معمارية المؤسسة هو مجموعة من المفاهيم والخطوات والقوالب التي تساعدك أن تبدأ دون أن تخترع كل شيء من الصفر، وأشهر هذه الأطر معيار TOGAF من The Open Group، والتي تصفه بأنه منهجية وإطار لمعمارية المؤسسة تستخدمه الشركات بمختلف أحجامها والجهات الحكومية. والإصدار الحالي هو الطبعة العاشرة TOGAF Standard, 10th Edition، وقد أعلنت The Open Group إطلاقها في 25 أبريل 2022 ببنية جديدة من جزأين: المحتوى الأساسي TOGAF Fundamental Content الذي فيه المفاهيم والممارسات الثابتة، وأدلة TOGAF Series Guides التي تشرح كيف تضبط هذا المحتوى لحالات مختلفة مثل المؤسسات التي تعمل بأسلوب Agile والتحول الرقمي، والسبب في هذا التقسيم كما يقول الإعلان أن الأدلة يمكن أن تصدر بشكل أسرع دون تغيير المحتوى الأساسي.

وقلب TOGAF هو طريقة تطوير المعمارية Architecture Development Method واختصاراً ADM، وهي دورة من المراحل تبدأ بمرحلة تمهيدية Preliminary لتجهيز ممارسة المعمارية نفسها، ثم مراحل مرقمة بالحروف من A إلى H، وفي وسطها إدارة المتطلبات Requirements Management التي ترتبط بكل المراحل. والصورة التالية رسم مبسط من إعدادنا لترتيب المراحل، وليس الشكل الرسمي الموجود في المعيار:

وفيما يلي معنى كل مرحلة بلغة بسيطة، مع مثال من شركة التوصيل الافتراضية التي تريد استبدال نظام توزيع الشحنات:

1. التمهيد Preliminary: تقرر المؤسسة كيف ستمارس المعمارية: من الفريق، وما المبادئ، وأي إطار ستعدله ليناسبها. وفي المثال: تتفق الشركة على خمسة مبادئ وتختار أداة بسيطة للمستودع.
2. الرؤية Architecture Vision (A): تحديد نطاق العمل وأصحاب المصلحة Stakeholders وصورة مختصرة للنتيجة، والحصول على الموافقة للبدء. وفي المثال: «نظام توزيع واحد لكل المدن بدلاً من نظامين، خلال 18 شهراً».
3. بنية الأعمال Business Architecture (B): القدرات والإجراءات والخدمات المتأثرة بين الوضع الحالي والمستهدف.
4. بنية أنظمة المعلومات Information Systems Architectures (C): البيانات والتطبيقات معاً، أي الكيانات التي يجب ترحيلها والتطبيقات التي ستبقى أو تستبدل.
5. البنية التقنية Technology Architecture (D): السيرفرات والمنصات والشبكات التي سيعمل عليها الوضع المستهدف.
6. الفرص والحلول Opportunities and Solutions (E): تجميع الفجوات في مشاريع ومبادرات، وقرارات مثل الشراء أو البناء أو إعادة الاستخدام.
7. تخطيط الانتقال Migration Planning (F): ترتيب المشاريع في خارطة طريق بأولويات وتكاليف.
8. حوكمة التنفيذ Implementation Governance (G): متابعة المشاريع أثناء التنفيذ حتى لا تبتعد عن المعمارية المتفق عليها، وهنا تظهر مراجعة المعمارية التي سنشرحها لاحقاً.
9. إدارة التغيير Architecture Change Management (H): متابعة التغييرات بعد الإطلاق، وتقرير متى تحتاج المؤسسة دورة جديدة.

وقد يتساءل البعض: هل يجب أن تمر كل مبادرة على المراحل التسع بالترتيب؟ والإجابة لا، فالمعيار نفسه يقدم ADM كدورة تتكرر وتعدل حسب المؤسسة، والمرحلة التمهيدية هدفها تحديداً أن تضبط الإطار على مقاس مؤسستك، لذلك قد تمر مبادرة صغيرة على الرؤية والتطبيقات والانتقال في أسبوعين، بينما يحتاج برنامج تحول كبير كل المراحل بعمق. ومن يطبق الدورة كاملة بكل قوالبها في مؤسسة صغيرة سوف ينتج وثائق كثيرة لا يقرؤها أحد، وهذا هو الفشل الذي سنتكلم عنه بعد قليل.

ويجدر الإشارة هنا إلى أمرين: الأول أن المعيار متاح للتحميل مجاناً للاستخدام غير التجاري، أي داخل مؤسستك عادة، وللاستخدام التجاري رخصة تجارية، ونصه وأشكاله محفوظة الحقوق لصالح The Open Group، لذلك لم ننقل منه نصاً ولا رسماً، والثاني أن TOGAF ليس الإطار الوحيد، فهيئة الحكومة الرقمية مثلاً تذكر في دليلها أن من الأطر المعروفة Zachman وإطار البنية المؤسسية الفدرالية الأمريكي FEAF وTOGAF، وأنها بنت منهجيتها الوطنية على أفضل الممارسات العالمية.

إطار Zachman باختصار

إطار Zachman أقدم من TOGAF، ونشره John Zachman عام 1987 في مقال بعنوان A framework for information systems architecture في مجلة IBM Systems Journal، وفكرته مختلفة تماماً عن ADM، فهو لا يقول لك ماذا تفعل أولاً، وإنما كيف ترتب وصف المؤسسة. ويشرح موقع Zachman International أن الإطار مخطط Schema يلتقي فيه تصنيفان: الأسئلة الأساسية للتواصل وهي ماذا What وكيف How ومتى When ومن Who وأين Where ولماذا Why، ومستويات التحول من الفكرة المجردة إلى التنفيذ، فيرسم عادة كمصفوفة 6 × 6، ويؤكد الموقع أن الإطار «ليس منهجية» Methodology، وإنما هيكل Ontology لوصف المؤسسة، والمنهجية هي العملية التي تختارها أنت.

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

والفائدة العملية من Zachman ليست أن تملأ 36 خلية، وإنما أن تسأل عند كل وثيقة: أي سؤال تجيب عنه هذه الوثيقة، ولأي جمهور؟ فإذا وجدت أن كل وثائقك تجيب عن «ماذا» و«كيف» للمهندسين، ولا يوجد شيء يجيب عن «لماذا» للإدارة، فقد عرفت أين النقص. لذلك يستخدمه كثير من المعماريين كقائمة تحقق Checklist لاكتمال الوصف، ويستخدمون TOGAF أو منهجية محلية كعملية.

لغة ArchiMate وأداة Archi

بعد أن تعرف ماذا تصف، تحتاج طريقة موحدة للرسم حتى لا يرسم كل معماري الصناديق والأسهم بمعنى مختلف، وهنا تأتي مواصفة ArchiMate، وهي معيار من The Open Group أيضاً، وتصفه بأنه لغة نمذجة Modeling Language مفتوحة ومستقلة لمعمارية المؤسسة، تدعمها أدوات من موردين مختلفين، وتسمح بوصف العلاقات بين مجالات الأعمال بشكل لا يحتمل أكثر من معنى. وحسب صفحة التحميل الرسمية فأحدث إصدار هو ArchiMate 4 الذي صدر في أبريل 2026، وقبله الإصدار 3.2 الذي ما زالت تعتمد عليه أدوات كثيرة منها Archi كما سيأتي.

والفكرة الأساسية في ArchiMate أن كل عنصر له نوع، مثل الممثل Actor والخدمة Service والإجراء Process والتطبيق Application Component والعقدة Node، وأن كل علاقة لها نوع ومعنى، مثل «يخدم» Serves و«يحقق» Realizes و«يستضيف»، فعندما ترى سهماً تعرف معناه دون أن تسأل من رسمه. والصورة التالية عرض صغير بهذا الأسلوب لخدمة التتبع، والأشكال مبسطة من إعدادنا وليست رموز المواصفة:

وإذا أردت أن تجرب، فأشهر أداة مفتوحة المصدر هي Archi، وهي أداة مجانية متعددة المنصات Cross-platform، ورخصتها MIT كما في مستودعها على GitHub، وآخر إصدار عند كتابة المقال هو 5.10.0 بتاريخ 3 سبتمبر 2026، وتذكر صفحة التحميل أنه يدعم ArchiMate 3.2، أي أن دعم الإصدار 4 لم يصل إليها بعد. وفي مقال خريطة القدرات قارنا Archi بأدوات أخرى مفتوحة المصدر لإدارة محفظة التطبيقات.

من يعمل في فريق معمارية المؤسسة؟

لا يوجد هيكل واحد يناسب كل المؤسسات، ولكن دليل التأسيس الصادر عن هيئة الحكومة الرقمية (صفحة 13) يقترح هيكلاً واضحاً لمكتب البنية المؤسسية EA Office يصلح كنقطة بداية لأي مؤسسة كبيرة، وفيما يلي الأدوار مع ما يفعله كل دور في الواقع:

• رئيس المعماريين Chief Architect: يملك المبادئ وخارطة الطريق، ويمثل المعمارية أمام الإدارة العليا.
• معماري الأعمال Business Architect: يبني خريطة القدرات ويربطها بالخدمات والإجراءات والإدارات.
• معماري البيانات Data Architect: يعرف الكيانات الأساسية ومالك كل منها، وأين تحفظ وكيف تنتقل بين الأنظمة.
• معماري التطبيقات Application Architect: يملك سجل التطبيقات ومخطط التكامل، ويقيم كل نظام جديد مقابل ما هو موجود.
• معماري التقنية Technology Architect: يملك قائمة التقنيات المعتمدة والبنية التحتية المستهدفة.
• مسؤول الأداة وأخصائي النمذجة Tool Admin and Modeling Specialist: يبقي المستودع نظيفاً ومحدثاً، ويولد الرسوم والتقارير منه.

ويضع الدليل فوق المكتب مجلس مراجعة البنية Architecture Review Board واختصاراً ARB، ولجنة التحول الرقمي التي تحوكم أعماله، ويوصي أن يكون المكتب في جانب الأعمال، أي في التخطيط الاستراتيجي أو الحوكمة، حتى يخدم كل قطاعات الجهة وليس قسم التقنية فقط. ولاحظ أن الهيكل المقترح لا يذكر معماري الحلول Solution Architect الذي يصمم نظاماً بعينه داخل مشروع، ففي أغلب المؤسسات يعمل هذا الدور مع فرق المشاريع، ولكنه أكثر من يتعامل مع المكتب، لأن تصميمه يمر على المراجعة.

والمراجعة هي المكان الذي تتحول فيه المعمارية من وثائق إلى قرارات، والصورة التالية تبين مساراً بسيطاً لها قبل شراء أي نظام جديد:

وفي المسار أعلاه لاحظ التالي:

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

الفشل الأشهر: معمارية في البرج العاجي

أشهر طريقة تفشل بها معمارية المؤسسة لها اسم معروف بين المعماريين، وهو البرج العاجي Ivory Tower، أي فريق يجلس بعيداً عن الفرق التي تبني وتشغل الأنظمة، ويرسم الوضع المستهدف بدقة، ويصدر المعايير، ثم يكتشف بعد سنة أن لا أحد يتبعها. وقد ذكرنا في مقال التصميم والمعمارية رأي Martin Fowler أن المجموعات المركزية التي تقرر في كل نظام لا تستطيع أن تفهم مشكلات هذا العدد الكبير من الأنظمة فتصدر قرارات سيئة، وفيما يلي العلامات التي تعرف بها أن فريقك يتجه إلى هذا البرج:

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

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

كيف تبدأ مؤسسة صغيرة بمعمارية خفيفة؟

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

1. سجل التطبيقات: جدول واحد فيه كل نظام، ومالكه من الأعمال ومالكه التقني، وعدد مستخدميه، وأين يعمل، والبيانات المهمة فيه، والأنظمة التي يتكامل معها، وتاريخ انتهاء عقده أو دعمه. ويمكن أن يكون ملف Excel مشتركاً، أو قاعدة بيانات بواجهة جداول مثل NocoDB تثبتها على سيرفرك، وفي مقال خريطة القدرات وضعنا أعمدة جاهزة لهذا الجدول.
2. خريطة القدرات: صفحة واحدة بالقدرات الرئيسية للمؤسسة، تلونها حسب حالة الأنظمة التي تخدمها.
3. المبادئ: من خمسة إلى عشرة مبادئ مكتوبة، ولكل مبدأ سبب، مثل «لا نشتري نظاماً لقدرة يغطيها نظام موجود إلا بقرار مكتوب».
4. سجل القرارات: ملف ADR لكل قرار معماري مهم، داخل مستودع Git، بنفس الطريقة التي شرحناها في مقال توثيق المعمارية.
5. مراجعة شهرية: اجتماع قصير يمر على كل طلب شراء أو مشروع جديد، ويحدث السجل بعده.

وبهذا الشكل تكون قد بنيت المستودع والمبادئ والمراجعة، وهي نفس عناصر المعمارية الكبيرة ولكن بحجم يناسبك، وعندما يكبر عدد الأنظمة تنقل نفس البيانات إلى أداة مثل Archi أو أداة لإدارة المحفظة دون أن تبدأ من الصفر.

تدريب عملي

1. اكتب قائمة بكل الأنظمة التي تعرفها في مؤسستك، ولكل نظام مالك واحد على الأقل، ثم اسأل زميلين من إدارتين مختلفتين عن أنظمة لم تكتبها، وغالباً سوف تجد ملفات Excel تعمل كأنظمة وخدمات سحابية لم يسمع بها قسم التقنية.
2. اختر نظاماً واحداً قديماً، وارسم الاعتماديات حوله كما في الصورة الأولى: من يقرأ منه، ومن يكتب إليه، وما الخدمة التي تتوقف إذا توقف. ثم ثبت Archi وارسم نفس الشيء بعناصر ArchiMate وقارن بين الرسمين.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• معمارية المؤسسة ممارسة تحفظ العلاقات بين الخدمات والبيانات والتطبيقات والتقنية، وتدرس الوضع الحالي، وتحدد الوضع المستهدف، وتبني الطريق بينهما.
• جدول الأنظمة وحده يجيب عن «ماذا نملك»، والمعمارية تجيب عن «ماذا يتأثر» و«لماذا لدينا نظامان»، والسبب أنها تحفظ الروابط وتبقيها محدثة.
• المجالات الأربعة هي الأعمال والبيانات والتطبيقات والتقنية، والمخرجات قوائم ومصفوفات ورسوم من مستودع واحد.
• TOGAF إطار ومنهجية من The Open Group، والطبعة العاشرة صدرت في أبريل 2022، وقلبها دورة ADM التي تعدلها على مقاس مؤسستك ولا تطبقها كاملة كل مرة.
• Zachman هيكل لترتيب الوصف بستة أسئلة ومناظير متعددة وليس منهجية، وArchiMate لغة رسم موحدة أحدث إصداراتها 4 في أبريل 2026، وأداة Archi المفتوحة المصدر تدعم 3.2.
• الفشل الأشهر هو البرج العاجي، والعلاج أن تبدأ من الأسئلة والقرارات، وأن تجعل التحديث جزءاً من العمل اليومي، والمؤسسة الصغيرة تبدأ بخمس أدوات بسيطة.

وفي المقالين التاليين من نفس المرحلة نبني خريطة القدرات ومحفظة التطبيقات خطوة بخطوة، ثم ننظر في متطلبات الجهات الحكومية في المملكة:

دليلCapability Map: كيف تقرر مصير كل نظام في مؤسستككيف تبني خريطة لقدرات مؤسستك وتربط بها أنظمتك، لتكتشف التكرار والفجوات وتقرر ما تبقيه وما توقفه.دليلمعمارية المؤسسة EA في الجهات الحكومية السعوديةما الذي تطلبه هيئة الحكومة الرقمية من الجهات في البنية المؤسسية بالنص، وكيف يقاس، وأين يلتقي مع ضوابط الأمن السيبراني.دليلالتصميم والمعمارية: أربعة مستويات لنشاط واحدما الفرق بين تصميم البرمجيات ومعماريتها وتصميم الأنظمة ومعمارية المؤسسة، ومن يقرر في كل مستوى وكم يعيش قراره.دليلتوثيق المعمارية: مخططات C4 وسجلات القرارات المعمارية ADRكيف ترسم نظامك بمخططات C4 يفهمها المطور الجديد، وتحفظ سبب كل قرار مهم في سجل ADR داخل المستودع.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، ومراجعة صفحة TOGAF وإعلان الطبعة العاشرة وصفحات ArchiMate من The Open Group، وصفحة Zachman International، وصفحة تحميل Archi 5.10.0، ودليل تأسيس البنية المؤسسية من هيئة الحكومة الرقمية بنسختيه العربية والإنجليزية.