TIME-model (Tolerér, Investér, Migrér, Eliminér) for appporteføljer

Mødet om applikationsrationalisering starter kl. 9.00. Klokken 11.00 har teamet klassificeret tolv ud af de fire hundrede applikationer, der er omfattet. Tre af disse tolv klassifikationer er allerede blevet anfægtet, revideret og anfægtet igen. COBOL-batchprogrammet, der kører løn, er tydeligvis ikke Eliminer, men er det Tolerate eller Invest? Det traditionelle faktureringssystem, som alle er enige om er teknisk utilstrækkeligt, er tydeligvis Migrate, men migrer til hvad, og hvad sker der med de sytten programmer, der er afhængige af det? Mødet er planlagt til middag. Kl. 12 foreslår nogen at fortsætte i næste uge. Inden den følgende måned er initiativet stille og roligt holdt op med at producere output.

Gartner TIME-modellen er det mest anvendte rammeværk for applikationsporteføljestyring inden for virksomheds-IT. Det sorterer alle applikationer i porteføljen i en af ​​fire dispositioner: Tolerér, Investér, Migrér, Eliminér, ved hjælp af to scoringsdimensioner: forretningsværdi og teknisk tilpasning. Rammeværket er logisk forsvarligt, bredt anvendeligt og citeret af det amerikanske føderale CIO Councils Application Rationalization Playbook som en anbefalet metode. Det fejler også i praksis oftere end det lykkes, af en grund, som rammeværkets fortalere nævner, men sjældent udvikler: klassifikationerne er kun så gode som beviserne bag dem. Uden strukturelle beviser, tæller reel afhængighed, målinger af reel kompleksitet, data om reel forretningsværdi udledt af eksekveringsspor snarere end ejerinterviews, bliver TIME-klassifikationer til organisationspolitik. Placeringsargumenter starter ved Migrér og Eliminér, hvor en persons yndlingsapplikation er på spil, og de løses aldrig.

Modellen: To akser, fire dispositioner

TIME-modellen plotter hver applikation på en 2×2-matrix. Den vandrette akse er teknisk tilpasning, hvor godt applikationens nuværende tekniske implementering understøtter dens tilsigtede funktion: arkitekturkvalitet, vedligeholdelse, integrationskapacitet, sikkerhedsposition, driftssikkerhed. Den lodrette akse er forretningsværdi, hvor vigtig applikationens funktion er for organisationens forretningsdrift, indtægtsgenerering, overholdelse af lovgivning eller strategiske mål.

	Høj teknisk pasform	Lav teknisk pasform
Høj forretningsværdi	INVESTEREFinansier det. Ansøgningen er både strategisk vigtig og teknisk solid. Invester for at bevare dens førende position.	MIGRATERVirksomheden har brug for det, teknologien er forkert. Erstat platformen, ikke funktionen.
Lav forretningsværdi	TOLERERELad det være for nu. Applikationen er sund, men ikke værd at investere yderligere i.	ELIMINERPensionér den. Lav værdi, lav kvalitet, ingen grund til at beholde den.

Enkelheden er bevidst. TIME er ikke designet til at producere detaljeret investeringsplanlægning, men til at producere entydige retningsbeslutninger for hver applikation i porteføljen. En applikation, der ikke kan placeres klart, er en applikation, der kræver mere information, før klassificering er mulig.

De fire kvadrant-driftsmodeller

Hver TIME-disposition er ikke bare en etiket, det er en driftsmodel, der bestemmer, hvordan organisationen administrerer applikationen fremadrettet.

Investér: Maksimal værdiudvinding

Invest-applikationer er porteføljens kronjuveler: høj forretningsværdi, høj teknisk tilpasning. De retfærdiggør den mest aggressive investering i nye funktioner, ydeevneoptimering, integrationsudvidelse og vedligeholdelse af teknisk valuta. En Invest-applikation, der sakker bagud med sin tekniske valuta, en aldrende runtime, en forældet sikkerhedstilstand og en akkumulerende afhængighedsgæld, risikerer at glide ind i Migrate, før faldet bemærkes.

