Warum Architektur-Modernisierung?
Software-Architektur ist kein Selbstzweck, sondern wird von Qualitätszielen getrieben. Qualitätsziele verändern sich. So kann zu Beginn eines Software-Vorhabens das möglichst schnelle Erstellen einer ersten vorzeigbaren Version der Software im Vordergrund stehen, um z.B. potenzielle Investorinnen und Investoren zu überzeugen oder den Markt zu testen (MVP). In diesem Fall haben Qualitätsziele, wie Einfachheit oder Geringe Kosten hohe Priorität. War der erste Wurf erfolgreich, ändern sich i.d.R. die Qualitätsziele. Z.B. gewinnen Ziele wie Skalierbarkeit, Wartbarkeit und Robustheit an Bedeutung. Der ursprünglich gewählte monolithische Architekturstil unterstützt diese Ziele nur unzureichend. Wird er dennoch beibehalten, läuft das erfolgreich gestartete Projekt Gefahr zu scheitern, da auf Änderungen nur noch langsam oder garnicht mehr reagiert werden kann. Es wird Zeit für eine Architektur-Modernisierung.
Wie Architektur-Modernisierung?
Architektur-Modernisierung beginnt mit einem Architektur-Review. Eine Modernisierung ist dann erforderlich, wenn im Review festgestellt wird, dass die aktuelle Architektur die aktuellen Qualitätsziele gar nicht mehr oder nur noch unzureichend unterstützt. Die Modernisierung startet mit der Erarbeitung aktueller Qualitätsziele, z.B. im Rahmen eines Qualitätsszenarien-Workshop. Basierend auf den Ergebnissen erfolgt die Bestimmung einer neuen Zielarchitektur. Anschließend erarbeiten wir einen Plan zur iterativen Architekturüberführung.
Ziel ist es, das System während der gesamten Modernisierung produktiv am Laufen zu halten. Zur Vermeidung von Big-Bang-Releases sorgen wir dafür, dass die Modernisierung in kleinen und messbaren Schritten erfolgt, und das Ergebnis jedes Modernisierungsschrittes unmittelbar deployed wird.
Beispiele für Architektur-Modernisierungen
Das klassische Beispiel einer Architektur-Modernisierung ist die Überführung einer monolithischen Architektur in eine Service-basierte Architektur. Der häufigste Grund für diese Art von Modernisierung ist die mangelnde Unterstützung des Qualitätsziels Wartbarkeit: Änderungen oder neue Features lassen sich nur noch sehr schwerfällig, risikobehaftet und unter hohem Aufwand umsetzen. Ein bewährtes Vorgehen zur Überführung eines Monolithen in einzelne Services beschreibt das Strangler Fig Pattern: Einzelne Funktionsblöcke werden nach und nach aus dem Monolithen herausgeschnitten und als jeweils dedizierte Services reimplementiert. Der Monolith wird über die Zeit immer kleiner, bis er im Idealfall komplett abgelöst werden kann.
Ein anderes Beispiel für eine Architektur-Modernisierung ist der entgegengesetzte Fall: Devertikalisierung. Ein auf viele Services aufgeteiltes System mit jeweils eigenverantwortlichen Teams soll auf einige wenige Services zusammengefasst werden. Der maßgebliche Treiber für diese Form der Modernisierung sind Kosten: Das System ist zwar hoch flexibel, aber auf Dauer zu teuer.
Methoden und Techniken zur Architektur-Modernisierung
Qualitätsszenarien
Fitness Functions
Wir helfen weiter
Software-Architektur und deren Modernisierung sind komplexe Themen. Wir analysieren und bewerten Ihre bestehende Architektur und erarbeiten gemeinsam mit Ihnen zukunftsfähige Modernisierung-Strategien.