حين تطلب نظاماً لإدارة الطلبات أو المخزون أو الفوترة، نادراً ما تسأل عن المنصة التي سيُبنى عليها، فهي تبدو شأناً تقنياً يخص الفريق المنفّذ. لكن هذا الاختيار يبقى معك سنوات بعد الإطلاق، ويظهر أثره في كلفة الصيانة، وفي سهولة الترقية، وفي قدرتك على نقل النظام إلى فريق آخر إن احتجت إلى ذلك.
في ITS نبني الخدمات الخلفية وواجهات API لأنظمة الأعمال على .NET. في هذا المقال نشرح لماذا، بلغة تخص صاحب القرار لا المبرمج، ونوضح متى قد يكون خيار آخر مناسباً، ونختم بأسئلة تطرحها على أي مورّد مهما كانت منصته.
ما الذي يهمك أنت في اختيار المنصة
صاحب العمل لا يحتاج إلى مقارنة لغات البرمجة. يحتاج إلى إجابات عن أسئلة عملية تمس ميزانيته واستمرارية عمله:
- هل ستبقى المنصة مدعومة بتحديثات الأمان طوال عمر النظام؟
- هل يمكن التخطيط للترقيات مسبقاً، أم ستأتي مفاجأة؟
- هل تتوفر أدوات ناضجة لما تحتاجه أنظمة الأعمال: البيانات والصلاحيات والربط مع الأنظمة الأخرى؟
- هل يستطيع فريق آخر أن يفهم الكود ويصونه إن تغيّر المورّد؟
- هل لديك حرية في اختيار مكان الاستضافة؟
هذه هي المعايير التي نقيس بها اختيارنا، وهي نفسها المعايير التي ننصحك أن تقيس بها أي عرض يصلك.
دعم طويل الأمد وترقيات يمكن التخطيط لها
النظام الإداري لا يُستبدل كل عام، لذلك يهمنا أن تكون للمنصة سياسة دعم معلنة. وفق سياسة الدعم المنشورة على موقع .NET الرسمي، يصدر إصدار رئيسي جديد كل عام في شهر نوفمبر. الإصدارات ذات الأرقام الزوجية إصدارات دعم طويل الأمد، تحصل على دعم وتحديثات مجانية مدة ثلاث سنوات، والإصدارات ذات الأرقام الفردية إصدارات دعم قياسي مدتها سنتان.
الأثر العملي أنك تعرف مسبقاً متى ينتهي دعم الإصدار الذي يعمل عليه نظامك. فتستطيع أن تضع الترقية في خطة العام وميزانيته، بدل أن تكتشف فجأة أن نظامك يعمل على إصدار لم يعد يتلقى تحديثات الأمان.
لنفترض أن نظامك أُطلق على إصدار دعم طويل الأمد. يمكنك أن تتفق مع فريقك على نافذة ترقية محددة قبل انتهاء الدعم، تُختبر فيها الترقية على نسخة من النظام، ثم تُطبَّق في وقت هادئ من السنة. هكذا تصبح الترقية مهمة صيانة مخططاً لها، لا حالة طوارئ.
ونخطط لكل ترقية كمشروع صغير له نطاق واضح: مراجعة المكتبات التي يعتمد عليها النظام، وتشغيل الاختبارات، وتجربة النظام على بيئة منفصلة قبل نقله إلى بيئة التشغيل. وكلما كان الكود منظماً ومختبراً، كانت الترقية أقصر وأقل مخاطرة.
أدوات ناضجة لأنظمة الأعمال
أنظمة الأعمال تتشابه في احتياجاتها الأساسية: قاعدة بيانات تتغير مع الوقت، وواجهات API تربط النظام بتطبيق الجوال أو بنظام آخر، وصلاحيات تحدد من يرى ماذا. وحين توفر المنصة أدوات معروفة لهذه الاحتياجات، يصرف الفريق وقته على قواعد عملك، لا على بناء الأساسيات من الصفر.
- الوصول إلى البيانات: مكتبة Entity Framework Core مفتوحة المصدر من Microsoft، تنظّم التعامل مع قاعدة البيانات، وتدعم محركات قواعد بيانات متعددة، وتتيح تطوير بنية قاعدة البيانات خطوة بخطوة مع تطور النظام.
- واجهات API: إطار ASP.NET Core يُستخدم لبناء تطبيقات الويب وواجهات API التي تحتاجها التطبيقات والأنظمة المرتبطة.
- الأمان: يتضمن ASP.NET Core ميزات مدمجة للمصادقة والتفويض وحماية البيانات، فلا يُكتب ذلك كله يدوياً في كل مشروع.
لنفترض أن نظامك يحتاج إلى ربط مع تطبيق جوال للمندوبين، ثم مع متجر إلكتروني بعد عام. وجود إطار معروف لبناء واجهات API يعني أن الربط الجديد يتبع النمط نفسه، وأن الصلاحيات المطبقة على الشاشات تنطبق على الواجهات أيضاً.
الاستضافة: خيارات لا قيد واحد
منصة .NET مجانية ومفتوحة المصدر، وتعمل تطبيقاتها على Windows وLinux وmacOS، ويمكن تشغيلها في حاويات Docker. وبحسب توثيق ASP.NET Core، يمكن نشر التطبيقات في مراكز البيانات الخاصة بالمؤسسة أو في السحابة.
هذا يمنحك حرية القرار: خادم داخل شركتك إن كانت سياسة البيانات تتطلب ذلك، أو خدمة سحابية إن كانت أنسب لفروعك. ولا يفرض عليك اختيار المنصة مزوّد استضافة بعينه.
ويمكن أن تبدأ على خادم داخلي ثم تنتقل إلى السحابة حين يتغير حجم العمل، دون أن يفرض عليك ذلك تغيير المنصة التي بُني عليها النظام.
كود أسهل في الصيانة والتسليم
لغة C#، وهي لغة البرمجة الأساسية في .NET، لغة ذات أنواع صارمة. معنى ذلك ببساطة أن كل قيمة في الكود لها نوع محدد، مثل مبلغ أو تاريخ أو رقم فاتورة، وأن كثيراً من الأخطاء يظهر أثناء بناء النظام قبل أن يصل إلى المستخدم.
في نظام صغير قد لا يبدو هذا مهماً. لكن نظام ERP مخصّصاً يُبنى وحدة بعد وحدة يكبر مع الوقت، وكل تعديل في وحدة قد يمس وحدات أخرى. وحين تكون الأنواع واضحة يرى المبرمج أثر التعديل مبكراً، ويقل خطر أن يكسر إصلاحٌ في المبيعات شيئاً في المحاسبة.
لنفترض أن حقل الخصم تغيّر من مبلغ ثابت إلى مبلغ أو نسبة. في لغة ذات أنواع صارمة يدل بناء النظام على كل موضع يستخدم هذا الحقل، فلا يبقى موضع منسي يحسب الخصم بالطريقة القديمة.
وهناك أثر يهمك مباشرة: التسليم. المنصة المفتوحة المصدر والمعروفة على نطاق واسع تقلل اعتماد نظامك على فريق واحد أو مهارة نادرة. فإذا قررت يوماً أن تنقل صيانة النظام إلى فريقك الداخلي أو إلى مورّد آخر، يجد الفريق الجديد أدوات وتوثيقاً يعرفهما. ولهذا نهتم بأن يكون الكود مقروءاً وموثقاً، يفهمه من يتسلّمه بعدنا.
ليست الخيار الوحيد
لا نقول إن .NET هي الخيار الصحيح لكل مشروع. هناك منصات أخرى ناضجة تُبنى عليها أنظمة جيدة، والفريق الذي يتقن منصته ويكتب كوداً واضحاً ومختبراً أهم من اسم المنصة نفسها.
وقد يكون خيار آخر أنسب في حالات محددة: إن كان لديك فريق داخلي يعمل على منصة أخرى وسيتسلم الصيانة، أو إن كان النظام الجديد امتداداً لنظام قائم مبني بتقنية مختلفة. في هذه الحالات نناقش الأمر بصراحة، لأن انسجام النظام مع من سيصونه أهم من تفضيلاتنا.
وما يهمنا في النهاية ليس المنصة بحد ذاتها، بل ما تعنيه لك: نظام يتلقى تحديثات الأمان، وترقيات تعرف موعدها، وكود يستطيع غيرنا أن يفهمه ويصونه.
وفي مقال «Microservices: متى تحتاجها ومتى لا تحتاجها» شرحنا فكرة قريبة: القرار التقني السليم يبدأ من طبيعة العمل وحجم الفريق، لا من المصطلحات. واختيار المنصة يخضع للقاعدة نفسها.
المنصة المناسبة هي التي تستطيع أن تصونها وترقّيها وتسلّمها بعد سنوات، لا التي تبدو حديثة اليوم.
أسئلة تطرحها على أي مورّد
سواء عملت معنا أو مع غيرنا، اطرح هذه الأسئلة قبل التعاقد، واطلب إجابات مكتوبة:
- على أي منصة وأي إصدار سيُبنى النظام، ومتى ينتهي دعم هذا الإصدار؟
- ما خطة الترقية قبل انتهاء الدعم، ومن يتحمل كلفتها؟
- هل الكود ملك لي، وهل سأستلمه مع توثيق يكفي لفريق آخر؟
- هل يمكن استضافة النظام على خادم داخلي أو في السحابة، أم أنه مرتبط بمزوّد واحد؟
- كيف تُدار الصلاحيات وحماية البيانات، وهل تعتمد على أدوات المنصة أم على حلول مكتوبة يدوياً؟
- كيف تُختبر التعديلات قبل وصولها إلى المستخدمين؟
الإجابات الواضحة عن هذه الأسئلة تخبرك عن نضج المورّد أكثر مما يخبرك اسم المنصة. وإذا كنت تقيّم عرضاً لنظام جديد أو تفكر في تحديث نظام قائم، يمكنك أن تناقش حالتك مع فريق ITS لنراجع معاً الخيارات التقنية وأثرها على عملك.
الخدمة المرتبطةالخدمات الخلفية وMicroservices