نموذج TIME (التسامح، الاستثمار، الترحيل، الإزالة) لمحفظة التطبيقات

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

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

النموذج: محوران، أربعة ترتيبات

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

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

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

نماذج التشغيل الرباعية

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

الاستثمار: تحقيق أقصى قيمة

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

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

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

الترحيل: استبدال المنصة، مع الحفاظ على الوظيفة

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

يجيب خيار "الترحيل" على سؤال محدد: هل تستحق الوظيفة الحفاظ عليها؟ إذا كانت الإجابة نعم، فقم بالترحيل. أما إلى ماذا يتم الترحيل وكيف، فهو قرار منفصل لا يحدده تصنيف الوقت، بل يحدد فقط أن المنصة الحالية ليست هي الحل.

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

التسامح: التقاعس المتعمد مع تاريخ انتهاء الصلاحية

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

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

تُراكم المؤسسات التي تتعامل مع وضع "التسامح" كوضع دائم، الديون التقنية التي صُمم نموذج TIME لمنعها. فبرنامج COBOL الذي تم التسامح معه في عام 2019، والذي لا يزال في خانة "التسامح" في عام 2026، يكون قد تلقى سبع سنوات إضافية من الصيانة المؤجلة التي سيحتاج إليها في نهاية المطاف، إما كحالة طارئة عند حدوث عطل ما، أو كعملية نقل قسرية عندما يتعذر دعم المنصة.

الاستبعاد: القرار الذي يتخذه الجميع ولا ينفذه أحد

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

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

ثلاثة عوائق محددة تحول دون تنفيذ عملية الإلغاء:

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

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

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

مشكلة الأدلة: لماذا يفشل نموذج TIME بدون بيانات هيكلية

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

تُسهم الأدلة الهيكلية في حل هذه المفاوضات من خلال استبدال الرأي بالقياس.

لتقييم الملاءمة الفنية، فإن الأدلة المهمة هي:

مؤشر الملاءمة الفنية	مصدر	ينقل التصنيف نحو
التعقيد الحلقي لكل برنامج (متوسط)	تحليل الكود الثابت	منخفض = ملاءمة أفضل، مرتفع = ملاءمة أقل
نسبة الرموز الميتة	تحليل إمكانية الوصول	ارتفاع نسبة التعليمات البرمجية غير المستخدمة = انخفاض جودة الملاءمة
عدد التبعيات الواردة (Fan-in)	تعيين التبعية	زيادة عدد المراوح الداخلة بشكل كبير، تحمل أكثر من، إزالة
نطاق مشاركة دفتر النسخ	تحليل تبعية النسخ	مشاركة عالية = اقتران أعلى = ملاءمة أقل
الوقت المنقضي منذ آخر تغيير ذي مغزى	سجل إدارة التغييرات في Git	قد يشير الخمول الطويل إلى رمز غير فعال أو إلى استقرار النظام
عدد الثغرات الأمنية	مسح SAST	عدد كبير = ملاءمة أقل

لتقييم القيمة التجارية، فإن الأدلة المهمة هي:

مؤشر القيمة التجارية	مصدر	ينقل التصنيف نحو
عدد المعاملات لكل فترة	سجلات تنفيذ JCL، سجلات المجدول	حجم كبير = قيمة أعلى
انتشار المصب	تعيين التبعية	زيادة الانتشار = قيمة أعلى (يعتمد عليها الكثيرون)
علامة الوظيفة التنظيمية	تصنيف البيانات، سجل الامتثال	القيمة الحالية = الحد الأدنى بغض النظر عن الدرجات الأخرى
تجاور الإيرادات	تحليل تدفق البيانات إلى أنظمة الفوترة/الإيرادات	التجاور المباشر = قيمة أعلى
عدد المستخدمين أو عدد استدعاءات واجهة برمجة التطبيقات	سجلات الوصول، حركة مرور الشبكة	عدد كبير = قيمة أعلى

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

تقييم الملاءمة التقنية لأنظمة COBOL والأنظمة القديمة

لا تنطبق معايير التقييم القياسية للملاءمة التقنية، وتوافق واجهة برمجة التطبيقات، وجاهزية الحوسبة السحابية، ودعم الحاويات، وبنية الخدمات المصغرة، على برامج COBOL الدفعية. لا يمكن تحويل برنامج COBOL إلى حاوية؛ وتقييمه وفقًا لمعايير الحوسبة السحابية ينتج عنه درجة ملاءمة تقنية صفرية لكل برنامج قديم، وهو ما لا يُفيد المؤسسة بشيء.

بالنسبة لأنظمة COBOL والأنظمة المركزية، تتطلب درجة الملاءمة التقنية معايير خاصة بـ COBOL:

مؤشر التعقيد (الوزن: 30%): متوسط ​​التعقيد الحلقي عبر فقرات البرنامج وأقسامه. البرامج التي يقل متوسط ​​مؤشر التعقيد الحلقي فيها عن 10 تتمتع بتعقيد يمكن إدارته؛ أما البرامج التي يزيد متوسط ​​مؤشر التعقيد الحلقي فيها عن 20 فتتميز بتعقيد هيكلي يجعل صيانتها مكلفة ومحفوفة بالمخاطر.

