Model TIME (Tolerovat, Investovat, Migrovat, Eliminovat) pro portfolia aplikací

Schůzka k racionalizaci aplikací začíná v 9 hodin ráno. Do 11 hodin tým klasifikoval dvanáct ze čtyř set aplikací v rozsahu. Tři z těchto dvanácti klasifikací již byly napadeny, revidovány a znovu napadeny. Dávkový program v COBOLu, který spouští mzdovou agendu, zjevně není Eliminovat, ale je to Tolerovat nebo Investovat? Starší fakturační systém, na kterém se všichni shodují, že je technicky nedostatečný, je zjevně Migrovat, ale na co migrovat a co se stane se sedmnácti programy, které na něm závisí? Schůzka je naplánována do poledne. V poledne někdo navrhne pokračovat příští týden. Do následujícího měsíce iniciativa tiše přestala produkovat výstupy.

Model Gartner TIME je nejrozšířenějším rámcem pro správu portfolia aplikací v podnikových IT. Třídí každou aplikaci v portfoliu do jedné ze čtyř dispozic: Tolerovat, Investovat, Migrovat, Eliminovat, a to pomocí dvou bodovacích dimenzí: obchodní hodnoty a technické shody. Rámec je logicky správný, široce použitelný a v publikaci Application Rationalization Playbook americké federální Rady pro informační a komunikační technologie (CIO Council) jej uvádí jako doporučenou metodologii. V praxi také selhává častěji než se mu daří, a to z důvodu, který zastánci rámce zmiňují, ale jen zřídka rozvádějí: klasifikace jsou jen tak dobré, jako důkazy, které za nimi stojí. Bez strukturálních důkazů, skutečného počtu závislostí, skutečného měření složitosti, skutečných dat o obchodní hodnotě odvozených ze stop provádění, nikoli z rozhovorů s vlastníky, se klasifikace TIME stávají organizační politikou. Hádky o umístění začínají u migrace a eliminace, kde je v sázce něčí oblíbená aplikace, a nikdy se nevyřeší.

Model: Dvě osy, čtyři dispozice

Model TIME znázorňuje každou aplikaci v matici 2×2. Vodorovná osa představuje technickou vhodnost, tj. jak dobře aktuální technická implementace aplikace podporuje její zamýšlenou funkci: kvalitu architektury, udržovatelnost, integrační schopnosti, bezpečnostní stav, provozní spolehlivost. Svislá osa představuje obchodní hodnotu, tj. jak důležitá je funkce aplikace pro obchodní operace organizace, generování příjmů, dodržování předpisů nebo strategické cíle.

	Vysoká technická přizpůsobivost	Nízká technická zdatnost
Vysoká obchodní hodnota	INVESTOVAT, Financujte to. Aplikace je strategicky důležitá i technicky zdatná. Investujte, abyste si udrželi vedoucí postavení.	MIGROVATPodnikání to potřebuje, technologie je špatná. Vyměňte platformu, ne funkci.
Nízká obchodní hodnota	TOLEROVAT, Prozatím to nechte být. Aplikace je v pořádku, ale nestojí za další investice.	ODSTRANITVyřaďte to. Nízká hodnota, nízká kvalita, není důvod si to ponechat.

Jednoduchost je záměrná. TIME není navržen tak, aby vytvářel podrobné investiční plánování, ale aby vytvářel jednoznačná směrová rozhodnutí pro každou aplikaci v portfoliu. Aplikace, kterou nelze jasně zařadit, je aplikace, která vyžaduje více informací, než je možné ji klasifikovat.

Operační modely čtyř kvadrantů

Každá dispozice TIME není jen označení, je to operační model, který určuje, jak bude organizace spravovat aplikaci v budoucnu.

Invest: Maximální extrakci hodnoty

Aplikace Invest jsou klenoty portfolia: vysoká obchodní hodnota a vysoká technická shoda. Ospravedlňují ty nejagresivnější investice do nových funkcí, optimalizace výkonu, rozšíření integrace a údržby technické aktuálnosti. Aplikace Invest, která zaostává ve své technické aktuálnosti, má stárnoucí běhové prostředí, zastaralé bezpečnostní prostředí a hromadící se dluh ze závislostí, riskuje, že sklouzne do režimu Migrate dříve, než si toho člověk všimne.

