إعادة تصميم المنصة أم إعادة تصميم البنية؟ كيف تختار مسار التحديث الأمثل لبرامج كوبول القديمة؟

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

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

ما يعنيه كل مسار فعليًا بالنسبة للغة كوبول

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

إعادة تصميم منصة COBOL

تُنقل عملية إعادة تصميم المنصة برامج COBOL إلى بيئة تشغيل جديدة، عادةً ما تكون بنية تحتية سحابية، مع الحفاظ على الكود دون تغيير يُذكر. يتم تجميع وتشغيل COBOL على المنصة الجديدة، إما بشكل أصلي (باستخدام مُجمِّع COBOL من IBM على نظام Linux) أو من خلال طبقة محاكاة تعترض استدعاءات خاصة بالحاسوب المركزي (CICS، VSAM، JES) وتُترجمها إلى ما يُعادلها في بيئة الحوسبة السحابية.

ما يحتفظ به إعادة تصميم المنصة:

• شفرة المصدر COBOL
• منطق البرنامج وحساباته وقواعد العمل الخاصة به
• نموذج التنفيذ الدفعي (حلقات PERFORM، معالجة الملفات المتسلسلة)
• هياكل البيانات (تخطيطات السجلات، تعريفات دفتر النسخ)
• بنية وظيفة JCL (أعيدت كتابتها للمجدول الجديد، ولكنها مكافئة منطقيًا)

ما هي التغييرات التي تطرأ على إعادة تصميم المنصات؟

• البنية التحتية المادية (z/OS → Linux على السحابة)
• نظام الإدخال/الإخراج الفرعي (VSAM → تخزين الملفات المُدارة أو قاعدة البيانات، حسب الأداة)
• جدولة المهام (JES2/JES3 → AWS Batch، Azure Logic Apps، أو ما يعادلها)
• نموذج التكلفة (الفوترة القائمة على MIPS → الفوترة السحابية القائمة على الاستهلاك)

الخلاصة الرئيسية: إعادة تصميم النظام الأساسي خيارٌ صائبٌ عندما تكمن المشكلة في النظام الأساسي نفسه، أو تكلفة تشغيل نظام z/OS، أو الاعتماد على البنية التحتية، أو نموذج فوترة MIPS. أما إذا كانت المشكلة في الكود أو في بنية النظام، فهو خيارٌ خاطئ.

إعادة تصميم COBOL

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

ما هي التغييرات التي تطرأ على إعادة تصميم العمارة؟

• لغة البرمجة (كوبول → جافا، بايثون، جو، سي شارب)
• نموذج التنفيذ (دفعي ← قائم على الأحداث، أو متدفق، أو قائم على واجهة برمجة التطبيقات)
• طبقة البيانات (ملفات VSAM → قاعدة بيانات علائقية، NoSQL، تخزين سحابي أصلي)
• نموذج المعاملات (CICS شبه المحادثة → خدمات RESTful عديمة الحالة)
• نمط التكامل (مجموعات البيانات المشتركة ← عقود واجهة برمجة التطبيقات، قوائم انتظار الرسائل)

ما يجب أن تحافظ عليه عملية إعادة التصميم المعماري:

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

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

العوامل الخاصة بلغة كوبول التي تُغير هذا القرار

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

تبعيات معاملات CICS

نظام CICS (نظام التحكم بمعلومات العملاء) هو برنامج وسيط لمعالجة المعاملات تستخدمه العديد من برامج COBOL في أحمال العمل التفاعلية. يعتمد برنامج COBOL الذي يُجري استدعاءات EXEC CICS ضمنيًا على خادم معاملات CICS لإدارة الشاشة، والتواصل مع الطرفية، وتوزيع المهام، والتحكم في البرنامج.

تأثير إعادة تصميم النظام الأساسي: تحاكي أدوات مثل محاكاة CICS من Micro Focus، وOpenFrame، وبعض ميزات تحديث AWS Mainframe، دلالات CICS. إذا كان استخدام CICS قياسيًا وسليمًا، فقد تنجح المحاكاة. أما إذا كان البرنامج يعتمد على مكونات CICS الداخلية، أو معالجة منطقة الاتصال، أو التحكم في نقاط التزامن، أو التخزين على مستوى المهام، فإن دقة المحاكاة تتراجع.

تبعات إعادة التصميم: يجب إعادة تصميم نموذج المعاملات شبه الحواري لبرنامج CICS الذي تم تحويله إلى واجهة برمجة تطبيقات REST ليصبح تفاعلات غير مرتبطة بحالة. هذا تغيير معماري، وليس مجرد ترجمة برمجية.

