TIME-modell (Tolerera, Investera, Migrera, Eliminera) för appportföljer

Mötet om rationalisering av applikationer börjar klockan 9.00. Klockan 11.00 har teamet klassificerat tolv av de fyrahundra applikationerna som omfattas. Tre av dessa tolv klassificeringar har redan ifrågasatts, reviderats och ifrågasatts igen. COBOL-batchprogrammet som kör lönehantering är uppenbarligen inte Eliminera, men är det Tolerate eller Invest? Det äldre faktureringssystemet som alla är överens om är tekniskt otillräckligt är helt klart Migrate, men migrera till vad, och vad händer med de sjutton program som är beroende av det? Mötet är planerat till middagstid. Klockan 12.00 föreslår någon att man fortsätter nästa vecka. Nästa månad har initiativet i tysthet slutat producera resultat.

Gartners TIME-modell är det mest använda ramverket för applikationsportföljhantering inom företags-IT. Den sorterar varje applikation i portföljen i en av fyra dispositioner, Tolerera, Investera, Migrera, Eliminera, med hjälp av två poängdimensioner: affärsvärde och teknisk anpassning. Ramverket är logiskt sunt, brett tillämpligt och citerats av US Federal CIO Council's Application Rationalization Playbook som en rekommenderad metod. Det misslyckas också i praktiken oftare än det lyckas, av en anledning som ramverkets förespråkare nämner men sällan utvecklar: klassificeringarna är bara så bra som bevisen bakom dem. Utan strukturella bevis, räknas verkliga beroenden, verkliga komplexitetsmätningar, verkligt affärsvärde som härrör från exekveringsspår snarare än ägarintervjuer, TIME-klassificeringar blir organisationspolitik. Placeringsargument börjar vid Migrera och Eliminera, där någons favoritapplikation står på spel, och de löses aldrig.

Modellen: Två axlar, fyra dispositioner

TIME-modellen visar varje applikation på en 2×2-matris. Den horisontella axeln är teknisk lämplighet, hur väl applikationens nuvarande tekniska implementering stöder dess avsedda funktion: arkitekturkvalitet, underhållbarhet, integrationsförmåga, säkerhetsställning, driftsäkerhet. Den vertikala axeln är affärsvärde, hur viktig applikationens funktion är för organisationens affärsverksamhet, intäktsgenerering, regelefterlevnad eller strategiska mål.

	Hög teknisk passform	Låg teknisk passform
Högt affärsvärde	INVESTERAFinansiera det. Applikationen är både strategiskt viktig och tekniskt sund. Investera för att behålla dess försprång.	FLYTTAVerksamheten behöver det, tekniken är fel. Ersätt plattformen, inte funktionen.
Lågt affärsvärde	TOLERERALåt det vara så länge. Applikationen är i god form men inte värd en extra investering.	ELIMINERA, Pensionera den. Lågt värde, låg kvalitet, inga skäl att behålla den.

Enkelheten är avsiktlig. TIME är inte utformad för att producera detaljerad investeringsplanering, utan för att producera entydiga riktningsbeslut för varje applikation i portföljen. En applikation som inte kan placeras tydligt är en applikation som kräver mer information innan klassificering är möjlig.

De fyra kvadrantoperativa modellerna

Varje TIME-disposition är inte bara en etikett, det är en verksamhetsmodell som avgör hur organisationen hanterar applikationen framöver.

Investera: Maximal värdeutvinning

Invest-applikationer är portföljens kronjuveler: högt affärsvärde, hög teknisk anpassning. De motiverar den mest aggressiva investeringen i nya funktioner, prestandaoptimering, integrationsexpansion och underhåll av teknisk växelström. En Invest-applikation som halkar efter med sin tekniska växelström, en åldrande runtime, en föråldrad säkerhetsställning och en ackumulerad beroendeskuld riskerar att glida in i Migrate innan nedgången märks.

Rörelseåtaganden för Invest:

• Dedikerad ingenjörskapacitet för funktionsutveckling och tekniskt underhåll
• Förstprioriterade säkerhetsuppdateringar och efterlevnadsuppdateringar
• Arkitekturgranskningsnämndens bevakning av alla betydande förändringar
• Proaktiv övervakning med SLA-mål på nivå 1-nivå

Migrera: Ersätt plattformen, bevara funktionen

Migreringsapplikationer utför en affärsfunktion som organisationen verkligen behöver, men på en teknisk plattform som inte längre är tillräcklig, för dyr att underhålla, för ömtålig att utöka och för isolerad från det moderna integrationslandskapet. Affärsvärdet motiverar migreringsinvesteringen; det tekniska tillståndet gör fortsatta investeringar i den nuvarande plattformen till en dålig avkastning.

