الهندسة ككود تفتح مرحلة جديدة في حوكمة المؤسسات التقنية

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

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

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

من مراجعات نقطية إلى ضمان معماري مستمر

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

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

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

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

الفرق بين ما يُقال وما يُنفذ

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

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

الأمر نفسه ينطبق على الحالات الأقل حدة. قد يمتلك webhook مصادقة صحيحة، لكنه يفتقر إلى نموذج تهديدات أو سجل قرار معماري. في هذه الحالة، لا يكون الحكم بالضرورة «غير متوافق»، بل قد يكون «يحتاج أدلة إضافية». هذا التفريق مهم لأنه يجعل الحوكمة أكثر دقة، وأقل تعسفاً، وأكثر فائدة للفرق الهندسية.

الذكاء الاصطناعي كطبقة تفسير لا كجهة قرار

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

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

على سبيل المثال، إذا رصد محرك الضوابط أن وثيقة التصميم تتحدث عن OAuth/OIDC بينما تُظهر المواصفة التنفيذية اعتماد API key، فيمكن للطبقة الآلية أن تصنف الحالة على أنها تعارض بين الادعاء والدليل، ثم تولد شرحاً واضحاً: إما تعديل التنفيذ ليتوافق مع النمط المعتمد، أو تقديم استثناء محدد بزمن وانضباط تعويضي، مع الإشارة إلى أن الأدلة الأخرى ما تزال غير مكتملة.

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

حوكمة مدمجة داخل دورة التطوير

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

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

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

مخاطر الأتمتة الشكلية

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

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

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

ما الذي يتغير بالنسبة للمؤسسات الكبرى

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

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

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

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