Rakendusportfellide TIME mudel (talumine, investeerimine, migreerimine, kõrvaldamine)

Rakenduste ratsionaliseerimise koosolek algab kell 9. Kella 11-ks on meeskond klassifitseerinud neljasajast käsitletud rakendusest kaksteist. Kolm neist kaheteistkümnest klassifikatsioonist on juba vaidlustatud, läbi vaadatud ja uuesti vaidlustatud. Palgaarvestust haldav COBOLi partiiprogramm ei ole ilmselgelt Eliminate (Elikaavimine), aga kas see on Tolerate (Tolereeri) või Invest (Investeeri)? Pärandlik arveldussüsteem, mille tehniliseks ebapiisavuse kohta kõik nõustuvad, on selgelt Migrate (Migreeri), aga kuhu migreerida ja mis saab seitsmeteistkümnest sellest sõltuvast programmist? Koosolek on planeeritud keskpäevani. Keskpäevaks teeb keegi ettepaneku jätkata järgmisel nädalal. Järgmiseks kuuks on algatus vaikselt väljundi tootmise lõpetanud.

Gartneri TIME mudel on ettevõtte IT-s enimkasutatav rakenduste portfelli haldusraamistik. See sorteerib iga portfelli rakenduse ühte neljast jaotusest: talumine, investeerimine, migreerimine, kõrvaldamine, kasutades kahte hindamismõõdet: äriväärtus ja tehniline sobivus. Raamistik on loogiliselt usaldusväärne, laialdaselt rakendatav ja USA föderaalse CIO nõukogu rakenduste ratsionaliseerimise käsiraamatus on seda soovitatud metoodikana mainitud. See ebaõnnestub praktikas sagedamini kui õnnestub, põhjusel, mida raamistiku pooldajad mainivad, kuid harva arendavad: klassifikatsioonid on sama head kui nende taga olevad tõendid. Ilma struktuuriliste tõendite, tegelike sõltuvuste arvu, tegelike keerukusmõõtmiste ja tegelike äriväärtuse andmeteta, mis on tuletatud teostusjälgedest, mitte omanike intervjuudest, muutuvad TIME klassifikatsioonid organisatsioonipoliitikaks. Paigutuse vaidlused algavad migreerimisest ja kõrvaldamisest, kus kellegi lemmikrakendus on ohus, ja need ei lahenda kunagi probleemi.

Mudel: kaks telge, neli paigutust

TIME mudel kujutab iga rakendust 2×2 maatriksis. Horisontaalteljel on tehniline sobivus, mis näitab, kui hästi rakenduse praegune tehniline teostus toetab selle kavandatud funktsiooni: arhitektuuri kvaliteeti, hooldatavust, integreerimisvõimet, turvalisust, töökindlust. Vertikaalteljel on äriväärtus, mis näitab, kui oluline on rakenduse funktsioon organisatsiooni äritegevuse, tulude genereerimise, regulatiivse vastavuse või strateegiliste eesmärkide jaoks.

	Kõrge tehniline sobivus	Madal tehniline sobivus
Kõrge äriväärtus	INVESTEERI, Rahastage seda. Rakendus on nii strateegiliselt oluline kui ka tehniliselt usaldusväärne. Investeerige, et säilitada oma edumaa.	MIGREEERIÄri vajab seda, tehnoloogia on vale. Asenda platvorm, mitte funktsioon.
Madal äriväärtus	TALUMAJäta see praegu rahule. Rakendus on terve, aga lisainvesteeringut pole väärt.	ELIMINEERI, Viska see pensionile. Madal väärtus, madal kvaliteet, pole mõtet seda alles hoida.

Lihtsus on taotluslik. TIME ei ole loodud detailse investeerimisplaneerimise loomiseks, vaid üheselt mõistetavate suunaotsuste tegemiseks iga portfelli rakenduse jaoks. Rakendus, mida ei saa selgelt paigutada, on rakendus, mis vajab enne klassifitseerimise võimalikkust lisateavet.

Nelja kvadrandi toimimismudelid