Driftsforpligtelser for Invest:

• Dedikeret ingeniørkapacitet til funktionsudvikling og teknisk vedligeholdelse
• Førsteprioritets sikkerhedsopdateringer og compliance-opdateringer
• Dækning af arkitekturbedømmelsesudvalg for enhver væsentlig ændring
• Proaktiv overvågning med SLA-mål på niveau 1

Migrer: Udskift platformen, bevar funktionen

Migreringsapplikationer udfører en forretningsfunktion, som organisationen reelt har brug for, men på en teknisk platform, der ikke længere er tilstrækkelig, for dyr at vedligeholde, for skrøbelig at udvide og for isoleret fra det moderne integrationslandskab. Forretningsværdien retfærdiggør migreringsinvesteringen; den tekniske tilstand gør fortsatte investeringer i den nuværende platform til et dårligt afkast.

Migreringsdispositionen besvarer et specifikt spørgsmål: Er funktionen værd at bevare? Hvis ja, migrer. Hvad der skal migreres til, og hvordan, er en separat beslutning, som TIME-klassifikationen ikke træffer; den fastslår kun, at den nuværende platform ikke er svaret.

Det mest almindelige migreringsscenarie i ældre miljøer: Et COBOL-batchprogram, der implementerer kritisk forretningslogik, komplekse regulatoriske beregninger, proprietære prisregler og jurisdiktionspecifik skattelogik på en platform, der gør det dyrt at udvide, teste og integrere. Logikken er uerstattelig; platformen er problemet. Migrer til en moderne platform, der bevarer logikken, samtidig med at den leverer de operationelle egenskaber, som virksomheden nu kræver.

Tolerér: Bevidst passivitet med en udløbsdato

Tolerance er den mest misforståede kvadrant. Det betyder ikke, at "denne applikation er fin". Det betyder, at "denne applikations tekniske kvalitet retfærdiggør ikke investeringen i at ændre den lige nu, og dens forretningsmæssige værdi retfærdiggør ikke at eliminere den". Det er et bevidst valg at acceptere status quo i en defineret periode, ikke en ubestemt udsættelse.

Tolerering er en tidsbegrænset holding, ikke en permanent tilstand. Hver applikation i Tolereringskvadranten bør have en eksplicit gennemgangsdato, typisk 12 til 18 måneder, og definerede betingelser, der ville udløse tidlig omklassificering: en sikkerhedssårbarhed, der ikke kan rettes, en afhængighedsudfasning, der fremtvinger en platformændring, en stigning i forretningsværdien, der gør applikationen værd at investere i, eller en ændring i forretningsfunktionen, der eliminerer dens formål.

Organisationer, der behandler Tolerate som permanent, akkumulerer præcis den tekniske gæld, som TIME-modellen var designet til at forhindre. Et COBOL-program, der blev Tolereret i 2019, men stadig befinder sig i Tolerate-kvadranten i 2026, har modtaget syv yderligere års udskudt vedligeholdelse, som det i sidste ende vil få brug for, enten som en nødsituation, når noget går i stykker, eller som en tvungen migrering, når platformen ikke længere kan understøttes.

Eliminer: Beslutningen alle træffer, og ingen udfører

Eliminering er den mest ligefremme klassificering og den mindst udførte bortskaffelse. Applikationen har lav forretningsværdi og lav teknisk egnethed, der er ingen grund til at beholde den. Slet den.

Den manglende udførelse er veldokumenteret: Eliminate bliver entusiastisk befolket, og der handles næsten aldrig på dem. En porteføljegennemgang i 2024 hos en stor finansiel institution viste 87 Eliminate-kandidater. Atten måneder senere var 71 af dem stadig i gang. Det er i kløften mellem klassificeringen og nedlæggelsen, at rationaliseringsprogrammerne mister momentum.

Tre specifikke hindringer forhindrer udførelse af Elimination:

Skjulte afhængigheder. Applikationen blev klassificeret som Eliminate baseret på dens tilsyneladende standalone-status. Efter klassificeringen afslører strukturanalysen, at tolv andre programmer producerer output, som Eliminate-kandidaten behandler, eller at tre eksterne systemer sender data til den via en udokumenteret filgrænseflade. Applikationen er ikke standalone; den er den skjulte infrastruktur for andre systemer. Klassificeringen skal genovervejes.

Blokering af datamigrering. Applikationen indeholder data, der ikke kan destrueres, lovgivningsmæssige registre med obligatoriske opbevaringsperioder, kundedata, der skal overføres til et efterfølgende system, historiske transaktionsregistre, som revisionsprocesser forespørger årligt. Datamigreringen skal gå forud for nedlukningen, og datamigreringen er dyr.

Lovpligtige forpligtelser. Nogle applikationer kan ikke trækkes tilbage, selv når deres forretningsværdi er nul, fordi de lovgivningsmæssige rammer kræver den funktion, de leverer. En rapporteringsapplikation, der producerer en kvartalsvis lovgivningsmæssig indberetning, har en lovgivningsmæssig værdi, der ikke fremgår af nogen forretningsværdiundersøgelse. Indtil den lovgivningsmæssige forpligtelse overføres til et andet system, skal applikationen køre.

Bevisproblemet: Hvorfor TIME fejler uden strukturelle data

Den mest betydningsfulde fejltilstand i TIME-implementeringer er præcis, hvad Catios dokumentation identificerer: placeringsargumenter starter ved Migrate og Eliminate, hvor en persons foretrukne applikation er på spil. Uden objektive beviser er enhver klassificering en forhandling. Applikationsejeren argumenterer for Invest. IT-teamet argumenterer for Migrate. Finansteamet ønsker Eliminate. Mødet slutter i Tolerate, fordi det er den mindst kontroversielle position.

Strukturel evidens løser disse forhandlinger ved at erstatte mening med måling.

For teknisk fit-scoring er det vigtigt at følge de beviser:

Indikator for teknisk tilpasning	Kilde	Flytter klassificering mod
Cyklomatisk kompleksitet pr. program (gennemsnit)	Statisk kodeanalyse	Lav = bedre pasform, Høj = dårligere pasform
Procentdel af død kode	Analyse af tilgængelighed	Høj dødkode = lavere tilpasning
Fan-in (antal indgående afhængigheder)	Afhængighedskortlægning	Høj fan-in øges. Tolerer frem for eliminer.
Bredde for deling af kopibøger	COPY-afhængighedsanalyse	Høj deling = højere kobling = lavere tilpasning
Tid siden sidste meningsfulde ændring	Git/ændringsstyringslog	Lang dvaleperiode kan indikere død kode eller stabilitet
Antal sikkerhedssårbarheder	SAST-scanning	Højt antal = lavere pasform

For forretningsværdivurdering er det bevismateriale, der betyder noget:

Indikator for forretningsværdi	Kilde	Flytter klassificering mod
Transaktionsvolumen pr. periode	JCL-udførelseslogfiler, planlægningsregistreringer	Høj volumen = højere værdi
Downstream-fan-out	Afhængighedskortlægning	Høj fan-out = højere værdi (mange er afhængige af det)
Flag for regulatorisk funktion	Dataklassificering, compliance-register	Nuværende = minimumsværdi uanset andre scorer
Indtægtsnærhed	Dataflowanalyse til fakturerings-/indtægtssystemer	Direkte tilstødning = højere værdi
Brugerantal eller API-opkaldsantal	Adgangslogfiler, netværkstrafik	Højt antal = højere værdi

Den afgørende indsigt: For ældre COBOL-systemer er de fleste af disse indikatorer ikke tilgængelige fra CMDB-poster, interviews med applikationsejere eller netværkstrafikanalyser. De er tilgængelige fra strukturel analyse af kildekoden, udførelseslogfiler og JCL-jobplanen, der dokumenterer, hvad der rent faktisk kører i produktion, og hvornår.

Vurdering af teknisk tilpasning til COBOL og ældre systemer

