سياسات معمارية الأنظمة والخدمات

سياسات معمارية الأنظمة والخدمات


مقدمة

انطلاقا من توجه وكالة الوزارة لتقنية المعلومات لتحقيق تحول رقمي محوكم وفعال وتبني منهجية التطوير المرنة عالية الجودة، فقد اعتمدت الوكالة المساعدة للتحول الرقمي سياسات تضبط معمارية جميع المشاريع والمهام الرقمية داخل وزارة العدل، وتضمن تحقيقها للتوجهات الاستراتيجية للوزارة.

الأهداف

  • توافق معمارية الأنظمة مع توجهات الوزارة في التحول الرقمي
  • تحقيق المتطلبات غير الوظيفية للأنظمة
  • الاستفادة من أنماط المعمارية الحديثة بما يخدم أعمال الوزارة

نطاق الوثيقة

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

تعريفات أساسية

معمارية التطبيقات (Application Architecture)

المعمارية هي بنية النظام التي تحقق أهدافه الوظيفية (functional requirements) وغير الوظيفية (non-functional requirements) في إطار القيود (constraints) الموضوعة على الفريق المنفذ، أو هي القرارات الفنية عالية الكلفة التي يتطلب تغييرها وقتا وجهدا كبيرا.

المتطلبات الوظيفية (functional requirements)

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

المتطلبات غير الوظيفية (non-functional requirements)

هي خصائص النظام الفنية التي لا تعد من ضمن خصائصه أو وظائفه الإجرائية، لكنها تؤثر بصورة مباشرة على إمكانية استخدام النظام وجودته، ولذلك تسمى أيضا خصائص جودة النظام (quality attributes). ومن أمثلة المتطلبات غير الوظيفية: أمن النظام (application security)، وسرعة الأداء (performance)، وسهولة استخدامه (usability)، وإتاحيته (availability)، إلخ.

القيود المعمارية (Architectural constraints)

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

السياسات العامة للمعمارية

  • اعتماد منهجيات SOA وما يندرج تحتها من مبادئ وأساليب وممارسات، خاصة REST Constraints.
  • اعتماد أفضل الممارسات (best practices) لتطوير هيكلية البرمجيات المشابهة (Enterprise Applications)، مثل Onion Architecture/Clean Architecture/Screaming Architecture.
  • اعتماد أفضل الممارسات (best practices) لتطوير الأجزاء المشتركة (crosscutting concerns) مثل: إدارة المستخدمين وصلاحياتهم، وإدارة الإعدادات، والتحقق من البيانات المدخلة،.. إلخ.
  • اعتماد أفضل الممارسات والأدوات لمتابعة الأخطاء وأنشطة المستخدمين ومدى تفاعلهم مع وظائف ومزايا النظام مثل Application Insights من ميكروسوفت أزور (Microsoft Azure) و Dynatrace.
  • الاستفادة من الأنماط المعمارية الحديثة (modern architectures) ما أمكن، مثل microservices، CQRS، DDD إلخ.
  • الأخذ في الاعتبار المتطلبات غير الوظيفية (non-functional requirements) مثل:
    • متطلبات التصميم الفني (Design requirement)
      • اتساق تصميم البرنامج الفني في جميع أجزائه (conceptual integrity)
      • سهولة التعديل  (changeability/maintainability)
      • إعادة الاستخدام للأجزاء البرمجية (reusability)
    • متطلبات التشغيل  (Runtime requirements)
      • الإتاحية والاعتمادية (availability and reliability)
      • التوافقية أو الربط مع الجهات/الخدمات الأخرى (Interoperability)
      • سهولة الإدارة والمراقبة/المتابعة (manageability)
      • سرعة الأداء – أقصى حد لتحميل الواجهات في المتصفح – ثانية واحدة. (Performance)
      • القدرة على تحمل زيادة ضغط المستخدمين (Scalability)
      • سهولة الإدارة والمراقبة/المتابعة (manageability)
      • أمن المعلومات (Security) والقدرة على الصمود أمام محاولات الاختراق الرقمية.
    • متطلبات المستخدمين  (User requirements)
      • اعتماد أفضل الممارسات مثل (Impact Mapping) و (INVEST) أو ما يشابههما لتجزئة المتطلبات وإعداد ال Product Backlog  وربطها بالأهداف
      • سهولة الاستخدام (مع مراعاة تقليل الواجهات والنقرات) Usability/User Experience
    • متطلبات أخرى
      • سهولة اكتشاف المشكلات وحلها (Supportability)
      • سهولة إجراء الاختبارات الآلية (Testability)
  • استخدام أحدث الإصدارات من أطر الأعمال (Frameworks) والمكتبات البرمجية الجاهزة (Libraries) المستخدمة في الأنظمة المشابهة (Enterprise Applications).
  • تتيح معمارية النظام العمل على البنية السحابية (Cloud-Native applications)
  • تجنب إعادة بناء وظائف أو خدمات متاحة في الوزارة
  • الالتزام بالتقنيات المعتمدة في وزارة العدل
  • الالتزام بالمعايير المعتمدة في الوزارة
  • منصة ناجز هي النظام الوحيد لخدمات المستفيدين في الوزارة، ويجب التقيد بدعم التكامل معها
  • توثيق المعمارية وتحديثها أولا بأول
  • تطوير اختبارات ضمان الالتزام بالمعمارية الموضوعة للنظام وعدم مخالفتها ولو بالخطأ