Iga TIME dispositsioon ei ole lihtsalt silt, vaid tegutsemismudel, mis määrab, kuidas organisatsioon rakendust edaspidi haldab.

Investeeri: Maksimaalse väärtuse ekstraheerimine

Invest-rakendused on portfelli kroonijuveelid: kõrge äriväärtus ja hea tehniline sobivus. Need õigustavad kõige agressiivsemaid investeeringuid uutesse funktsioonidesse, jõudluse optimeerimisse, integratsiooni laiendamisse ja tehnilise valuuta hooldusse. Invest-rakendus, mis jääb oma tehnilise valuuta osas maha, vananeb käituskeskkonnaga, aegunud turvapositsiooniga või kuhjuva sõltuvusvõlaga, riskib libiseda migreerimisrežiimi enne, kui langust märgatakse.

Investi tegevuskulud:

• Spetsiaalne insenerivõimekus funktsioonide arendamiseks ja tehniliseks hoolduseks
• Esmatähtsad turvapaigad ja vastavusvärskendused
• Arhitektuurikomisjoni kajastus iga olulise muudatuse kohta
• Ennetav jälgimine koos SLA eesmärkidega 1. tasemel

Migreerimine: platvormi asendamine, funktsiooni säilitamine

Rakenduste migreerimine täidab ärifunktsiooni, mida organisatsioon tegelikult vajab, kuid tehnilisel platvormil, mis pole enam piisav, on liiga kallis hooldada, liiga habras laiendada ja liiga isoleeritud tänapäevasest integratsioonimaastikust. Äriline väärtus õigustab migratsiooniinvesteeringut; tehniline seisukord muudab praegusesse platvormi jätkuva investeerimise kehvaks tuluks.

Migreerimiskäsk vastab konkreetsele küsimusele: kas funktsioon on säilitamist väärt? Kui jah, siis migreerige. Millele ja kuidas migreerida, on eraldi otsus, mida TIME klassifikatsioon ei tee, see vaid kinnitab, et praegune platvorm ei ole lahendus.

Kõige levinum migreerimisstsenaarium pärandkeskkondades: COBOL-i partiiprogramm, mis rakendab kriitilist äriloogikat, keerulisi regulatiivseid arvutusi, patenteeritud hinnakujundusreegleid ja jurisdiktsioonipõhist maksuloogikat platvormil, mille laiendamine, testimine ja integreerimine on kulukas. Loogika on asendamatu; probleem on platvorm. Migreerige moodsale platvormile, mis säilitab loogika, pakkudes samal ajal ettevõtte jaoks vajalikke operatiivseid omadusi.

Taluma: tahtlik tegevusetus aegumiskuupäevaga

Talumine on kõige valesti mõistetud kvadrant. See ei tähenda, et „see rakendus on korras“. See tähendab, et „selle rakenduse tehniline kvaliteet ei õigusta investeeringut selle muutmiseks praegu ja selle äriline väärtus ei õigusta selle kõrvaldamist“. See on teadlik valik aktsepteerida status quo'd kindlaksmääratud aja jooksul, mitte määramata ajaks edasilükkamine.

Talumise kvadrandis olev rakendus on ajaliselt piiratud, mitte püsiv olek. Igal talumise kvadrandis oleval rakendusel peaks olema selge ülevaatuskuupäev, tavaliselt 12–18 kuud, ja määratletud tingimused, mis käivitavad varajase ümberklassifitseerimise: turvanõrkus, mida ei saa parandada, sõltuvuse eemaldamine, mis sunnib platvormi vahetama, äriväärtuse kasv, mis muudab rakenduse investeerimist väärt, või ärifunktsiooni muutus, mis kaotab selle eesmärgi.

Organisatsioonid, mis käsitlevad Tolerate'i püsivana, koguvad täpselt sama palju tehnilist võlga, mille vältimiseks TIME mudel loodi. 2019. aastal Tolerate'i kvadrandis loodud COBOL-programm, mis on 2026. aastal endiselt Tolerate'i kvadrandis, on saanud seitse täiendavat aastat edasilükatud hooldust, mida see lõpuks vajab, kas hädaolukorras, kui midagi katki läheb, või sunnitud migratsioonina, kui platvormi enam toetada ei saa.

