Legacy-Software modernisieren

Ohne Komplettaustausch, ohne Stillstand, und ohne die Fachlichkeit zu verlieren, die in zwanzig Jahren hineingewachsen ist.

Altsysteme werden selten abgelöst, weil sie kaputt sind. Sie werden abgelöst, weil sie nichts mehr zulassen: keine Schnittstelle, keine neue Anforderung, keinen Zugriff von außerhalb des Hauses. Das System funktioniert, es steht nur allem im Weg.

Der Punkt, an dem ein System zur Bremse wird

Die Anzeichen sind erstaunlich einheitlich, egal ob es um eine Access-Datenbank, eine gewachsene Java-Anwendung oder ein Modul im ERP geht. Eine Anforderung aus dem Fachbereich wird mit „das geht damit nicht“ beantwortet. Eine Schnittstelle lässt sich nicht anbauen, also wird exportiert und manuell nachgepflegt. Es gibt eine Person, die das System versteht, und einen Kalender, in dem deren Ruhestand steht.

Was in dieser Lage fehlt, ist selten Geld und fast nie Einsicht. Was fehlt, ist ein Weg, der nicht verlangt, zwei Jahre lang nichts zu liefern.

Wie Altsysteme abgelöst werden, und was das jeweils kostet

Welcher Weg der richtige ist, hängt bei uns an einer anderen Rechnung als anderswo. Der Komplettaustausch scheitert sonst meist an der Bauzeit: Über zwei Jahre hat niemand etwas von dem Vorhaben, und am Umschalttag muss alles gleichzeitig sitzen. Bei uns steht das Grundgerüst am selben Tag und die Handarbeit ist vorher benannt, also schrumpft der erste Einwand auf Wochen. Damit ist der Austausch wieder eine ernsthafte Wahl, und oft der sauberere Weg, weil danach keine Brücke zwischen alt und neu gepflegt werden muss.

Komplettaustausch, der Big Bang

Alles neu, ein Umschalttag. Der übliche Einwand, dass über die lange Bauzeit niemand etwas davon hat, wiegt bei uns weniger: Das Grundgerüst steht am selben Tag. Der Stichtag bleibt die Hürde: Dort müssen auch die undokumentierten Sonderfälle sitzen.

Bereich für Bereich herauslösen

Das Altsystem läuft weiter, ein fachlicher Ausschnitt nach dem anderen zieht um. Jeder Schritt liefert Nutzen und ist einzeln zurückdrehbar, bezahlt mit einer Parallelphase und einer Brücke zwischen alt und neu. Der Weg für große, verflochtene Bestände.

Nur die Oberfläche erneuern

Neues Frontend auf die alte Datenbank. Löst Bedienbarkeit und Optik, lässt Datenmodell, Rechte und Schnittstellen unberührt. Als Zwischenschritt vertretbar, als Ziel selten: Die Altlast wird dadurch schwerer sichtbar.

Danebenstellen und auslaufen lassen

Neue Vorgänge im neuen System, alte im alten, bis sie abgearbeitet sind. Passt, wo Vorgänge eine natürliche Laufzeit haben: Verträge, Projekte, Fälle. Bei Stammdaten passt es nicht.

Welche Altlast vor Ihnen liegt

Der Begriff „Legacy“ verdeckt, dass es sich um sehr verschiedene Probleme handelt. In der Praxis begegnen uns drei Typen, und sie verlangen unterschiedliche erste Schritte.

Die gewachsene Tabelle oder Datenbank

Excel und Access, entstanden als Selbsthilfe der Fachabteilung, inzwischen tragende Infrastruktur. Kleinster Umfang, schnellster Erfolg, meist der beste Einstieg.

Der Monolith

Eine große Anwendung, die alles kann und deshalb nichts mehr verändern lässt. Sie wird Bereich für Bereich entkernt, bis am Ende nichts mehr übrig ist.

Die zerfallene Landschaft

Fünf Anwendungen, fünf Anmeldungen, fünf Wahrheiten. Hier steht nicht Ablösung am Anfang, sondern eine gemeinsame Benutzerverwaltung und eine Oberfläche.

