TIME-Modell (Tolerieren, Investieren, Migrieren, Eliminieren) für App-Portfolios

Das Meeting zur Anwendungsrationalisierung beginnt um 9 Uhr. Bis 11 Uhr hat das Team zwölf der vierhundert relevanten Anwendungen klassifiziert. Drei dieser zwölf Klassifizierungen wurden bereits angefochten, überarbeitet und erneut angefochten. Das COBOL-Batchprogramm für die Gehaltsabrechnung ist eindeutig nicht zu eliminieren, aber sollte es toleriert oder in die Zukunft investiert werden? Das veraltete Abrechnungssystem, das allgemein als technisch unzureichend gilt, ist eindeutig zu migrieren, aber wohin soll migriert werden, und was geschieht mit den siebzehn Programmen, die davon abhängen? Das Meeting ist bis Mittag angesetzt. Um 12 Uhr schlägt jemand vor, es nächste Woche fortzusetzen. Im darauffolgenden Monat hat die Initiative stillschweigend ihre Arbeit eingestellt.

Das Gartner TIME-Modell ist das am weitesten verbreitete Framework für das Anwendungsportfoliomanagement in der Unternehmens-IT. Es ordnet jede Anwendung im Portfolio anhand zweier Bewertungskriterien – Geschäftswert und technische Eignung – einer von vier Kategorien zu: Tolerieren, Investieren, Migrieren und Eliminieren. Das Framework ist logisch fundiert, breit anwendbar und wird vom US Federal CIO Council in seinem „Application Rationalization Playbook“ als empfohlene Methodik angeführt. In der Praxis scheitert es jedoch häufiger als es erfolgreich ist. Der Grund dafür wird von den Befürwortern des Frameworks zwar genannt, aber selten näher erläutert: Die Klassifizierungen sind nur so gut wie die zugrunde liegenden Daten. Ohne strukturelle Belege, tatsächliche Abhängigkeitsanalysen, reale Komplexitätsmessungen und reale Daten zum Geschäftswert, die aus Ausführungsprotokollen statt aus Interviews mit den Verantwortlichen gewonnen werden, verkommen die TIME-Klassifizierungen zu einem Instrument der internen Politik. Diskussionen über die Platzierung beginnen bei den Kategorien „Migrieren“ und „Eliminieren“, wo die Lieblingsanwendung eines Mitarbeiters auf dem Spiel steht, und führen nie zu einer Lösung.

Das Modell: Zwei Achsen, vier Dispositionen

Das TIME-Modell stellt jede Anwendung in einer 2×2-Matrix dar. Die horizontale Achse zeigt die technische Passung an, also wie gut die aktuelle technische Implementierung der Anwendung ihre beabsichtigte Funktion unterstützt: Architekturqualität, Wartbarkeit, Integrationsfähigkeit, Sicherheitsstatus und Betriebssicherheit. Die vertikale Achse repräsentiert den Geschäftswert, also wie wichtig die Funktion der Anwendung für die Geschäftstätigkeit, die Umsatzgenerierung, die Einhaltung gesetzlicher Bestimmungen oder die strategischen Ziele des Unternehmens ist.

	Hochwertige technische Passform	Niedrige technische Passform
Hoher Geschäftswert	INVESTITIONFinanzieren Sie es. Die Anwendung ist sowohl strategisch wichtig als auch technisch ausgereift. Investieren Sie, um ihre Führungsposition zu sichern.	WANDERNDas Unternehmen braucht es, die Technologie ist ungeeignet. Ersetzen Sie die Plattform, nicht die Funktion.
Geringer Geschäftswert	TOLERIERENLassen Sie es vorerst so. Die Anwendung ist zwar gut, aber keine weitere Investition wert.	BESEITIGENWeg damit! Geringer Wert, schlechte Qualität, kein Grund, es zu behalten.

Die Einfachheit ist beabsichtigt. TIME ist nicht für detaillierte Investitionsplanung konzipiert, sondern für eindeutige Richtungsentscheidungen für jede Anwendung im Portfolio. Eine Anwendung, die sich nicht eindeutig zuordnen lässt, benötigt weitere Informationen, bevor eine Klassifizierung möglich ist.

Die Vier-Quadranten-Betriebsmodelle