Elimineerimine: otsus, mille kõik teevad ja keegi ei täida

„Ekvideeri” on kõige lihtsam liigitus ja kõige harvemini teostatav dispositsioon. Rakendusel on madal äriväärtus ja madal tehniline sobivus, seega pole alust seda alles hoida. Eemalda see.

Täitmise ebaõnnestumine on hästi dokumenteeritud: Eliminate'i programmi rakendatakse entusiastlikult ja sellele ei reageerita peaaegu kunagi. Suure finantsasutuse 2024. aasta portfelli läbivaatamine andis tulemuseks 87 Eliminate'i kandidaati. Kaheksateist kuud hiljem oli neist 71 endiselt töös. Klassifitseerimise ja tegevuse lõpetamise vaheline lõhe on koht, kus ratsionaliseerimisprogrammid kaotavad oma hoo.

Kolm konkreetset takistust takistavad Eliminatsiooni elluviimist:

Varjatud sõltuvused. Rakendus klassifitseeriti Eliminate'iks selle näilise eraldiseisva staatuse tõttu. Pärast klassifitseerimist näitab struktuurianalüüs, et kaksteist muud programmi toodavad väljundit, mida Eliminate'i kandidaat töötleb, või et kolm välist süsteemi saadavad talle andmeid dokumenteerimata faililiidese kaudu. Rakendus ei ole iseseisev; see on teiste süsteemide peidetud infrastruktuur. Klassifikatsiooni tuleb uuesti läbi vaadata.

Andmete migreerimise blokeerijad. Rakendus sisaldab andmeid, mida ei saa hävitada, kohustuslike säilitusperioodidega regulatiivseid andmeid, kliendiandmeid, mis tuleb üle kanda järglassüsteemi, ja ajaloolisi tehinguandmeid, mille päringuid auditeeritakse igal aastal. Andmete migreerimine peab eelnema dekomisjoneerimisele ja see on kulukas.

Regulatiivsed kohustused. Mõnda rakendust ei saa isegi siis, kui selle äriväärtus on null, eemaldada, kuna regulatiivsed raamistikud nõuavad nende pakutavat võimalust. Aruandlusrakendusel, mis koostab kvartalisi regulatiivseid aruandeid, on regulatiivne väärtus, mis ei kajastu üheski äriväärtuse uuringus. Kuni regulatiivne kohustus ei ole teise süsteemi üle kantud, peab rakendus töötama.

Tõendusprobleem: miks TIME ilma struktuuriandmeteta ebaõnnestub

TIME rakenduste kõige olulisem ebaõnnestumisviis on see, mida Catio dokumentatsioon täpselt määratleb: paigutusega seotud argumendid algavad migreerimise ja kõrvaldamise juures, kus kaalul on kellegi lemmikrakendus. Ilma objektiivsete tõenditeta on iga klassifitseerimine läbirääkimiste küsimus. Rakenduse omanik pooldab investeerimist. IT-meeskond pooldab migreerimist. Finantsmeeskond soovib kõrvaldamist. Koosolek lõpeb talumisega, kuna see on kõige vähem vaieldav seisukoht.

Struktuursed tõendid lahendavad need läbirääkimised, asendades arvamuse mõõtmisega.

Tehnilise sobivuse hindamisel on olulised tõendid:

Tehnilise sobivuse indikaator	allikas	Liigutab klassifitseerimist suunas
Tsüklomaatiline keerukus programmi kohta (keskmine)	Staatilise koodi analüüs	Madal = parem sobivus, kõrge = halvem sobivus
Surnud koodi protsent	Saavutatavuse analüüs	Suur surnud kood = madalam sobivus
Sissetulevate sõltuvuste arv (ventilaator)	Sõltuvuste kaardistamine	Suur fännikogus suurendab taluvust üleliigse kõrvaldamise
Copybooki jagamise ulatus	KOOPIA sõltuvuse analüüs	Suur jagamine = suurem sidumine = madalam sobivus
Aeg viimasest olulisest muudatusest	Giti/muudatuste haldamise logi	Pikk seisvus võib viidata surnud koodile või stabiilsusele
Turvahaavatavuste arv	SAST-skannimine	Suur arv = madalam sobivus

