Model TIME (tolerowanie, inwestowanie, migracja, eliminacja) dla portfeli aplikacji

Spotkanie racjonalizacji aplikacji rozpoczyna się o 9:00. Do 11:00 zespół sklasyfikował dwanaście z czterystu aplikacji objętych zakresem. Trzy z tych dwunastu klasyfikacji zostały już zakwestionowane, poprawione i ponownie zakwestionowane. Program wsadowy COBOL, który obsługuje naliczanie płac, to ewidentnie nie Eliminate, ale czy to Tolerate, czy Invest? Stary system rozliczeniowy, który wszyscy uznają za technicznie niewystarczający, to ewidentnie Migrate, ale do czego migrować i co stanie się z siedemnastoma programami, które od niego zależą? Spotkanie zaplanowano do południa. W południe ktoś zasugerował kontynuację w przyszłym tygodniu. W następnym miesiącu inicjatywa po cichu przestała przynosić rezultaty.

Model TIME Gartnera to najszerzej stosowany model zarządzania portfelem aplikacji w korporacyjnym IT. Klasyfikuje on każdą aplikację w portfelu według jednej z czterech dyspozycji: Toleruj, Inwestuj, Migruj, Eliminuj, wykorzystując dwa wymiary punktacji: wartość biznesową i dopasowanie techniczne. Model jest logicznie uzasadniony, ma szerokie zastosowanie i jest cytowany w podręczniku Application Rationalization Playbook amerykańskiej federalnej rady CIO Council jako rekomendowana metodologia. W praktyce częściej zawodzi niż odnosi sukces, z powodu, który wymieniają zwolennicy modelu, ale rzadko rozwijają: klasyfikacje są tak dobre, jak dowody, które za nimi stoją. Bez dowodów strukturalnych, rzeczywistych zależności, rzeczywistych pomiarów złożoności, rzeczywistych danych o wartości biznesowej pochodzących ze śladów wykonania, a nie z wywiadów z właścicielami, klasyfikacje TIME stają się polityką organizacyjną. Argumenty o umiejscowienie zaczynają się od Migracji i Eliminacji, gdzie na szali stoi czyjaś ulubiona aplikacja, a problem nigdy nie zostaje rozwiązany.

Model: dwie osie, cztery dyspozycje

Model TIME przedstawia każdą aplikację na macierzy 2×2. Oś pozioma przedstawia dopasowanie techniczne, czyli stopień, w jakim bieżąca implementacja techniczna aplikacji wspiera jej zamierzoną funkcję: jakość architektury, łatwość utrzymania, możliwości integracji, poziom bezpieczeństwa i niezawodność operacyjną. Oś pionowa przedstawia wartość biznesową, czyli znaczenie funkcji aplikacji dla działalności biznesowej organizacji, generowania przychodów, zgodności z przepisami lub celów strategicznych.

	Wysokie dopasowanie techniczne	Niskie dopasowanie techniczne
Wysoka wartość biznesowa	ZAINWESTUJ, Sfinansuj to. Aplikacja jest zarówno strategicznie ważna, jak i technicznie solidna. Inwestuj, aby utrzymać jej pozycję lidera.	MIGROWAĆBiznes tego potrzebuje, technologia jest zła. Wymień platformę, a nie funkcję.
Niska wartość biznesowa	TOLEROWAĆZostaw to na razie w spokoju. Aplikacja działa, ale nie warto w nią inwestować.	WYELIMINOWAĆWycofaj to. Niska wartość, niska jakość, nie ma powodu, żeby to trzymać.

Prostota jest celowa. TIME nie został zaprojektowany do szczegółowego planowania inwestycji, lecz do podejmowania jednoznacznych decyzji kierunkowych dla każdego zastosowania w portfelu. Zastosowanie, którego nie można jednoznacznie umiejscowić, wymaga więcej informacji, zanim będzie możliwe dokonanie klasyfikacji.

Czterokwadrantowe modele operacyjne

Każda dyspozycja TIME nie jest jedynie etykietą, jest to model operacyjny, który określa sposób, w jaki organizacja będzie zarządzać aplikacją w przyszłości.