Standardkriterier for teknisk tilpasning, API-kompatibilitet, cloud-native parathed, containeriseringsunderstøttelse og mikroservicearkitektur er irrelevante for COBOL-batchprogrammer. Et COBOL-program kan ikke containeriseres; at score det i forhold til cloud-native kriterier giver en teknisk tilpasningsscore på nul for hvert legacy-program, hvilket ikke fortæller organisationen noget nyttigt.

For COBOL- og mainframe-systemer kræver den tekniske tilpasningsscore COBOL-specifikke kriterier:

Kompleksitet score (vægt: 30%): Gennemsnitlig cyklomatisk kompleksitet på tværs af programmets afsnit og afsnit. Programmer med en gennemsnitlig CC under 10 har håndterbar kompleksitet; programmer over 20 har strukturel kompleksitet, der gør vedligeholdelse dyr og risikabel.

Vedligeholdelsesscore (vægt: 25%): Sammensat af procentdel død kode, deling af kopibøger og duplikeringsrate. Et program med 40% død kode, 15 delte kopibøger og betydelig kodeduplikering har lav vedligeholdelsesevne uanset dets funktionelle korrekthed.

Afhængighedsrisikoscore (vægt: 20%): Antal fan-in vægtet efter kritiskheden af ​​indgående afhængige. Et program med 50 indgående afhængigheder fra Tier 1-programmer har en høj afhængighedsrisiko, og ændringer af den kræver koordinering af 50 downstream-programmer.

Valutascore (vægt: 15%): COBOL-dialekt og compilerversionens valuta, JCL-syntaksmodernitet og databasegrænseflade (embedded SQL vintage, VSAM vs DB2, batch-only vs batch+CICS). Programmer skrevet i COBOL-85-syntaks med DB2 embedded SQL er mere aktuelle end programmer skrevet i COBOL-74 med kun VSAM-filadgang.

Sikkerhedsstatus-score (vægtning: 10%): Tilstedeværelse af hardcodede legitimationsoplysninger, ubeskyttet filadgang, fravær af FILSTATUS-kontrol og eksponering for SQL-injektion i dynamisk SQL-konstruktion.

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.

Denne scoreformel giver en teknisk tilpasningsscore på 0-100, der er baseret på strukturel kodeanalyse snarere end en kvalitativ vurdering. To applikationer med identiske funktioner, men forskellige strukturelle egenskaber, vil give forskellige tekniske tilpasningsscorer, og disse scorer vil nøjagtigt afspejle de forskellige investeringer, der kræves for at vedligeholde og udvide hver enkelt.

Problemet med tolereret drift: Styring af holdekvadranten

Tolerate er den kvadrant, der akkumulerer gæld over tid i enhver organisation, der bruger TIME uden eksplicit Tolerate-styring. Mekanismen er enkel: en applikation går ind i Tolerate, fordi den ikke er værd at ændre, og derefter forbliver den i Tolerate på ubestemt tid, fordi ændring af den aldrig er den mest presserende prioritet.

En tolerant forvaltningsdisciplin forhindrer ubestemt udskydelse:

Tilstandsbaserede omklassificeringsudløsere:

• Sikkerhedssårbarhed identificeret, som ikke kan rettes inden for 30 dage → gennemgå for migrering eller eliminering
• Leverandør annoncerer udløb af levetiden for en platformkomponent, som applikationen er afhængig af → gennemgang af Migrate
• Forretningsværdi-score stiger over tærsklen (nyt lovgivningskrav, ændring af forretningsmodel) → gennemgang for Investér eller Migrér
• Afhængighedstilbagetrækning fremtvinger grænsefladeændring → gennemgang for Migrer eller Eliminer
• Analyse af død kode afslører, at applikationen reelt er inaktiv → gennemgang for Eliminer

Tidsbaseret gennemgangskadence:

• Ansøgninger indtræder i Tolerance med en 12-måneders gennemgangsdato
• Ved 12-månedersgennemgangen omklassificeres ansøgningen eksplicit eller omtolereres eksplicit med en ny 12-måneders dato.
• Gentolerance kræver en skriftlig begrundelse, der dokumenterer, hvorfor forholdene ikke har ændret sig
• En ansøgning, der er blevet retolereret mere end to gange uden omklassificering, udløser en eskalering til arkitekturgennemgangsudvalget.

