Agilität heißt permanente Modernisierung

Artikel als PDF herunterladen:
Download Agilität heißt permanente Modernisierung (2 MB)

Geschäftliche Anforderungen ändern sich kontinuierlich und Softwaresysteme müssen dem Rechnung tragen. Während neue Features oft noch mit vertretbarem Aufwand hinzugefügt werden können, wird es zur Herausforderung, wenn Eigenschaften wie fehlende Wartbarkeit oder mangelnde Skalierbarkeit den wirtschaftlichen Nutzen zunehmend relativieren und die bestehende Systemarchitektur in Frage stellen.

Die Verwendung des Begriffs „Legacy-System“ löst zum gleichen Zeitpunkt zwei gegenläufige Reaktionen aus: Bewunderung sowie Mitleid mit dem Betroffenen. Wartung und Erweiterung von Anwendungen, die über Jahre, vielleicht schon Jahrzehnte gewachsen sind, die Generationen von Entwicklern gesehen haben, gelten als schwierig und aufwändig. Auf der anderen Seite steht aber die Tatsache, dass genau diese Systeme oft das unentbehrliche Rückgrat betrieblicher Abläufe darstellen, in denen wertvolles Wissen über die fachliche Domäne und den damit verbundenen Prozessen kodiert ist.

Diese Spannung tritt sehr deutlich zu Tage, wenn sich Rahmenbedingungen ändern, z. B. erhöhter Innovationsdruck durch neue Mitbewerber oder Anpassungen des Geschäftsmodells wie ein geplantes Angebot von Software as a Service (SaaS). Kann das alte System den neuen Anforderungen gerecht werden und wie müsste es angepasst werden? Ist das überhaupt möglich? Welche Aufwände entstehen und welche Risiken gehen damit einher? Wäre es nicht besser, eine Neuentwicklung auf der „grünen Wiese“ zu beginnen?

Die Qualitäten eines Systems

Ein wichtiger Schlüssel zur Beantwortung dieser Fragen liegt auf der Ebene der Architektur. Diese beschäftigt sich mit der technischen Umsetzung grundlegender qualitativer Anforderungen an ein System. Dazu zählen u. a. Begriffe wie Sicherheit, Robustheit, Skalierbarkeit, Performanz und Effizienz, aber auch Erweiterbarkeit oder Wartbarkeit. Diese können sich gegenseitig ergänzen, stehen jedoch nicht selten in Konflikt zueinander. Ein klassisches Beispiel ist die Bestimmung eines passenden Trade-Offs zwischen Sicherheit und Performanz.

Die konkrete Architektur eines Systems ist eine Menge von Entscheidungen, die sich in der Auswahl passender Technologien, der Strukturierung des Systems in interne Komponenten bzw. unabhängige Services oder der Definition von Schnittstellen sowie deren Eigenschaften manifestieren. Dazu kommt die Klärung von Fragen zum Hosting-Modell, Roll-Out-Prozess oder Teststrategien und die Abstimmung der einzelnen Aspekte aufeinander. Es ergeben sich daraus Muster und Regeln, die bei der Implementierung des Systems konsistent und konsequent umgesetzt werden sollten.

Einmal gefällte Architekturentscheidungen besitzen eine unangenehme Eigenschaft: sie sind grundlegender Natur und wirken sich auf weite Teile des Systems aus. Das bedeutet im Umkehrschluss, dass sie im Nachhinein nur schwer zu ändern sind und damit hoher Aufwand sowie meist hohes Risiko verbunden ist.

Fortbewegung auf glattem Eis

Erschwert wird die Situation dadurch, dass die Architektur bestehender Systeme oft den beteiligten Entwicklern und Architekten selbst nur eingeschränkt bekannt ist oder zumindest ein hohes Gefühl der Unsicherheit existiert. Dies ist eine Folge dessen, dass im Alltagsgeschäft relevante Entscheidungen oft nur implizit gefällt und darüber hinaus nur sehr spärlich dokumentiert bzw. kommuniziert werden.

Daraus ergibt sich ein Dilemma: Informationen über den aktuellen Zustand des Systems sind oft veraltet, nur lückenhaft oder schwer zugänglich. Gleichzeitig soll die Architektur des Systems sich weiterentwickelnden geschäftlichen Anforderungen folgen können, also agil sein. Zwei Beispielszenarien sollen den Bedarf für Refactorings skizzieren:

1. Eine Webanwendung muss zum Erhalt der Wettbewerbsfähigkeit auf bessere Nutzbarkeit optimiert werden. Welche konkreten Maßnahmen die Akzeptanz jedoch bei den Anwendern erhöhen, ist schwer vorauszusagen. Daher sollen künftig kleine Änderungen zügig ausgerollt werden, um schnelles Feedback zu generieren. Die Anwendung ist derzeit jedoch Teil eines monolithischen Systems, das einem mehrmonatigen Release-Zyklus unterliegt. Kann sie herausgelöst werden, um ein Ausrollen innerhalb weniger Tage oder perspektivisch weniger Stunden zu ermöglichen? Welcher Aufwand und welche Risiken verbinden sich damit? Sind Restrukturierungen und Anpassungen am Rollout-Prozess schon ausreichend?

