Der Zustand eines Legacy-Systems sagt weniger aus, als viele Unternehmen glauben.
Eine alte Programmiersprache, ein Mainframe oder ein Monolith gelten schnell als Beweis dafür, dass eine Organisation technisch zurückliegt.
Doch das Alter einer Technologie ist kein verlässlicher Indikator für die tatsächliche Modernisierungsfähigkeit eines Unternehmens.
Entscheidender ist eine andere Frage:
Kann die Organisation nachvollziehen, welche geschäftlichen Entscheidungen im System stecken – und kann sie bewusst über deren Zukunft entscheiden?
Genau dafür haben wir das Legacy Decision Maturity Model (LDMM) entwickelt.
Es bewertet nicht, wie modern eine Technologie ist. Es beschreibt, wie reif eine Organisation im Umgang mit ihren Legacy-Systemen entscheidet.
Legacy Decision Maturity Model
Von der Technologiefrage zur organisatorischen Fähigkeit
Das LDMM misst nicht den technischen Zustand eines Systems, sondern die Entscheidungsreife einer Organisation im Umgang mit ihren Legacy-Systemen.
Je höher die Reife, desto weniger ist Legacy ein technisches Problem – und desto stärker wird Modernisierung zu einer Führungsaufgabe der Organisation.
Warum ein weiteres Reifegradmodell?
Viele Reifegradmodelle messen Technologien, Prozesse oder Architekturpraktiken.
Das greift bei Legacy System Modernization zu kurz.
Ein Unternehmen kann moderne Plattformen einsetzen und trotzdem kaum entscheidungsfähig sein. Umgekehrt kann ein dreissig Jahre altes System stabil, gut verstanden und bewusst geführt werden.
Der eigentliche Unterschied liegt deshalb nicht zwischen „alt“ und „neu“, sondern zwischen:
- impliziten und expliziten Entscheidungen,
- unklarer und klarer Verantwortung,
- einmaliger Analyse und dauerhafter Transparenz,
- projektweiser Migration und kontinuierlicher Modernisierung.
Das LDMM macht diese Entwicklung in vier Stufen sichtbar.
Stufe 1: Legacy als Technologieproblem
Auf der ersten Stufe wird Legacy vor allem als technisches Defizit verstanden.
Typische Aussagen lauten:
- „Wir müssen weg vom Mainframe.“
- „Wir brauchen Microservices.“
- „Wir schreiben das System neu.“
- „AI kann den alten Code konvertieren.“
Die Organisation konzentriert sich auf Plattformen, Programmiersprachen und Zielarchitekturen. Die im System enthaltenen Geschäftsentscheidungen bleiben weitgehend unbeachtet.
Typisches Risiko
Code wird ersetzt, ohne die zugrunde liegende Geschäftslogik ausreichend zu verstehen. Das Ergebnis ist häufig ein neues System, das alte Unklarheiten in moderner Technologie reproduziert.
Nächster Entwicklungsschritt
Die Organisation muss erkennen, dass Legacy nicht nur aus Code besteht, sondern aus über Jahre angesammelten und oft nicht mehr dokumentierten Entscheidungen.
Stufe 2: Legacy als Wissensproblem
Auf der zweiten Stufe erkennt das Unternehmen, dass fehlendes Wissen der zentrale Engpass ist.
Nun stehen Fragen im Vordergrund wie:
- Welche Abhängigkeiten existieren?
- Wo liegt die relevante Geschäftslogik?
- Welche Personen verfügen über kritisches Wissen?
- Welche Teile des Systems ändern sich besonders häufig?
- Welche Regeln sind noch gültig?
Hier entfaltet Generative AI einen erheblichen Nutzen. Sie kann Abhängigkeiten analysieren, Architekturstrukturen rekonstruieren, Geschäftsregeln extrahieren und technische Hotspots sichtbar machen.
Typisches Risiko
Die Organisation verwechselt Transparenz mit Fortschritt. Es entstehen Heat Maps, Inventare und Analysen – aber keine verbindlichen Entscheidungen.
Nächster Entwicklungsschritt
Die Erkenntnisse müssen fachlichen Verantwortlichen zugeordnet und in konkrete Entscheidungen überführt werden.
Stufe 3: Legacy als Entscheidungsproblem
Auf der dritten Stufe wird deutlich: Das System ist inzwischen besser verstanden, doch die Organisation kommt trotzdem nicht voran.
Der Engpass liegt jetzt in der Entscheidungsfähigkeit.
Typische Konflikte entstehen zwischen:
- Business und IT,
- kurzfristiger Delivery und langfristiger Modernisierung,
- Compliance und Veränderung,
- Betrieb und Architektur,
- Standardisierung und geschäftlichen Sonderfällen.
Entscheidend wird nun die Zuordnung von Verantwortung zu Geschäftsfähigkeiten. Nicht die IT allein entscheidet, wie eine Tariflogik, Kundenidentifikation oder Abrechnung künftig funktionieren soll. Das Geschäft trägt die fachliche Verantwortung; Software Engineering liefert Transparenz, Optionen und Konsequenzen.
Typisches Risiko
Entscheidungen werden vertagt oder zwischen Gremien weitergereicht. Der bestehende Code bleibt dadurch der faktische Default.
Nächster Entwicklungsschritt
Governance muss von Projektkontrolle zu echter Entscheidungsführung werden. Entscheidungen brauchen Eigner, Fristen und nachvollziehbare Konsequenzen.
Stufe 4: Legacy als organisatorische Fähigkeit
Auf der vierten Stufe ist Modernisierung kein zeitlich begrenztes Sonderprojekt mehr.
Die Organisation verfügt über eine dauerhafte Fähigkeit, geschäftliche Fähigkeiten von ihren technischen Implementierungen zu entkoppeln und bewusst weiterzuentwickeln.
Typische Merkmale sind:
- klare fachliche Eignerschaft,
- kontinuierlich aktualisierte Transparenz,
- verbindliche Modernisierungs-Governance,
- inkrementelle statt einmalige Ablösung,
- Messung von Delivery-Performance und Teamgesundheit,
- bewusste Priorisierung von Modernisierung und Tagesgeschäft.
AI wird auf dieser Stufe nicht nur für ein initiales Assessment eingesetzt. Sie wird zu einem dauerhaften Transparenzdienst im Entwicklungs- und Betriebsprozess.
Das Ziel
Nicht jedes alte System muss ersetzt werden.
Ein System ist dann beherrschbar, wenn die Organisation weiss, was es tut, warum es dies tut und wie es verändert oder ersetzt werden kann, sobald dies geschäftlich sinnvoll ist.
Wo steht Ihre Organisation?
Eine erste Einordnung gelingt mit wenigen Fragen:
- Wird Legacy hauptsächlich über Technologie oder über Geschäftsfähigkeiten diskutiert?
- Sind die zentralen Geschäftsregeln und Abhängigkeiten nachvollziehbar?
- Gibt es für jede relevante Geschäftsfähigkeit einen fachlichen Eigner?
- Werden Modernisierungsentscheidungen verbindlich getroffen oder wiederholt vertagt?
- Wird Transparenz einmalig in Projekten hergestellt oder kontinuierlich gepflegt?
- Messen Sie nur Migrationsfortschritt oder auch Änderungsgeschwindigkeit, Stabilität und Teamgesundheit?
Die Antworten zeigen meist schnell, an welcher Stelle das eigentliche Hindernis liegt.
Was das LDMM bewusst nicht ist
Das LDMM ist kein technischer Audit-Katalog und kein Punktesystem, das Unternehmen in „gut“ oder „schlecht“ einteilt.
Es soll eine gemeinsame Sprache schaffen.
Denn viele Legacy-Diskussionen scheitern bereits daran, dass unterschiedliche Beteiligte über verschiedene Probleme sprechen:
- Die IT spricht über Plattformen.
- Das Business spricht über Risiken und Fähigkeiten.
- Der Betrieb spricht über Stabilität.
- Compliance spricht über Nachweisbarkeit.
- Die Führung spricht über Kosten und Handlungsfähigkeit.
Das LDMM verbindet diese Perspektiven über die gemeinsame Frage der Entscheidungsreife.
Fazit
Legacy System Modernization beginnt nicht mit einer neuen Plattform.
Sie beginnt damit, dass eine Organisation ihre bisherigen Entscheidungen wieder sichtbar macht, Verantwortung klärt und bewusst über die Zukunft ihrer Geschäftsfähigkeiten entscheidet.
Generative AI kann diesen Prozess erheblich beschleunigen. Sie ersetzt jedoch nicht die Governance und die Führungsarbeit, die aus Transparenz tatsächliche Veränderung machen.
Das Legacy Decision Maturity Model hilft dabei, den aktuellen Engpass zu erkennen – und den nächsten sinnvollen Entwicklungsschritt zu bestimmen.