Tolerate-registeret: En vedligeholdt liste over alle Tolerate-applikationer med klassificeringsdato, gennemgangsdato, ejer og den betingelse, der ville udløse omklassificering. Dette register gennemgås på hvert møde i arkitekturgennemgangsudvalget, ikke kun ved den årlige porteføljegennemgang.

Gør Eliminate Executable: Lukning af afviklingskløften

Det er i kløften mellem "klassificeret som Eliminer" og "succesfuldt afviklet" at rationaliseringsprogrammer går i stå. At lukke dette hul kræver, at hver Eliminer-beslutning behandles som et projekt med defineret omfang, afhængigheder og succeskriterier, ikke som en konklusion.

Tjekliste for elimineringsudførelse:

• Afhængighedsbekræftelse fuldført: Statisk analyse bekræfter nul indgående produktionsafhængigheder (ikke kun nul dokumenterede afhængigheder, strukturelt verificeret nul)
• Plan for datadisponering godkendt: Identificerede krav til opbevaring af data, plan for datamigrering eller arkivering godkendt af juridiske og compliance-afdelinger
• Nedstrømsmeddelelse fuldført: Ejeren af ​​alle forbrugersystemer underrettede og bekræftede, at der ikke var nogen aktiv afhængighed
• Kontrol af lovpligtig forpligtelse fuldført: Ingen aktive krav til lovgivningsmæssig indsendelse, revision eller overholdelse afhænger af ansøgningen.
• Tildelt ejer af nedlukning: Navngiven person, der er ansvarlig for at udføre nedlukningen, ikke kun klassificeringsbeslutningen
• Tilbagetrækningsplan defineret: Procedure for genoprettelse af tjenesten, hvis nedlukningen afslører en uopdaget afhængighed
• Dato for nedlukning: En specifik dato i IT-kalenderen, ikke "når vi når til det"

Strukturanalyseporten: Ingen elimineringsbeslutning fortsætter til afviklingsplanlægning, indtil en strukturanalyse bekræfter nul indgående afhængigheder fra produktionsudførelsesstier. Den mest almindelige årsag til fejl i elimineringsudførelsen er opdagelsen af ​​en afhængighed efter afviklingsmeddelelsen, der tvinger en tilbageførsel. Strukturel afhængighedsanalyse før meddelelsen forhindrer dette.

TIME-revurderingscyklussen

TIME-klassifikationer er ikke permanente. Forretningsværdi ændrer sig i takt med at organisationens strategi udvikler sig. Teknisk tilpasning ændrer sig, når applikationen vedligeholdes, udvides eller får lov til at ældes. Modellen er et øjebliksbillede; porteføljen kræver et levende billede.

Årlig fuld revurdering: Hver ansøgning i porteføljen scores i forhold til den aktuelle forretningsværdi og kriterierne for teknisk egnethed. Klassifikationer, der ikke har ændret sig i tre på hinanden følgende år, undersøges specifikt, enten om ansøgningen er reelt stabil (dokumentér hvorfor), eller om vurderingen ikke registrerer ændringer, der sker.

Hændelsesudløst revurdering: Specifikke hændelser udløser øjeblikkelig gennemgang af omklassificering:

• Fusion eller opkøb (ny porteføljekombination)
• Reguleringsændringer, der påvirker compliance-forpligtelser
• Vigtig meddelelse om udfasning af platform (database, operativsystem, runtime)
• Væsentlig ændring af forretningsmodel (ny produktlinje, markedsudtræden, organisatorisk omstrukturering)
• Sikkerhedshændelse involveret i applikationen

Disciplin i ændringslog: Enhver omklassificering logges med: tidligere klassificering, ny klassificering, dato, beviser for ændringen og godkender. Klassificeringshistorikken for hver ansøgning er det revisionsspor, der viser, at porteføljen aktivt administreres i stedet for at blive kategoriseret og glemt.

Hvordan SMART TS XL Giver bevis for TIME-klassificering