Inwestuj: Maksymalna ekstrakcja wartości

Aplikacje Invest to klejnoty w koronie portfela: wysoka wartość biznesowa, wysokie dopasowanie techniczne. Uzasadniają one najbardziej agresywne inwestycje w nowe funkcje, optymalizację wydajności, rozbudowę integracji i utrzymanie aktualności technicznej. Aplikacja Invest, która nie spełnia wymogów aktualności technicznej, ma przestarzałe środowisko wykonawcze, przestarzałe zabezpieczenia i narastające zadłużenie, ryzykuje przejściem do Migrate, zanim ten spadek zostanie zauważony.

Zobowiązania operacyjne dla Invest:

• Dedykowane możliwości inżynieryjne w zakresie rozwoju funkcji i konserwacji technicznej
• Priorytetowe poprawki zabezpieczeń i aktualizacje zgodności
• Relacja komisji ds. przeglądu architektury dotycząca każdej istotnej zmiany
• Proaktywny monitoring z celami SLA na poziomie Tier 1

Migracja: wymiana platformy, zachowanie funkcjonalności

Migracja aplikacji realizuje funkcję biznesową, której organizacja rzeczywiście potrzebuje, ale na platformie technicznej, która nie jest już wystarczająca, zbyt kosztowna w utrzymaniu, zbyt krucha w rozbudowie i zbyt odizolowana od nowoczesnego środowiska integracyjnego. Wartość biznesowa uzasadnia inwestycję w migrację; stan techniczny sprawia, że ​​dalsze inwestowanie w obecną platformę przynosi marne zyski.

Dyspozycja migracji odpowiada na konkretne pytanie: czy funkcja jest warta zachowania? Jeśli tak, należy przeprowadzić migrację. To, do czego i w jaki sposób przeprowadzić migrację, to osobna decyzja, której klasyfikacja TIME nie podejmuje, a jedynie stwierdza, że ​​obecna platforma nie jest rozwiązaniem.

Najczęstszy scenariusz migracji w starszych środowiskach: program wsadowy COBOL implementujący krytyczną logikę biznesową, złożone obliczenia regulacyjne, zastrzeżone reguły cenowe, logikę podatkową właściwą dla danej jurysdykcji, na platformie, której rozbudowa, testowanie i integracja są kosztowne. Logika jest niezastąpiona; problemem jest platforma. Migracja na nowoczesną platformę, która zachowuje logikę, zapewniając jednocześnie parametry operacyjne wymagane obecnie przez firmę.

Tolerować: celowe zaniechanie z datą ważności

Tolerancja to najbardziej niezrozumiany kwadrant. Nie oznacza on „ta aplikacja jest w porządku”. Oznacza on „jakość techniczna tej aplikacji nie uzasadnia inwestycji w jej natychmiastową zmianę, a jej wartość biznesowa nie uzasadnia jej eliminacji”. To świadomy wybór, aby zaakceptować status quo przez określony czas, a nie odroczenie na czas nieokreślony.

Tolerowanie to stan wstrzymania czasowego, a nie stan permanentny. Każda aplikacja w kwadrancie „Tolerowanie” powinna mieć jasno określoną datę przeglądu, zazwyczaj 12–18 miesięcy, oraz zdefiniowane warunki, które spowodują wczesną reklasyfikację: lukę w zabezpieczeniach, której nie można naprawić, wycofanie zależności wymuszające zmianę platformy, wzrost wartości biznesowej, który sprawia, że ​​warto inwestować w aplikację, lub zmianę funkcji biznesowej, która eliminuje jej cel.

Organizacje, które traktują Tolerate jako coś trwałego, gromadzą dokładnie tyle długu technicznego, ile model TIME miał zapobiegać. Program w COBOL-u, który został oznaczony jako Tolerate w 2019 roku i nadal znajduje się w kwadrancie Tolerate w 2026 roku, otrzymał siedem dodatkowych lat odroczonej konserwacji, którą ostatecznie będzie musiał otrzymać – albo w trybie awaryjnym, gdy coś się zepsuje, albo w ramach wymuszonej migracji, gdy platforma nie będzie już obsługiwana.

