Wege zu einer modernen IT

Von „Alles bleibt, wie es ist“ über Kapselung und Wrapping bis Re-Engineering und Monolith Crunching: Für die Modernisierung von IT-Systemen und Anwendungslandschaften gibt es die unterschiedlichsten Möglichkeiten. Entziehen kann sich dem heute kein Unternehmen mehr. Zu hoch ist der Modernisierungsdruck.

Das liegt zum einen an den technischen und organisatorischen Herausforderungen des digitalen Wandels. Zum zweiten erfordert der zunehmende Wettbewerbsdruck die Anpassung der Geschäftsmodelle und der unterstützenden Geschäftsprozesse in immer kürzer werdenden Zyklen. Dazu kommen wirtschaftliche Globalisierung und Vernetzung, die die Interaktion mit externen Dritten, seien es Partner oder Kunden, immer entscheidender für den Unternehmenserfolg machen. 

Bei vielen unserer Mandanten sehen wir eine kritische Distanz zur aktuellen Situation der IT und dem Wunsch, neue Architekturkonzepte zu verfolgen, um die notwendige Geschwindigkeit zur Implementierung neuer Geschäftsideen oder Optimierungen bei bestehenden Geschäftsprozessen, etwa im Rahmen der Industrie4.0 Initiative, zu erreichen. Entscheidet sich ein Unternehmen zu handeln, so muss es sich für einen Lösungsansatz bei der Modernisierung unterscheiden. Dabei lassen sich grob drei Stoßrichtungen erkennen: 

1. Beibehaltung
2. Veränderung
3.  Ablösung

Diesen Stoßrichtungen lassen sich die verschiedenen strategischen Lösungsansätze oder Handlungsoptionen relativ klar zuordnen. Die Grafik zeigt sieben Handlungsoptionen, die hier häufig Anwendung finden. Allerdings selten in ng finden. Allerdings selten in g finden. Allerdings selten in finden. Allerdings selten in nden. Allerdings selten den. Allerdings selten den. Allerdings selten in Reinform. In der Praxis werden zumeist In der Praxis werden zumeist Mischformen der Handlungsoptionen umgesetzt.

Beibehaltung als valide Option haltung 

In der Stoßrichtung „Beibehaltung“ entscheidet sich ein Unternehmen bewusst gegen die Kosten und Risiken einer Umstellung und setzt seine Kraft in die Verbesserung der Wartung und Weiterentwicklung. Dies kann ein valides Vorgehen sein, falls finanzielle oder kapazitative Mittel zur Modernisierung fehlen oder die berechtigte Erwartung besteht, dass in absehbarer Zeit Standardsysteme den nötigen Funktionsumfang besitzen.

Veränderungen im gewohnten System umsetzen

Eine weitere Stoßrichtung mit einem überschaubaren Risiko ist die gezielte Veränderung über ein Re-Hosting oder eine Portierung der Legacy-Applikation. Dies kann in der Praxis unterschiedlich aussehen und häufig wird dies als Projekt mit einem klaren Anforderungskatalog umgesetzt.

• Re-Hosting/Lift & Shift: Die bestehende Anwendung wird in einem Re-Hosting auf eine andere und günstigere Infrastruktur-Plattform automatisiert migriert. Hierzu zählt auch der sogenannte Lift-&-Shift- Ansatz zur Portierung des Monolithen ohne jegliche Code-Portierung auf eine Cloud-Infrastruktur. Dieser Ansatz verändert die Funktionalität nicht und wird auch zu keiner nennenswerten Verbesserung der Zukunftsfähigkeit oder Wartung führen.

• Portierung/Migration: Eine weitere Option ist eine Migration der Code-Basis, etwa durch eine automatisierte Migration des Codes selbst auf eine zukunftssichere Plattform oder die Vergabe als Gewerk an eine Off-Shoring-Einheit. Werkzeuge für eine automatisierte Mig- ration von COBOL auf eine Java-Code- Basis existieren bereits. In der Regel wird der bestehende Monolith bei der Portierung auf eine andere günstigere Infrastruktur-Plattform migriert.