TIME-modellens klassificeringsbeslutninger er kun så gode som beviserne bag dem. For moderne applikationer med CMDB-dækning, API-overvågning og dokumenterede arkitekturer er disse beviser tilgængelige. For ældre COBOL-porteføljer, hvor CMDB'en er ufuldstændig, ejerne er gået på pension, og afhængighedsstrukturen er udokumenteret, skal beviserne komme fra strukturel analyse af selve koden.

SMART TS XL's statisk kodeanalyse producerer de tekniske tilpasningsinput, som COBOL-scoring kræver: cyklomatisk kompleksitet pr. program, procentdel af død kode, fund af sikkerhedsmønstre (hardcodede legitimationsoplysninger, ubeskyttet filadgang) og COBOL-dialektvaluta. Disse målinger er afledt af kildekoden, ikke fra udviklernes estimater, og de afhænger ikke af, at nogen husker, hvad applikationen gør.

Programafhængighedskortlægningen producerer fan-in-tællinger, der forhindrer for tidlige Eliminate-beslutninger, og fan-out-tællinger , der understøtter forretningsværdivurdering. En applikation med 45 indgående afhængigheder fra produktionsprogrammer er ikke en sikker Eliminate-kandidat, uanset hvordan dens ejer vurderer dens forretningsværdi. Afhængighedsantallet er den strukturelle kendsgerning, der tilsidesætter klassifikationsargumentet.

Analysen af ​​den ældre modernisering producerer en opgørelse over død kode, der ændrer klassifikationer: Programmer, der vises i CMDB'en som aktive applikationer, men har nul indgående produktionsafhængigheder, er kandidater til død kode, der omklassificeres fra Tolerer til Eliminer baseret på strukturelle beviser, ikke på virksomhedsejerens vurdering af et program, de måske aldrig vidste eksisterede.

Effektanalysefunktionen gør Eliminate-udførelsestjeklisten mulig: den strukturelle analyse, der bekræfter nul indgående produktionsafhængigheder, før nogen planlægning af nedlukning begynder. Dette er den port, der forhindrer den mest almindelige Eliminate-udførelsesfejl, den uopdagede afhængighed, der dukker op efter annonceringen.

Virksomhedssøgningsfunktionen gør det muligt at forespørge på TIME - klassificeringsprocessen gennem hele revurderingscyklussen: find alle applikationer klassificeret som Tolerate med en gennemgangsdato inden for de næste 30 dage, alle applikationer klassificeret som Eliminate uden tildelt nedlukningsdato, og alle applikationer med en teknisk fit-score under 30, der stadig er klassificeret som Invest. Disse forespørgsler er det styringsværktøj, der holder TIME-modellen til et aktivt styringsinstrument snarere end en engangsklassificeringsøvelse.

Et rammeværk er kun så godt som dets beviser

TIME-modellens toaksede struktur er korrekt. Forretningsværdi og teknisk tilpasning er de rigtige dimensioner for beslutninger om applikationsporteføljer. De fire dispositioner er de rigtige muligheder. Problemet er ikke rammeværket, det er evidensgrundlaget, som organisationer bidrager med.

Klassifikationer baseret på interviewdata og CMDB-estimater skaber organisatoriske debatter. Klassifikationer baseret på strukturel analyse, målt kompleksitet, verificerede afhængighedsantal og kodeafledt teknisk egnethed producerer forsvarlige beslutninger. Applikationsejeren, der argumenterer for, at deres COBOL-program er Invest snarere end Migrate, har en sværere sag, når den strukturelle analyse viser en cyklomatisk kompleksitet på gennemsnitligt 35, 40 % død kode og 12 sikkerhedsresultater. IT-teamet, der argumenterer for, at et program kan elimineres, har en svagere sag, når afhængighedsanalysen viser 45 indgående produktionsafhængigheder.

TIME-modellen fungerer, når beviserne taler for sagen. Strukturel analyse af applikationsporteføljen er, hvordan organisationer opbygger disse beviser for de ældre applikationer, der har størst behov for rationaliseringsbeslutninger og mindst sandsynligt har den dokumentation, der gør disse beslutninger nemme.