إشارة تدفع نحو إعادة التصميم: استخدام مكثف لـ CICS مع معالجة معقدة لمنطقة الاتصال، أو ربط المعاملات الخلفية، أو منطق نقطة التزامن.

بنية ملفات VSAM

VSAM (طريقة الوصول إلى التخزين الافتراضي) هو نظام الملفات المفهرس المستخدم في معظم برامج COBOL الإنتاجية. تتميز ملفات VSAM بأنماط وصول محددة، مثل KSDS (التسلسل المفهرس)، وESDS (التسلسل المدخلي)، وRRDS (السجل النسبي)، والتي لا يوجد لها مثيل مباشر في التخزين السحابي الأصلي.

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

الآثار المترتبة على إعادة التصميم: يتطلب استبدال VSAM بقاعدة بيانات علائقية ربط تخطيطات السجلات بمخططات الجداول، والتعامل مع تحويلات أنواع البيانات الضمنية، وإعادة كتابة كل عملية وصول إلى الملفات لاستخدام SQL أو ORM.

إشارة تدفع نحو إعادة التصميم: ملفات VSAM المشتركة عبر العديد من البرامج، وأنماط الوصول البديلة للفهرس، أو متطلبات الأداء في الوقت الحقيقي التي لا يمكن للمحاكاة تلبيتها.

متطلبات المعالجة الدفعية مقابل متطلبات المعالجة الآنية

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

تأثير تغيير المنصة: تتوافق دلالات المعالجة الدفعية بشكل جيد مع تنفيذ الدفعات السحابية (AWS Batch، Azure Batch). يبقى نموذج المعالجة التسلسلية فعالاً حتى بعد تغيير المنصة. إذا كان المطلوب هو تشغيل نفس مهمة الدفعات على بنية تحتية أقل تكلفة، فإن تغيير المنصة يلبي هذا المطلب مباشرةً.

تداعيات إعادة تصميم البنية: إذا تغيرت متطلبات العمل، من المعالجة الدفعية الليلية إلى المعالجة شبه الفورية، ومن تبادل الملفات إلى تكامل واجهة برمجة التطبيقات، ومن عمليات المعالجة الدفعية المتكاملة إلى الخدمات المصغرة التي يتم تشغيلها بشكل فردي، فإن إعادة تصميم المنصة لا يمكنها تلبية المتطلبات الجديدة. يجب تغيير البنية.

إشارة تدفع نحو إعادة التصميم: متطلبات أصحاب المصلحة للمعالجة في الوقت الحقيقي، والتكامل القائم على واجهة برمجة التطبيقات، والهندسة المعمارية القائمة على الأحداث، أو أوقات الاستجابة التي تقل عن ثانية والتي لا يمكن أن توفرها دلالات الدفعات.

منطق أعمال مضمن بدون مواصفات خارجية

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

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

نتيجة إعادة التصميم: يجب استخراج قواعد العمل من مصدر COBOL قبل إعادة تنفيذها. <cite index=”28-1″>يؤدي الكود غير الموثق والمترابط بشدة إلى مضاعفة الجهد في كل مرحلة.</cite> إذا كان هذا الاستخراج غير مكتمل، فسيكون للنظام الجديد مواصفات مختلفة عن النظام القديم، وستظهر هذه الاختلافات في بيئة الإنتاج.

إطار عمل لاتخاذ القرار: ثمانية أسئلة

قبل اختيار المسار، توفر هذه الأسئلة الثمانية الأدلة اللازمة لاتخاذ القرار بثقة بدلاً من الافتراض.

1. ما هو المحرك الرئيسي لهذا التحديث؟

• تكلفة البنية التحتية ← إعادة المنصة كافية
• الاعتماد على النظام الأساسي (z/OS) ← إعادة النظام الأساسي كافية
• متطلبات الوقت الفعلي ← مطلوب مهندس معماري خلفي
• متطلبات التكامل (واجهة برمجة التطبيقات) ← من المحتمل الحاجة إلى إعادة تصميم النظام
• قابلية الصيانة / توافر المواهب ← إعادة تصميم أو إعادة هيكلة النظام

٢. ما هو مستوى اقتران CICS؟ اذكر جميع استدعاءات EXEC CICS. احسب البرامج التي تحتوي على أكثر من عشرين أمرًا مختلفًا من أوامر CICS. البرامج ذات الاقتران العالي مع CICS تُعتبر مرشحة ضعيفة لإعادة التشغيل إذا كانت دقة المحاكاة غير مؤكدة.