Wyeliminuj: Decyzja, którą każdy podejmuje, a nikt jej nie wykonuje

Eliminacja to najprostsza klasyfikacja i najrzadziej wykonywana procedura. Aplikacja ma niską wartość biznesową i słabe dopasowanie techniczne, nie ma więc powodu, aby ją zatrzymać. Wycofaj ją.

Niepowodzenie w realizacji jest dobrze udokumentowane: program Eliminate jest entuzjastycznie obsadzany, a jego realizacja prawie nigdy nie jest podejmowana. Przegląd portfela w dużej instytucji finansowej przeprowadzony w 2024 roku ujawnił 87 kandydatów do programu Eliminate. Osiemnaście miesięcy później 71 z nich nadal było w programie. Luka między klasyfikacją a wycofaniem z programu to miejsce, w którym programy racjonalizacji tracą impet.

Istnieją trzy konkretne przeszkody uniemożliwiające wykonanie Eliminacji:

Ukryte zależności. Aplikacja została sklasyfikowana jako Eliminate na podstawie jej pozornego statusu autonomicznego. Po klasyfikacji, analiza strukturalna ujawnia, że ​​dwanaście innych programów generuje dane wyjściowe, które kandydat do Eliminate przetwarza, lub że trzy systemy zewnętrzne przesyłają do niej dane za pośrednictwem nieudokumentowanego interfejsu plików. Aplikacja nie jest autonomiczna; stanowi ukrytą infrastrukturę dla innych systemów. Klasyfikacja musi zostać ponownie przeanalizowana.

Blokady migracji danych. Aplikacja przechowuje dane, których nie można zniszczyć, rejestry regulacyjne z obowiązkowymi okresami przechowywania, dane klientów, które muszą zostać przeniesione do systemu następczego, historyczne rejestry transakcji, które audytują zapytania przetwarzane corocznie. Migracja danych musi poprzedzać wycofanie z eksploatacji, a migracja danych jest kosztowna.

Obowiązki regulacyjne. Niektórych aplikacji nie można wycofać z użytku, nawet jeśli ich wartość biznesowa wynosi zero, ponieważ ramy regulacyjne wymagają funkcji, które oferują. Aplikacja raportująca, która generuje kwartalne dane regulacyjne, ma wartość regulacyjną, która nie pojawia się w żadnym badaniu wartości biznesowej. Dopóki obowiązek regulacyjny nie zostanie przeniesiony do innego systemu, aplikacja musi działać.

Problem dowodów: dlaczego TIME zawodzi bez danych strukturalnych

Najistotniejszy tryb awarii we wdrożeniach TIME jest dokładnie zidentyfikowany w dokumentacji Catio: argumenty dotyczące umiejscowienia zaczynają się od opcji Migrate i Eliminate, gdzie stawką jest czyjaś ulubiona aplikacja. Bez obiektywnych dowodów każda klasyfikacja jest negocjacją. Właściciel aplikacji argumentuje za Invest. Zespół IT argumentuje za Migrate. Zespół finansowy chce Eliminate. Spotkanie kończy się opcją Tolerate, ponieważ jest to najmniej kontrowersyjne stanowisko.

Dowody strukturalne rozwiązują te negocjacje poprzez zastąpienie opinii pomiarami.

W przypadku oceny zgodności technicznej istotne są następujące dowody:

Wskaźnik dopasowania technicznego	Źródło	Przesuwa klasyfikację w kierunku
Złożoność cyklomatyczna na program (średnia)	Statyczna analiza kodu	Niskie = lepsze dopasowanie, Wysokie = gorsze dopasowanie
Procent martwego kodu	Analiza osiągalności	Wysoki kod martwy = niższe dopasowanie
Fan-in (liczba zależności przychodzących)	Mapowanie zależności	Wysokie zwiększenie liczby fanów zwiększa tolerancję w stosunku do eliminacji
Szerokość dzielenia się zeszytami	Analiza zależności COPY	Wysoki poziom współdzielenia = wyższe sprzężenie = niższe dopasowanie
Czas od ostatniej znaczącej zmiany	Dziennik Git/zarządzania zmianami	Długi okres uśpienia może wskazywać na martwy kod lub jego stabilność
Liczba luk w zabezpieczeniach	Skanowanie SAST	Wysoka liczba = niższe dopasowanie