Jede TIME-Disposition ist nicht nur eine Bezeichnung, sondern ein Betriebsmodell, das festlegt, wie die Organisation die Anwendung künftig verwaltet.

Investieren: Maximale Wertschöpfung

Invest-Anwendungen sind die Kronjuwelen des Portfolios: hoher Geschäftswert und hervorragende technische Ausstattung. Sie rechtfertigen die umfangreichsten Investitionen in neue Funktionen, Leistungsoptimierung, Integrationserweiterung und die Aktualisierung der technischen Aktualität. Eine Invest-Anwendung, die in puncto technischer Aktualität, veralteter Laufzeitumgebung, überholter Sicherheitsarchitektur oder zunehmender Abhängigkeiten hinterherhinkt, riskiert, in die Migrationsphase zu geraten, bevor der Verfall überhaupt bemerkt wird.

Operative Verpflichtungen für Invest:

• Eigene Entwicklungskapazitäten für Funktionsentwicklung und technische Wartung
• Sicherheitspatches und Compliance-Updates mit höchster Priorität
• Prüfung durch den Architekturausschuss für jede bedeutende Änderung
• Proaktives Monitoring mit SLA-Zielen auf Tier-1-Ebene

Migration: Plattform ersetzen, Funktion erhalten

Die zu migrierenden Anwendungen erfüllen eine für das Unternehmen dringend notwendige Geschäftsfunktion, laufen aber auf einer technischen Plattform, die nicht mehr zeitgemäß, zu wartungsintensiv, zu fehleranfällig für Erweiterungen und zu stark von modernen Integrationslandschaften abgekoppelt ist. Der geschäftliche Nutzen rechtfertigt die Investition in die Migration; der technische Zustand macht weitere Investitionen in die aktuelle Plattform jedoch unrentabel.

Die Migrationsdisposition beantwortet eine konkrete Frage: Ist die Funktion erhaltenswert? Wenn ja, migrieren Sie. Wohin migriert werden soll und wie, ist eine separate Entscheidung, die die TIME-Klassifizierung nicht trifft; sie stellt lediglich fest, dass die aktuelle Plattform nicht die Lösung ist.

Das häufigste Migrationsszenario in Legacy-Systemen: Ein COBOL-Batchprogramm implementiert kritische Geschäftslogik, komplexe regulatorische Berechnungen, proprietäre Preisregeln und länderspezifische Steuerlogik auf einer Plattform, deren Erweiterung, Test und Integration kostspielig sind. Die Logik ist unersetzlich; die Plattform ist das Problem. Migrieren Sie zu einer modernen Plattform, die die Logik beibehält und gleichzeitig die für Ihr Unternehmen erforderlichen operativen Eigenschaften bietet.

Tolerieren: Vorsätzliches Nichtstun mit einem Ablaufdatum

Tolerieren ist der am meisten missverstandene Quadrant. Es bedeutet nicht „Diese Anwendung ist in Ordnung“. Es bedeutet vielmehr: „Die technische Qualität dieser Anwendung rechtfertigt derzeit keine Investition in eine Änderung, und ihr Geschäftswert rechtfertigt nicht ihre Abschaffung.“ Es ist eine bewusste Entscheidung, den Status quo für einen bestimmten Zeitraum zu akzeptieren, keine unbefristete Verschiebung.

„Tolerieren“ ist ein zeitlich begrenzter Haltezeitpunkt, kein Dauerzustand. Jede Anwendung im Tolerierungsquadranten sollte ein explizites Überprüfungsdatum (typischerweise 12 bis 18 Monate) und definierte Bedingungen haben, die eine vorzeitige Neuklassifizierung auslösen: eine nicht behebbare Sicherheitslücke, die Abschaffung einer Abhängigkeit, die einen Plattformwechsel erfordert, eine Wertsteigerung, die eine Investition in die Anwendung lohnenswert macht, oder eine Änderung der Geschäftsfunktion, die ihren Zweck aufhebt.

Organisationen, die „Tolerieren“ als permanenten Zustand betrachten, häufen genau die technischen Schulden an, die das TIME-Modell eigentlich verhindern sollte. Ein COBOL-Programm, das 2019 als „Tolerieren“ eingestuft wurde und sich 2026 immer noch im „Tolerieren“-Quadranten befindet, hat sieben weitere Jahre aufgeschobener Wartung erhalten, die es früher oder später benötigen wird – entweder im Notfall, wenn etwas kaputtgeht, oder im Rahmen einer erzwungenen Migration, wenn die Plattform nicht mehr unterstützt werden kann.

