Uygulama Portföyleri için TIME Modeli (Tolerans Göster, Yatırım Yap, Geçiş Yap, Ortadan Kaldır)

Uygulama rasyonelleştirme toplantısı sabah 9'da başlıyor. Saat 11'e kadar ekip, kapsam dahilindeki dört yüz uygulamadan on ikisini sınıflandırmış durumda. Bu on iki sınıflandırmadan üçü zaten tartışılmış, revize edilmiş ve tekrar tartışılmış. Bordro işlemlerini yürüten COBOL toplu iş programı açıkça "Elimine Et" değil, peki "Tolerans Göster" mi yoksa "Yatırım Yap" mı? Herkesin teknik olarak yetersiz olduğunu kabul ettiği eski faturalama sistemi açıkça "Geçiş Yap", ancak neye geçiş yapılacak ve ona bağlı on yedi programa ne olacak? Toplantı öğlene kadar planlanmış. Öğlen, birisi gelecek hafta devam etmeyi öneriyor. Bir sonraki aya gelindiğinde, girişim sessizce çıktı üretmeyi durdurmuş durumda.

Gartner TIME modeli, kurumsal BT'de en yaygın kullanılan uygulama portföyü yönetim çerçevesidir. Portföydeki her uygulamayı, iş değeri ve teknik uyumluluk olmak üzere iki puanlama boyutu kullanarak, Tolerans Göster, Yatırım Yap, Taşı, Ortadan Kaldır olmak üzere dört kategoriye ayırır. Çerçeve mantıksal olarak sağlam, geniş çapta uygulanabilir ve ABD federal CIO Konseyi'nin Uygulama Rasyonelleştirme Rehberi'nde önerilen bir metodoloji olarak gösterilmektedir. Ancak, çerçeve savunucularının bahsettiği ancak nadiren geliştirdiği bir nedenden dolayı, pratikte başarısından daha sık başarısız olur: sınıflandırmalar, arkalarındaki kanıtlar kadar iyidir. Yapısal kanıtlar, gerçek bağımlılık sayıları, gerçek karmaşıklık ölçümleri, sahip görüşmelerinden ziyade yürütme izlerinden elde edilen gerçek iş değeri verileri olmadan, TIME sınıflandırmaları kurumsal politikaya dönüşür. Yerleştirme tartışmaları, birinin favori uygulamasının tehlikede olduğu Taşı ve Ortadan Kaldır kategorilerinde başlar ve asla çözüme kavuşmaz.

Model: İki Eksen, Dört Konum

TIME modeli, her uygulamayı 2x2'lik bir matris üzerinde gösterir. Yatay eksen, teknik uyumluluğu, yani uygulamanın mevcut teknik uygulamasının amaçlanan işlevini ne kadar iyi desteklediğini gösterir: mimari kalitesi, sürdürülebilirlik, entegrasyon yeteneği, güvenlik durumu, operasyonel güvenilirlik. Dikey eksen ise iş değerini, yani uygulamanın işlevinin kuruluşun iş operasyonları, gelir elde etme, mevzuata uyum veya stratejik hedefleri için ne kadar önemli olduğunu gösterir.

	Yüksek Teknik Uyumluluk	Düşük Teknik Uyumluluk
Yüksek İş Değeri	YATIRIMBunu finanse edin. Uygulama hem stratejik açıdan önemli hem de teknik olarak sağlam. Liderliğini korumak için yatırım yapın.	GÖÇİşletmenin buna ihtiyacı var, teknoloji yanlış. İşlevi değil, platformu değiştirin.
Düşük İşletme Değeri	TOLERA ETŞimdilik dokunmayın. Uygulama sağlıklı çalışıyor ancak ek yatırım yapmaya değmez.	ELEMEKArtık kullanımdan kaldırın. Değeri düşük, kalitesi düşük, tutmanın hiçbir gerekçesi yok.

Sadeliğin bir amacı var. TIME, ayrıntılı yatırım planlaması üretmek için değil, portföydeki her uygulama için net yönlendirme kararları üretmek için tasarlanmıştır. Net bir şekilde sınıflandırılamayan bir uygulama, sınıflandırmanın mümkün olması için daha fazla bilgi gerektiren bir uygulamadır.

