Viele Unternehmen verfolgen inzwischen einen Modern Work Ansatz und stehen deshalb vor der Entscheidung, Legacy Anwendungen zu modernisieren, zu ersetzen oder vollständig neu zu entwickeln, was zu erheblichen Investitionen führen kann. In diesem Beitrag wird ein erfolgreiches, und bewährtes Phasenmodell für die Transformation von Legacy Anwendung beschrieben. Dabei analysieren wir nicht die Legacy Anwendung, sondern betrachten die zugrunde liegenden Prozesse, um mit Hilfe des hier vorgestellten Transformationsmodell eine zukunftsfähige und moderne Lösung zu entwickeln.
Was sind Legacy Anwendungen?
Legacy Anwendungen besitzen folgende Eigenschaften: Wie der Namen schon sagt sind es in der Regel ältere Lösungen, z. B. Software, die in einem Unternehmen oder einer Organisation weiterhin genutzt wird, obwohl sie veraltet oder technologisch überholt ist und keinem modernen Anspruch entspricht. Solche Systeme sind oft schwer zu warten und weiterzuentwickeln, da sie auf alten Programmiersprachen, Betriebssystemen oder Hardware basieren. Dennoch bleiben sie häufig im Einsatz, weil sie kritische Geschäftsprozesse unterstützen und die Transformation mit erheblichen Kosten, Risiken oder Komplexitäten verbunden sein kann. Häufig fehlt das Know-how oder der Mut zur Transformation bzw. Modernisierung.
Es gibt aber auch aktuelle Anwendungen, die dennoch als Legacy bezeichnet werden müssen. Das ist immer dann der Fall, wenn Unternehmen oder Unternehmensbereiche zusammengeführt werden und eine homogene Softwarelandschaft bereitgestellt werden muss. Verschiedene eigene Anwendungen beizubehalten oder eine nur abzulösen und durch die andere zu ersetzen, ist oft nicht zielführend. In der Regel ändern sich auch die Prozesse, auf die dann die bestehende Software nicht angepasst ist.
Der Bedarf für die Transformation ist hoch
Die Notwendigkeit zur Transformation von Legacy Software Lösungen ergibt sich aus:
- Kompatibilitätsproblemen mit modernen Systemen
- Sicherheitslücken, da sie nicht mehr regelmäßig aktualisiert werden kann
- Mangel an Fachkräften, die die alte Technologie noch beherrschen
- Nichtumsetzbarkeit von Ansprüchen an heutige Anforderungen wie Datenschutz und rechtliche oder betriebliche Vorgaben
Ein weiterer sehr entscheidender Faktor sind die immer wichtigeren Compliance-Vorgaben, da Legacy Systeme oft nicht mehr den aktuellen rechtlichen und sicherheitsrelevanten Anforderungen entsprechen.
Die heutige Arbeitswelt ist teamorientiert. Teams teilen sich gemeinsame Daten, was wiederum Funktionalitäten erfordert, die Legacy Anwendungen technisch nicht zur Verfügung stellen können. In unserem Whitepaper finden Sie hierzu eine erfolgreiche Transformation von Excel in eine hybride Cloud-Lösung.
Damit ist auch ein weiterer treibender Faktor genannt. Viele Unternehmen können sich immer weniger dem Migrationsdruck in die Cloud entziehen.
Diese Herausforderungen machen die Entscheidung über den Umgang mit Legacy-Software komplex und strategisch bedeutsam. Wie unser Artikel zeigen wird, haben wir eine Lösung dieser Probleme.
Komplexe Anforderungen an die Datensicherheit – die Lösung ist unser Berechtigungskonzept
Die Erfahrungen mit unseren Kunden zeigen, dass die Vorgaben an die Datensicherheit immer komplexer werden und einen wesentlichen Druck in Richtung Transformation ausüben. Für Transformationen unserer Kunden setzen wir ein Berechtigungskonzept um, das – je nach Bedarf – folgende Merkmale besitzt:
- Berechtigungen werden auf der Basis von Rollen definiert, die wiederum auf Gruppen basieren.
- Berechtigungen werden für verschiedene Phasen im Businessprozess automatisch angepasst. Je nach Phase werden Daten für bestimmte Rollen eingefroren oder ausgeblendet.
- Berechtigungen können ohne Eingriff in den Anwendungscode angepasst werden.
- Jede einzelne Funktion der Lösung wird gesondert nochmal abgesichert.
- Daten werden automatisch, d. h. über die Anwendung, gelöscht je nach Vorgabe durch das Unternehmen.
Beim automatischen Löschen kann je nach Bedarf auch ein Vieraugenprinzip umgesetzt werden. Die Löschung wird durch einen User beantragt, die ein anderer bestätigen muss. Die User arbeiten dann nur mit den Daten, die sie auch tatsächlich benötigen.
Der Prozess für eine erfolgreiche Ablösungen von Legacy Anwendungen
Die im Folgenden beschriebenen Schritte zu einer gelungenen Transformation sind effizient und transparent für Kunden und basieren auf den Erfahrungen erfolgreich abgeschlossener Projekte. Es handelt sich hier um eine aus fünf Phasen bestehende Vorgehensweise, an deren Anfang eine Vision steht.
Ein wesentlicher Aspekt sind hier die Kosten. Die beschriebene Vorgehensweise erlaubt es, diese nach Abschluss einer jeden Phase besser einschätzen zu können. Die Transformation ist sowohl ein Beratungs- als auch ein Entwicklungsprojekt.
Transformation von Legacy Anwendungen braucht eine Vision
Die Transformation von Legacy Anwendungen beginnt immer mit einer Vision. Dabei zeigt sich, dass diese Visionen unabhängig vom jeweiligen Ökosystem oder Altsystem des Kunden sind. In der Praxis finden wir Visionen wie:
- Zukunftsfähig durch aktuelle Technologie, Datensicherheit und ein den Ansprüchen entsprechendes Berechtigungskonzept
- Transparente Schnittstellen
- Unterstützung mobiler Endgeräte
- Gewährleistung des Supports
- Integration in die bestehende Systemlandschaft
- Offenheit für weitere Implementierungen
- Erste Schritte Richtung Cloud oder besonders mutig direkt Cloud Nativ
Phase 1: Analyse der Prozesse und der Infrastruktur
Das Ziel der Analyse ist die Bestandsaufnahme der Infrastruktur des Altsystems und der abgebildeten Geschäftsprozesse. Zudem muss die Vision des Auftragsgebers auf Machbarkeit analysiert werden. Eine erste Roadmap mit Meilensteinen wird ermittelt, die erforderlich sind, um eine Dokumentation zu erstellen, die eine Entscheidungsgrundlage für das weitere Vorgehen liefert.
Hier hat sich gezeigt, dass man auf die aktuellen Prozesse schauen muss und nicht versuchen darf, einfach die Technologie des Altsystems auszutauschen. Je nach Projekt wird man sich den Code erst gar nicht anschauen.
Infrastrukturparameter bei der Ablösung von Legacy Anwendungen
In der Analysephase werden unter anderem Infrastrukturparameter wie Serverarchitektur, interne und externe Kommunikation, Sicherheit, File Shares, Systemgrenzen und unverzichtbare Systeme erkannt. Das Ergebnis ist eine statistische und logische Bestandsaufnahme, die als Rahmenbedingung für die Geschäftsprozesse anzusehen ist. Zudem wird ein erster Eindruck möglich, wie hoch die zu erwartenden Aufwände sein können.
Hier muss eine Vielzahl von Entscheidungskriterien berücksichtigt werden. Dabei spielt das Zeitfenster für die abzulösenden Komponenten eine wichtige Rolle. Sollen diese sofort, kurz- oder langfristig abgelöst werden? Sind die Komponenten verzichtbar oder müssen sie mit oder ohne Anpassung beibehalten werden?
Ebenso wird es in der Regel notwendig sein, Fremdsysteme zu integrieren, in einem unserer Fallbeispiele ein branchenspezifisches ERP-System.
Weitere Komponenten sind: Router, Firewalls sowie Clientsysteme und Arbeitsplätze.
Geschäftsprozesse in der Transformation
Geschäftsprozesse werden den Unternehmen durch eine Vielzahl von Anwendungen abgebildet. Diese werden im Laufe der Zeit angepasst, ohne dass eine der Entwicklung entsprechende Transformation stattgefunden hat. Ein typisches Beispiel ist die Abbildung von Geschäftsprozessen in Excelmappen mit Makros als Businesslogik. Diese müssen heutzutage angepasst werden, weil sie beispielsweise den Anforderungen an die Compliance nicht mehr genügen. In der Analyse müssen in einem ersten Schritt alle Anwendungen identifiziert und einem Geschäftsprozess zugeordnet werden.
Dies führt zu einer ersten Systematik:
- Priorität
- Lösung ist redundant
- Lösung kann durch No-Code oder Low-Code ersetzt werden
- Mehrere Lösungen können zusammengefasst werden
- Die Lösung kann wegfallen, weil der Geschäftsprozess nicht mehr existiert
- Workflows müssen neu gedacht werden
- Lösung kommuniziert mit anderen Systemen
Entscheidung am Ende dieser Transformationsphase
Nachdem die oben vorgenommenen Analysen dokumentiert sind, führen sie zu einer Entscheidung. Der Kunde entscheidet sich auf der Basis seiner Vision für eine Transformation/Ablösung und für die Suche nach der Zieltechnologie als nächste Phase im Transformationsprozess. Die Entscheidung kann aber auch gegen eine Transformation ausfallen. In diesem Fall erhält der Kunde die dokumentierten Analyseergebnisse als Mehrwert.
Phase 2: Identifikation Zieltechnologie der Transformation
In der Phase 2 werden technologische Ziele definiert. Diese können Hardware- und Infrastrukturkomponenten sein, z. B. die Entscheidung für spezifische Protokolle.
Kriterien für Zieldefinitionen
Die Zieldefinition orientiert sich an den folgenden Punkten:
- Zukunftsfähig und damit offen für Erweiterungen
- Machbarkeit
- Vorhandenes Know-how
- Kosten
- Sicherheit
- On Prem oder Cloud oder hybride Lösung
Praxisbeispiel hybride Technologie
Aufgrund einer Projektanalyse in einem unserer Projekte wurde eine moderne hybride Lösung mit Authentifizierung in der Cloud und lokale Anwendungen im LAN empfohlen.
Konkret wurden folgende Transformationen vorgeschlagen:
- Ersetzen der Server durch Microsoft Server und damit Migration des File Share in den SharePoint
- Einführung von MS Office und Microsoft Exchange Online auf den Arbeitsplätzen
- Ersetzen komplexer alter Anwendungen durch webbasierte Lösungen mit Schnittstelle zum ERP-System.
- Lokaler SQL Server
- Internet Information Server
- Implementierung mit .NET und zukunftsfähigem und stabilem Framework, Angular oder React
- Teilbereiche der webbasierten Lösung sind mobil nutzbar
- Bei einfachen Anwendungen werden Low Code Lösungen in Form von Power Apps vorgeschlagen
- Zu Erhöhung der Datensicherheit wird ein rollenbasiertes Berechtigungskonzept umgesetzt
- Die Verwaltung der Benutzer erfolgt im Azure Entra ID
Alle Komponenten wurden so geplant und umgesetzt, dass eine schrittweise Migration in die Cloud möglichst einfach erfolgen kann.
Phase 3: Requirements Engineering als zentrale Voraussetzung für eine gelungene Transformation
Nach der Entscheidung für die vorgeschlagene Zieltechnologien wird die Anforderungsanalyse, das sogenannte Requirements Engineering (RE), mit zertifizierten Beratern durchgeführt.
RE dient der Qualitätssicherung. Nach IS025010 sind die Qualitätsziele:
- Sicherheit
- Zuverlässigkeit
- Benutzbarkeit
- Übertragbarkeit
- Änderbarkeit
- Performanz
Nach unserer Erfahrung können mit einem guten Requirements Engineering Budgetüberschreitungen vermieden oder zumindest abgemildert werden. Außerdem können in dieser Phase schon mögliche Fehlerquellen erkanntwerden. RE schafft wichtige Vorrausetzungen für eine gelungene Transformation, weil die beteiligten Systeme und der Systemkontext erfasst und dokumentiert wird. Damit erfolgt auch eine Abgrenzung zu anderen Systemen.
Das Requirements Engineering überprüft, ob andere Systeme Grenzen setzen, wie beispielsweise Unternehmensrichtlinien. Nicht zuletzt werden in diesem Prozess alle Stakeholder ermittelt. Das sind die IT-Infrastruktur, Fachabteilungen, Projektverantwortliche, Entwickler und IT Pro sowie Compliance Verantwortliche.
Das Ergebnis der Prozessanalyse wird in User Stories, Use Case Diagrammen und Aktivitätsdiagrammen festgehalten. Der Umfang hängt hier vom Transformationsprozess ab. Während des gesamten Requirements Engineerings wird ein Glossar aufgebaut, welches die Eindeutigkeit der Kommunikation gewährleistet. Das Ergebnis des RE ist die Basis für die weitere Projektplanung und letztendlich die Umsetzung.
Phase 4: Projektplanung mit einem modernen agilen Ansatz
Die Projektplanung erfolgt im DevOps Kontext. Hier werden Entwicklung, Development, IT und in unserer Lösung der Kunde über eine gemeinsame Plattform zusammengeführt. Zum Einsatz kommt Azure DevOps. In dieser Phase werden agile Methoden eingesetzt und eine enge Kooperation mit dem Auftraggeber implementiert. Hierzu erhält der Kunde Zugriff auf Teilbereiche des DevOps Projektes, in denen die Anforderung dokumentiert sind.
Auf Grundlage der im Requirements Engineering gewonnen Erkenntnisse werden Arbeitselementen, sogenannte Work Items, erfasst. Dies sind die Elemente Feature, Product Backlog Item (PBI), Task, Aufgaben und Bug.
Features fassen Hauptthemen zusammen, wie z. B. die Implementierung einer Benutzeroberfläche. Aus den Features ergeben sich Arbeitspakete, die PBIs. Und aus einem PBI werden dann Tasks abgeleitet, die die Basis der Implementierung sind. Damit wird DevOps zum Single Point of Truth. Work Items und das Glossar sind die Grundlage, um Missverständnisse zu vermeiden. Das ist ein zentraler Punkt bei der Transformation von Softwarelösungen, weil hier oft aus der Sicht des Kunden „Neuland“ betreten wird.
Phase 5: Agile Implementierung der Transformation
Der agile Ansatz mit DevOps ist für das hier beschriebene Phasenmodell ohne Alternative. In der Vergangenheit hat sich gezeigt, dass andere Projektstrategien bei großen Projekten (100 Personentagen und mehr) nicht zu dem erwünschten Ergebnis führten.
Qualitätskriterien für die Umsetzung sind:
- Organisation in Sprints
- Sprintdauer
- Sprintziele
- Automatisierte Tests, Unit Tests und Integration Tests
- Testdokumentation
- Reviews
- Automatisierte Bereitstellung, Deployment
Während der Implementierungsphase kommt es entsprechend der Sprintziele zur regelmäßigen Auslieferung von Releases. Diese bestehen aus jeweiligen Erweiterungen (Inkrements), die durch die Sprintziele festgelegt wurden. Jedes Release ist also aufgrund seiner Erweiterungen durch den Kunden testbar. Damit ermöglicht unser Ansatz ein zeitnahes Feedback des Kunden.
Fazit für eine optimale Transformation Ihrer Legacy Anwendung
In diesem Beitrag wird ein Phasenmodell beschrieben, das als Blaupause für die erfolgreiche Transformation von Legacy Anwendungen dient. Im Anschluss an die Vision des Kunden werden die Phasen Prozessanalyse, Technologieentscheidung, Requirements Engineering, Projektplanung mit agilem Ansatz und letztendlich die agile Implementierung durchlaufen.
Veranschaulicht haben wir das Phasenmodell noch einmal am Beispiel der Ablösung von Lotus Notes Anwendungen:
Der Projektablauf besteht damit aus einer Beratungsphase und einer Implementierungsphase. Am Ende der ersten drei Phasen erfolgt immer eine Entscheidung, ob in die nächste Phase gewechselt werden soll. Dennoch erbringt jede Phase einen Mehrwert für den Kunden.
Planung und Implementierung erfolgen immer in einem agilen Kontext mit Azure DevOps als zentrales Werkzeug und Scrum Elementen für die konkrete Implementierung. Die Vorgehensweise implizit immer auch die Notwendigkeit, den Kunden in das Projekt zu integrieren und schafft damit Transparenz auch unter dem Gesichtspunkt der Kostenkontrolle. Ein detailliertes Vorgehen sowie viele spannende Fallbeispiele haben wir in unserem Whitepaper zusammengetragen.
