Anwendungsportfolio und Rationalisierung: wo man anfängt

Mit dem Inventar beginnen

Tabellen weichen voneinander ab, Verantwortliche wechseln, und niemand weiß mehr, welche Anwendungen ihren Platz noch verdienen. Application Portfolio Management führt ein einziges Inventar und behandelt Anwendungen wie ein Portfolio, das gemessen, verglichen und neu ausbalanciert wird.

Für jede Anwendung nennt das Inventar, wer verantwortlich ist, welcher Anbieter sie liefert, wo sie im Lebenszyklus steht, was sie kostet, in welchem Zustand sie ist und was von ihr abhängt. Die Rationalisierung stützt sich auf dieses Inventar.

Die Informationen, die Entscheidungen tragen

Eine Liste sagt, was das Unternehmen besitzt. Das Portfolio ergänzt die Informationen, die Entscheidungen tragen, und erhebt sie in regelmäßigen Abständen. Ohne sie beginnt bei jeder Vertragsverlängerung, jedem Audit und jeder Transformation dieselbe Rekonstruktionsarbeit.

In ArchiLU ist jede Anwendung mit ihren Fähigkeiten, Prozessen, Schnittstellen, Technologien und Verträgen verbunden: Bevor sie geändert wird, sieht die verantwortliche Person, was von ihr abhängt. Alle zwölf Monate erhält jede verantwortliche Person eine Aufgabe, um ihre Objekte zu bestätigen.

• Verantwortung: eine benannte verantwortliche Person je Anwendung, fachlich und in der IT.
• Abhängigkeit von Anbietern: von welchen Herstellern das Unternehmen abhängt und wie konzentriert diese Abhängigkeit ist.
• Technologien: der Stack hinter jeder Anwendung und die Versionen, deren Support endet.
• Lebenszyklus: vom Pilot über den Betrieb bis zur Stilllegung.
• Abhängigkeiten: wer was aufruft, damit nichts blind stillgelegt wird.
• Verträge und Kosten: Lizenzen, Laufzeiten und Verlängerungen.

Rationalisierung als wiederkehrende Entscheidung

Die Rationalisierung entscheidet, welche Anwendungen bleiben, sich weiterentwickeln oder stillgelegt werden. Sie kehrt mit jedem Budgetzyklus und jeder Vertragsverlängerung wieder. Das Ziel: Doppelungen verringern, vermeidbare Kosten streichen und Risiken senken, ohne das Geschäft zu beschädigen, das sich auf diese Systeme stützt.

Eine teure Anwendung, die einen regulierten Prozess unterstützt, wird nicht zum Kandidaten für die Stilllegung, nur weil sie im Budget rot erscheint. Umgekehrt kann eine günstige Anwendung die riskanteste im Bestand sein, wenn sie auf nicht mehr unterstützter Technologie läuft und niemand mehr weiß, wie sie funktioniert. Die Entscheidung wägt deshalb Wert, Qualität, Kosten und Risiko gemeinsam ab.

Das TIME-Modell: Tolerieren, Investieren, Migrieren, Eliminieren

Das TIME-Modell von Gartner ordnet jede Anwendung nach fachlichem Wert und technischer Qualität ein. Der Quadrant schlägt eine Standardmaßnahme vor. Das Modell eröffnet eine strukturierte Diskussion; die Verantwortlichen entscheiden die Grenzfälle.

In ArchiLU ordnet die TIME-Ansicht jede Anwendung nach der Bewertung ihrer Nutzer und dem Anteil ihrer noch unterstützten Technologien ein. Die Klasse bleibt eine erfasste Entscheidung mit Begründung: Die verantwortliche Person der Anwendung schlägt sie vor, der Unternehmensarchitekt legt sie fest. Nach „Eliminieren“ oder „Migrieren“ wählt die verantwortliche Person, die Stilllegung vorzubereiten oder eine Anforderung zu eröffnen. Die Bewertung der Nutzer ist privat: Sie ist nur als Aggregat lesbar, über zwölf Monate und ab fünf Antwortenden.

• Tolerieren: geringer Wert, solide Technik. Die Anwendung bleibt ohne neue Investition unter Beobachtung.
• Investieren: hoher Wert, solide Technik. Die Anwendung wird geschützt und modernisiert; neue Ausgaben fließen hierhin.
• Migrieren: hoher Wert, fragile Technik. Die Anwendung wechselt die Plattform oder wird ersetzt, bevor sie zur Belastung wird.
• Eliminieren: geringer Wert, fragile Technik. Die Anwendung wird stillgelegt, mit den Kosten und Risiken, die sie trug.

Kosten, Zustand und Risiko