Dört Kadranlı İşletme Modelleri

Her TIME yaklaşımı sadece bir etiket değil, kuruluşun uygulamayı gelecekte nasıl yöneteceğini belirleyen bir işletim modelidir.

Yatırım: Maksimum Değer Elde Etme

Yatırım uygulamaları, portföyün en değerli varlıklarıdır: yüksek iş değeri, yüksek teknik uyumluluk. Yeni özelliklere, performans optimizasyonuna, entegrasyon genişletmesine ve teknik güncelliğin korunmasına yönelik en agresif yatırımı haklı çıkarırlar. Teknik güncelliğinde geride kalan, eski bir çalışma ortamına, güncelliğini yitirmiş bir güvenlik duruşuna ve biriken bağımlılık borcuna sahip bir yatırım uygulaması, fark edilmeden önce Geçiş aşamasına geçme riski taşır.

Invest'in faaliyet taahhütleri:

• Özellik geliştirme ve teknik bakım için özel mühendislik kapasitesi
• Öncelikli güvenlik yamaları ve uyumluluk güncellemeleri
• Mimari inceleme kurulunun her önemli değişiklik için yaptığı değerlendirmeler
• Birinci kademe seviyesinde SLA hedefleriyle proaktif izleme.

Taşıma: Platformu Değiştir, İşlevi Koru

Uygulamaların taşınması, kuruluşun gerçekten ihtiyaç duyduğu bir işlevi yerine getiren ancak artık yeterli olmayan, bakımı çok pahalı olan, genişletilmesi çok kırılgan olan ve modern entegrasyon ortamından çok uzak bir teknik platformda çalışan uygulamaları kapsar. İş değeri, taşıma yatırımını haklı çıkarır; ancak teknik durum, mevcut platforma yapılan yatırımın devam etmesinin düşük getiri sağlamasına neden olur.

"Göç Et" seçeneği belirli bir soruyu yanıtlar: İşlev korunmaya değer mi? Eğer evet ise, geçiş yapın. Neye ve nasıl geçiş yapılacağı ayrı bir karardır ve TIME sınıflandırması bu konuda bir karar vermez, sadece mevcut platformun çözüm olmadığını belirler.

Eski sistemlerde en sık karşılaşılan geçiş senaryosu: Kritik iş mantığını, karmaşık düzenleyici hesaplamaları, özel fiyatlandırma kurallarını, yargı alanına özgü vergi mantığını uygulayan bir COBOL toplu işlem programı; mevcut platformda genişletme, test etme ve entegre etme maliyeti yüksektir. Mantık yeri doldurulamaz; sorun platformdadır. İşletmenin artık ihtiyaç duyduğu operasyonel özellikleri sağlarken mantığı koruyan modern bir platforma geçiş yapılır.

Tolerans Göstermek: Belirli Bir Son Kullanma Tarihi Olan Kasıtlı Eylemsizlik

Tolerans gösterme, en yanlış anlaşılan çeyrektir. "Bu uygulama sorunsuz" anlamına gelmez. "Bu uygulamanın teknik kalitesi, şu anda değiştirilmesi için yapılacak yatırımı haklı çıkarmaz ve iş değeri de ortadan kaldırılmasını haklı çıkarmaz" anlamına gelir. Bu, süresiz bir erteleme değil, belirli bir süre için mevcut durumu kabul etme yönünde bilinçli bir tercihtir.

Tolerans, kalıcı bir durum değil, süreli bir bekleme durumudur. Tolerans kategorisindeki her uygulamanın, genellikle 12 ila 18 ay arasında değişen açık bir inceleme tarihi ve erken yeniden sınıflandırmayı tetikleyecek tanımlanmış koşulları olmalıdır: yama yapılamayan bir güvenlik açığı, platform değişikliğini zorunlu kılan bir bağımlılığın ortadan kaldırılması, uygulamaya yatırım yapmaya değer kılan bir iş değeri artışı veya amacını ortadan kaldıran bir iş fonksiyonu değişikliği.