2. Die Katalog-Komponente eines eCommerce-Systems erfreut sich stark wachsender Nutzerzahlen und soll daher abhängig von der angeforderten Last skaliert werden können. Kann dies mit dem bestehenden System realisiert und in diesem Zusammenhang über Hosting bei einem Cloud-Anbieter nachgedacht werden? Kann der Katalog als eigenständiger Service herausgelöst werden, um die auf Basis genutzter Systemressourcen anfallenden Kosten zu minimieren? Welche Technologien müssen abgelöst werden, damit ein Betrieb beim favorisierten Anbieter überhaupt möglich wird und wie tief sind diese im System verankert? Welche Schnittstellen zu anderen Teilen des Systems müssen migriert oder geschaffen werden?

Die Beispiele sind nicht abschließend, verdeutlichen aber die Ebene von Fragestellungen, die relevant für Architekturanpassungen sind. Notwendige Entscheidungen sollten dabei im Sinne von „informed decisions“ auf Basis belastbarer Fakten getroffen werden, um Möglichkeiten, Aufwände und Risiken verlässlich abschätzen zu können.

Analyse und Bewertung

Vor einer ausstehenden Änderung ist es also sinnvoll, Zeit in eine Analyse des aktuellen Systems zu investieren und das erworbene Wissen in die Bewertung und Planung einfließen zu lassen. Die Alternative wäre ein Umbau im Blindflug, dessen Umfang und insbesondere Risiken nur äußerst schwer vorhersagbar sind. Aus geschätzten Wochen entwickeln sich durch falsche Annahmen schnell Monate, nicht selten Jahre.

Eine zielorientierte, strukturierte und fundierte Architekturanalyse nimmt natürlich Zeit in Anspruch, liefert aber wertvolle Informationen Dazu zählen u. a.:

  • Wie sind Architekturkonzepte im Code als Strukturen bzw. Muster abgebildet?
  • Welche fachlichen und technischen Komponenten existieren und wie stark sind diese miteinander vernetzt? Welche sichtbaren und unsichtbaren Abhängigkeiten bestehen zwischen ihnen und auf welche Komponenten wirken sich potentielle Änderungen aus?
  • Welche externen Frameworks bzw. Bibliotheken kommen zum Einsatz und welche Komponenten verwenden sie?
  • Gibt es Komponenten, die anhand von Metriken wie hoher Komplexität oder geringer Testabdeckung als besonders risikobehaftet einzustufen sind?
  • Welche Projektbeteiligten besitzen viel Wissen über einzelne Komponenten und sollten in Entscheidungen einbezogen werden? Gibt es Bereiche, in denen durch Personalfluktua-tion auf dieses Wissen nicht mehr zugegriffen werden kann und für die weitere Maßnahmen geplant werden müssen?

Eine Herausforderung besteht in der Erhebung der entsprechenden Informationen. Das bestehende Wissen über die Architektur eines Systems lässt sich oft wie folgt kategorisieren:

  • Dokumentiert: Entweder eine äußerst schwergewichtige Sammlung von Diagrammen bzw. Word-Dateien oder alternativ eine eher skizzenartige Sammlung von Powerpoint-Präsentationen. Beide Ausprägungen sind meist nicht gepflegt und veraltet.
  • Gefühlt: Die lückenhafte Abbildung des Systems in den Köpfen der Beteiligten, die zudem oft durch Insel- und Halbwissen geprägt ist.
  • Real: Die tatsächlich im Code manifestierte Architektur, die aufgrund seines Umfangs, seiner Komplexität bzw. mangelnder Strukturierung nur eingeschränkt erkennbar ist.

Relevant ist letztendlich nur die reale Architektur, die zwar durch Dokumentation bzw. Entwicklerwissen ergänzt werden kann, manuell aber nur unter hohem Zeitaufwand erfassbar ist.

Solide Fakten, planbares Refactoring

Abhilfe kann durch den Einsatz geeigneter Verfahren und Werkzeuge zur Analyse geschaffen werden. Umfangreiche Code-Strukturen können durch Letztere eingelesen, auf Architekturkonzepte abgebildet und unter gewünschten Gesichtspunkten visualisiert werden. Durch die Hinzunahme weiterer Quellen wie Testberichte, Projekthistorie oder das Ticket-System können sie um qualitative Informationen angereichert werden und ermöglichen auf dieser Basis Bewertungen und Planungen.

Wird das Vorgehen automatisiert und damit reproduzierbar, eröffnet sich darüber hinaus eine Möglichkeit, den aktuellen Architekturzustand kontinuierlich zu erfassen: Planungsaufwände für Refactorings und deren Risiken werden nachhaltig reduziert, das Gefühl der Unsicherheit verschwindet.

Im Workshop „Lasst uns einen Monolithen (z)erlegen“ wird ein entsprechendes Vorgehen als iterativer Prozess am oben skizzierten Beispiel beschrieben: Ein in Java implementiertes eCommerce-System enthält eine Katalog-Komponente, welche sich wachsender Nachfrage erfreut, diese aber in Stoßzeiten nicht mehr bedienen kann. Darüber hinaus werden in Lastsituationen andere kritische Komponenten wie Payment negativ hinsichtlich Verfügbarkeit beeinflusst. Verschiedene Optimierungen, z. B. Caching, wurden bereits umgesetzt, geraten aber ebenfalls an Grenzen. Es wird daher die Möglichkeit in Erwägung gezogen, den Katalog herauszulösen und als eigenständigen Service zu betreiben.

Zum Autor

Dirk Mahler ist Berater bei buschmais. Der Schwerpunkt seiner über 15-jährigen Tätigkeit liegt im Bereich Architektur, Qualitätssicherung und Entwicklung von Anwendungen im Unternehmensumfeld.

Weitere Artikel von Dirk

Kommentare sind abgeschaltet.