Migreringsdispositionen besvarar en specifik fråga: är funktionen värd att bevara? Om ja, migrera. Vad man ska migrera till, och hur, är ett separat beslut som TIME-klassificeringen inte fattar, den fastställer bara att den nuvarande plattformen inte är lösningen.

Det vanligaste migreringsscenariot i äldre miljöer: Ett COBOL-batchprogram som implementerar kritisk affärslogik, komplexa regulatoriska beräkningar, proprietära prissättningsregler och jurisdiktionspecifik skattelogik på en plattform som gör det dyrt att utöka, testa och integrera. Logiken är oersättlig; plattformen är problemet. Migrera till en modern plattform som bevarar logiken samtidigt som den tillhandahåller de operativa egenskaper som verksamheten nu kräver.

Tolerera: Avsiktlig passivitet med ett utgångsdatum

Att tolerera är den mest missförstådda kvadranten. Det betyder inte att ”den här applikationen är bra”. Det betyder att ”applikationens tekniska kvalitet motiverar inte investeringen för att ändra den just nu, och dess affärsvärde motiverar inte att den elimineras”. Det är ett medvetet val att acceptera status quo under en definierad period, inte en obestämd uppskjutning.

Tolerera är en tidsbegränsad spärr, inte ett permanent tillstånd. Varje applikation i Tolerera-kvadranten bör ha ett explicit granskningsdatum, vanligtvis 12 till 18 månader, och definierade villkor som skulle utlösa tidig omklassificering: en säkerhetsbrist som inte kan åtgärdas, en beroendepensionering som tvingar fram en plattformsändring, en ökning av affärsvärdet som gör applikationen värd att investera i, eller en förändring av affärsfunktionen som eliminerar dess syfte.

Organisationer som behandlar Tolerate som permanent ackumulerar exakt den tekniska skuld som TIME-modellen utformades för att förhindra. Ett COBOL-program som Tolererades 2019 men fortfarande befinner sig i Tolerate-kvadranten 2026 har fått ytterligare sju år av uppskjuten underhållsuppmärksamhet som det så småningom kommer att behöva, antingen som en nödsituation när något går sönder eller som en påtvingad migrering när plattformen inte längre kan stödjas.

Eliminera: Beslutet alla fattar och ingen verkställer

Eliminera är den enklaste klassificeringen och den minst utförda avyttringen. Applikationen har lågt affärsvärde och dålig teknisk lämplighet, det finns inget skäl att behålla den. Avveckla den.

Misslyckandet med genomförandet är väl dokumenterat: Eliminate befolkas entusiastiskt och ageras nästan aldrig. En portföljgranskning 2024 vid ett stort finansinstitut gav 87 Eliminate-kandidater. Arton månader senare var 71 av dem fortfarande aktiva. Det är i klyftan mellan klassificeringen och avvecklingen som rationaliseringsprogrammen tappar fart.

Tre specifika hinder förhindrar elimineringskörning:

Dolda beroenden. Applikationen klassificerades som Eliminate baserat på dess uppenbara fristående status. Efter klassificeringen visar strukturell analys att tolv andra program producerar utdata som Eliminate-kandidaten bearbetar, eller att tre externa system skickar data till den via ett odokumenterat filgränssnitt. Applikationen är inte fristående; den är den dolda infrastrukturen för andra system. Klassificeringen måste ses över.

Blockering av datamigrering. Applikationen innehåller data som inte kan förstöras, myndighetsregister med obligatoriska lagringsperioder, kunddata som måste överföras till ett efterföljande system, historiska transaktionsregister som granskar processer och frågar årligen. Datamigreringen måste föregå avvecklingen, och datamigreringen är dyr.

Myndighetsskyldigheter. Vissa applikationer kan inte tas ur bruk även om deras affärsvärde är noll, eftersom regelverk kräver den kapacitet de tillhandahåller. En rapporteringsapplikation som producerar en kvartalsvis regulatorisk inlämning har ett regulatoriskt värde som inte framgår av någon affärsvärdesundersökning. Tills den regulatoriska skyldigheten överförs till ett annat system måste applikationen köras.

Bevisproblemet: Varför TIME misslyckas utan strukturella data

Det mest betydande felläget i TIME-implementeringar är vad Catios dokumentation identifierar exakt: placeringsargument börjar vid Migrate och Eliminate, där någons favoritapplikation står på spel. Utan objektiva bevis är varje klassificering en förhandling. Applikationsägaren argumenterar för Invest. IT-teamet argumenterar för Migrate. Ekonomiteamet vill Eliminate. Mötet slutar i Tolerate eftersom det är den minst kontroversiella ståndpunkten.