Tolerans göstermeyi kalıcı bir durum olarak ele alan kuruluşlar, tam olarak TIME modelinin önlemeyi amaçladığı teknik borcu biriktirirler. 2019'da Tolerans gösterilen ve 2026'da hala Tolerans bölgesinde bulunan bir COBOL programı, yedi yıl daha ertelenmiş bakım ilgisi almış demektir; bu bakım, bir şey bozulduğunda acil bir durum olarak veya platform artık desteklenemediğinde zorunlu bir Geçiş olarak eninde sonunda alınması gerekecektir.

Eleme: Herkesin Verdiği Ama Kimsenin Uygulamadığı Karar

Eleme, en basit sınıflandırma ve en az uygulanan yöntemdir. Uygulamanın iş değeri ve teknik uygunluğu düşüktür, tutulması için hiçbir neden yoktur. Kullanımdan kaldırın.

Uygulama başarısızlığı iyi belgelenmiştir: "Eliminate" (Eliminate) seçeneği büyük bir coşkuyla doldurulur ancak neredeyse hiç uygulanmaz. Büyük bir finans kurumunda 2024 yılında yapılan bir portföy incelemesi 87 "Eliminate" adayı ortaya çıkardı. On sekiz ay sonra, bunların 71'i hala çalışır durumdaydı. Sınıflandırma ile devre dışı bırakma arasındaki boşluk, rasyonelleştirme programlarının ivme kaybettiği noktadır.

Eliminate uygulamasının gerçekleştirilmesini engelleyen üç özel engel bulunmaktadır:

Gizli bağımlılıklar. Uygulama, görünürdeki bağımsız durumu nedeniyle "Ele Geçirilecek" olarak sınıflandırılmıştı. Sınıflandırmanın ardından yapılan yapısal analiz, "Ele Geçirilecek" adayının işlediği çıktıyı üreten on iki başka programın olduğunu veya üç harici sistemin belgelenmemiş bir dosya arayüzü aracılığıyla ona veri gönderdiğini ortaya koymaktadır. Uygulama bağımsız değildir; diğer sistemler için gizli altyapıdır. Sınıflandırma yeniden gözden geçirilmelidir.

Veri geçişini engelleyen faktörler. Uygulama, imha edilemeyen veriler, zorunlu saklama sürelerine sahip düzenleyici kayıtlar, halef sisteme aktarılması gereken müşteri verileri ve denetim süreçlerinin yıllık olarak sorguladığı geçmiş işlem kayıtları içerir. Veri geçişi, sistemin devre dışı bırakılmasından önce yapılmalıdır ve veri geçişi maliyetlidir.

Mevzuat yükümlülükleri. Bazı uygulamalar, iş değeri sıfır olsa bile, düzenleyici çerçeveler sağladıkları yeteneği gerektirdiğinden, devre dışı bırakılamaz. Üç aylık düzenleyici bildirim üreten bir raporlama uygulamasının, herhangi bir iş değeri araştırmasında görünmeyen düzenleyici bir değeri vardır. Mevzuat yükümlülüğü başka bir sisteme devredilene kadar, uygulamanın çalışması gerekir.

Kanıt Sorunu: TIME Yapısal Veriler Olmadan Neden Başarısız Oluyor?

TIME uygulamalarındaki en önemli başarısızlık modu, Catio'nun dokümantasyonunda tam olarak tanımlandığı gibidir: Yerleştirme tartışmaları, birinin favori uygulamasının söz konusu olduğu "Taşı" ve "Ele Geçir" seçeneklerinde başlar. Objektif kanıt olmadan, her sınıflandırma bir müzakeredir. Uygulama sahibi "Yatırım Yap"ı savunur. BT ekibi "Taşı"yı savunur. Finans ekibi "Ele Geçir"i ister. Toplantı, en az tartışmalı pozisyon olduğu için "Tolerans Göster" seçeneğiyle sona erer.

Yapısal kanıtlar, görüşün yerini ölçümle değiştirerek bu müzakereleri çözüme kavuşturur.

Teknik uygunluk puanlaması için önemli olan kanıtlar şunlardır:

Teknik Uygunluk Göstergesi	Kaynak	Sınıflandırmayı İleriye Doğru Harekete Geçiriyor
Program başına döngüsel karmaşıklık (ortalama)	Statik kod analizi	Düşük = daha yüksek uyum, Yüksek = daha düşük uyum
Ölü kod yüzdesi	Erişilebilirlik analizi	Yüksek ölü kod sayısı = düşük uyum
Fan-in (gelen bağımlılık sayısı)	Bağımlılık eşlemesi	Yüksek fan giriş artışı Tolere edilebilir, ortadan kaldırılabilir
Defter paylaşımı genişliği	KOPYA bağımlılık analizi	Yüksek paylaşım = daha yüksek eşleşme = daha düşük uyum
Son anlamlı değişiklikten bu yana geçen süre	Git/değişiklik yönetimi günlüğü	Uzun süreli hareketsizlik, ölü kod veya istikrarın bir göstergesi olabilir.
Güvenlik açığı sayısı	SAST taraması	Yüksek sayı = daha düşük uyum

İş değeri puanlaması için önemli olan kanıtlar şunlardır:

İş Değeri Göstergesi	Kaynak	Sınıflandırmayı İleriye Doğru Harekete Geçiriyor
Dönem başına işlem hacmi	JCL yürütme günlükleri, zamanlayıcı kayıtları	Yüksek hacim = daha yüksek değer
Aşağı yönde yayılma	Bağımlılık eşlemesi	Yüksek dağıtım ağı = daha yüksek değer (çoğu buna bağlıdır)
Düzenleyici işlev bayrağı	Veri sınıflandırması, uyumluluk kaydı	Mevcut değer, diğer puanlardan bağımsız olarak minimum değer tabanıdır.
Gelir yakınlığı	Fatura/gelir sistemlerine yönelik veri akışı analizi	Doğrudan komşuluk = daha yüksek değer
Kullanıcı sayısı veya API çağrı sayısı	Erişim kayıtları, ağ trafiği	Yüksek sayı = daha yüksek değer

Kritik nokta şu: eski COBOL sistemleri için bu göstergelerin çoğu CMDB kayıtlarından, uygulama sahibi görüşmelerinden veya ağ trafiği analizinden elde edilemez. Bunlar, kaynak kodunun yapısal analizinden, yürütme günlüklerinden ve üretimde neyin ne zaman çalıştığını belgeleyen JCL iş zamanlamasından elde edilebilir.

COBOL ve Eski Sistemler için Teknik Uygunluğun Puanlanması

Standart teknik uygunluk puanlama kriterleri, API uyumluluğu, bulut tabanlı hazırlık, konteynerleştirme desteği, mikro hizmet mimarisi, COBOL toplu iş programları için önemsizdir. Bir COBOL programı konteynerleştirilemez; bulut tabanlı kriterlere göre puanlanması, her eski program için sıfır teknik uygunluk puanı üretir ve bu da kuruluşa hiçbir yararlı bilgi vermez.

COBOL ve ana bilgisayar sistemleri için teknik uygunluk puanı, COBOL'a özgü kriterler gerektirir:

Karmaşıklık puanı (ağırlık: %30): Programın paragrafları ve bölümlerindeki ortalama döngüsel karmaşıklık. Ortalama döngüsel karmaşıklık puanı 10'un altında olan programlar yönetilebilir karmaşıklığa sahiptir; 20'nin üzerindeki programlar ise bakımı pahalı ve riskli hale getiren yapısal karmaşıklığa sahiptir.

Bakım kolaylığı puanı (ağırlık: %25): Ölü kod yüzdesi, copybook paylaşım kapsamı ve kopyalama oranının birleşimi. %40 ölü koda, 15 paylaşımlı copybook'a ve önemli kod kopyalamasına sahip bir programın, işlevsel doğruluğundan bağımsız olarak bakım kolaylığı düşüktür.

Bağımlılık riski puanı (ağırlık: %20): Gelen bağımlıların kritiklik derecesine göre ağırlıklandırılmış giriş sayısı. 1. Kademe programlardan 50 gelen bağımlılığı olan bir program yüksek bağımlılık riskine sahiptir; bu programda yapılacak değişiklikler 50 alt programın koordinasyonunu gerektirir.

