خدمات تطوير برمجيات المؤسسات: ماذا تشتري فعليًا

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

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

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

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

ما الذي يجعل المشروع مؤسسيًا

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

سطح التكامل

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

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

التزام الجاهزية

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

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

أصحاب مصلحة يملكون حق النقض

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

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

الأنظمة التي لم يعد أحد يفهمها

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

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

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

الشراء نصف العمل

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

ومنذ 24 فبراير 2025 يعمل القطاع العام البريطاني وفق Procurement Act 2023، وعلى المورّدين المتقدمين للعقود العامة أن يكونوا مسجّلين على المنصة الرقمية المركزية ضمن خدمة Find a Tender الموسّعة. أما الشراء في القطاع الخاص فليس له باب أمامي واحد مكافئ، وهو ما يجعله أبطأ على نحو متناقض، لأن كل مشترٍ اخترع بابه.

استبيان الأمن

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

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

ضم المورّدين والتأمين والفحوص المالية

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

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

لماذا تدوم دورة البيع أطول من أول دفعة تسليم

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

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

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

المتطلبات غير الوظيفية هي التسليم الحقيقي

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

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

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

نقطة التعافي وزمن التعافي بلغة بسيطة

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

وكلا الرقمين يُترجم مباشرة إلى معمارية. تعرض AWS أربع استراتيجيات عامة في إرشاداتها للتعافي من الكوارث: Backup and Restore، وPilot Light، وWarm Standby، وMulti-Site Active/Active. وهي تمتد من الرخيص البطيء إلى الغالي شبه الفوري، والاختيار يُحسم عنك بمجرد الاتفاق على الهدفين.

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

حساب الجاهزية وما يشتريه اتفاق مستوى الخدمة فعلًا

نسب الجاهزية تخفي معناها خلف فاصلة عشرية. فعلى مدى شهر من 30 يومًا، تسمح 99.9 بالمئة بنحو 43 دقيقة توقف، وتسمح 99.95 بالمئة بنحو 22 دقيقة، وتسمح 99.99 بالمئة بنحو 4 دقائق. وتلك ميزانية الشهر كله، بما فيها عمليات النشر وتجديد الشهادات وتبديل قاعدة البيانات الذي استغرق أطول من المتوقع.

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

زمن الاستجابة والإنتاجية والحمل الذي لم يقسه أحد

أهداف زمن الاستجابة تحتاج مئينًا ونطاقًا، لأن المتوسطات تخفي حالات الفشل. فهدف معلن قدره 200 مللي ثانية عند المئين 95 لنقطة نهاية الدفع تحت 400 طلب في الثانية قابل للاختبار. أما هدف سريع فليس كذلك، ولا المتوسط كذلك، لأن متوسطًا قدره 200 مللي ثانية يتوافق مع انتظار مستخدم من كل عشرين أربع ثوان.

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

قابلية التدقيق والاحتفاظ

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

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

الشهادات التي سيطلبها المشتري

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

Cyber Essentials وCyber Essentials Plus

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

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

والمخطط مهم تجاريًا كما هو مهم تقنيًا. PPN 014، النافذ منذ 24 فبراير 2025 عبر الوزارات المركزية ووكالاتها والهيئات العامة غير الوزارية وهيئات NHS، يشترط الحصول على الشهادة حين يتعامل المورّدون مع معلومات شخصية للمواطنين، أو معلومات شخصية لموظفي الحكومة، أو أنظمة تقنية معلومات تعالج بيانات على مستوى OFFICIAL.

ISO/IEC 27001

ISO/IEC 27001 هو المعيار الدولي لنظام إدارة أمن المعلومات، الصادر عن ISO وIEC. والإصدار الحالي هو ISO/IEC 27001:2022، مع Amendment 1 لعام 2024 الذي يضيف صياغة عن العمل المناخي إلى بنود السياق، تماشيًا مع تغيير طُبِّق على معايير أنظمة الإدارة لدى ISO كلها.

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

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

SOC 2

SOC 2 أمريكي ومختلف في طبيعته. تعرّفه AICPA بأنه تقرير عن الضوابط لدى مؤسسة خدمية فيما يتصل بالأمن أو الجاهزية أو سلامة المعالجة أو السرية أو الخصوصية، ويُنجَز وفق معايير خدمات الثقة الخاصة بها. وهو تقرير تصديق تصدره شركة محاسبة قانونية، لا شهادة، وليس فيه درجة نجاح ولا شعار يُعرض.

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

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