Eliminieren: Die Entscheidung, die jeder trifft und niemand umsetzt

Die Eliminierung ist die einfachste Klassifizierung und die am seltensten angewandte Maßnahme. Die Anwendung hat einen geringen Geschäftswert und eine geringe technische Eignung; es gibt keinen Grund, sie beizubehalten. Sie sollte stillgelegt werden.

Das Scheitern der Umsetzung ist gut dokumentiert: Eliminierungskandidaten werden zwar enthusiastisch ausgewählt, aber so gut wie nie tatsächlich umgesetzt. Eine Portfolioüberprüfung im Jahr 2024 bei einem großen Finanzinstitut ergab 87 Eliminierungskandidaten. Achtzehn Monate später waren 71 davon noch immer aktiv. In der Zeitspanne zwischen der Klassifizierung und der Stilllegung verlieren Rationalisierungsprogramme an Dynamik.

Drei spezifische Hindernisse verhindern die Eliminierung der Ausführung:

Versteckte Abhängigkeiten. Die Anwendung wurde aufgrund ihres scheinbar eigenständigen Status als „Eliminieren“ klassifiziert. Eine anschließende Strukturanalyse zeigt jedoch, dass zwölf weitere Programme Ausgaben erzeugen, die von der Anwendung verarbeitet werden, oder dass drei externe Systeme Daten über eine undokumentierte Dateischnittstelle an sie senden. Die Anwendung ist nicht eigenständig; sie bildet die verborgene Infrastruktur für andere Systeme. Die Klassifizierung muss überdacht werden.

Hindernisse bei der Datenmigration. Die Anwendung enthält Daten, die nicht gelöscht werden dürfen, behördliche Unterlagen mit vorgeschriebenen Aufbewahrungsfristen, Kundendaten, die in ein Nachfolgesystem übertragen werden müssen, sowie historische Transaktionsdaten, die jährlich von Prüfprozessen abgefragt werden. Die Datenmigration muss vor der Außerbetriebnahme erfolgen und ist kostspielig.

Regulatorische Verpflichtungen. Manche Anwendungen können selbst dann nicht außer Betrieb genommen werden, wenn ihr Geschäftswert null ist, da regulatorische Rahmenbedingungen die von ihnen bereitgestellten Funktionen erfordern. Eine Anwendung, die vierteljährliche Meldungen an die Aufsichtsbehörden erstellt, hat einen regulatorischen Wert, der in keiner Geschäftswertanalyse erscheint. Solange die regulatorische Verpflichtung nicht auf ein anderes System übertragen wird, muss die Anwendung ausgeführt werden.

Das Beweisproblem: Warum TIME ohne Strukturdaten versagt

Der gravierendste Fehler bei TIME-Implementierungen ist genau das, was die Catio-Dokumentation beschreibt: Die Diskussionen um die Platzierung beginnen bei „Migrieren“ und „Eliminieren“, wo die Lieblingsanwendung einer Person auf dem Spiel steht. Ohne objektive Beweise ist jede Klassifizierung eine Verhandlung. Der Anwendungsinhaber plädiert für „Investieren“. Das IT-Team plädiert für „Migrieren“. Das Finanzteam möchte „Eliminieren“. Die Besprechung endet mit „Tolerieren“, weil dies die am wenigsten strittige Position ist.

Strukturelle Evidenz löst diese Verhandlungen, indem sie Meinungen durch Messungen ersetzt.

Für die Bewertung der technischen Passform sind folgende Nachweise relevant:

Technischer Passformindikator	Quelle	Verschiebt die Klassifizierung in Richtung
Zyklomatische Komplexität pro Programm (Durchschnitt)	Statische Code-Analyse	Niedrig = höhere Passform, Hoch = geringere Passform
Prozentsatz an totem Code	Erreichbarkeitsanalyse	Hoher Totcode = niedrigere Anpassung
Fan-in (Anzahl der eingehenden Abhängigkeiten)	Abhängigkeitszuordnung	Hoher Fan-in-Wert erhöht die Toleranz gegenüber der Eliminierung
Breite des Copybook-Sharings	COPY-Abhängigkeitsanalyse	Hohes Sharing = höhere Kopplung = geringere Passung
Zeit seit der letzten bedeutsamen Änderung	Git-/Änderungsmanagement-Protokoll	Lange Ruhephase kann auf toten Code oder Stabilität hindeuten.
Anzahl der Sicherheitslücken	SAST-Scan	Hohe Zählrate = geringere Passform