• Kapselung und Wrapping: Ein weiterer, aus meiner Sicht sehr vielversprechender Ansatz besteht in einer besonderen Form der Applikationsintegration: Der Kapselung beziehungsweise dem Wrapping oder dem API-Enablement der Funktionen oder Oberflächen des Alt-Systems, damit die bewährte und ausreichende Funktionalität des Monolithen in neuen Anwendungen verwendet werden kann. Der Ausdruck der „Servicefizierung von Monolithen“ beschreibt diesen Ansatz recht gut.

Grundlegende strategische Optionen der Modernisierung und ihre Stoßrichtungen.

Die alten Systeme ablösen

Die Ablösung des Monolithen ist in der Regel die einzige Stoßrichtung, um eine Zukunftsfähigkeit mit der notwendigen funktionalen Innovation für die Endanwender zu erreichen und eine Evolutionsfähigkeit der Anwendungslandschaft zu erzielen. Bleibt man in dem Denkmuster, der Ablösung des Monolithen durch ein neues System, so sind in der Regel drei Optionen denkbar.

• Standardsoftware: Stellt das nehmen im Rahmen einer Untersuchung fest, dass alle wesentlichen Geschäftsprozesse zur Wertschöpfung durch den Einsatz einer Standardsoftware mit einem geringen Maß an Anpassungen (Customizing/Parametrisierung) unterstützt werden, so bietet sich die Einführung der Standardlösung an. Ob diese Lösung nun on-prem oder gehostet eingeführt wird oder als SaaS-Lösung ist sekundär.

• Re-Engineering: Eine kostenintensive, zeitaufwendige und risikoreiche Option ist die Neuentwicklung des Monolithen. Hierbei muss der Fachbereich mit den Kenntnissen zu Geschäftsprozessen und Geschäftsregeln intensiv eingebunden werden, was zu einer hohen Beanspruchung der Fachbereiche oft über mehrere Jahre führen kann. Insbesondere werden bei der Neuentwicklung meist auch neue Funktionalitäten implementiert, damit die neue Lösung auch fachliche Mehrwerte erhält. Dieser Ansatz birgt somit auch die größten Chancen.

• Monolith Crunching: Ein Gegenentwurf zur vollständigen Neuentwicklung ist das iterative Re-Engineering durch ein Monolith Crunching. Nach einer Phase der Analyse des Reverse-Engineerings, in dem Verständnis und Transparenz über die technischen Strukturen des Monolithen hergestellt werden, erfolgt im Sinne eines Forward Engineerings die sukzessive Umstellung (oder auch Neuentwicklung) der Funktionalitäten des Monolithen auf die neue Plattform.

Sowohl beim Ansatz des Re-Engineering als auch beim Monolith Crunching geht es letztlich um die Zerlegung des Monolithen in Sub-Systeme, seien es Micro Services, Serverless Functions oder Self-Contained Systems. Beide Ansätze möchten am Ende getrennte Produktstrategien und unabhängige Releasezyklen ermöglichen.

Fazit

Die Möglichkeiten für die Transformation von Enterprise Applikationslandschaften sind vielfältig. Bei genauem Hinsehen hat jede Option ihre Berechtigung und schafft unter Umständen eine valide Grundlage für die Anforderungen des Digitalen Wandels. Die Entscheidung hängt erfahrungsgemäß vom Handlungsspielraum und der Strategie des Unternehmens ab. Um erfolgreich in die Digitalisierung zu starten, heißt es, die verschiedenen Optionen sorgfältig abzuwägen.

Steht zum Beispiel der zukünftige Nutzen für den Fachbereich im Mittelpunkt und das qualitative Kriterium der Evolutionsfähigkeit mit entsprechender Agilität und Adaptivität wird sehr hoch bewertet, so erscheint die Ablösung des Monolithen oft der einzig sinnvolle Ansatz zu sein.

Sind geringe Betriebs- und Wartungskosten das entscheidende Kriterium, so liegt es nahe, eine Veränderung des Alt-Systems durch Portierung, Re-Hosting oder Wrapping zu verfolgen. In diesem Fall ist der Fachbereich nicht nennenswert involviert und IT selbst führt diese Veränderung als klassisches IT-Projekt eigenständig durch.

Es gibt also wie so oft keine Standardantwort. Meine Empfehlung lautet: Genau hinschauen und daraufhin die passende Option bei der Transformation verfolgen. Resignatives Abwarten aber auch übereiltes Handeln sind hier der falsche Weg.