مؤشر قابلية الصيانة (الوزن: 25%): يتكون من نسبة الكود غير المستخدم، ومدى مشاركة ملفات النسخ، ومعدل التكرار. البرنامج الذي يحتوي على 40% من الكود غير المستخدم، و15 ملف نسخ مشترك، وتكرار كبير للكود، يُعتبر منخفض قابلية الصيانة بغض النظر عن صحة وظائفه.

مؤشر مخاطر الاعتماد (الوزن: 20%): عدد البرامج التابعة مُرجّحًا بأهمية البرامج التابعة الواردة. البرنامج الذي يحتوي على 50 برنامجًا تابعًا واردًا من برامج المستوى الأول يُعتبر عالي المخاطر، وتتطلب التغييرات فيه تنسيق 50 برنامجًا تابعًا.

مؤشر الحداثة (الوزن: 15%): حداثة لهجة لغة COBOL وإصدار المترجم، وحداثة صيغة JCL، وواجهة قاعدة البيانات (إصدار SQL المضمن القديم، VSAM مقابل DB2، معالجة الدفعات فقط مقابل معالجة الدفعات مع CICS). البرامج المكتوبة بصيغة COBOL-85 مع SQL المضمن في DB2 أحدث من البرامج المكتوبة بلغة COBOL-74 مع الوصول إلى الملفات عبر VSAM فقط.

درجة الوضع الأمني ​​(الوزن: 10٪): وجود بيانات اعتماد مضمنة، والوصول إلى الملفات غير المحمية، وعدم وجود فحص حالة الملف، والتعرض لحقن SQL في بناء SQL الديناميكي.

Technical Fit Score = (100 - complexity_score) × 0.30
                    + maintainability_score × 0.25
                    + (100 - dependency_risk) × 0.20
                    + currency_score × 0.15
                    + security_score × 0.10

Where each component is scored 0-100, with 100 being best.

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

مشكلة الانحراف المتسامح: الحوكمة في ربع الاحتجاز

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

يمنع نظام الحوكمة القائم على التسامح التأجيل إلى أجل غير مسمى:

محفزات إعادة التصنيف القائمة على الحالة:

• تم تحديد ثغرة أمنية لا يمكن إصلاحها خلال 30 يومًا ← مراجعة لتحديد ما إذا كان سيتم نقلها أو إزالتها
• أعلن المورّد عن انتهاء دعم أحد مكونات النظام الأساسي التي يعتمد عليها التطبيق ← مراجعة لـ Migrate
• ارتفاع قيمة الأعمال فوق الحد الأدنى (متطلبات تنظيمية جديدة، تغيير في نموذج العمل) ← مراجعة للاستثمار أو الهجرة
• إلغاء الاعتمادات يُجبر على تغيير واجهة المستخدم ← مراجعة لخيار الترحيل أو الإلغاء
• تحليل الكود غير المستخدم يكشف أن التطبيق غير نشط فعليًا ← مراجعة لحذفه

وتيرة المراجعة القائمة على الوقت:

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

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

جعل برنامج "إلغاء" قابلاً للتنفيذ: سد فجوة إيقاف التشغيل

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

قائمة التحقق الخاصة بتنفيذ عملية الإزالة:

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

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

دورة إعادة تقييم الوقت

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

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

إعادة التقييم بناءً على حدث معين: تؤدي أحداث محددة إلى مراجعة فورية لإعادة التصنيف:

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

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

كيفية SMART TS XL يقدم الدليل على تصنيف الوقت

تعتمد دقة قرارات تصنيف نموذج TIME على قوة الأدلة التي تستند إليها. بالنسبة للتطبيقات الحديثة التي تغطيها قاعدة بيانات إدارة التكوين (CMDB)، وتراقب واجهات برمجة التطبيقات (API)، وتوثق بنيتها، فإن هذه الأدلة متاحة. أما بالنسبة لأنظمة COBOL القديمة التي تفتقر إلى قاعدة بيانات إدارة التكوين، وتقاعد مالكوها، وبنية التبعيات غير الموثقة، فيجب أن تأتي الأدلة من التحليل البنيوي للبرنامج نفسه.

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

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

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

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

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

لا يكون الإطار فعالاً إلا بقدر جودة الأدلة التي يستند إليها.

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

تُثير التصنيفات المبنية على بيانات المقابلات وتقديرات قاعدة بيانات إدارة التكوين (CMDB) نقاشات تنظيمية. أما التصنيفات المبنية على التحليل الهيكلي، وقياس التعقيد، والتحقق من عدد التبعيات، والملاءمة التقنية المستمدة من الكود، فتُفضي إلى قرارات قابلة للدفاع. يواجه مالك التطبيق الذي يُجادل بأن برنامج COBOL الخاص به يستحق الاستثمار بدلاً من الترحيل، موقفاً أكثر صعوبة عندما يُظهر التحليل الهيكلي تعقيداً حلقياً بمتوسط ​​35، و40% من الكود غير المستخدم، و12 ثغرة أمنية. في المقابل، يواجه فريق تكنولوجيا المعلومات الذي يُجادل بإمكانية حذف البرنامج موقفاً أضعف عندما يُظهر تحليل التبعيات 45 تبعية واردة من بيئة الإنتاج.

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