Architekturmigration durch iterativen Neubau

Komplexe monolithische Architekturen sind nicht gewollt – im Normalfall sind sie historisch gewachsen und bremsen die sie betreuenden Teams mit ihrer Vielzahl an Abhängigkeiten immer weiter aus: In der Folge sind Wartung und Weiterentwicklung häufig kaum noch mit vertretbarem Aufwand zu meistern. Eine Überarbeitung der bestehenden Softwarearchitektur im laufenden Betrieb ist daher meist der einzige Weg, um der Wartungsfalle zu entkommen und die Effizienz wieder herzustellen.

Auch große Geschäftsanwendungen starten nicht als undurchschaubare Monolithen. Gerade am Anfang einer Neuentwicklung sind Applikationen stattdessen normalerweise noch überschaubar und gut zu verstehen. Wenn die anfangs konzipierte Architektur umgesetzt und die Anwendung in Produktion ist, muss sich ein eingespieltes Team aus guten Entwicklern somit zunächst meist keine Gedanken über Fragen der Softwarearchitektur machen. Das Team kann die anfangs noch wenigen Abhängigkeiten stattdessen problemlos im Blick behalten und die Anwendung mühelos anpassen und erweitern.

Die Strategie, eine Anwendung über einen längeren Zeitraum nach diesem Schema zu betreuen, birgt allerdings Risiken. Da erfolgreiche Applikationen ständig neuen fachlichen und technischen Anforderungen gerecht werden müssen, wachsen sie geradezu zwangsläufig zu einer Größe und Komplexität heran, die zum einen nicht mehr ohne weiteres zu durchschauen sind und zum anderen ein größeres Entwicklungsteam erforderlich machen.

Diese Entwicklung wird durch das Fehlen einer vorgegebenen Zielarchitektur noch verstärkt: Wenn nicht bereits zu Anfang der Anwendungsentwicklung auf eine stringente Modularisierung der Software geachtet wurde, existieren häufig auch keine klaren Schnittstellen für konkrete Fachfunktionen. Eine ähnliche Situation entsteht, wenn die initial gewählte Architektur nicht angepasst wird, sobald weitere Anforderungen entstehen, und neue Funktionalitäten stattdessen lediglich in bereits existierenden Modulen untergebracht werden. In der Folge wachsen die Fachfunktionen stark an oder es gibt viel redundanten Code. Notwendige Maßnahmen, um die Codestrukturen anzupassen, Funktionen besser zu schneiden und den Modulschnitt sicherzustellen bzw. anzupassen, werden aufgrund von Zeitdruck, fehlendem Know-How oder Angst vor Umbaumaßnahmen jedoch oft nicht durchgeführt. Die Turnaround-Zeit, die von der Codeänderung bis zum Zeitpunkt, an dem ein Entwickler die Effekte der Änderung in einer lauffähigen Umgebung analysieren kann, verstreicht, kann in diesem Fall mehrere Stunden – im Extremfall sogar Tage – betragen.

Da versäumt wurde, die Schnittstelle der konkreten Anwendung anzupassen und damit die Anzahl der zu übergebenen Parameter minimal zu halten, kann die Anzahl der Parameter, die beispielsweise bei der Einführung eines neuen Features berücksichtigt werden müssen, beträchtlich sein. Weil unbeabsichtigte Seiteneffekte nicht auszuschließen sind, muss somit häufig auch bei kleinen Anpassungen die gesamte Anwendung beachtet und getestet werden. Das Testen der Kombinatorik über alle übergebenen Parameter hinweg ist nicht mehr möglich. Ein weiterer Negativeffekt sind lang laufende Buildprozesse für monolithische Anwendungen. Spätestens an diesem Punkt fallen Fehler in der Architektur bzw. Design auf.

Die Erkenntnis, dass die Arbeit an der Software nicht rund läuft, reift in den meisten Fällen nicht auf der Ebene der konkret am System arbeitenden Entwickler.

Der Umstand, dass einzelne Entwickler in komplexen monolithischen Strukturen einerseits meist nicht mehr erkennen und verstehen können, was das System eigentlich macht, und andererseits auf das Feedback, ob ihre konkreten Anpassungen funktionieren, stunden- bis tagelang warten müssen, führt unweigerlich zu Frustration in den Entwicklungsteams. Dennoch reift die Erkenntnis, dass die Arbeit an der Software nicht rund läuft, meiner Erfahrung nach in den meisten Fällen nicht auf der Ebene der konkret am System arbeitenden Entwickler. Insbesondere unter Entwicklern, die an großen Systemen arbeiten, ist stattdessen oftmals der Glaube verbreitet, dass Komplexität und Schwerfälligkeit in derartigen Projekten normal sei und hingenommen werden muss.

Der Impuls, den Status quo der Softwarearchitektur zu hinterfragen, kommt stattdessen meist aus der Fachabteilung oder dem Management, die das Budget für die Softwareentwicklung bereitstellen. Da die hohen Aufwände, die das Entwicklungsteam für Anpassungen betreiben muss, viel Zeit beanspruchen, wird der fachliche Output notwendigerweise geringer. Die berechtigte Frage, warum die Entwicklung trotz gleichbleibender Ausgaben immer weniger Vorgaben umsetzen kann, ist somit der häufigste Aufhänger für eine Überprüfung der Architektur.