Provozní závazky společnosti Invest:

• Vyhrazená technická kapacita pro vývoj funkcí a technickou údržbu
• Aktualizace zabezpečení a dodržování předpisů s nejvyšší prioritou
• Zprávy z revizní komise pro architekturu o každé významné změně
• Proaktivní monitorování s cíli SLA na úrovni Tier 1

Migrace: Vyměňte platformu, zachovávejte funkčnost

Migrace aplikací plní obchodní funkci, kterou organizace skutečně potřebuje, ale na technické platformě, která již není dostačující, její údržba je příliš drahá, její rozšíření je příliš křehké a aplikace je příliš izolovaná od moderního integračního prostředí. Obchodní hodnota investice do migrace ospravedlňuje; technický stav však činí pokračující investice do stávající platformy chabou návratností.

Dispozice Migrate odpovídá na konkrétní otázku: má smysl funkci zachovat? Pokud ano, migrujte. Na co migrovat a jak, je samostatné rozhodnutí, které klasifikace TIME nedělá, pouze stanoví, že aktuální platforma není odpovědí.

Nejběžnější scénář migrace ve starších prostředích: Dávkový program v COBOLu, který implementuje kritickou obchodní logiku, složité regulační výpočty, proprietární pravidla pro tvorbu cen, daňovou logiku specifickou pro danou jurisdikci, na platformě, jejíž rozšiřování, testování a integrace jsou nákladné. Logika je nenahraditelná; platforma je problém. Migrujte na moderní platformu, která zachovává logiku a zároveň poskytuje provozní vlastnosti, které podnik nyní vyžaduje.

Tolerovat: Úmyslnou nečinnost s datem vypršení platnosti

Tolerance je nejvíce nepochopený kvadrant. Neznamená to, že „tato aplikace je v pořádku“. Znamená to, že „technická kvalita této aplikace neodůvodňuje investici do její změny hned teď a její obchodní hodnota neodůvodňuje její odstranění“. Je to vědomá volba akceptovat status quo po stanovenou dobu, nikoli na dobu neurčitou.

Tolerace je časově omezený stav, nikoli trvalý. Každá aplikace v kvadrantu Tolerace by měla mít explicitní datum kontroly, obvykle 12 až 18 měsíců, a definované podmínky, které by spustily předčasnou reklasifikaci: bezpečnostní zranitelnost, kterou nelze opravit, vyřazení závislosti, které vynutí změnu platformy, zvýšení obchodní hodnoty, které činí aplikaci hodnotnou investicí, nebo změnu obchodní funkce, která eliminuje její účel.

Organizace, které považují Tolerate za trvalý program, hromadí přesně ten technický dluh, kterému měl model TIME předcházet. Program v COBOLu, který byl v roce 2019 označen jako Tolerate a který se v roce 2026 stále nachází v kvadrantu Tolerate, obdržel dalších sedm let odložené údržby, kterou bude nakonec potřebovat, ať už v nouzovém případě, když se něco porouchá, nebo v rámci nucené migrace, když platforma již nemůže být podporována.

Eliminovat: Rozhodnutí, které dělá každý a nikdo ho neprovádí

Eliminace je nejpřímější klasifikace a nejméně prováděné řešení. Aplikace má nízkou obchodní hodnotu a nízkou technickou způsobilost, není důvod ji ponechat. Vyřaďte ji.

Selhání realizace je dobře zdokumentováno: Kandidáti na Eliminace jsou obsazováni s nadšením a téměř nikdy se na ně nekonalo. Revize portfolia v roce 2024 ve velké finanční instituci přinesla 87 kandidátů na Eliminaci. O osmnáct měsíců později jich 71 stále běželo. Právě mezera mezi klasifikací a vyřazením z provozu je místem, kde racionalizační programy ztrácejí svou dynamiku.

Tři specifické překážky brání provedení Eliminace:

Skryté závislosti. Aplikace byla klasifikována jako Eliminate na základě svého zdánlivého samostatného statusu. Po klasifikaci strukturální analýza odhalila, že dvanáct dalších programů produkuje výstup, který kandidát na Eliminate zpracovává, nebo že tři externí systémy do ní odesílají data prostřednictvím nedokumentovaného rozhraní souborů. Aplikace není samostatná; je to skrytá infrastruktura pro jiné systémy. Klasifikaci je třeba přehodnotit.

Blokátory migrace dat. Aplikace uchovává data, která nelze zničit, regulační záznamy s povinnými dobami uchovávání, zákaznická data, která musí být přenesena do nástupnického systému, a historické záznamy o transakcích, které auditní procesy každoročně dotazují. Migrace dat musí předcházet vyřazení z provozu a migrace dat je nákladná.

Regulační povinnosti. Některé aplikace nelze vyřadit z provozu, i když je jejich obchodní hodnota nulová, protože regulační rámce vyžadují funkce, které poskytují. Aplikace pro vykazování, která vytváří čtvrtletní regulační podání, má regulační hodnotu, která se neobjevuje v žádném průzkumu obchodní hodnoty. Dokud není regulační povinnost převedena do jiného systému, musí aplikace běžet.

Problém s důkazy: Proč TIME selhává bez strukturálních dat

Nejvýznamnějším způsobem selhání v implementacích TIME je to, co dokumentace společnosti Catio přesně identifikuje: hádky o umístění začínají u migrace a eliminace, kde je v sázce něčí oblíbená aplikace. Bez objektivních důkazů je každá klasifikace vyjednáváním. Vlastník aplikace argumentuje pro investice. IT tým argumentuje pro migraci. Finanční tým chce eliminaci. Schůzka končí u Tolerace, protože je to nejméně sporná pozice.

Strukturální důkazy řeší tato jednání nahrazením názoru měřením.

Pro hodnocení technické shody jsou důležité tyto důkazy:

Indikátor technické způsobilosti	Zdroj	Posouvá klasifikaci směrem k
Cyklomatická složitost na program (průměr)	Statická analýza kódu	Nízká = vyšší pas, Vysoká = nižší pas
Procento mrtvého kódu	Analýza dosažitelnosti	Vysoký počet nefunkčních kódů = nižší shoda
Počet závislostí (Fan-in)	Mapování závislostí	Vysoké přivádění ventilátoru zvyšuje toleranci nad eliminaci
Šířka sdílení sešitů	Analýza závislostí COPY	Vysoké sdílení = vyšší vazba = nižší shoda
Doba od poslední smysluplné změny	Protokol správy Gitu/změn	Dlouhá dormance může naznačovat mrtvý kód nebo stabilitu
Počet bezpečnostních zranitelností	SAST sken	Vysoký počet = nižší uchycení

Pro hodnocení obchodní hodnoty jsou důležité tyto důkazy:

Ukazatel obchodní hodnoty	Zdroj	Posouvá klasifikaci směrem k
Objem transakcí za období	Záznamy spuštění JCL, záznamy plánovače	Vyšší objem = vyšší hodnota
Rozdělení po proudu	Mapování závislostí	Vysoký rozptyl = vyšší hodnota (mnoho na tom závisí)
Příznak regulační funkce	Klasifikace dat, registr shody	Současnost = minimální hodnota bez ohledu na ostatní skóre
Sousedství příjmů	Analýza datového toku do fakturačních/příjmových systémů	Přímá sousednost = vyšší hodnota
Počet uživatelů nebo počet volání API	Přístupové protokoly, síťový provoz	Vysoký počet = vyšší hodnota

Důležitý poznatek: u starších systémů COBOL není většina těchto indikátorů k dispozici ze záznamů v CMDB, rozhovorů s vlastníky aplikací ani z analýzy síťového provozu. Jsou k dispozici ze strukturální analýzy zdrojového kódu, protokolů provádění a harmonogramu úloh JCL, který dokumentuje, co a kdy se ve skutečnosti spouští v produkčním prostředí.

Hodnocení technické shody pro COBOL a starší systémy