W przypadku oceny wartości biznesowej liczą się następujące dowody:

Wskaźnik wartości biznesowej	Źródło	Przesuwa klasyfikację w kierunku
Wolumen transakcji w danym okresie	Rejestry wykonania JCL, rekordy harmonogramu	Duża objętość = większa wartość
Wentylator downstream	Mapowanie zależności	Wysokie rozproszenie = wyższa wartość (wiele osób od tego zależy)
Flaga funkcji regulacyjnej	Klasyfikacja danych, rejestr zgodności	Obecny = minimalna wartość dolna bez względu na inne wyniki
Sąsiedztwo przychodów	Analiza przepływu danych do systemów rozliczeniowych/przychodowych	Bezpośrednie sąsiedztwo = wyższa wartość
Liczba użytkowników lub liczba wywołań API	Rejestry dostępu, ruch sieciowy	Wysoka liczba = wyższa wartość

Kluczowa informacja: w przypadku starszych systemów COBOL większość tych wskaźników nie jest dostępna w bazach danych CMDB, wywiadach z właścicielami aplikacji ani analizie ruchu sieciowego. Są one dostępne w analizie strukturalnej kodu źródłowego, dziennikach wykonania oraz harmonogramie zadań JCL, który dokumentuje, co i kiedy jest faktycznie uruchamiane w środowisku produkcyjnym.

Ocena dopasowania technicznego dla systemów COBOL i starszych wersji

Standardowe kryteria oceny zgodności technicznej, kompatybilność z API, gotowość do pracy w chmurze, obsługa konteneryzacji i architektura mikrousług nie mają znaczenia dla programów wsadowych COBOL. Programu COBOL nie da się skonteneryzować; ocena pod kątem kryteriów natywnych dla chmury daje zerowy wynik zgodności technicznej dla każdego starszego programu, co nie wnosi nic wartościowego do organizacji.

W przypadku systemów COBOL i komputerów mainframe, wynik dopasowania technicznego wymaga spełnienia kryteriów specyficznych dla języka COBOL:

Wskaźnik złożoności (waga: 30%): Średnia złożoność cyklomatyczna w akapitach i sekcjach programu. Programy ze średnią złożonością poniżej 10 charakteryzują się łatwą do opanowania złożonością; programy powyżej 20 charakteryzują się złożonością strukturalną, która sprawia, że ​​utrzymanie jest kosztowne i ryzykowne.

Wskaźnik utrzymywalności (waga: 25%): Złożony z odsetka martwego kodu, szerokości współdzielonych kopii i wskaźnika duplikacji. Program z 40% martwego kodu, 15 współdzielonymi kopiami i znaczną duplikacją kodu ma niską utrzymywalność, niezależnie od jego poprawności funkcjonalnej.

Wynik ryzyka zależności (waga: 20%): Liczba połączeń przychodzących ważona krytycznością połączeń przychodzących. Program z 50 połączeniami przychodzącymi z programów poziomu 1 charakteryzuje się wysokim ryzykiem zależności, a zmiany w nim wymagają koordynacji 50 programów podrzędnych.

Ocena aktualności (waga: 15%): aktualność dialektu COBOL i wersji kompilatora, nowoczesność składni JCL oraz interfejs bazy danych (zaawansowany wbudowany SQL, VSAM vs. DB2, tylko wsadowy vs. wsadowy + CICS). Programy napisane w składni COBOL-85 z wbudowanym SQL DB2 są bardziej aktualne niż programy napisane w COBOL-74 z dostępem do plików tylko za pomocą VSAM.