Strukturella bevis löser dessa förhandlingar genom att ersätta åsikt med mätning.

För teknisk anpassningspoängsättning är det viktigt att:

Indikator för teknisk anpassning	Källa	Flyttar klassificering mot
Cyklomatisk komplexitet per program (genomsnitt)	Statisk kodanalys	Låg = högre passform, Hög = lägre passform
Procentuell dödkod	Nåbarhetsanalys	Hög dödkod = lägre anpassning
Fan-in (antal inkommande beroenden)	Beroendemappning	Hög fläktingång ökar Tolerera framför Eliminera
Bredd i delningsutrymme för häften	COPY-beroendeanalys	Hög delning = högre koppling = lägre anpassning
Tid sedan senaste betydelsefulla förändring	Git/ändringshanteringslogg	Lång vila kan indikera död kod eller stabilitet
Antal säkerhetssårbarheter	SAST-skanning	Högt antal = lägre anpassning

För affärsvärdebedömning är det viktigt med bevis:

Indikator för affärsvärde	Källa	Flyttar klassificering mot
Transaktionsvolym per period	JCL-körningsloggar, schemaläggningsposter	Hög volym = högre värde
Nedströms utbyggnad	Beroendemappning	Hög utbredningsgrad = högre värde (många är beroende av det)
Flagga för regleringsfunktion	Dataklassificering, efterlevnadsregister	Nuvarande = lägsta värdegolv oavsett andra poäng
Intäktsnärhet	Dataflödesanalys till fakturerings-/intäktssystem	Direkt angränsning = högre värde
Användarantal eller API-anropsantal	Åtkomstloggar, nätverkstrafik	Högt antal = högre värde

Den avgörande insikten: för äldre COBOL-system är de flesta av dessa indikatorer inte tillgängliga från CMDB-poster, intervjuer med applikationsägare eller analyser av nätverkstrafik. De är tillgängliga från strukturell analys av källkoden, exekveringsloggar och JCL-jobbschemat som dokumenterar vad som faktiskt körs i produktion och när.

Poängsättning av teknisk anpassning för COBOL och äldre system

Standardkriterier för teknisk anpassning, API-kompatibilitet, molnbaserad beredskap, containeriseringsstöd och mikrotjänstarkitektur är irrelevanta för COBOL-batchprogram. Ett COBOL-program kan inte containeriseras; att poängsätta det mot molnbaserade kriterier ger en teknisk anpassningspoäng på noll för varje äldre program, vilket inte säger organisationen något användbart.

För COBOL- och stordatorsystem kräver den tekniska anpassningspoängen COBOL-specifika kriterier:

Komplexitetspoäng (vikt: 30 %): Genomsnittlig cyklomatisk komplexitet över programmets stycken och avsnitt. Program med genomsnittlig CC under 10 har hanterbar komplexitet; program över 20 har strukturell komplexitet som gör underhåll dyrt och riskabelt.

Underhållbarhetspoäng (vikt: 25 %): Sammansatt av andel död kod, delningsbredd för kopieböcker och dupliceringsgrad. Ett program med 40 % död kod, 15 delade kopieböcker och betydande kodduplicering har låg underhållbarhet oavsett dess funktionella korrekthet.

Beroenderiskpoäng (vikt: 20 %): Antal Fan-in viktat efter hur kritiska inkommande beroenden är. Ett program med 50 inkommande beroenden från nivå 1-program har hög beroenderisk, ändringar av den kräver samordning av 50 nedströmsprogram.

Valutapoäng (vikt: 15 %): COBOL-dialekt och kompilatorversionens valuta, JCL-syntaxmodernitet och databasgränssnitt (inbäddad SQL vintage, VSAM vs DB2, endast batch vs batch+CICS). Program skrivna i COBOL-85-syntax med inbäddad DB2 SQL är mer aktuella än program skrivna i COBOL-74 med endast VSAM-filåtkomst.

Säkerhetsstatuspoäng (vikt: 10 %): Förekomst av hårdkodade autentiseringsuppgifter, oskyddad filåtkomst, avsaknad av FILSTATUS-kontroll och exponering för SQL-injektioner 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.

Denna poängformel ger en teknisk anpassningspoäng på 0–100, hämtad från strukturell kodanalys snarare än från kvalitativ bedömning. Två applikationer med identiska funktioner men olika strukturella egenskaper kommer att producera olika tekniska anpassningspoäng, och dessa poäng kommer korrekt att återspegla de olika investeringar som krävs för att underhålla och utöka var och en.