Standardní kritéria pro hodnocení technické shody, kompatibilita s API, připravenost pro cloudové nativní prostředí, podpora kontejnerizace a architektura mikroslužeb jsou pro dávkové programy v COBOLu irelevantní. Program v COBOLu nelze kontejnerizovat; jeho porovnání s kritérii pro cloudové nativní prostředí vede k nulovému skóre technické shody pro každý starší program, což organizaci neříká nic užitečného.

Pro systémy COBOL a mainframe vyžaduje skóre technické shody kritéria specifická pro COBOL:

Skóre složitosti (váha: 30 %): Průměrná cyklomatická složitost napříč odstavci a sekcemi programu. Programy s průměrnou CC pod 10 mají zvládnutelnou složitost; programy nad 20 mají strukturální složitost, která činí údržbu drahou a riskantní.

Skóre udržovatelnosti (váha: 25 %): Složení procenta mrtvého kódu, šíře sdílení sešitů a míry duplikace. Program se 40 % mrtvého kódu, 15 sdílenými sešity a významnou duplikací kódu má nízkou udržovatelnost bez ohledu na svou funkční správnost.

Skóre rizika závislostí (váha: 20 %): Počet vstupů vážený kritičností příchozích závislých programů. Program s 50 příchozími závislostmi z programů 1. úrovně má vysoké riziko závislosti, změny v něm vyžadují koordinaci 50 navazujících programů.

Skóre měn (váha: 15 %): aktuálnost dialektu a verze kompilátoru COBOL, modernita syntaxe JCL a databázové rozhraní (starší verze vestavěného SQL, VSAM vs. DB2, pouze dávkové vs. dávkové+CICS). Programy napsané v syntaxi COBOL-85 s vestavěným SQL z DB2 jsou aktuálnější než programy napsané v COBOL-74 s přístupem k souborům pouze přes VSAM.

Skóre bezpečnostního stavu (váha: 10 %): Přítomnost pevně zakódovaných přihlašovacích údajů, nechráněný přístup k souborům, absence kontroly STAVU SOUBORU a vystavení SQL injection v dynamické konstrukci 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.

Tento vzorec pro hodnocení vytváří skóre technické shody na stupnici 0–100, které je odvozeno z analýzy konstrukčních předpisů, nikoli z kvalitativního posouzení. Dvě aplikace se stejnými funkcemi, ale různými konstrukčními charakteristikami, povedou k různým skóre technické shody a tato skóre budou přesně odrážet různé investice potřebné k údržbě a rozšíření každé z nich.

Problém tolerování driftu: Správa a řízení pro holdingový kvadrant

Tolerance je kvadrant, který v průběhu času hromadí dluh v každé organizaci, která používá TIME bez explicitního řízení Tolerance. Mechanismus je jednoduchý: aplikace se dostane do stavu Tolerate, protože se nevyplatí ji měnit, a poté v něm zůstane na dobu neurčitou, protože její změna nikdy není nejnaléhavější prioritou.

Disciplína v oblasti správy a řízení Tolerate zabraňuje neomezenému odkladu:

Spouštěče reklasifikace založené na podmínkách:

• Identifikována bezpečnostní zranitelnost, kterou nelze opravit do 30 dnů → kontrola pro migraci nebo odstranění
• Dodavatel oznamuje ukončení podpory komponenty platformy, na které je aplikace závislá → kontrola pro migraci
• Hodnotové skóre firmy se zvyšuje nad prahovou hodnotu (nový regulační požadavek, změna obchodního modelu) → přezkoumání pro investici nebo migraci
• Změna rozhraní pro vyřazení závislostí z provozu → kontrola migrace nebo eliminace
• Analýza mrtvého kódu odhaluje, že aplikace je fakticky neaktivní → recenze pro Eliminate

Kadence přezkoumání založená na čase:

• Žádosti vstupují do systému Tolerate s 12měsíčním datem kontroly
• Při 12měsíčním přezkoumání je žádost explicitně překlasifikována nebo explicitně přetolerována s novým 12měsíčním datem.
• Opakovaná tolerance vyžaduje písemné zdůvodnění, které dokumentuje, proč se podmínky nezměnily.
• Aplikace, která byla více než dvakrát znovu tolerována bez reklasifikace, spouští eskalaci k komisi pro kontrolu architektury.