ما لا تثبته أي منها

لا تشهد أي من الثلاث بأن برمجياتك آمنة. فـCyber Essentials يغطي خط أساس من نظافة البنية التحتية. وISO 27001 يغطي ما إذا كانت المؤسسة تدير الأمن بوصفه عملية. وSOC 2 يغطي ما إذا كانت ضوابط معلنة قد عملت عبر فترة. وثلاثتها تخص المورّد لا المنتج.

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

التعرّض التنظيمي حسب القطاع

التنظيم هو المكان الذي تصبح فيه النصيحة المؤسسية العامة غير آمنة. وما يلي يسمّي التزامات يمكن التحقق منها ويتوقف قبل المشورة القانونية، التي ينبغي أن تأخذها من مستشار مؤهل.

UK GDPR الذي ينطبق على الجميع تقريبًا

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

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

الخدمات المالية والصحة، باختصار وحذر

في الخدمات المالية، يشترط نظام المرونة التشغيلية لدى FCA على الشركات المشمولة تحديد خدمات الأعمال المهمة، ووضع حدود تحمّل للأثر لها، والقدرة على البقاء ضمن تلك الحدود أثناء اضطراب شديد لكنه محتمل. وقد انتهت الفترة الانتقالية في 31 مارس 2025، فالالتزام سارٍ وهو يشكّل ما يجب أن يثبته المورّد لتلك الشركات.

وفي الصحة والرعاية، يستدعي نظام تقنية معلومات صحي معايير إدارة المخاطر السريرية لدى NHS England: DCB0129 للمصنّعين وDCB0160 للمؤسسات التي تنشره. وكلاهما قيد مراجعة وطنية، مع استشارة عامة تمتد من 29 يونيو 2026 إلى 11 سبتمبر 2026، فتأكد من الوضع الحالي قبل الاعتماد على أي ملخص، بما في ذلك هذا الملخص.

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

معمارية التكامل هي حيث يذهب المال

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

نقطة إلى نقطة مقابل وسيط

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

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

التزامن مقابل القيادة بالأحداث

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

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

التكرار الآمن وإعادة التشغيل والمطابقة

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

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

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

التعايش مع الأنظمة القديمة وشجرة التين الخانقة

الاستبدال الكامل لنظام يعمل هو أعلى الخيارات المتاحة خطرًا، ويُختار أكثر بكثير مما ينبغي. والبديل التدريجي وثّقته Microsoft باسم نمط Strangler Fig: ضع واجهة أمام النظام القديم، ووجّه الطلبات عبرها، وانقل الوظائف قطعة قطعة حتى لا تبقى للنظام القديم حركة مرور فيمكن إطفاؤه.

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

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

الاختبار على مقياس المؤسسات

الاختبار في برنامج مؤسسي مشكلة لوجستية بقدر ما هو مشكلة هندسية، وهو المكان الذي تموت فيه الخطط المتفائلة.

البيئات

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

بيانات الاختبار ومشكلة البيانات الشخصية

أنظمة المؤسسات تحتاج بيانات واقعية لتختبر عليها، والبيانات الواقعية هي بيانات الإنتاج، وهي تحتوي معلومات شخصية. ونسخها إلى بيئة اختبار معالجة بموجب UK GDPR، والتزامات Article 32 تتبعها إلى هناك، بما فيها التحكم في الوصول وأمن البيئة التي تحتضنها.

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

اختبار الأداء

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

وشغّله على أحجام بيانات الإنتاج. فالاستعلام الفوري على 10,000 صف وغير القابل للاستعمال على 40 مليون صف هو أشيع عيب أداء في برمجيات المؤسسات، وهو غير مرئي على مجموعة بيانات صغيرة.

اختبار قبول المستخدم مع أشخاص لديهم وظائف أخرى

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

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

نموذج التسليم والحوكمة

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

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

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

النماذج التجارية ومن يحمل المخاطرة

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

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

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

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

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

خدمات تطوير برمجيات المؤسسات: ما الذي يدفع التكلفة

محركات التكلفة بترتيب الأثر

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

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

نطاقات أسعار إرشادية في بريطانيا

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