Für die Bewertung des Geschäftswerts sind folgende Nachweise entscheidend:

Geschäftswertindikator	Quelle	Verschiebt die Klassifizierung in Richtung
Transaktionsvolumen pro Periode	JCL-Ausführungsprotokolle, Scheduler-Aufzeichnungen	Hohes Volumen = höherer Wert
Downstream-Fan-Out	Abhängigkeitszuordnung	Hoher Fan-Out = höherer Wert (viele hängen davon ab)
Kennzeichen für Regulierungsfunktion	Datenklassifizierung, Konformitätsregister	Gegenwart = Mindestwert unabhängig von anderen Werten
Umsatznachbarschaft	Datenflussanalyse zu Abrechnungs-/Einnahmesystemen	Direkte Nachbarschaft = höherer Wert
Benutzeranzahl oder API-Aufrufanzahl	Zugriffsprotokolle, Netzwerkverkehr	Hohe Anzahl = höherer Wert

Die entscheidende Erkenntnis: Bei älteren COBOL-Systemen lassen sich die meisten dieser Indikatoren nicht über CMDB-Einträge, Interviews mit Anwendungsbetreibern oder Netzwerkverkehrsanalysen gewinnen. Sie sind jedoch durch die Strukturanalyse des Quellcodes, der Ausführungsprotokolle und des JCL-Jobplans verfügbar, der dokumentiert, was in der Produktion wann tatsächlich ausgeführt wird.

Bewertung der technischen Eignung für COBOL- und Legacy-Systeme

Standardmäßige Kriterien für die technische Eignung – API-Kompatibilität, Cloud-native-Fähigkeit, Containerisierungsunterstützung, Microservices-Architektur – sind für COBOL-Batchprogramme irrelevant. Ein COBOL-Programm lässt sich nicht containerisieren; die Bewertung anhand von Cloud-nativen Kriterien führt für jedes dieser Programme zu einer technischen Eignung von null Punkten, was dem Unternehmen keinerlei nützliche Informationen liefert.

Für COBOL- und Mainframe-Systeme erfordert die Bewertung der technischen Eignung COBOL-spezifische Kriterien:

Komplexitätswert (Gewichtung: 30 %): Durchschnittliche zyklomatische Komplexität der Absätze und Abschnitte des Programms. Programme mit einem durchschnittlichen Komplexitätswert unter 10 weisen eine überschaubare Komplexität auf; Programme mit einem Wert über 20 weisen eine strukturelle Komplexität auf, die die Wartung aufwändig und riskant macht.

Wartbarkeitswert (Gewichtung: 25 %): Zusammensetzung aus Anteil ungenutzten Codes, Umfang der Copybook-Nutzung und Duplikationsrate. Ein Programm mit 40 % ungenutztem Code, 15 gemeinsam genutzten Copybooks und erheblicher Code-Duplizierung weist unabhängig von seiner funktionalen Korrektheit eine geringe Wartbarkeit auf.

Risikobewertung für Abhängigkeiten (Gewichtung: 20 %): Anzahl der eingehenden Abhängigkeiten, gewichtet nach deren Kritikalität. Ein Programm mit 50 eingehenden Abhängigkeiten aus Programmen der Stufe 1 weist ein hohes Abhängigkeitsrisiko auf; Änderungen daran erfordern die Koordination von 50 nachgelagerten Programmen.

Aktualitätsbewertung (Gewichtung: 15 %): Aktualität des COBOL-Dialekts und der Compilerversion, Aktualität der JCL-Syntax und Datenbankschnittstelle (Alter des eingebetteten SQL, VSAM vs. DB2, reine Batchverarbeitung vs. Batchverarbeitung + CICS). Programme in COBOL-85-Syntax mit eingebettetem DB2-SQL sind aktueller als Programme in COBOL-74 mit reinem VSAM-Dateizugriff.

Sicherheitsstatusbewertung (Gewichtung: 10%): Vorhandensein fest codierter Anmeldeinformationen, ungeschützter Dateizugriff, fehlende Überprüfung des Dateistatus und Gefährdung durch SQL-Injection bei der dynamischen 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.

