DIETER JUNGKUNZ CONSULTING
Application Modernization mit dem Strangler Fig Pattern
Budget freundliche Clouds, bessere Usability und die Flexibilität mithilfe agiler Softwareentwicklung neue Geschäftsmöglichkeiten zu nutzen, setzen Unternehmen mit Kernanwendungen auf Host Systemen unter Druck. Oft sind die Anwendungen Grundlage des Geschäfts. Wie können diese erfolgreich als Teil einer DevOps- und Agile-Strategie einer digitalen Transformationsstrategie zugänglich gemacht werden?
Für das Refactoring oder die komplette Modernisierung eines Systems gibt es verschiedene Beweggründe:
IT kann der wettbewerbs- und wachstumsbedingten Anpassung von Unternehmensprozessen nicht gerecht werden...
Viele mittelständische Unternehmen kämpfen irgendwann in ihrer Entwicklung mit einem typischen Wachstumsproblem: Die IT-Infrastruktur, die in den Anfangstagen einen Vorteil darstellte, wird nun langsam zu einer Last, die den täglichen Betrieb zur Qual macht und letztlich einige strategische Wachstumsoptionen nicht realisierbar werden lässt.
Die Systemarchitektur hat sich zu einem unübersichtlichen, gewachsenen Organismus entwickelt - iterative Entwicklung, Continues Development und Deployment lassen sich mit einem solchen Gebilde oft nicht erreichen und die gewünschte Agilität leidet oder wird schlicht unmöglich.
Wenn der aktuelle Technologie-Stack als "brennende Plattform" betrachtet wird, soll dieser durch einen neueren ersetzt werden...
Der Begriff "brennende Plattform" wird typischerweise verwendet, um eine Technologie zu bezeichnen, die als "end-of-life" betrachtet wird. Es kann zu schwierig oder zu teuer sein, Support für die Technologie zu bekommen, zu schwierig, Mitarbeiter mit der entsprechenden Erfahrung einzustellen.
Ein gängiges Beispiel für eine Technologie, die von den meisten Unternehmen als "burning platform" betrachtet wird, ist eine COBOL-Mainframe-Anwendung.
Wie kommt man nun aus dieser Sackgasse heraus?
Hier hat sich die "Strangler Fig" Methode bewährt - anstelle eines BigBang wird die zu ersetzende Plattform schrittweise ersetzt - oder von der wachsenden Schicht der neuen äußeren Services langsam quasi "abgewürgt". Auf diese Weise vermeidet man die Risiken die mit einem harten Schnitt, also dem ersetzen des kompletten Altsystems auf einen Schlag verbunden sind.
Einzelne Funktionsblöcke des Altsystems können als neuer Service implementiert werden und über Schnittstellen mit der Kernapplikation kommunizieren. Diese Services können so konstruiert werden, dass sie über Feature-Toggles ein- und ausschaltbar sind. Ein Rollback ist damit per Konfigurationsänderung möglich.
Es besteht auch die Möglichkeit, die beiden Funktionsblöcke parallel auszuführen und die Ergebnisse zu vergleichen. Auf diese Weise kann die Zuverlässigkeit des neuen Codes im Alltagsbetrieb überwacht und ggf. optimiert werden.
Neue Services werden schnell und iterativ ausgerollt und Anwender können sehr früh Feedback geben - so verhindert man Enttäuschung und Frust - die Software Modernisierung wird agil...
Benötigen Sie Unterstützung bei Ihrem Refactoring- oder Modernisierungs-Projekt?
Hier erfahren Sie mehr über mein Angebot...