وبعيدًا عن الجدول: خدمة واحدة بتكاملين أو ثلاثة، ومستخدمين داخليين، وهدف 99.5 بالمئة، تقع بين GBP 120,000 وGBP 250,000 في سنتها الأولى. ونظام إداري موجّه للعملاء بخمسة إلى ثمانية تكاملات عند 99.9 بالمئة يتراوح بين GBP 300,000 وGBP 700,000. ومنصة أساسية تحل محل نظام قديم، بعشرة إلى عشرين تكاملًا وهدف 99.95 بالمئة، تتراوح بين GBP 900,000 وGBP 2.5 مليون. وبرنامج منظَّم متعدد الكيانات عند 99.99 بالمئة يبدأ عند GBP 2.5 مليون ويرتفع.

تكلفة التشغيل التي ليست في الميزانية

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

الخروج والاستمرارية

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

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

والتوثيق ينبغي أن يمكّن طرفًا ثالثًا كفؤًا من تشغيل النظام: المعمارية، وعقود التكامل، وأدلة التشغيل لأنماط الفشل التي وقعت فعلًا، وجرد بيانات الاعتماد. ومقالنا عن التوثيق التقني الذي يُقرأ فعلًا يتناول ما ينجو من عملية التسليم.

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

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

الحكم على مصداقية المورّد المؤسسية في اجتماع واحد

خمسة أسئلة تثبت معظم ذلك في ساعة، والتردد يخبرك بقدر ما تخبرك الإجابة.

اسأل عن أهداف الجاهزية والتعافي التي سلّموا مقابلها، وكيف قيست الجاهزية. فالمورّد الذي حمل التزامًا قدره 99.95 بالمئة يسمّي نقطة القياس وترتيب المناوبة دون أن يُسأل. أما من لم يفعل فيتحدث عن التكرار بعبارات عامة.

واطلب أن ترى بيان النطاق على شهادة ISO 27001 لديهم، أو قسم الاستثناءات في SOC 2 Type 2 لديهم. وكلاهما طلب عادي لمورّد يحملهما ومحرج لمن يملك شعارًا فقط. ثم اسأل كيف تعاملوا مع فارق مطابقة في الإنتاج، وهو ما لا يستطيع أحد الإجابة عنه من النظرية.

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

ما الذي يعنيه هذا للمشتري

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

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

الأسئلة الشائعة

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

كم يكلف برنامج تطوير برمجيات مؤسسات في بريطانيا؟ بوصفها تقديرات داخلية من ارتباطات بريطانية، تتراوح خدمة واحدة بتكاملين أو ثلاثة وهدف جاهزية قدره 99.5 بالمئة بين GBP 120,000 وGBP 250,000 في سنتها الأولى. ونظام إداري موجّه للعملاء عند 99.9 بالمئة يتراوح بين GBP 300,000 وGBP 700,000. ومنصة أساسية تحل محل نظام قديم تتراوح بين GBP 900,000 وGBP 2.5 مليون. وأضف بين خمسة عشر وخمسة وعشرين بالمئة من تكلفة البناء سنويًا للتشغيل والدعم.

هل يحتاج مورّد المؤسسات إلى ISO 27001 أو Cyber Essentials أو SOC 2؟ هي تثبت أشياء مختلفة. فـCyber Essentials خط أساس مدعوم من الحكومة البريطانية من خمسة ضوابط تقنية، وله مستوى Plus متحقق منه بتدقيق تقني مستقل ويشترطه PPN 014 لكثير من عقود القطاع العام. وISO/IEC 27001:2022 يعتمد نظام إدارة أمن المعلومات، فبيان النطاق على الشهادة أهم من الشهادة نفسها. وSOC 2 تقرير تصديق أمريكي تصدره شركة محاسبة قانونية، ولا يختبر ما إذا كانت الضوابط قد عملت عبر فترة إلا Type 2.

ما هما هدف نقطة التعافي وهدف زمن التعافي؟ هدف نقطة التعافي هو كم من البيانات تقبل خسارته بعد كارثة، فـRPO قدره ساعة واحدة يعني أن حتى ساعة من المعاملات قد تختفي. أما هدف زمن التعافي فهو كم من الوقت تقبل أن تكون غير متاح، فـRTO قدره أربع ساعات يعني أن الخدمة يجب أن تعود إلى تقديم حركة المرور خلال أربع ساعات. وكلاهما يدفع المعمارية والتكلفة أكثر من أي ميزة، لأنهما يختاران بين Backup and Restore وPilot Light وWarm Standby وMulti-Site Active/Active.

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