Äriväärtuse hindamisel on olulised tõendid:

Äriväärtuse indikaator	allikas	Liigutab klassifitseerimist suunas
Tehingute maht perioodi kohta	JCL-i täitmislogid, ajakava kirjed	Suur maht = suurem väärtus
Allavoolu väljavool	Sõltuvuste kaardistamine	Suur ventilatsiooniulatus = suurem väärtus (paljud sõltuvad sellest)
Regulatiivse funktsiooni lipp	Andmete klassifitseerimine, vastavusregister	Olevik = minimaalne väärtuslävi olenemata muudest skooridest
Tulude lähedus	Andmevoo analüüs arveldus-/tulusüsteemidesse	Otsene külgnevus = suurem väärtus
Kasutajate või API-kõnede arv	Juurdepääsulogid, võrguliiklus	Suur arv = suurem väärtus

Oluline tähelepanek: pärand-COBOL-süsteemide puhul ei ole enamik neist indikaatoritest saadaval CMDB kirjetest, rakenduse omaniku intervjuudest ega võrguliikluse analüüsist. Need on saadaval lähtekoodi struktuurianalüüsist, täitmislogidest ja JCL-i töögraafikust, mis dokumenteerib, mis ja millal tegelikult tootmises töötab.

COBOL-i ja pärandsüsteemide tehnilise sobivuse hindamine

Standardsed tehnilise sobivuse hindamiskriteeriumid, API-ühilduvus, pilvepõhine valmisolek, konteinerdamise tugi ja mikroteenuste arhitektuur ei ole COBOL-i partiiprogrammide puhul olulised. COBOL-programmi ei saa konteinerdada; selle pilvepõhiste kriteeriumide alusel hindamine annab iga pärandprogrammi tehnilise sobivuse skooriks nulli, mis ei ütle organisatsioonile midagi kasulikku.

COBOLi ja suurarvutite puhul nõuab tehnilise sobivuse skoori arvutamine COBOLi-spetsiifilisi kriteeriume:

Keerukuse skoor (kaal: 30%): Programmi lõikude ja sektsioonide keskmine tsüklomaatiline keerukus. Programmid, mille keskmine CC on alla 10, on hallatava keerukusega; programmid, mille keskmine CC on üle 20, on struktuuriliselt keerulised, mis muudab hoolduse kalliks ja riskantseks.

Hooldatavuse skoor (kaal: 25%): surnud koodi protsendi, õpikute jagamise ulatuse ja dubleerimise määra liitnäitaja. Programmil, millel on 40% surnud koodi, 15 jagatud õpikut ja märkimisväärne koodi dubleerimine, on madal hooldatavus olenemata selle funktsionaalsest korrektsusest.

Sõltuvusriski skoor (kaal: 20%): sissetulevate ülalpeetavate kriitilisusega kaalutud sissetulevate ülalpeetavate arv. Programmil, millel on 50 sissetulevat sõltuvust 1. taseme programmidest, on kõrge sõltuvusrisk, selle muudatused nõuavad 50 allavoolu programmi koordineerimist.

Valuutahinnang (kaal: 15%): COBOL-dialekti ja kompilaatori versiooni ajakohasus, JCL-süntaksi kaasaegsus ja andmebaasiliides (manus SQL-i vanamoodne versioon, VSAM vs DB2, ainult partiipõhine vs partiipõhine+CICS). COBOL-85 süntaksis ja DB2 manus SQL-iga kirjutatud programmid on ajakohasemad kui COBOL-74 süntaksis ja ainult VSAM-ile tugineva failijuurdepääsuga kirjutatud programmid.