Registr Tolerate: Udržovaný seznam všech aplikací Tolerate s datem klasifikace, datem kontroly, vlastníkem a nastavenou podmínkou, která by spustila reklasifikaci. Tento registr je kontrolován na každém zasedání komise pro revizi architektury, nejen při výroční revizi portfolia.

Jak vytvořit spustitelný soubor Eliminate: Jak překlenout mezeru mezi vyřazováním z provozu

Rozdíl mezi „klasifikováno jako vyřazeno“ a „úspěšně vyřazeno z provozu“ je místem, kde se racionalizační programy zastavují. Překlenutí této mezery vyžaduje, aby se s každým rozhodnutím o vyřazení zacházelo jako s projektem s definovaným rozsahem, závislostmi a kritérii úspěšnosti, nikoli jako se závěrem.

Kontrolní seznam provedení Eliminovat:

• Ověření závislosti dokončeno: Statická analýza potvrzuje nulové závislosti na vstupní produkci (nejen nulové zdokumentované závislosti, ale strukturálně ověřené nulové).
• Schválený plán likvidace dat: Identifikace regulačních požadavků na uchovávání dat, schválení plánu migrace dat nebo archivace právním a dodržovacím orgánem
• Oznámení následného postupu dokončeno: Každý vlastník spotřebovávajícího systému byl upozorněn a potvrzen jako neaktivní závislost.
• Kontrola regulačních povinností dokončena: Žádné aktivní regulační podání, audit nebo požadavek na shodu nezávisí na aplikaci
• Přiřazený vlastník vyřazení z provozu: Jmenovaná osoba odpovědná za provedení vyřazení z provozu, nikoli pouze za rozhodnutí o klasifikaci
• Definován plán vrácení zpět: Postup pro obnovení služby, pokud vyřazení z provozu odhalí neobjevenou závislost
• Datum vyřazení z provozu: Konkrétní datum v IT kalendáři, ne „až k tomu dojdeme“

Brána strukturální analýzy: Rozhodnutí o žádném vyřazení pokračuje k plánování vyřazení z provozu, dokud strukturální analýza nepotvrdí nulové příchozí závislosti z produkčních cest provádění. Nejčastější příčinou selhání provedení vyřazení je zjištění závislosti po oznámení o vyřazení z provozu, která vynutí návrat k původní verzi. Analýza strukturálních závislostí před oznámením tomu zabrání.

Cyklus přehodnocení TIME

Klasifikace TIME nejsou trvalé. Obchodní hodnota se mění s vývojem strategie organizace. Technická vhodnost se mění s tím, jak je aplikace udržována, rozšiřována nebo stárne. Model je momentka; portfolio vyžaduje pohyblivý obraz.

Každoroční kompletní přehodnocení: Každá aplikace v portfoliu je hodnocena podle aktuální obchodní hodnoty a kritérií technické vhodnosti. Klasifikace, které se nezměnily ve třech po sobě jdoucích letech, jsou zkoumány konkrétně, buď je aplikace skutečně stabilní (zdokumentujte proč), nebo hodnocení nezachycuje probíhající změny.

Přehodnocení vyvolané událostí: Specifické události spouštějí okamžité přezkoumání reklasifikace:

• Fúze nebo akvizice (nová kombinace portfolia)
• Regulační změna ovlivňující povinnosti v oblasti dodržování předpisů
• Oznámení o ukončení životního cyklu hlavní platformy (databáze, operační systém, běhové prostředí)
• Významná změna obchodního modelu (nová produktová řada, odchod z trhu, organizační restrukturalizace)
• Bezpečnostní incident týkající se aplikace

Disciplína v protokolu změn: Každá reklasifikace je zaznamenána s uvedením: předchozí klasifikace, nové klasifikace, data, důkazů, které změnu vedly, a schvalovatele. Historie klasifikace každé žádosti je auditní stopou, která prokazuje, že portfolio je aktivně spravováno, nikoli kategorizováno a zapomenuto.

Jak SMART TS XL Poskytuje důkazy pro klasifikaci TIME