Diese Bewertungsformel liefert einen technischen Eignungswert von 0 bis 100, der auf der Analyse von Bauvorschriften und nicht auf einer qualitativen Beurteilung basiert. Zwei Anwendungen mit identischen Funktionen, aber unterschiedlichen strukturellen Eigenschaften, ergeben unterschiedliche technische Eignungswerte, die den jeweils erforderlichen Investitionsaufwand für Instandhaltung und Erweiterung präzise widerspiegeln.

Das Problem der tolerierten Drift: Governance für den Holding-Quadranten

Der Bereich „Toleranz“ ist derjenige, in dem sich in jeder Organisation, die TIME ohne explizite Toleranzsteuerung nutzt, mit der Zeit Schulden anhäufen. Der Mechanismus ist einfach: Eine Anwendung gelangt in den Bereich „Toleranz“, weil sie sich nicht zu ändern lohnt, und verbleibt dort auf unbestimmte Zeit, da ihre Änderung nie höchste Priorität hat.

Eine tolerante Governance-Disziplin verhindert unbefristete Aufschiebung:

Auslöser für zustandsbasierte Reklassifizierungen:

• Sicherheitslücke identifiziert, die nicht innerhalb von 30 Tagen behoben werden kann → Prüfung auf Migration oder Eliminierung
• Der Anbieter kündigt das Ende des Lebenszyklus einer Plattformkomponente an, von der die Anwendung abhängt → Überprüfung für Migration
• Der Geschäftswert steigt über den Schwellenwert (neue regulatorische Anforderung, Änderung des Geschäftsmodells) → Prüfung auf Investition oder Migration
• Die Änderung der Schnittstelle aufgrund der Abhängigkeitsrente erfordert eine Anpassung → Überprüfung auf Migration oder Eliminierung
• Die Analyse des toten Codes zeigt, dass die Anwendung praktisch inaktiv ist → Überprüfung auf Eliminierung

Zeitbasierte Überprüfungsfrequenz:

• Bewerbungen werden bei Tolerate mit einer 12-monatigen Überprüfungsfrist eingereicht.
• Bei der Überprüfung nach 12 Monaten wird der Antrag explizit neu klassifiziert oder explizit erneut toleriert, mit einem neuen Gültigkeitsdatum nach 12 Monaten.
• Für eine erneute Toleranz ist eine schriftliche Begründung erforderlich, die dokumentiert, warum sich die Bedingungen nicht geändert haben.
• Ein Antrag, der mehr als zweimal ohne Neuklassifizierung erneut toleriert wurde, führt zu einer Eskalation an den Architekturprüfungsausschuss.

Das Tolerate-Register: Eine Liste aller Tolerate-Anwendungen mit Klassifizierungsdatum, Überprüfungsdatum, Eigentümer und den Bedingungen für eine mögliche Neuklassifizierung. Dieses Register wird in jeder Sitzung des Architekturprüfungsausschusses geprüft, nicht nur bei der jährlichen Portfolioüberprüfung.

Eliminate umsetzbar machen: Die Stilllegungslücke schließen

Die Lücke zwischen „als auszumustern“ und „erfolgreich stillgelegt“ ist der Punkt, an dem Rationalisierungsprogramme ins Stocken geraten. Um diese Lücke zu schließen, muss jede Ausmusterungsentscheidung als Projekt mit definiertem Umfang, Abhängigkeiten und Erfolgskriterien behandelt werden, nicht als abgeschlossenes Ergebnis.

Die Eliminierungs-Checkliste:

• Abhängigkeitsprüfung abgeschlossen: Die statische Analyse bestätigt, dass keine eingehenden Produktionsabhängigkeiten bestehen (nicht nur keine dokumentierten Abhängigkeiten, sondern strukturell verifizierte Null).
• Datenlöschplan genehmigt: Regulatorische Aufbewahrungspflichten identifiziert, Datenmigrations- oder Archivierungsplan von der Rechts- und Compliance-Abteilung genehmigt
• Benachrichtigung der nachgelagerten Systeme abgeschlossen: Jeder Eigentümer des konsumierenden Systems wurde benachrichtigt und bestätigt, dass keine aktive Abhängigkeit besteht.
• Prüfung der regulatorischen Verpflichtungen abgeschlossen: Für die Anwendung sind keine aktiven behördlichen Einreichungs-, Prüfungs- oder Compliance-Anforderungen erforderlich.
• Stilllegungsbeauftragter zugewiesen: Benannte Person, die für die Durchführung der Stilllegung verantwortlich ist, nicht nur für die Klassifizierungsentscheidung
• Rollback-Plan definiert: Vorgehensweise zur Wiederherstellung des Dienstes, falls die Stilllegung eine unentdeckte Abhängigkeit aufdeckt
• Festgelegter Stilllegungstermin: Ein konkretes Datum im IT-Kalender, nicht „wenn wir dazu kommen“.