Turvalisuse skoor (kaal: 10%): kõvakodeeritud volituste olemasolu, kaitsmata failidele juurdepääs, FAILI OLEKU kontrolli puudumine ja SQL-i süstimise oht dünaamilises SQL-i konstruktsioonis.

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.

See hindamisvalem annab tehnilise sobivuse skaalal 0–100 skoori, mis on tuletatud struktuurikoodi analüüsist, mitte kvalitatiivsest hindamisest. Kaks rakendust, millel on identsed funktsioonid, kuid erinevad struktuurilised omadused, annavad erinevad tehnilise sobivuse skoori ning need skoorid kajastavad täpselt iga rakenduse hooldamiseks ja laiendamiseks vajalikke erinevaid investeeringuid.

Triivi talumise probleem: Holding Quadrandi juhtimine

Taluvus on kvadrant, mis akumuleerib aja jooksul võlga igas organisatsioonis, mis kasutab aega ilma selgesõnalise taluvuse juhtimiseta. Mehhanism on lihtne: rakendus siseneb taluvuse olekusse, kuna seda ei tasu muuta, ja seejärel jääb see taluvuse olekusse määramata ajaks, kuna selle muutmine pole kunagi kõige pakilisem prioriteet.

Taluva juhtimise distsipliin hoiab ära määramata ajaks edasilükkamise:

Tingimusel põhinevad ümberklassifitseerimise käivitajad:

• Tuvastatud turvanõrkus, mida ei saa 30 päeva jooksul parandada → vaadatakse üle migreerimise või kõrvaldamise eesmärgil
• Tarnija teatab platvormikomponendi, millest rakendus sõltub, eluea lõppemisest → migreerimise läbivaatamine
• Äriväärtuse skoor tõuseb üle lävendi (uus regulatiivne nõue, ärimudeli muutus) → Invest või Migrate läbivaatamine
• Sõltuvuste eemaldamine sunnib liidest muutma → vaadake üle migreerimine või kõrvaldamine
• Surnud koodi analüüs näitab, et rakendus on sisuliselt passiivne → Eliminate'i ülevaade

Ajapõhine arvustuse sagedus:

• Taotlused sisestatakse lubatavaks olekusse 12-kuulise läbivaatamise kuupäevaga
• 12-kuulise läbivaatamise käigus liigitatakse taotlus selgesõnaliselt ümber või antakse sellele uus 12-kuuline kuupäev.
• Taastaluvuse korral on vaja kirjalikku põhjendust, mis dokumenteerib, miks tingimused pole muutunud.
• Rakendus, millele on antud rohkem kui kaks korda uus luba ilma ümberklassifitseerimiseta, käivitab eskalatsiooni arhitektuuri läbivaatamise komisjonile.

Talustamisregister: Kõigist talumistaotlustest koosnev peetav nimekiri koos klassifitseerimiskuupäeva, läbivaatamise kuupäeva, omaniku ja ümberklassifitseerimise käivitava tingimusega. Seda registrit vaadatakse üle igal arhitektuuri läbivaatamise nõukogu koosolekul, mitte ainult iga-aastasel portfoolio läbivaatamisel.

Eliminate'i teostatavaks muutmine: dekomisjoneerimislünga täitmine

Lõhe „klassifitseeritud kui Eliminate” ja „edukalt dekomisjoneeritud” vahel on see, kus ratsionaliseerimisprogrammid takerduvad. Selle lõhe kaotamiseks tuleb iga Eliminate-otsust käsitleda projektina, millel on määratletud ulatus, sõltuvused ja edukriteeriumid, mitte järeldusena.

Elimineerimise teostamise kontroll-loend:

• Sõltuvuse kontrollimine on lõpetatud: Staatiline analüüs kinnitab sissetulevate tootmissõltuvuste nulli (mitte ainult dokumenteeritud sõltuvuste nulli, vaid struktuurilt kontrollitud nulli)
• Andmete käsutamise plaan kinnitatud: Regulatiivsed säilitamisnõuded on kindlaks tehtud, andmete migreerimise või arhiveerimiskava on õigus- ja vastavusosakonna poolt heaks kiidetud
• Allavoolu teavitus on valmis: Iga tarbiva süsteemi omanikku teavitati ja kinnitati aktiivse sõltuvuse puudumist
• Regulatiivse kohustuse kontroll on lõpule viidud: Rakendusest ei sõltu aktiivsed regulatiivsed esitamise, auditi ega vastavusnõuded.
• Dekomisjoneerimise omanik määratud: Nimetatud isik, kes vastutab dekomisjoneerimise teostamise, mitte ainult klassifitseerimisotsuse eest
• Tagasipööramise plaan määratletud: Teenuse taastamise kord, kui dekomisjoneerimise käigus ilmneb avastamata sõltuvus
• Käibest kõrvaldamise kuupäev: Konkreetne kuupäev IT-kalendris, mitte „millal me selleni jõuame“

Struktuurianalüüsi värav: Eliminate-otsuse puudumisel jätkatakse dekomisjoneerimise planeerimisega, kuni struktuurianalüüs kinnitab tootmise teostusradadelt tulevate sõltuvuste puudumist. Eliminate-teostamise nurjumise kõige levinum põhjus on sõltuvuse avastamine pärast dekomisjoneerimise teadaannet, mis sunnib tagasipööramist. Struktuurisõltuvuste analüüs enne teadaannet seda hoiab ära.

TIME ümberhindamise tsükkel

AJA-klassifikatsioonid ei ole püsivad. Äriväärtus muutub organisatsiooni strateegia arenedes. Tehniline sobivus muutub rakenduse hooldamisel, laiendamisel või vananemisel. Mudel on hetktõmmis; portfoolio vajab liikuvat pilti.

Iga-aastane täielik ümberhindamine: iga portfoolio taotlust hinnatakse praeguse äriväärtuse ja tehnilise sobivuse kriteeriumide alusel. Klassifikatsioone, mis pole kolme järjestikuse aasta jooksul muutunud, uuritakse eraldi, kas taotlus on tõeliselt stabiilne (dokumenteerige, miks) või ei kajasta hindamine toimuvaid muutusi.

Sündmuse käivitatud ümberhindamine: konkreetsed sündmused käivitavad viivitamatu ümberklassifitseerimise läbivaatamise:

• Ühinemine või omandamine (uus portfelli kombinatsioon)
• Nõuetele vastavust mõjutavad regulatiivsed muudatused
• Platvormi (andmebaas, operatsioonisüsteem, käituskeskkond) eluea lõppemise oluline teadaanne
• Oluline ärimudeli muutus (uus tootesari, turult lahkumine, organisatsiooniline ümberkorraldamine)
• Rakendusega seotud turvaintsident

Muudatuste logi: Iga ümberklassifitseerimine logitakse koos järgmisega: eelmine klassifikatsioon, uus klassifikatsioon, kuupäev, muudatuse aluseks olevad tõendid ja kinnitaja. Iga taotluse klassifitseerimise ajalugu on auditeerimisjälg, mis näitab, et portfooliot hallatakse aktiivselt, mitte ei kategoriseerita ja unustata.

Kuidas SMART TS XL Annab tõendeid TIME klassifikatsiooni kohta

TIME mudeli klassifitseerimisotsused on sama head kui nende aluseks olevad tõendid. Kaasaegsete rakenduste puhul, millel on CMDB katvus, API jälgimine ja dokumenteeritud arhitektuurid, on need tõendid kättesaadavad. Vananenud COBOL-portfellide puhul, kus CMDB on mittetäielik, omanikud on pensionil ja sõltuvusstruktuur on dokumenteerimata, peavad tõendid pärinema koodi enda struktuurianalüüsist.

SMART TS XL'S staatilise koodi analüüs annab tehnilise sobivuse sisendandmed, mida COBOL-i hindamine nõuab: programmi tsüklomaatiline keerukus, surnud koodi protsent, turvamustrite leiud (kõvakodeeritud volitused, kaitsmata failidele juurdepääs) ja COBOL-i dialekti valuuta. Need mõõdikud tuletatakse lähtekoodist, mitte arendaja hinnangutest, ja need ei sõltu sellest, kas keegi mäletab, mida rakendus teeb.