Wynik oceny bezpieczeństwa (waga: 10%): obecność zakodowanych na stałe danych uwierzytelniających, niezabezpieczony dostęp do plików, brak sprawdzania STATUSU PLIKU oraz narażenie na atak typu SQL injection podczas dynamicznej konstrukcji kodu 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.

Ten wzór punktacji generuje wynik dopasowania technicznego w skali 0–100, wywodzący się z analizy strukturalnej kodu, a nie z oceny jakościowej. Dwie aplikacje o identycznych funkcjach, ale o różnych cechach strukturalnych, uzyskają różne wyniki dopasowania technicznego, które dokładnie odzwierciedlają różnice w nakładach inwestycyjnych wymaganych do utrzymania i rozwoju każdej z nich.

Problem tolerancji dryfu: zarządzanie kwadrantem holdingowym

Tolerowanie to kwadrant, który akumuluje dług w czasie w każdej organizacji, która korzysta z TIME bez wyraźnego zarządzania Tolerowaniem. Mechanizm jest prosty: aplikacja przechodzi do Tolerowania, ponieważ nie warto jej zmieniać, a następnie pozostaje w Tolerowaniu na czas nieokreślony, ponieważ jej zmiana nigdy nie jest najpilniejszym priorytetem.

Dyscyplina zarządzania oparta na tolerancji zapobiega nieograniczonemu odraczaniu:

Wyzwalacze reklasyfikacji oparte na stanie:

• Zidentyfikowano lukę w zabezpieczeniach, której nie można naprawić w ciągu 30 dni → przejrzyj pod kątem migracji lub eliminacji
• Dostawca ogłasza koniec cyklu życia komponentu platformy, od którego zależy aplikacja → przegląd pod kątem migracji
• Wartość biznesowa wyniku wzrasta powyżej progu (nowy wymóg regulacyjny, zmiana modelu biznesowego) → sprawdź pod kątem inwestycji lub migracji
• Wycofanie zależności wymusza zmianę interfejsu → przegląd pod kątem migracji lub eliminacji
• Analiza martwego kodu ujawnia, że ​​aplikacja jest w zasadzie nieaktywna → przejrzyj w celu wyeliminowania

Rytm przeglądu oparty na czasie:

• Aplikacje są przyjmowane w ramach procedury Tolerate z datą rozpatrzenia wynoszącą 12 miesięcy
• Podczas przeglądu po 12 miesiącach wniosek jest wyraźnie ponownie klasyfikowany lub wyraźnie ponownie tolerowany z nową datą 12 miesięcy
• Ponowna tolerancja wymaga pisemnego uzasadnienia dokumentującego, dlaczego warunki nie uległy zmianie
• Wniosek, który został ponownie tolerowany więcej niż dwa razy bez ponownej klasyfikacji, powoduje eskalację do komisji ds. przeglądu architektury

Rejestr Tolerate: Utrzymywana lista wszystkich aplikacji Tolerate wraz z datą klasyfikacji, datą przeglądu, właścicielem oraz zestawem warunków, które powodują reklasyfikację. Rejestr ten jest przeglądany na każdym posiedzeniu rady ds. przeglądu architektury, a nie tylko podczas corocznego przeglądu portfolio.

Uczynienie eliminacji wykonalną: likwidacja luki w wycofaniu z eksploatacji

Różnica między „zaklasyfikowaniem jako Eliminowane” a „pomyślnie wycofane z eksploatacji” to miejsce, w którym programy racjonalizacji utknęły w martwym punkcie. Aby ją zniwelować, należy traktować każdą decyzję o Eliminowaniu jako projekt o zdefiniowanym zakresie, zależnościach i kryteriach sukcesu, a nie jako wniosek.

Lista kontrolna wykonania Eliminacji:

• Weryfikacja zależności zakończona: Analiza statyczna potwierdza brak zależności produkcyjnych (nie tylko brak udokumentowanych zależności, lecz brak strukturalnie zweryfikowanych zależności)
• Zatwierdzono plan usunięcia danych: Zidentyfikowano wymogi dotyczące przechowywania danych, zatwierdzono plan migracji danych lub archiwizacji przez organ prawny i ds. zgodności
• Zakończono powiadamianie downstream: Właściciel każdego systemu odbiorczego został powiadomiony i potwierdził brak aktywnej zależności
• Kontrola obowiązku regulacyjnego zakończona: Aplikacja nie wymaga żadnych aktywnych zgłoszeń regulacyjnych, audytów ani wymogów zgodności
• Przypisany właściciel wycofania ze służby: Wskazana osoba odpowiedzialna za przeprowadzenie likwidacji, a nie tylko za decyzję o klasyfikacji
• Zdefiniowano plan wycofania: Procedura przywracania usługi w przypadku, gdy wycofanie z eksploatacji ujawni nieodkrytą zależność
• Zatwierdzona data wycofania z eksploatacji: Konkretna data w kalendarzu IT, a nie „kiedy się za to zabierzemy”

Bramka analizy strukturalnej: Decyzja o eliminacji przechodzi do planowania wycofania z eksploatacji, dopóki analiza strukturalna nie potwierdzi braku zależności przychodzących ze ścieżek wykonania produkcyjnego. Najczęstszą przyczyną niepowodzenia wykonania eliminacji jest odkrycie zależności po ogłoszeniu wycofania z eksploatacji, która wymusza wycofanie. Analiza zależności strukturalnych przed ogłoszeniem zapobiega temu.

Cykl ponownej oceny TIME

Klasyfikacje TIME nie są trwałe. Wartość biznesowa zmienia się wraz z ewolucją strategii organizacji. Dopasowanie techniczne zmienia się wraz z konserwacją, rozbudową lub starzeniem się aplikacji. Model jest migawką; portfolio wymaga dynamicznego obrazu.

Coroczna pełna ponowna ocena: Każda aplikacja w portfolio jest oceniana pod kątem aktualnej wartości biznesowej i kryteriów dopasowania technicznego. Klasyfikacje, które nie zmieniły się przez trzy kolejne lata, są szczegółowo badane – albo aplikacja jest rzeczywiście stabilna (należy udokumentować przyczynę), albo ocena nie uwzględnia zachodzących zmian.

Ponowna ocena wywołana zdarzeniem: Konkretne zdarzenia powodują natychmiastową kontrolę ponownej klasyfikacji:

• Fuzja lub przejęcie (nowe połączenie portfela)
• Zmiana przepisów mająca wpływ na obowiązki zgodności
• Ogłoszenie o zakończeniu cyklu życia głównej platformy (baza danych, system operacyjny, środowisko wykonawcze)
• Istotna zmiana modelu biznesowego (nowa linia produktów, wyjście z rynku, restrukturyzacja organizacyjna)
• Incydent bezpieczeństwa dotyczący aplikacji

Dyscyplina dziennika zmian: Każda reklasyfikacja jest rejestrowana z uwzględnieniem: poprzedniej klasyfikacji, nowej klasyfikacji, daty, dowodów, które spowodowały zmianę, oraz osoby zatwierdzającej. Historia klasyfikacji każdego wniosku stanowi ślad audytu, który pokazuje, że portfel jest aktywnie zarządzany, a nie kategoryzowany i zapomniany.

W jaki sposób SMART TS XL Dostarcza dowodów na klasyfikację TIME

Decyzje klasyfikacyjne modelu TIME są tak dobre, jak dowody, które za nimi stoją. W przypadku nowoczesnych aplikacji z pokryciem CMDB, monitorowaniem API i udokumentowaną architekturą, dowody te są dostępne. W przypadku starszych portfeli COBOL, w których CMDB jest niekompletne, właściciele przeszli na emeryturę, a struktura zależności jest nieudokumentowana, dowody muszą pochodzić z analizy strukturalnej samego kodu.