TIME gibt der Entscheidung ihre Form; drei Gruppen von Informationen zeigen, mit welcher Sicherheit sie getroffen werden kann. Kosten umfassen Lizenz, Hosting, Support und internen Aufwand. Der Zustand umfasst fachliche Eignung, Stabilität, Zufriedenheit der Nutzer und Aktualität der Technologie. Das Risiko umfasst die Fragilität des Anbieters, einzelne Ausfallpunkte, regulatorische Exponierung und Komponenten am Ende ihrer Lebensdauer.

In einer Bank ist eine zahlungsnahe Anwendung mit fragilem Anbieter und nicht mehr unterstützter Laufzeitumgebung lange vor einer Kostenfrage eine Risikofrage. In einer Behörde ist ein altes, günstiges Formularsystem, das nur ein Entwickler kurz vor der Rente versteht, ein Kontinuitätsrisiko. Die Informationen bleiben dieselben; ihr Gewicht ändert sich je nach Branche.

In ArchiLU wird ein Vertrag den Anwendungen zugeordnet, die er abdeckt, mit der Begründung der Aufteilung, und die Seite Verträge zeigt Laufzeitende und erkannte automatische Verlängerung. Jede Anwendung zeigt ihren Technologie-Stack; 90 Tage vor einem Supportende öffnet sich ein Case: verlängern, migrieren, stilllegen oder das Risiko akzeptieren.

Technische Schulden und die Kosten des Wartens

Technische Schulden sind der Abstand zwischen der heutigen Bauweise einer Anwendung und der, die sie sicher, wartbar und anpassbar machen würde. Sie verursachen selten einen spektakulären Ausfall. Sie zeigen sich in steigendem Wartungsaufwand, langsameren Änderungen, der Abhängigkeit von wenigen Personen und einer schlecht bekannten Angriffsfläche.

Sie verändern die Rechnung der Rationalisierung. Eine Anwendung, die in der Lizenzzeile günstig wirkt, kann teuer werden, sobald Wartungsaufwand und Risiko eines Betriebs ohne Support beziffert sind. Werden die Schulden Anwendung für Anwendung sichtbar, entscheiden sie nicht anstelle der Verantwortlichen über die Roadmap.

Stilllegung und Gesamtbetriebskosten

Die Entscheidung zur Stilllegung ist der leichte Teil; eine Stilllegung ohne Zwischenfall braucht Vorbereitung. Gescheiterte Stilllegungen stolpern über versteckte Abhängigkeiten, Aufbewahrungspflichten für Daten und nachgelagertes Reporting, von dem niemand wusste. Eine Reihenfolge hilft: eingehende Schnittstellen trennen, Daten archivieren, dann die Anwendung stilllegen.

In ArchiLU öffnet „Entfernen“ einen Case in vier Schritten: Auswirkung, Ersatz, Entscheidung und Ausführung. Das Portfolio-Review nennt die Kosten der Kandidaten für die Stilllegung, die geschätzte und die festgestellte Einsparung, jeweils mit Zeitraum und Währung; ein Unbekanntes zählt dort nie als null.

Die Gesamtbetriebskosten umfassen Lizenz und Hosting, aber auch Einführung, Pflege der Integrationen, interne Wartung, Support und den Aufschlag alternder Technologie. Zwei Anwendungen mit derselben Lizenzzeile können sehr unterschiedliche Gesamtkosten haben, und dieser Unterschied verschiebt eine Entscheidung oft von Tolerieren zu Migrieren oder Eliminieren.

Nach einer Fusion

Zwei zusammengeführte Bestände enthalten oft mehrere Anwendungen für dieselbe Fähigkeit. Die Arbeit beginnt bei der Fähigkeitenkarte: Jede Fähigkeit, die mehrere Anwendungen tragen, zeigt auf ein zu prüfendes Duplikat.

In ArchiLU zeigt das Dashboard die Fähigkeiten, die mehrere Anwendungen tragen. Jedes Duplikat durchläuft seine TIME-Klasse, dann die Stilllegung oder „Zusammenführen“, das seine Verknüpfungen auf die verbleibende Anwendung überträgt. Die Einsparung jedes Bestands wird in seiner Währung gelesen.

Die Rationalisierung dauerhaft halten

Ein einmaliges Rationalisierungsaudit veraltet schnell: Neue Anwendungen kommen hinzu, Verantwortliche wechseln, und das Inventar wandert zurück in die Tabelle. Governance hält das Portfolio aktuell, mit einer verantwortlichen Person für das Inventar, einem regelmäßigen Review und einer Regel: Keine Anwendung kommt ohne verantwortliche Person, Platz im Modell und erklärten Lebenszyklus in den Bestand.

Die Rationalisierung hält besser, wenn sie bestehenden Rhythmen folgt: Budgetzyklen, Vertragsverlängerungen, Meilensteinen der Transformation. Entscheidungen haben Bestand, wenn das Portfolio dasselbe Modell ist, das Architekten, Finanzen und Risikomanagement bereits nutzen.