Für die gewachsene Tabelle und den Monolithen haben wir eigene Seiten, die tiefer gehen: Excel ablösen, Access-Datenbank ablösen und den Monolith in Microservices zerlegen. Für die zerfallene Landschaft: fragmentierte Anwendungen in einer Oberfläche zusammenführen.

Wie wir vorgehen, wenn Bereich für Bereich abgelöst wird

Von der Bestandsaufnahme bis zum Abschalten

Beim Komplettaustausch gilt der Ablauf aus dem Abschnitt oben. Wird stattdessen Stück für Stück abgelöst, wiederholt sich dieselbe Schleife pro Bereich, statt dass ein Projektplan über zwei Jahre läuft.

  1. Bestand aufnehmen und schneiden

    Welche fachlichen Bereiche steckt das Altsystem ab, wo verlaufen die Grenzen, welche Daten hängen woran? Ergebnis ist eine Reihenfolge, keine Architekturskizze.

    Tage, nicht Wochen

  2. Ersten Bereich modellieren

    Der gewählte Ausschnitt wird mit Claudette aufgenommen und im Designer modelliert. Vorhandene Strukturen wie Tabellen, Masken und Berichte sind dabei die Vorlage, nicht der Feind.

    kostenlos bis zur laufenden Anwendung

  3. Eine Anwendung je Bereich, nicht eine für alles

    Aus dem zweiten und dritten Bereich wird selten ein weiteres Kapitel derselben Anwendung. Meistens entsteht je Bereich eine eigene, kleine Anwendung, und die Anwendungen sprechen untereinander. Sie teilen sich Anmeldung, Rechte und Erscheinungsbild, verweisen aufeinander und tauschen Daten aus, sodass es sich im Gebrauch wie ein System anfühlt.

    Der Gewinn zeigt sich später: Ein Bereich lässt sich ändern, neu erzeugen oder abschalten, ohne die anderen anzufassen. Wie das technisch zusammenhängt, steht unter Microservice-Architektur; wie es für den Anwender zusammenwächst, unter einer Oberfläche.

    verdrahtet statt verschmolzen

  4. Brücke bauen

    SOLUTIONS.transformer verbindet alt und neu: Stammdaten fließen in die vereinbarte Richtung, Änderungen werden abgeglichen. Hier wird festgelegt, welches System für welche Daten maßgeblich ist, die wichtigste Entscheidung der Parallelphase.

    konfiguriert, nicht programmiert

  5. Parallel betreiben und umschalten

    Der Bereich läuft eine definierte Zeit in beiden Systemen, dann wird umgeschaltet. Geht etwas schief, ist nur ein Bereich betroffen und der Weg zurück ist kurz.

    pro Bereich, nicht für alles

  6. Wiederholen, bis nichts mehr übrig ist

    Jeder weitere Bereich geht schneller als der erste: Der Weg ist eingespielt, die Brücke steht, und die Eigenheiten des Altsystems sind bekannt. Am Ende wird das Altsystem abgeschaltet, wirklich abgeschaltet und nicht „vorläufig noch behalten“.

    jeder Schritt liefert Nutzen

Warum das heute anders kalkuliert wird als früher

Der Grund, warum Modernisierungen so lange aufgeschoben werden, ist die Anfangsinvestition: Der erste Bereich ist der teuerste, weil mit ihm die gesamte Grundlage entsteht: Anmeldung, Rechte, Oberfläche, Betrieb, Auslieferung. Erst danach wird es billiger.

Dieser Anfangsblock entfällt bei generierten Anwendungen. Anmeldung, Rollen und Rechte, Formulare, Listen, Validierung und Mehrsprachigkeit kommen aus einem Framework, das seit Jahren in Betrieb ist. Die KI nimmt die Anforderung auf und konfiguriert. Den Code erzeugt anschließend ein deterministischer Generator. Übrig bleiben Ihre Fachlichkeit und die Datenübernahme. Damit ist der erste Schritt klein genug, um ihn zu tun, statt ihn zu verschieben.

Warum den Code bei uns ein Generator erzeugt →