Problemet med toleransdrift: Styrning för hållkvadranten

Tolerate är den kvadrant som ackumulerar skulder över tid i varje organisation som använder TIME utan explicit Tolerate-styrning. Mekanismen är enkel: en applikation går in i Tolerate eftersom den inte är värd att ändra, sedan förblir den i Tolerate på obestämd tid eftersom att ändra den aldrig är den mest brådskande prioriteten.

En tolerant styrningsdisciplin förhindrar obestämd uppskjutning:

Villkorsbaserade omklassificeringsutlösare:

• Säkerhetsproblem identifierat som inte kan åtgärdas inom 30 dagar → granska för migrering eller eliminering
• Leverantören meddelar att en plattformskomponent som applikationen är beroende av är slut på sin livscykel → granskning för Migrate
• Affärsvärdespoängen ökar över tröskelvärdet (nytt regelkrav, förändring av affärsmodell) → granskning för Investera eller migrera
• Beroendepensionering tvingar fram gränssnittsändring → granskning för migrering eller eliminering
• Analys av död kod visar att applikationen i praktiken är inaktiv → granska för Eliminera

Tidsbaserad granskningskadens:

• Ansökningar går in i Tolerate med ett granskningsdatum på 12 månader
• Vid 12-månadersgranskningen omklassificeras ansökan uttryckligen eller omtolereras uttryckligen med ett nytt 12-månadersdatum.
• Återtolerans kräver en skriftlig motivering som dokumenterar varför förhållandena inte har förändrats
• En ansökan som har blivit omtolererad mer än två gånger utan omklassificering utlöser en eskalering till arkitekturgranskningsnämnden.

Tolerate-registret: En underhållen lista över varje Tolerate-applikation med dess klassificeringsdatum, granskningsdatum, ägare och det villkor som skulle utlösa omklassificering. Detta register granskas vid varje möte för arkitekturgranskningsnämnden, inte bara vid den årliga portföljgranskningen.

Att göra Eliminate Executable: Att minska avvecklingsgapet

Det är i klyftan mellan ”klassificerad som Eliminera” och ”framgångsrikt avvecklad” som rationaliseringsprogram stannar upp. För att täppa till den klyftan krävs det att varje Eliminera-beslut behandlas som ett projekt med definierad omfattning, beroenden och framgångskriterier, inte som en slutsats.

Checklista för elimineringskörning:

• Beroendeverifiering klar: Statisk analys bekräftar noll beroenden för inkommande produktion (inte bara noll dokumenterade beroenden, strukturellt verifierad noll)
• Godkänd plan för datahantering: Myndigheternas krav på lagring identifierade, datamigrering eller arkiveringsplan godkänd av juridiska och efterlevnadsavdelningen
• Nedströmsmeddelande slutfört: Varje konsumerande systems ägare har meddelat och bekräftat att det inte finns några aktiva beroenden.
• Kontroll av regleringsskyldighet slutförd: Inget aktivt krav på regulatorisk inlämning, revision eller efterlevnad är beroende av ansökan.
• Avvecklingsägare tilldelad: Namngiven person som ansvarar för att verkställa avvecklingen, inte bara klassificeringsbeslutet
• Återställningsplan definierad: Procedur för att återställa tjänsten om avvecklingen avslöjar ett oupptäckt beroende
• Avvecklingsdatum: Specifikt datum i IT-kalendern, inte "när vi kommer till det"

Strukturanalysgrinden: Inget elimineringsbeslut fortsätter till avvecklingsplanering förrän en strukturanalys bekräftar noll inkommande beroenden från produktionskörningsvägar. Den vanligaste orsaken till att elimineringskörningen misslyckas är att upptäcka ett beroende efter avvecklingsmeddelandet som tvingar fram en återgång. Strukturberoendeanalys före meddelandet förhindrar detta.

TIME-omvärderingscykeln

TIME-klassificeringar är inte permanenta. Affärsvärdet förändras allt eftersom organisationens strategi utvecklas. Teknisk anpassning förändras allt eftersom applikationen underhålls, utökas eller tillåts åldras. Modellen är en ögonblicksbild; portföljen kräver en rörlig bild.

Årlig fullständig omvärdering: Varje ansökan i portföljen bedöms utifrån aktuellt affärsvärde och kriterier för teknisk lämplighet. Klassificeringar som inte har ändrats under tre på varandra följande år granskas specifikt, antingen är ansökan genuint stabil (dokumentera varför) eller så fångar inte bedömningen upp förändringar som sker.

Händelseutlöst omvärdering: Specifika händelser utlöser omedelbar omklassificeringsgranskning:

• Fusion eller förvärv (ny portföljkombination)
• Regeländringar som påverkar efterlevnadsskyldigheter
• Stort tillkännagivande om plattformens slut på livstid (databas, operativsystem, runtime)
• Betydande förändring av affärsmodell (ny produktlinje, marknadsavyttring, organisatorisk omstrukturering)
• Säkerhetsincident som involverar applikationen

Ändringsloggdisciplin: Varje omklassificering loggas med: tidigare klassificering, ny klassificering, datum, bevis som utlöste ändringen och godkännare. Klassificeringshistoriken för varje ansökan är den revisionslogg som visar att portföljen aktivt hanteras snarare än kategoriseras och glöms bort.

Hur SMART TS XL Ger bevis för TIME-klassificering

TIME-modellens klassificeringsbeslut är bara så bra som bevisen bakom dem. För moderna applikationer med CMDB-täckning, API-övervakning och dokumenterade arkitekturer är dessa bevis tillgängliga. För äldre COBOL-portföljer där CMDB är ofullständig, ägarna har gått i pension och beroendestrukturen är odokumenterad måste bevisen komma från strukturell analys av själva koden.

SMART TS XLÄr statisk kodanalys producerar de tekniska anpassningsdata som COBOL-poängsättning kräver: cyklomatisk komplexitet per program, procentandel död kod, säkerhetsmönsterfynd (hårdkodade autentiseringsuppgifter, oskyddad filåtkomst) och COBOL-dialektvaluta. Dessa mätvärden härleds från källkoden, inte från utvecklarens uppskattningar, och de är inte beroende av att någon kommer ihåg vad applikationen gör.

Mappningen av applikationsberoenden producerar de fan-in-antal som förhindrar för tidiga elimineringsbeslut och de fan-out-antal som stöder poängsättning för affärsvärde. En applikation med 45 inkommande beroenden från produktionsprogram är inte en säker elimineringskandidat oavsett hur dess ägare bedömer dess affärsvärde. Beroendeantalet är det strukturella faktum som åsidosätter klassificeringsargumentet.

Analysen av den äldre moderniseringen producerar en inventering av död kod som ändrar klassificeringar: program som visas i CMDB som aktiva applikationer men har noll beroenden för inkommande produktion är kandidater för död kod, omklassificerade från Tolerera till Eliminera baserat på strukturella bevis, inte på företagsägarens bedömning av ett program de kanske aldrig visste existerade.

Effektanalysfunktionen gör checklistan för Eliminate-körning möjlig: den strukturella analysen som bekräftar noll inkommande produktionsberoenden innan någon avvecklingsplanering påbörjas. Detta är grinden som förhindrar det vanligaste Eliminate-körningsfelet, det oupptäckta beroendet som uppstår efter tillkännagivandet.

Företagssökningsfunktionen gör TIME - klassificeringsprocessen sökbar under hela omvärderingscykeln: hitta alla applikationer som klassificerats som Tolereras med ett granskningsdatum inom de kommande 30 dagarna, alla applikationer som klassificerats som Elimineras utan tilldelat avvecklingsdatum, alla applikationer med en teknisk anpassningspoäng under 30 som fortfarande klassificeras som Invest. Dessa frågor är styrverktyget som gör att TIME-modellen är ett aktivt förvaltningsinstrument snarare än en engångsklassificeringsövning.

Ett ramverk är bara så bra som dess bevis

TIME-modellens tvåaxliga struktur är korrekt. Affärsvärde och teknisk anpassning är rätt dimensioner för beslut om applikationsportföljer. De fyra dispositionerna är rätt alternativ. Problemet är inte ramverket, det är evidensbasen som organisationer bidrar med.

Klassificeringar baserade på intervjudata och CMDB-uppskattningar producerar organisatoriska debatter. Klassificeringar baserade på strukturell analys, uppmätt komplexitet, verifierade beroenden och kodhärledd teknisk lämplighet producerar försvarbara beslut. Applikationsägaren som argumenterar för att deras COBOL-program är Invest snarare än Migrate har ett svårare fall när den strukturella analysen visar en cyklomatisk komplexitet på i genomsnitt 35, 40 % död kod och 12 säkerhetsresultat. IT-teamet som argumenterar för att ett program kan elimineras har ett svagare fall när beroendeanalysen visar 45 inkommande produktionsberoenden.

TIME-modellen fungerar när bevisen talar för dem. Strukturell analys av applikationsportföljen är hur organisationer bygger upp dessa bevis för de äldre applikationer som mest behöver rationaliseringsbeslut och som har minst chans att ha den dokumentation som gör dessa beslut enkla.