Rakenduse sõltuvuste kaardistamine loob sisse- ja väljalülitusloendused, mis takistavad enneaegseid Eliminate'i otsuseid, ja väljalülitusloendused, mis toetavad äriväärtuse hindamist. Rakendus, millel on 45 sissetulevat sõltuvust tootmisprogrammidest, ei ole turvaline Eliminate'i kandidaat, olenemata sellest, kuidas selle omanik selle äriväärtust hindab. Sõltuvuste arv on struktuuriline fakt, mis tühistab klassifitseerimisargumendi.

Pärandi moderniseerimise analüüs loob surnud koodi inventuuri, mis muudab klassifikatsioone: programmid, mis kuvatakse CMDB-s aktiivsete rakendustena, kuid millel pole sissetulevaid tootmissõltuvusi, on surnud koodi kandidaadid, mis liigitatakse ümber talutavast kategooriast elimineeritavaks struktuuriliste tõendite põhjal, mitte ettevõtte omaniku hinnangu põhjal programmi kohta, mille olemasolust nad poleks kunagi teadnud.

Mõjuanalüüsi võimalus muudab Eliminate'i teostusloendi teostatavaks: struktuurianalüüs, mis kinnitab sissetulevate tootmissõltuvuste puudumist enne mis tahes dekomisjoneerimise planeerimise alustamist. See on värav, mis hoiab ära kõige levinuma Eliminate'i teostusvea – avastamata sõltuvuse, mis ilmneb pärast väljakuulutamist.

Ettevõtte otsinguvõimalus muudab TIME klassifitseerimisprotsessi päringutega hõlpsasti hallatavaks kogu ümberhindamistsükli vältel: leia iga rakendus, mis on klassifitseeritud talutavaks ja mille läbivaatamise kuupäev on järgmise 30 päeva jooksul; iga rakendus, mis on klassifitseeritud kõrvaldatavaks ja millel pole määratud deaktiveerimise kuupäeva; iga rakendus, mille tehniline sobivusskoor on alla 30 ja mis on endiselt klassifitseeritud investeerimisrakenduseks. Need päringud on juhtimisvahend, mis hoiab TIME mudeli aktiivse haldusinstrumendina, mitte ühekordse klassifitseerimisharjutusena.

Raamistik on sama hea kui selle tõendid

TIME mudeli kaheteljeline struktuur on õige. Äriväärtus ja tehniline sobivus on rakenduste portfelli otsuste tegemisel õiged dimensioonid. Need neli dispositsiooni on õiged valikud. Probleem ei ole raamistikus, vaid tõendusbaasis, mida organisatsioonid sellele pakuvad.

Intervjuuandmetel ja CMDB hinnangutel põhinevad klassifikatsioonid tekitavad organisatsioonilisi vaidlusi. Struktuurianalüüsil, mõõdetud keerukusel, kontrollitud sõltuvuste arvul ja koodist tuletatud tehnilisel sobivusel põhinevad klassifikatsioonid annavad tulemuseks põhjendatud otsused. Rakenduse omanikul, kes väidab, et tema COBOL-programm on pigem investeerimis- kui migreerimisstrateegia, on raskem juhtum, kui struktuurianalüüs näitab tsüklomaatilist keerukust keskmiselt 35, 40% surnud koodi ja 12 turvaleiu. IT-meeskonnal, kes väidab, et programmi saab elimineerida, on nõrgem juhtum, kui sõltuvuste analüüs näitab 45 sissetulevat tootmissõltuvust.

TIME mudel toimib siis, kui tõendid seda kinnitavad. Rakenduste portfelli struktuurianalüüs on see, kuidas organisatsioonid koguvad tõendeid pärandrakenduste kohta, mis vajavad kõige rohkem ratsionaliseerimisotsuseid ja millel on kõige vähem tõenäoliselt dokumentatsiooni, mis neid otsuseid lihtsustaks.