Screenshot SOLUTIONS.import Ergebnislog

Die Brücke zwischen alt und neu ist das Handwerk

In jeder schrittweisen Ablösung entscheidet die Parallelphase über Erfolg oder Chaos. SOLUTIONS.transformer verbindet Altsystem und neue Anwendung grafisch. Datenquellen wie SQL, REST, SOAP, Verzeichnisdienste und Dateien werden angebunden, Felder abgebildet, Werte umgerechnet, Abgleiche zeitgesteuert ausgeführt. Jeder Lauf ist protokolliert und wiederholbar, also testbar, bevor er zählt. Und weil er konfiguriert und nicht programmiert ist, kann später jemand anderes ihn lesen als der, der ihn gebaut hat.

Weiterlesen

Häufige Fragen

Wann sollte man ein Altsystem ablösen?

Nicht, wenn es Fehler macht, sondern wenn es Vorhaben blockiert. Die praktischen Anzeichen: Eine Anforderung aus dem Fachbereich lässt sich nicht mehr umsetzen, eine Schnittstelle lässt sich nicht anbauen, das System hält Homeoffice oder Mobilgeräte nicht aus, oder nur noch eine einzige Person versteht es.

Big Bang oder schrittweise ablösen?

Beides geht, und der Komplettaustausch ist bei uns eher möglich als anderswo, weil das Grundgerüst am selben Tag steht statt nach Monaten. Schrittweise bleibt der ruhigere Weg, wenn viele Abteilungen betroffen sind oder die Altdaten unklar sind: Das Altsystem läuft weiter, während ein Bereich nach dem anderen herauswandert, und jeder davon liefert sofort Nutzen.

Wie lange läuft das Altsystem parallel weiter?

So lange, bis der letzte Bereich umgezogen ist, typischerweise Monate und nicht Jahre. Wichtig ist, dass die Parallelphase geplant ist und nicht passiert: Es braucht eine klare Festlegung, welches System für welche Daten maßgeblich ist, und eine Brücke, die beide synchron hält.

Was passiert mit den Daten aus zwanzig Jahren?

Sie werden übernommen, aber nicht ungeprüft. Der Übernahmelauf ist konfiguriert, protokolliert und beliebig oft wiederholbar. Sie können ihn testen, das Ergebnis ansehen, Regeln nachschärfen und erneut laufen lassen, bevor irgendetwas produktiv wird.

Lohnt sich Modernisierung überhaupt, oder gleich Standardsoftware?

Wo Ihr Prozess wirklich dem Standard entspricht, kann Standardsoftware der günstigere Weg sein, und dann sagen wir das auch. Nachrechnen sollten Sie es trotzdem: Wird pro Kopf lizenziert, kippt die Rechnung mit der Zahl der Anwender, und bei vielen Nutzern liegt sie über fünf Jahre oft über unserer. Bei uns hängt der Preis am Umfang der Anwendung, nicht daran, wie viele Menschen damit arbeiten.

Der zweite Punkt ist die Passung. Kaum ein gewachsenes Haus arbeitet durchgehend nach Standard, und was den Unterschied zum Wettbewerb ausmacht, steht fast nie darin; entsprechend viel wird am Standardprodukt angepasst, und jede Anpassung holt das nächste Update wieder ein. Der Gegensatz ist ohnehin kleiner, als er klingt: Unsere Anwendungen bestehen im Kern aus Standardteilen, aus Framework, Diensten und Generator. Eigen ist nur die Schicht darüber, und für dieselbe Schicht kaufen Sie am Standardprodukt Anpassungen.

Und eines nimmt Ihnen kein Weg ab: Die Daten aus dem Altsystem müssen übernommen werden, mit denselben Fragen nach Feldern, Formaten und Altlasten. Diese Aufgabe fällt bei jeder Entscheidung an, und dafür gibt es SOLUTIONS.transformer.

Stunde mit uns vereinbaren

Eine Stunde per Videokonferenz, kostenlos.

Sprechen Sie mit uns.

Wie dürfen wir Sie kontaktieren?*
Wir melden uns umgehend bei Ihnen.