3. ما هي أنماط الوصول إلى ملفات VSAM؟ حدد البرامج التي تصل إلى ملفات VSAM باستخدام مفاتيح بديلة، أو مجموعات مشتركة، أو وصول عشوائي حساس للأداء. هذه مؤشرات على مخاطر إعادة تشغيل النظام الأساسي.

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

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

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

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

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

تطبيق الإطار: أربعة ملفات تعريف لنظام COBOL

نبذة عن الشركة	الخصائص	المسار الموصى به	المنطق
أداة دفعية مستقرة	إدخال/إخراج الملفات التسلسلي، بدون CICS، منطق موثق جيدًا، تعقيد منخفض	إعادة النظام الأساسي	تكمن المشكلة في تكلفة المنصة، أما المشكلة فليست في الكود.
المعاملات الإلكترونية التي تعتمد بشكل كبير على نظام CICS	استخدام مكثف لـ EXEC CICS، تبعيات منطقة الاتصال، نموذج شبه حواري	مهندس خلفي	مخاطر محاكاة CICS عالية؛ ومن المرجح وجود متطلبات في الوقت الفعلي
معالج الملفات الرئيسية VSAM	أنماط وصول معقدة إلى VSAM، مشتركة بين العديد من البرامج، حجم قراءة عالٍ	قم بتقييم دقة المحاكاة أولاً؛ ثم أعد تثبيت النظام الأساسي إذا كانت المحاكاة سليمة.	تُعد محاكاة VSAM متغير القرار
خزانة منطق الأعمال	قواعد غير موثقة، لا توجد مواصفات خارجية، أهمية تنظيمية عالية	استخرج المنطق أولاً، ثم اختر	لا يمكن قبول مخاطر إعادة تصميم البنية دون استخراج منطق الأعمال مسبقًا

الخلاصة الرئيسية: <cite index=”30-1″>في الواقع، تمزج المؤسسات الكبيرة بين الأساليب: إعادة تصميم الأجزاء المستقرة، وإعادة هيكلة الكود الذي يصعب صيانته، وإعادة كتابة الأنظمة القليلة التي تحتاج إلى قدرات جديدة، وإيقاف تشغيل ما لم يعد مستخدمًا.</cite> القرار ليس على مستوى المحفظة، بل على مستوى عبء العمل، ويتم تطبيقه بشكل فردي على كل برنامج أو مجموعة برامج بناءً على الأدلة.

النهج الهجين: إعادة تصميم المنصة أولاً، ثم إعادة هندسة البنية عند الضرورة

قاعدة عملية: إعادة الاستضافة أو إعادة المنصة لوقف النزيف بسرعة، ثم إعادة هيكلة أو إعادة تصميم الأنظمة التي تمثل عوامل تمييز تنافسية حقيقية.

بالنسبة لمعظم المؤسسات التي لديها محافظ كبيرة من برامج COBOL، فإن التسلسل العملي هو:

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

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

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

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

---

ما يجب أن ينتج عن التحليل قبل اتخاذ أي قرار

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

ما يجب أن يحدده التحليل لكل برنامج:

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

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

كيفية SMART TS XL يُنتج الأدلة قبل اتخاذ القرار

SMART TS XLالصورة تحديث التراث يقوم التحليل بأتمتة المخزون الهيكلي الموصوف أعلاه، حيث يقوم بتحليل كل برنامج COBOL، ودفتر النسخ، ووظيفة JCL، ومرجع ملف VSAM في وقت واحد لبناء نموذج التبعية الموحد الذي يجعل قرار المسار قائمًا على الأدلة.

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

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

يقوم توسيع JCL بحل المعلمات الرمزية وبناء سلسلة تبعية تنفيذ الدفعة الكاملة، والتي تستدعي وظائف JCL أي البرامج، وبأي تسلسل، وبأي مجموعات بيانات، مما يوفر السياق التشغيلي الذي يحدد كيفية تصرف مخرجات أي مسار لتلبية جدول الدفعة.

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

تتيح خاصية البحث المؤسسي إمكانية الاستعلام عن المخزون الكامل في جميع أنحاء البرنامج: العثور على كل برنامج يستخدم أمر CICS معين، وكل برنامج يصل إلى مجموعة VSAM معينة، وكل ملف نسخ يحدد بنية بيانات معينة، في ثوانٍ، عبر ملايين أسطر COBOL.

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