Die strukturelle Analyse: Die Entscheidung „Eliminieren“ wird erst dann zur Stilllegungsplanung weitergeleitet, wenn eine strukturelle Analyse bestätigt, dass keine eingehenden Abhängigkeiten aus den Produktionsausführungspfaden bestehen. Die häufigste Ursache für das Fehlschlagen der Eliminierungsausführung ist das Entdecken einer Abhängigkeit nach der Stilllegungsankündigung, die eine Rücksetzung erzwingt. Eine strukturelle Abhängigkeitsanalyse vor der Ankündigung verhindert dies.

Der TIME-Neubewertungszyklus

Zeitklassifizierungen sind nicht statisch. Der Geschäftswert ändert sich mit der Weiterentwicklung der Unternehmensstrategie. Die technische Eignung ändert sich, wenn die Anwendung gewartet, erweitert oder altert. Das Modell ist eine Momentaufnahme; das Portfolio erfordert eine dynamische Betrachtung.

Jährliche vollständige Neubewertung: Jede Anwendung im Portfolio wird anhand des aktuellen Geschäftswerts und der Kriterien für die technische Eignung bewertet. Klassifizierungen, die sich drei Jahre in Folge nicht geändert haben, werden gesondert geprüft. Dabei wird entweder festgestellt, dass die Anwendung tatsächlich stabil ist (bitte begründen), oder die Bewertung erfasst die aktuellen Veränderungen nicht.

Ereignisgesteuerte Neubewertung: Bestimmte Ereignisse lösen eine sofortige Überprüfung der Neuklassifizierung aus:

• Fusion oder Übernahme (neue Portfoliozusammenstellung)
• Regulatorische Änderungen mit Auswirkungen auf die Compliance-Verpflichtungen
• Ankündigung des Lebenszyklusendes wichtiger Plattformen (Datenbank, Betriebssystem, Laufzeitumgebung)
• Wesentliche Änderung des Geschäftsmodells (neue Produktlinie, Marktaustritt, Umstrukturierung der Organisation)
• Sicherheitsvorfall im Zusammenhang mit der Anwendung

Disziplin bei Änderungsprotokollen: Jede Umklassifizierung wird protokolliert mit: vorheriger Klassifizierung, neuer Klassifizierung, Datum, Begründung für die Änderung und Genehmiger. Die Klassifizierungshistorie jeder Anwendung dient als Prüfprotokoll und belegt, dass das Portfolio aktiv verwaltet und nicht einfach kategorisiert und dann vergessen wird.

Wie SMART TS XL Liefert die Beweise für die TIME-Klassifizierung

Die Klassifizierungsentscheidungen des TIME-Modells sind nur so gut wie die zugrunde liegenden Beweise. Bei modernen Anwendungen mit CMDB-Abdeckung, API-Überwachung und dokumentierten Architekturen sind diese Beweise verfügbar. Bei älteren COBOL-Portfolios, in denen die CMDB unvollständig ist, die Verantwortlichen nicht mehr im Amt sind und die Abhängigkeitsstruktur nicht dokumentiert ist, müssen die Beweise aus der Strukturanalyse des Codes selbst gewonnen werden.

SMART TS XL statische Code-Analyse Es liefert die für die COBOL-Bewertung erforderlichen technischen Kennwerte: zyklomatische Komplexität pro Programm, Anteil ungenutzten Codes, Sicherheitsanalysen (fest codierte Anmeldeinformationen, ungeschützter Dateizugriff) und Aktualität des COBOL-Dialekts. Diese Metriken werden aus dem Quellcode abgeleitet, nicht aus Schätzungen von Entwicklern, und sie sind unabhängig davon, ob sich jemand an die Funktionsweise der Anwendung erinnert.