Güncellik puanı (ağırlık: %15): COBOL lehçesi ve derleyici sürümünün güncelliği, JCL sözdiziminin modernliği ve veritabanı arayüzü (gömülü SQL'in eski sürümü, VSAM vs DB2, yalnızca toplu işleme vs toplu işleme+CICS). DB2 gömülü SQL ile COBOL-85 sözdizimiyle yazılmış programlar, yalnızca VSAM dosya erişimiyle COBOL-74 ile yazılmış programlardan daha günceldir.

Güvenlik duruşu puanı (ağırlık: %10): Sabit kodlanmış kimlik bilgilerinin varlığı, korumasız dosya erişimi, dosya durumu kontrolünün olmaması ve dinamik SQL oluşturmada SQL enjeksiyonu açığı.

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.

Bu puanlama formülü, niteliksel değerlendirmeden ziyade yapısal kod analizinden türetilen 0-100 arasında bir teknik uygunluk puanı üretir. Aynı işlevlere sahip ancak farklı yapısal özelliklere sahip iki uygulama, farklı teknik uygunluk puanları üretecek ve bu puanlar, her birinin bakımı ve genişletilmesi için gereken farklı yatırımı doğru bir şekilde yansıtacaktır.

Tolerans Gösterme Sapması Sorunu: Holding Bölgesi için Yönetim

Tolerans, TIME'ı açık bir Tolerans yönetimi olmadan kullanan her kuruluşta zamanla borç biriktiren çeyrektir. Mekanizma basittir: bir uygulama, değiştirilmeye değmediği için Tolerans kategorisine girer ve daha sonra değiştirilmesi hiçbir zaman en acil öncelik olmadığı için süresiz olarak Tolerans kategorisinde kalır.

Hoşgörü yönetim disiplini, süresiz ertelemeyi önler:

Koşula dayalı yeniden sınıflandırma tetikleyicileri:

• 30 gün içinde yama yapılamayacak bir güvenlik açığı tespit edildi → Taşıma veya Kaldırma için inceleyin
• Tedarikçi, uygulamanın bağımlı olduğu bir platform bileşeninin kullanım ömrünün sona erdiğini duyurdu → Taşıma için inceleyin
• İş değeri puanı eşik değerin üzerine çıkarsa (yeni düzenleyici gereklilik, iş modeli değişikliği) → Yatırım mı, Geçiş mi değerlendirmesi yapılır?
• Bağımlılıktan kurtulma, arayüz değişikliğini zorunlu kılıyor → Taşıma veya Kaldırma için inceleme
• Ölü kod analizi, uygulamanın fiilen pasif olduğunu ortaya koyuyor → Eleme için gözden geçirin

Zaman bazlı inceleme sıklığı:

• Başvurular, 12 aylık bir inceleme süresiyle Tolerate sistemine girer.
• 12 aylık değerlendirmede, başvuru açıkça yeniden sınıflandırılır veya yeni bir 12 aylık tarihle açıkça yeniden "Tolerans" kapsamına alınır.
• Yeniden hoşgörü, koşulların neden değişmediğini belgeleyen yazılı bir gerekçe gerektirir.
• Yeniden sınıflandırılmadan iki defadan fazla "Yeniden Onaylandı" statüsüne alınan bir uygulama, mimari inceleme kuruluna iletilir.

Tolerate kayıt defteri: Her Tolerate başvurusunun sınıflandırma tarihi, inceleme tarihi, sahibi ve yeniden sınıflandırmayı tetikleyecek koşullar kümesiyle birlikte tutulduğu bir listedir. Bu kayıt defteri, yalnızca yıllık portföy incelemesinde değil, her mimari inceleme kurulu toplantısında gözden geçirilir.

Devre Dışı Bırakma İşlemini Uygulanabilir Hale Getirmek: Devre Dışı Bırakma Açığını Kapatmak

“Yok Edilmesi Gereken Olarak Sınıflandırıldı” ve “başarıyla devre dışı bırakıldı” arasındaki boşluk, rasyonelleştirme programlarının tıkandığı noktadır. Bu boşluğu kapatmak, her bir Yok Etme kararını bir sonuç olarak değil, tanımlanmış kapsamı, bağımlılıkları ve başarı kriterleri olan bir proje olarak ele almayı gerektirir.

Eliminate uygulamasının kontrol listesi:

• Bağımlılık doğrulama işlemi tamamlandı: Statik analiz, gelen üretim bağımlılıklarının sıfır olduğunu doğrular (sadece belgelenmiş bağımlılıkların sıfır olması değil, yapısal olarak da sıfır olduğu doğrulanmıştır).
• Veri imha planı onaylandı: Yasal düzenlemelere uygun saklama gereksinimleri belirlendi, veri taşıma veya arşivleme planı hukuk ve uyumluluk birimleri tarafından onaylandı.
• Aşağı yönlü bildirim tamamlandı: Her tüketici sistemin sahibine bildirim yapıldı ve aktif bir bağımlılığın olmadığı doğrulandı.
• Mevzuat yükümlülüğü kontrolü tamamlandı: Başvuruya bağlı herhangi bir aktif düzenleyici başvuru, denetim veya uyumluluk gerekliliği bulunmamaktadır.
• Devre dışı bırakma sorumlusu atandı: Sadece sınıflandırma kararından değil, hizmetten çıkarma işleminin yürütülmesinden sorumlu kişi olarak atanmış kişi.
• Geri alma planı tanımlandı: Devre dışı bırakma işlemi sırasında keşfedilmemiş bir bağımlılığın ortaya çıkması durumunda hizmetin geri yüklenmesi prosedürü
• Devre dışı bırakma tarihi taahhüdü: BT takviminde belirli bir tarih, "sıra gelince" değil.

Yapısal analiz aşaması: Üretim yürütme yollarından sıfır gelen bağımlılık doğrulanana kadar "Eleme" kararı devre dışı bırakma planlamasına geçmez. "Eleme" yürütme hatasının en yaygın nedeni, devre dışı bırakma duyurusundan sonra bir bağımlılığın keşfedilmesi ve bunun da geri dönüşü zorlamasıdır. Duyurudan önce yapılan yapısal bağımlılık analizi bunu önler.

TIME Yeniden Değerlendirme Döngüsü

TIME sınıflandırmaları kalıcı değildir. Kuruluşun stratejisi geliştikçe iş değeri de değişir. Uygulama sürdürüldükçe, genişletildikçe veya eskimeye bırakıldıkça teknik uyumluluk da değişir. Model bir anlık görüntüdür; portföy ise hareketli bir görüntü gerektirir.

Yıllık tam yeniden değerlendirme: Portföydeki her başvuru, mevcut iş değeri ve teknik uygunluk kriterlerine göre puanlanır. Üç yıl üst üste değişmeyen sınıflandırmalar özel olarak incelenir; ya başvuru gerçekten istikrarlıdır (nedenini belgeleyin) ya da değerlendirme, meydana gelen değişimi yansıtmamaktadır.

Olay tetiklemeli yeniden değerlendirme: Belirli olaylar, anında yeniden sınıflandırma incelemesini tetikler:

• Birleşme veya devralma (yeni portföy birleşimi)
• Uyumluluk yükümlülüklerini etkileyen mevzuat değişiklikleri
• Önemli platformların (veritabanı, işletim sistemi, çalışma ortamı) kullanım ömrünün sona erdiğine dair duyuru
• Önemli iş modeli değişikliği (yeni ürün serisi, pazardan çıkış, organizasyonel yeniden yapılanma)
• Uygulamayla ilgili güvenlik olayı

Değişiklik kayıt defteri disiplini: Her yeniden sınıflandırma şu bilgilerle kaydedilir: önceki sınıflandırma, yeni sınıflandırma, tarih, değişikliğe yol açan kanıt ve onaylayan kişi. Her uygulamanın sınıflandırma geçmişi, portföyün kategorize edilip unutulmak yerine aktif olarak yönetildiğini gösteren denetim izidir.

Ne kadar SMART TS XL TIME Sınıflandırması İçin Kanıt Sağlar

TIME modelinin sınıflandırma kararları, ancak arkalarındaki kanıtlar kadar iyidir. CMDB kapsamı, API izleme ve belgelenmiş mimarilere sahip modern uygulamalar için bu kanıtlara erişilebilir. CMDB'nin eksik olduğu, sahiplerinin emekli olduğu ve bağımlılık yapısının belgelenmediği eski COBOL portföyleri için ise kanıtlar, kodun kendisinin yapısal analizinden gelmelidir.

SMART TS XL'S statik kod analizi COBOL puanlamasının gerektirdiği teknik uygunluk girdilerini üretir: program başına döngüsel karmaşıklık, ölü kod yüzdesi, güvenlik açığı bulguları (sabit kodlanmış kimlik bilgileri, korumasız dosya erişimi) ve COBOL lehçesinin güncelliği. Bu ölçütler, geliştirici tahminlerinden değil, kaynak koddan türetilir ve uygulamanın ne yaptığını hatırlamaya bağlı değildir.

Uygulama bağımlılık haritalaması, erken "Eleme" kararlarını önleyen giriş sayımlarını ve iş değeri puanlamasını destekleyen çıkış sayımlarını üretir. Üretim programlarından 45 gelen bağımlılığı olan bir uygulama, sahibi iş değerini nasıl değerlendirirse değerlendirsin, güvenli bir "Eleme" adayı değildir. Bağımlılık sayısı, sınıflandırma argümanını geçersiz kılan yapısal bir gerçektir.

Eski sistemlerin modernizasyon analizi, sınıflandırmaları değiştiren ölü kod envanterini oluşturur: CMDB'de aktif uygulamalar olarak görünen ancak sıfır gelen üretim bağımlılığına sahip programlar, ölü kod adaylarıdır ve yapısal kanıtlara dayanarak, işletme sahibinin varlığından hiç haberdar olmayabileceği bir program hakkındaki değerlendirmesine değil, "Tolerans Göster"den "Ortadan Kaldır"a yeniden sınıflandırılır.

Etki analizi özelliği, devre dışı bırakma planlamasına başlamadan önce sıfır gelen üretim bağımlılığını doğrulayan yapısal analiz olan "Eliminate" uygulama kontrol listesinin gerçekleştirilebilir olmasını sağlar. Bu, en yaygın "Eliminate" uygulama hatasını, yani duyurudan sonra ortaya çıkan keşfedilmemiş bağımlılığı önleyen kapıdır.

Kurumsal arama özelliği, TIME sınıflandırma sürecini yeniden değerlendirme döngüsü boyunca sorgulanabilir hale getirir: önümüzdeki 30 gün içinde inceleme tarihi olan "Tolerans Göster" olarak sınıflandırılan her uygulamayı, devre dışı bırakma tarihi atanmamış "Elimine Et" olarak sınıflandırılan her uygulamayı, teknik uygunluk puanı 30'un altında olup hala "Yatırım Yap" olarak sınıflandırılan her uygulamayı bulun. Bu sorgular, TIME modelini tek seferlik bir sınıflandırma çalışması yerine aktif bir yönetim aracı olarak tutan yönetim aracıdır.

Bir çerçeve, ancak kanıtları kadar iyidir.

TIME modelinin iki eksenli yapısı doğrudur. İş değeri ve teknik uygunluk, uygulama portföyü kararları için doğru boyutlardır. Dört eğilim doğru seçeneklerdir. Sorun çerçevede değil, kuruluşların bu çerçeveye getirdiği kanıt tabanındadır.

Görüşme verilerine ve CMDB tahminlerine dayalı sınıflandırmalar, kurumsal tartışmalara yol açar. Yapısal analize, ölçülen karmaşıklığa, doğrulanmış bağımlılık sayılarına ve koddan türetilen teknik uygunluğa dayalı sınıflandırmalar ise savunulabilir kararlar üretir. COBOL programının "Yatırım Yapılmalı" mı yoksa "Geçiş Yapılmalı" mı olduğunu savunan uygulama sahibinin durumu, yapısal analizde ortalama 35 döngüsel karmaşıklık, %40 ölü kod ve 12 güvenlik bulgusu görüldüğünde daha da zorlaşır. Bir programın "Elimine Edilmeli" olduğunu savunan BT ekibinin durumu ise, bağımlılık analizinde 45 gelen üretim bağımlılığı görüldüğünde daha da zayıflar.

TIME modeli, kanıtlar durumu desteklediğinde işe yarar. Uygulama portföyünün yapısal analizi, kuruluşların rasyonelleştirme kararlarına en çok ihtiyaç duyan ve bu kararları kolaylaştıracak belgelere sahip olma olasılığı en düşük olan eski uygulamalar için bu kanıtları oluşturma yöntemidir.