Wege aus der Wartungsfalle: Big Bang oder iterativer Neubau

Steckt eine große Geschäftsanwendung in der soeben beschriebenen Wartungsfalle, sind Sanierungen des Altsystems kaum möglich. Ein Neubau ist somit meist die einzige Möglichkeit, eine neue Softwarearchitektur einzuführen, die eine effiziente Entwicklungsarbeit wieder ermöglicht. Für einen derartigen Neubau stehen grundsätzlich zwei Verfahrensweisen zur Auswahl: Die erste Variante sieht vor, erneut bei Null zu beginnen und das neue System „auf der grünen Wiese“ neben dem Altsystem zu erstellen. Sobald die neue Anwendung einen akzeptablen Stand erreicht hat, wird das Altsystem zu einem klar definierten Zeitpunkt abgeschaltet und das neue System zeitgleich in einem „Big Bang“ in Betrieb genommen.

Ein „Big Bang“ ist mit dem Risiko verbunden, dass sich erst nach dem Go-Live herausstellt, ob die Applikation für den produktiven Betrieb geeignet ist.

Diese Form des Neubaus hat den Vorteil, dass sie in vergleichsweise kurzer Zeit umgesetzt werden kann, da auf Zwischenlösungen weitestgehend verzichtet wird, und die Kosten vermeintlich kalkulierbar sind. Allerdings ist dieses Vorgehen mit dem Risiko verbunden, dass sich erst nach dem Go-Live endgültig herausstellt, ob die entwickelte Applikation tatsächlich für den produktiven Betrieb geeignet ist. Darüber hinaus können sich die Anforderungen an die Software auch während der Entwicklung des neuen Systems schlagartig ändern, sodass das mit dem Neubau beschäftigte Entwicklungsteam bereits vor dem eigentlichen Livegang reagieren muss. Man läuft sozusagen dem Altsystem hinterher, sodass die angebliche Kalkulierbarkeit des „Big Bangs“ im Hinblick auf Zeit und Budget lediglich virtuell ist.

Der aus meiner Sicht vielversprechendere Ansatz ist daher der iterative Neubau der Software. In diesem Verfahren werden zunächst sowohl eine fachliche als auch eine technische Zielarchitektur definiert. Auf dieser Basis können anschließend Module bestimmt werden, die – neben einzelnen rein technischen Komponenten im Hintergrund wie z.B. der Prozesssteuerung – vorrangig nach fachlichen Kriterien geschnitten werden. Sobald die Module voneinander abgegrenzt sind, kann das Entwicklungsteam mit der Neuentwicklung der ersten Komponente beginnen. Wenn diese bereit für den Livegang ist, kann die entsprechende Funktionalität im Altsystem abgeschaltet werden. Anfragen werden fortan an das neue Modul weitergeleitet. Die neuen Komponenten und das Altsystem befinden sich somit zeitweise im Parallelbetrieb und müssen in dieser Phase nahtlos ineinander aufgehen. Da auch die anderen Module schrittweise entwickelt und implementiert werden, wird der Anteil des Altsystems jedoch nach und nach immer kleiner, bis es schließlich vollkommen abgelöst ist.

Der in diesem Szenario notwendige Parallelbetrieb der beiden Systeme in der Übergangsphase wird häufig als Argument gegen den iterativen Neubau ins Feld geführt. Auf diese Weise würden unnötigerweise Ressourcen in das Altsystem fließen, dessen Ende ja bereits absehbar sei. Darüber hinaus wird auch kritisch darauf hingewiesen, dass sich eine Schritt für Schritt durchgeführte Systemmodernisierung über einen längeren Zeitraum hinziehe als im „Big Bang“-Modell und der Endpunkt mitunter sogar gar nicht kalkulierbar sei.

Diese Kritik ist nicht vollkommen aus der Luft gegriffen. Unstrittig ist, dass der Ansatz, die neuen Module schrittweise zu entwickeln, mehr Zeit in Anspruch nimmt. Zudem ist das initiale Investment in diesem Modell auf den ersten Blick höher, da während der Übergangsphase an den noch produktiven Teilen des Altsystems weitergearbeitet werden muss. Außerdem werden Funktionen für den Parallelbetrieb entwickelt, die später wieder wegfallen. Mit der Aufteilung des Neubaus in viele kleine Schritte wird die Komplexität der Systemmodernisierung jedoch deutlich minimiert: Anstatt wie beim „Big Bang“ auf ein reibungsloses Umschalten von Alt- auf Neusystem hoffen zu müssen, wird das Risiko auf viele „Small Bangs“ verteilt, deren mögliche Auswirkungen auf die Anwendung und die Geschäftsprozesse überschaubar bleiben.

Fazit

Die bestehende Softwarearchitektur im laufenden Betrieb durch eine neue zu ersetzen, ist ein äußerst komplexes Unterfangen. Eine iterative Herangehensweise erfordert zunächst zwar ein höheres Investment an Zeit und Geld. Zugleich hilft die Einteilung des Gesamtprojekts in viele überschaubare Schritte aber dabei, viele beim „Big Bang“-Verfahren weitestgehend unkalkulierbare Risiken beherrschbar zu machen. Auf diese Weise zeigt der iterative Neubau einen Weg auf, sich Schritt für Schritt aus der Wartungsfalle zu befreien.

Bildquelle: Fotolia – tektur