لم يعد التحدي الأكبر في تطوير البرمجيات يكمن في كتابة الكود، بل في تحديد ما يجب بناؤه، وكيفية ربط أجزائه، وكيفية صيانته مع تغيره. على مدى عقدين من الزمن، كان النقص في القدرة الإنتاجية؛ أما اليوم، فقد أصبح إنتاج الكود وفيراً ورخيصاً، وانتقل النقص كلياً إلى قرارات التصميم التي لا تستطيع أي أداة لتوليد الكود اتخاذها نيابةً عنك.
لهذا الأمر تبعات تجارية ملموسة على أي شركة تشتري خدمات تطوير البرمجيات في عام 2026: فالأجر بالساعة لكتابة البرمجيات آخذ في الانخفاض، بينما ترتفع تكلفة القرارات المعمارية الخاطئة. إن الشراء كما لو كنا لا نزال في عام 2019 - أي مقارنة مقدمي الخدمات بناءً على السعر والسرعة - هو في الواقع تحسين للمتغير الخاطئ.
يُشير الحدس إلى أنه إذا كانت كتابة الكود أسرع، فمن المفترض أن تنتهي المشاريع في وقت أقرب. لكن البيانات تُظهر عكس ذلك.
أظهر تقرير DORA لعام 2024، الذي أعدته جوجل كلاود من حوالي 39,000 متخصص في هذا المجال، أن زيادة تبني الذكاء الاصطناعي بنسبة 25% ارتبطت بانخفاض في إنتاجية التسليم بنسبة 1.5TP3T وانخفاض في الاستقرار بنسبة 7.2%. لم يكن السبب في ذلك رداءة الكود المُولّد بطبيعته، بل زيادة أحجام دفعات التغيير: حيث يتم نشر كميات أكبر من الكود دفعة واحدة، وتصبح المراجعات أقل دقة، ويزداد عدد الأكواد التي تتعطل. وفي الدراسة نفسها، أفاد 39.2% من المطورين بانعدام ثقتهم أو ضعفها في الكود المُولّد بواسطة الذكاء الاصطناعي.
قامت شركة GitClear، من خلال تحليل 211 مليون سطر من التعليمات البرمجية بين عامي 2020 و2024، بتوثيق الجانب الآخر من نفس الظاهرة: انخفضت التعليمات البرمجية المعاد هيكلتها أو "المنقولة" من حوالي 25% في عام 2021 إلى أقل من 10% في عام 2024، بينما ارتفع النسخ واللصق من 8.3% إلى 12.3% وزادت الكتل المكررة ثمانية أضعاف.
ترجمة: يُكتب المزيد، ويُعاد تنظيم القليل. إنه يتراكم.
أضافت دراسة METR التي نُشرت في يوليو 2025 بُعدًا دقيقًا يستدعي معالجةً موضوعية. ففي تجربة مضبوطة شملت 16 مطورًا متمرسًا في البرمجيات مفتوحة المصدر و246 مهمة واقعية، استغرق المشاركون وقتًا أطول باستخدام الذكاء الاصطناعي، على الرغم من توقعهم إنجاز المهمة بشكل أسرع، وبعد الاختبار، ظلوا يعتقدون أنهم أنجزوها بشكل أسرع. راجعت METR تصميم الدراسة في فبراير 2026 للتحقق من احتمالية وجود تحيز في الاختيار، وأظهرت مجموعة أكبر فرقًا أقل بكثير. لا تزال النتيجة الدقيقة محل نقاش. أما النتيجة الثانوية، فهي أمر لا جدال فيه: انفصال السرعة المُدركة عن السرعة الفعلية.
عندما ينفصل مفهوم السرعة عن الواقع، فإن الانضباط الذي يصحح المسار ليس التنفيذ، بل التصميم.
لا تتساوى جميع القرارات التقنية في أهميتها. ويكمن الفرق العملي بين ما يمكن تغييره في أسبوع وما سيُشكّل السنوات الخمس القادمة.
نوع القرار | مثال | تكلفة تغييره لاحقًا |
أداة | إطار عمل الواجهة الأمامية، مكتبة الرسومات | منخفض: أسابيع |
موفر نماذج | الانتقال من برنامج ماجستير في القانون إلى آخر | تحت ذلك طبقة من التجريد |
نموذج البيانات | كيفية تمثيل العميل أو الطلب | مرتفع: يؤثر على كل ما هو مبني فوقه |
الحدود بين الأنظمة | أي وحدة تحتوي على أي معلومات؟ | مرتفع جدًا: إعادة كتابة جزئية |
نموذج تصريح | من يستطيع رؤية ماذا وفعل ماذا، وبأي قدر من إمكانية التتبع؟ | مستوى عالٍ جدًا: يدل على الأمن والامتثال |
الصفان الأولان هما الأكثر إثارة للجدل في الاجتماعات التقنية. أما الصفوف الثلاثة الأخيرة فهي التي تحدد ما إذا كان بإمكان الشركة تطوير نظامها خلال ثلاث سنوات أم أنها ستضطر إلى إعادة كتابته بالكامل.
من الأمثلة الملموسة التي تتكرر في مجالات الخدمات اللوجستية والتأمين والرعاية الصحية، قرار تحديد ما إذا كان "سجل المريض" كيانًا مستقلًا له دورة حياة خاصة به، أم مجرد عرض مبني على جداول أخرى. يُتخذ هذا القرار في الأسبوع الثاني من المشروع، غالبًا دون نقاش، ويحدد لسنوات إمكانية تدقيق التغييرات، وإمكانية تطبيق سياسة الاحتفاظ بالبيانات، وإمكانية إتاحة السجل لطرف ثالث عبر واجهة برمجة التطبيقات (API). لن يتخذ أي مولد أكواد هذا القرار لأنه ليس مسألة برمجية، بل مسألة تجارية.
هذا هو العمل الذي نقوم به في تطوير البرمجيات المخصصة [رابط داخلي] قبل كتابة السطر الأول: حدد ما هو موجود، وما يملك ماذا، وما هو العقد الذي يربط كل وحدة بالوحدات الأخرى.
تُحدد بنية نظام المؤسسة بأربعة حدود. عندما تكون جميعها محددة بدقة، يتطور النظام. أما عندما يصبح أي منها غير واضح، يتدهور النظام، حتى لو كان الكود البرمجي مثالياً.
حدود البيانات. ينبغي أن يكون لكل معلومة مالك واحد: نظام واحد يُصدر الأوامر وأنظمة أخرى تستعلم عنها. أما البديل - ثلاثة أنظمة تُسجل نفس المعلومات - فيُنتج تناقضات لا تستطيع أي طبقة أعلى حلها، وهو السبب الجذري لمعظم مشاريع ذكاء الأعمال التي تنتهي بجدال حول الرقم الصحيح.
حدود العقود. تتواصل الوحدات البرمجية عبر واجهات واضحة وموثقة ومُؤرشفة. العقد هو وعد: "هذا ما أقدمه، وهذا ما أضمنه، وهذا ما أغيره بإشعار مسبق". بدون عقود، كل عملية دمج هي ربط جديد، وكل تغيير هو تفاوض.
حدود التصاريح. ينبغي أن يكون تحديد من يستطيع رؤية ماذا ومن يستطيع فعل ماذا طبقةً أساسيةً في النظام، لا شرطاً يتكرر في أربعين موضعاً. وقد أصبح هذا الحدّ بالغ الأهمية مع ظهور أنظمة الذكاء الاصطناعي التي تُنفّذ الإجراءات: فإذا كان نموذج الصلاحيات هشاً مع المستخدمين البشريين، فإنه ينهار مع الهويات غير البشرية.
حدود إمكانية الملاحظة. إن النظام الذي يستحيل فيه معرفة ما حدث ومتى ولماذا، لا يمكن صيانته ولا تدقيقه. ومنذ إدخال العناصر الاحتمالية في سلسلة التوريد، لم تعد إمكانية التتبع ممارسة تشغيلية جيدة، بل أصبحت مطلباً أساسياً للحوكمة.
تُشكّل هذه الحدود الأربعة بنيةً معماريةً قابلةً للتركيب، وهو نهجٌ نُفصّله في تحليلنا لـ بنية قابلة للتكوين، وواجهات برمجة التطبيقات، والذكاء الاصطناعي
لا يلزم إجراء تدقيق رسمي للكشف عن الأعراض المبكرة. هذه هي المؤشرات التي تظهر أولاً:
عند ظهور ثلاثة أعراض أو أكثر من هذه الأعراض، فإن زيادة القدرة على التطوير لا تُسرّع أي شيء، بل تزيد فقط من عدد الأشخاص الذين ينتظرون حسم قرار التصميم.
غالباً ما تُطرح حجج أهمية الهندسة المعمارية بمصطلحات هندسية، وهذا ما يُفقدها زخمها في لجان الإدارة. وبعبارة أخرى، تُحقق الهندسة المعمارية الجيدة أربعة أمور قابلة للقياس:
قلل من تكلفة تغيير رأيك. إن الشركة التي تستطيع تعديل عروضها أو عملية الفوترة أو نموذج التسعير الخاص بها في غضون أسابيع تتنافس بشكل مختلف عن الشركة التي تحتاج إلى ستة أشهر.
حوّل التكنولوجيا إلى أصل، لا إلى نفقة متكررة. يُعدّ النظام الذي يتميز بملكية واضحة للبرمجيات، وتوثيق دقيق، وعقود صريحة، ذا قيمة كبيرة في عملية التدقيق النافي للجهالة. أما النظام الذي يعتمد على مورد واحد، فلا يُعدّ كذلك.
فهو يسمح باستبدال الأجزاء دون إعادة بناء التجميع. وهذا الأمر ذو أهمية خاصة فيما يتعلق بنماذج الذكاء الاصطناعي، التي تتغير أسعارها وقدراتها وسياسات استخدامها عدة مرات في السنة.
فهو يجعل القرارات قابلة للتدقيق. مع ازدياد صرامة الإطار التنظيمي الأوروبي، من المهم أن نكون قادرين على إثبات ما فعله النظام وبأي بيانات تحول الأمر من كونه مرغوبًا فيه إلى كونه مطلوبًا.
في مجموعة ذا كلاود، يتمّ إضفاء الطابع الرسمي على هذا المفهوم من خلال إطار عملنا لهندسة الأنظمة TCG-SAF™، والذي يتألف من خمس مراحل: الرؤية، والمجالات، والوحدات، والهندسة، والتنفيذ، بالإضافة إلى وثيقة معمارية واحدة تُشرف على عملية البناء بأكملها. هذا ليس مجرد تفضيل جمالي، بل هو السبب الذي يُتيح لنا تقديم ضمانات مكتوبة بشأن المواعيد النهائية: إذ لا يُمكن الالتزام بتاريخ مُحدد إلا بعد تحديد نطاق العمل قبل البدء.
خلال ذروة الضجة الإعلامية، كان يُفترض أنه إذا أتيحت للجميع إمكانية الوصول إلى النماذج نفسها، فستتساوى القدرات. لكن ما حدث هو عكس ذلك تمامًا. فقد حصلت شركتان تتمتعان بإمكانية الوصول نفسها إلى الأدوات ذاتها على نتائج مختلفة جذريًا، ويكمن الاختلاف في بياناتهما الخاصة، ومعرفتهما المتخصصة، وجودة التكامل بين أنظمتهما.
تصبح النماذج سلعة. وتصبح أدوات توليد التعليمات البرمجية سلعة. أما ما لا يصبح سلعة فهو القدرة على تحويل الإمكانيات العامة إلى نظام محدد وموثوق وخاص.
تلك القدرة لها اسم قديم وغير جذاب إلى حد ما: الهندسة.
تُعرَّف هندسة البرمجيات بأنها مجموعة القرارات المتعلقة بالمكونات الموجودة، والمعلومات التي يحتويها كل مكون، وكيفية تواصلها فيما بينها. وهي أكثر أهمية من كتابة الكود، لأن الكود يمكن إعادة كتابته في غضون أسابيع، بينما قد يتطلب تغيير نموذج البيانات أو الحدود بين الأنظمة إعادة كتابة جزئية للمنتج.
تشمل الأعراض النموذجية ما يلي: تستغرق التغييرات الصغيرة نفس الوقت الذي تستغرقه التغييرات الكبيرة، وتكون التقديرات غير موثوقة، وتكلف كل عملية تكامل جديدة نفس تكلفة الأولى، وهناك مناطق في النظام يتجنب الفريق لمسها، وتعتمد معرفة تدفق المعلومات على شخص واحد.
لا، بل يزيد الأمر سوءًا. عندما يصبح توليد الشفرة رخيصًا، يتحول التحدي إلى تحديد ما يجب بناؤه وكيفية ربطه. وقد وجد تقرير DORA لعام 2024 أن زيادة تبني الذكاء الاصطناعي يرتبط بانخفاض استقرار التسليم، وذلك تحديدًا لأن حجم التغيير يزداد دون زيادة مقابلة في دقة التصميم.
أكثر ثلاثة جوانب تكلفةً عند الرجوع إليها هي نموذج البيانات (كيفية تمثيل الكيانات التجارية)، وحدود الملكية بين الأنظمة (أي وحدة تتحكم في أي معلومات)، ونموذج الأذونات والتتبع. أما تغيير الأطر أو موفري النماذج فهو أقل تكلفةً نسبيًا.
يعتمد الأمر على درجة الترابط، ولكن النمط المعتاد هو أن التكلفة تتزايد بشكل غير خطي مع مرور الوقت: فكل شهر من البناء على حدود غير محددة بدقة يضيف شيفرة برمجية تعتمد على هذا القرار. ولهذا السبب، عادةً ما تكلف المراجعة التقنية المبكرة جزءًا بسيطًا من تكلفة إعادة الكتابة التي تمنعها.
نعم. النهج المعتاد هو عزل النظام الحالي بعقود صريحة واستبدال المجالات واحداً تلو الآخر، بدلاً من إعادة كتابة كل شيء دفعة واحدة. يتطلب هذا تقييماً أولياً يحدد أولويات تحديث المجالات بناءً على المخاطر والقيمة التجارية.
هل تشك في أن تصميمك المعماري هو العائق؟ يقدم تدقيقنا التقني للبرمجيات تشخيصًا مكتوبًا للبنية، والبرمجيات، والديون، والأمان خلال 10 أيام عمل بسعر ثابت. لا يتضمن العرض أي مقترح تجاري: التشخيص أولًا، ثم القرار. طلب التدقيق → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