Die Abbildung der Anwendungsabhängigkeiten liefert die Anzahl der eingehenden Abhängigkeiten, die voreilige Eliminierungsentscheidungen verhindern, sowie die Anzahl der ausgehenden Abhängigkeiten, die die Bewertung des Geschäftswerts unterstützen. Eine Anwendung mit 45 eingehenden Abhängigkeiten aus Produktionsprogrammen ist unabhängig von der Bewertung ihres Geschäftswerts durch den Eigentümer kein sicherer Eliminierungskandidat. Die Anzahl der Abhängigkeiten ist die strukturelle Tatsache, die das Klassifizierungsargument außer Kraft setzt.

Die Analyse der Legacy-Modernisierung erzeugt ein Inventar des toten Codes, das zu Änderungen der Klassifizierungen führt: Programme, die in der CMDB als aktive Anwendungen erscheinen, aber keine eingehenden Produktionsabhängigkeiten aufweisen, sind Kandidaten für toten Code und werden aufgrund struktureller Beweise von „Tolerieren“ auf „Eliminieren“ umklassifiziert, nicht aufgrund der Einschätzung des Geschäftsinhabers über ein Programm, von dessen Existenz er möglicherweise nie etwas gewusst hat.

Die Auswirkungsanalyse ermöglicht die Umsetzung der Checkliste zur Eliminierung: die Strukturanalyse, die sicherstellt, dass vor Beginn der Stilllegungsplanung keine Abhängigkeiten von der eingehenden Produktion bestehen. Dies ist die entscheidende Hürde, um den häufigsten Fehler bei der Eliminierung zu verhindern – die unentdeckte Abhängigkeit, die erst nach der Ankündigung auftritt.

Die unternehmensweite Suchfunktion ermöglicht die Abfrage des TIME-Klassifizierungsprozesses während des gesamten Neubewertungszyklus: Finden Sie alle als „Tolerieren“ klassifizierten Anwendungen mit einem Überprüfungsdatum innerhalb der nächsten 30 Tage, alle als „Eliminieren“ klassifizierten Anwendungen ohne zugewiesenes Außerbetriebnahmedatum sowie alle Anwendungen mit einem technischen Eignungswert unter 30, die noch als „Investieren“ klassifiziert sind. Diese Abfragen sind das Steuerungsinstrument, das sicherstellt, dass das TIME-Modell ein aktives Managementinstrument und nicht nur eine einmalige Klassifizierungsübung bleibt.

Ein Rahmenwerk ist nur so gut wie seine Beweise.

Die Zwei-Achsen-Struktur des TIME-Modells ist korrekt. Geschäftswert und technische Passung sind die richtigen Dimensionen für Entscheidungen über Anwendungsportfolios. Die vier Dispositionen sind die richtigen Optionen. Das Problem liegt nicht im Rahmenwerk selbst, sondern in der Datengrundlage, die Organisationen einbringen.

Klassifizierungen, die auf Interviewdaten und CMDB-Schätzungen basieren, führen zu internen Diskussionen. Klassifizierungen, die auf Strukturanalysen, gemessener Komplexität, verifizierten Abhängigkeitsanzahlen und aus dem Code abgeleiteter technischer Eignung beruhen, ermöglichen hingegen fundierte Entscheidungen. Der Anwendungsinhaber, der argumentiert, sein COBOL-Programm sei eher eine Investitions- als eine Migrationsmaßnahme, hat es schwerer, wenn die Strukturanalyse eine durchschnittliche zyklomatische Komplexität von 35, 40 % ungenutzten Code und 12 Sicherheitslücken aufzeigt. Das IT-Team, das die Eliminierung eines Programms befürwortet, hat weniger Argumente, wenn die Abhängigkeitsanalyse 45 eingehende Produktionsabhängigkeiten aufdeckt.

Das TIME-Modell funktioniert, wenn die Beweislage die Argumentation stützt. Die Strukturanalyse des Anwendungsportfolios ist der Weg, wie Unternehmen diese Beweislage für die Legacy-Anwendungen schaffen, die am dringendsten Rationalisierungsentscheidungen erfordern und bei denen die Dokumentation, die diese Entscheidungen erleichtert, am wenigsten wahrscheinlich vorhanden ist.