Klasifikační rozhodnutí modelu TIME jsou jen tak dobrá, jako důkazy, na kterých jsou založeny. Pro moderní aplikace s pokrytím CMDB, monitorováním API a dokumentovanými architekturami jsou tyto důkazy dostupné. Pro starší portfolia COBOL, kde je CMDB neúplná, vlastníci se stáhli z provozu a struktura závislostí není dokumentována, musí důkazy pocházet ze strukturální analýzy samotného kódu.

SMART TS XLJe statická analýza kódu vytváří vstupy pro technickou shodu, které vyžaduje skórování COBOLu: cyklomatická složitost na program, procento mrtvého kódu, nalezené bezpečnostní vzory (pevně zakódované přihlašovací údaje, nechráněný přístup k souborům) a aktuálnost dialektu COBOLu. Tyto metriky jsou odvozeny ze zdrojového kódu, nikoli z odhadů vývojářů, a nezávisí na tom, zda si někdo pamatuje, co aplikace dělá.

Mapování závislostí aplikací vytváří počty příchozích a odchozích závislostí, které zabraňují předčasným rozhodnutím o eliminaci, a počty odchozích závislostí, které podporují hodnocení obchodní hodnoty. Aplikace se 45 příchozími závislostmi z produkčních programů není bezpečným kandidátem na eliminaci bez ohledu na to, jak její vlastník hodnotí její obchodní hodnotu. Počet závislostí je strukturální fakt, který přepisuje argument klasifikace.

Analýza modernizace starších programů vytváří inventář mrtvého kódu, který mění klasifikaci: programy, které se v CMDB zobrazují jako aktivní aplikace, ale nemají žádné závislosti na vstupním produkčním kódu, jsou kandidáty na mrtvý kód, překlasifikované z Tolerovat na Eliminovat na základě strukturálních důkazů, nikoli na základě posouzení vlastníkem firmy programu, o jehož existenci možná nikdy nevěděl.

Díky analýze dopadů je možné provést kontrolní seznam Eliminace provedení: strukturální analýza, která potvrzuje nulové závislosti na vstupní produkci před zahájením plánování vyřazování z provozu. Toto je brána, která zabraňuje nejčastějšímu selhání při provádění Eliminace, tedy neodhalené závislosti, která se objeví po oznámení.

Díky funkci podnikového vyhledávání je možné v procesu klasifikace TIME provádět dotazy v průběhu celého cyklu opětovného posouzení: najít každou žádost klasifikovanou jako Tolerovat s datem kontroly v příštích 30 dnech, každou žádost klasifikovanou jako Eliminovat bez přiřazeného data vyřazení z provozu a každou žádost se skóre technické shody pod 30, která je stále klasifikována jako Investovat. Tyto dotazy jsou nástrojem správy, který udržuje model TIME jako aktivní nástroj správy, nikoli jako jednorázový klasifikační úkol.

Rámec je jen tak dobrý, jako jeho důkazy

Dvouosá struktura modelu TIME je správná. Obchodní hodnota a technická vhodnost jsou správnými dimenzemi pro rozhodování o portfoliu aplikací. Čtyři dispozice jsou správnými možnostmi. Problém není v rámci, ale v důkazní základně, kterou do něj organizace přinášejí.

Klasifikace založené na datech z rozhovorů a odhadech CMDB vyvolávají organizační debaty. Klasifikace založené na strukturální analýze, měřené složitosti, ověřeném počtu závislostí a technické způsobilosti odvozené z kódu vedou k obhajitelným rozhodnutím. Vlastník aplikace, který tvrdí, že jeho program v COBOLu je investovatelný, nikoli migrovatelný, má těžší argumenty, když strukturální analýza ukazuje cyklomatickou složitost v průměru 35, 40 % mrtvého kódu a 12 bezpečnostních zjištění. IT tým, který tvrdí, že program lze eliminovat, má slabší argumenty, když analýza závislostí ukazuje 45 závislostí v příchozí produkci.

Model TIME funguje, když pro to existují důkazy. Strukturální analýza aplikačního portfolia je způsob, jakým organizace budují důkazy pro starší aplikace, které nejvíce potřebují racionalizační rozhodnutí a u kterých je nejméně pravděpodobné, že budou mít dokumentaci, která tato rozhodnutí usnadňuje.