سياسات معمارية واجهات الأنظمة (Front-end)

  • الالتزام بالهوية الرقمية المعتمدة في أنظمة الوزارة لتحقيق أفضل مرونة في استجابة الواجهات وعمل النظام على مختلف المتصفحات والأجهزة (Responsive Web Design) وهي على سبيل المثال لا الحصر: الأجهزة المكتبية، والأجهزة اللوحية، واللاب توب، والهواتف المحمولة، وأجهزة الخدمة الذاتية.
  • واجهات المستخدم يجب أن تكون تفاعلية بما يحسن تجربة الاستخدام
  • ضمان جودة التجربة الرقمية User Experience  والاهتمام باختبارات خبرة المستخدمة والسهولة Usability Testing
  • الإهتمام بمعايير ال Search Engine Optimization  في حالة المواقع أو البوابات الخدمية على الانترنت

سياسات معمارية خدمات الويب (web services) وواجهات الويب البرمجية (Web APIs)

  • تطوير خدمات الويب للتعامل مع الطلبات المتزامنة والغير متزامنة (synchronous and asynchronous) والطلبات اللحظية (Real-time) لمختلف الأنظمة.
  • رسائل خدمات الويب (input and output) تُعرَّف بحيث لا تسرّب التفاصيل الداخلية للأنظمة وقواعد البيانات التي وراءها (No internal data structure leakages)
  • اتباع أفضل الممارسات لتطوير خدمات الويب لتتحمل الطلبات الضخمة (bulk requests) ومعالجتها بشكل سلس.
  • جميع خدمات الويب تكون RESTful APIs وتخضع للمعايير المعتمدة في وزارة العدل.
  • جميع خدمات الويب المستخدمة داخل النظام نفسه أو للتكامل مع الأنظمة والجهات الخارجية يتم نشرها على المنصة التكامل المعتمدة في الوزارة (Apigee).
  • الوسيلة الوحيدة المسموحة للتكامل بين الأنظمة هي واجهات الويب البرمجية (Web APIs) ولا يسمح بأي نوع آخر مثل التكامل عن طريق قواعد البيانات أو الملفات أو غيرها من الطرق.
  • جميع قواعد الأعمال (business rules) تكون موجودة في الواجهات الخلفية للنظام (back-end) بغض النظر هل هي موجودة في الواجهات الأمامية (front-end) لتحسين تجربة المستفيدين أم لا
  • جميع واجهات الويب البرمجية تصمم على إمكانية استخدامها من داخل النظام أو من خارجه على السواء