SMART TS XL'S statyczna analiza kodu generuje techniczne dane wejściowe wymagane przez COBOL scoring: złożoność cyklomatyczną dla każdego programu, odsetek martwego kodu, wyniki dotyczące wzorców bezpieczeństwa (zakodowane na stałe dane uwierzytelniające, niezabezpieczony dostęp do plików) oraz aktualność dialektu COBOL. Te wskaźniki pochodzą z kodu źródłowego, a nie z szacunków programistów, i nie zależą od tego, czy ktokolwiek pamięta, co robi aplikacja.

Mapowanie zależności aplikacji generuje liczbę połączeń przychodzących, które zapobiegają przedwczesnym decyzjom o eliminacji, oraz liczbę połączeń wychodzących, które wspierają punktację wartości biznesowej. Aplikacja z 45 zależnościami przychodzącymi z programów produkcyjnych nie jest bezpiecznym kandydatem do eliminacji, niezależnie od tego, jak jej właściciel ocenia jej wartość biznesową. Liczba zależności to fakt strukturalny, który ma pierwszeństwo przed argumentem klasyfikacji.

Analiza modernizacji starszych wersji generuje inwentaryzację martwego kodu, która zmienia klasyfikacje: programy, które pojawiają się w bazie CMDB jako aktywne aplikacje, ale nie mają żadnych zależności produkcyjnych, są kandydatami na martwy kod, przeklasyfikowanymi z kategorii Tolerowane na Eliminowane na podstawie dowodów strukturalnych, a nie oceny właściciela firmy dotyczącej programu, o którego istnieniu mógł on nigdy nie wiedzieć.

Możliwość analizy wpływu umożliwia realizację listy kontrolnej wykonania Eliminacji: analizy strukturalnej, która potwierdza brak zależności produkcyjnych przed rozpoczęciem planowania wycofania z eksploatacji. To brama, która zapobiega najczęstszemu błędowi wykonania Eliminacji, czyli nieodkrytej zależności, która pojawia się po ogłoszeniu.

Funkcja wyszukiwania w przedsiębiorstwie umożliwia wyszukiwanie w procesie klasyfikacji TIME w całym cyklu ponownej oceny: znajdź każdą aplikację sklasyfikowaną jako „Tolerowane” z datą przeglądu w ciągu najbliższych 30 dni, każdą aplikację sklasyfikowaną jako „Eliminowane” bez przypisanej daty wycofania z eksploatacji, każdą aplikację z wynikiem dopasowania technicznego poniżej 30, która nadal jest sklasyfikowana jako „Inwestowane”. Te zapytania stanowią narzędzie zarządzania, dzięki któremu model TIME jest aktywnym narzędziem zarządzania, a nie jednorazowym ćwiczeniem klasyfikacyjnym.

Struktura jest tak dobra, jak dowody na niej oparte

Dwuosiowa struktura modelu TIME jest poprawna. Wartość biznesowa i dopasowanie techniczne to właściwe wymiary dla decyzji dotyczących portfolio aplikacji. Cztery dyspozycje to właściwe opcje. Problemem nie jest struktura, lecz baza dowodowa, którą organizacje do niej wnoszą.

Klasyfikacje oparte na danych z wywiadów i szacunkach CMDB wywołują debaty w organizacji. Klasyfikacje oparte na analizie strukturalnej, zmierzonej złożoności, zweryfikowanej liczbie zależności i sprawności technicznej pochodzącej z kodu prowadzą do decyzji, które można obronić. Właściciel aplikacji, który twierdzi, że jego program COBOL wymaga inwestycji, a nie migracji, ma trudniejsze zadanie, gdy analiza strukturalna wykazuje średnią złożoność cyklomatyczną na poziomie 35, 40% martwego kodu i 12 ustaleń dotyczących bezpieczeństwa. Zespół IT, który twierdzi, że program można wyeliminować, ma słabsze zadanie, gdy analiza zależności wskazuje 45 przychodzących zależności produkcyjnych.

Model TIME działa, gdy dowody potwierdzają tę tezę. Analiza strukturalna portfolio aplikacji to sposób, w jaki organizacje budują dowody dla starszych aplikacji, które najczęściej wymagają racjonalizacji decyzji i najprawdopodobniej nie posiadają dokumentacji ułatwiającej podejmowanie takich decyzji.