المسار 7 · التوجهات والتصميم المستقبلي
الوحدة 29 من 37
تصميم الوضع المستقبلي — التطبيقات والبيانات
هنا تُحلّ أغلب ما استلزمه تصميم الأعمال. والقاعدة الحاكمة: تُصمَّم البيانات قبل التطبيقات، لا العكس.
جهة أنجزت تصميم الأعمال وتجربة المستفيد بعمود «يستلزم» ممتلئ. والمطلوب تحويل كل بند فيه إلى تصميم قابل للتنفيذ.
«يعني نشتري نظام جديد؟»
البيانات قبل التطبيقات
هذه القاعدة الأهم في الوحدة، وسببها من التشخيص نفسه:
ثلاث وحدات بناء تحسم شكل كل ما فوقها
تصميم البيانات — ثلاثة قرارات
| القرار | السؤال | أثره |
| مصدر الحقيقة | من يُنشئ ويُحدّث هذا الكيان حصراً؟ | يُنهي التضارب |
| آلية التوزيع | كيف تصل النسخة للأنظمة الأخرى؟ | يحدّد شكل التكامل |
| الهيكلة | ما الذي يجب أن يصير بيانات مهيكلة ولم يكن؟ | يفتح الأتمتة |
تصميم التطبيقات — القرارات الأربعة
لكل وظيفة مكرّرة رصدتَها في U22، القرار واحد من أربعة:
- دمج — وظيفة واحدة في تطبيق واحد والباقي يستهلكه
- إلغاء — الوظيفة نفسها لم تعد مطلوبة
- إبقاء مع تكامل — التكرار مبرَّر والتزامن يحلّ التضارب
- استبدال — الثلاثة تُلغى ويحلّ محلّها حلّ واحد
التطبيق يُؤتمِت الإجراء ويُنشئ كيان بيانات — والتصميم يُحدّد أي تطبيق لأي كيان
سجل التصميم
| المكوّن | وحدة البناء | القرار | مصدر الحقيقة أو التطبيق المالك | ما يُلبّيه من «يستلزم» | ما يستلزمه بدوره |
| المستفيد | كيان بيانات | إنشاء كيان مرجعي | سجل المستفيد المرجعي الجديد | حقول تُملأ آلياً — U28 | خدمة هوية وتشفير نقل — U30 |
| الاشتراط | كيان بيانات | إنشاء | محرّك القواعد | استعلام الاشتراطات حسب النشاط — U28 | واجهة إدارة محتوى — لا تقنية إضافية |
| تسجيل طلب مستفيد | وظيفة التطبيق | دمج في نظام التراخيص | نظام التراخيص | إجراء موحَّد بنقطة دخول واحدة — U28 | إلغاء الوظيفة من نظامين وتحويل مستخدميهما |
| إشعار المستفيد | وظيفة التطبيق | استبدال بخدمة إشعارات مشتركة | خدمة الإشعارات | إشعار آلي قبل الانتهاء — U28 | جدولة ومراقبة — U30 |
ما لا يُصمَّم هنا
تحقّق من الفهم
تمرين5 أسئلة · تحتاج 4 صحيحة للاجتياز