تصميم بنية التطبيقات في الرياض

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

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

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

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

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

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