Auf dem Weg zur High-Level-Zielarchitektur

Langwierige Architekturplanung am Whiteboard ist üblicherweise nicht das, was wir agilen Teams empfehlen. Bei jahrelang gewachsenen Legacy-Systemen kann es jedoch sinnvoll sein, eine High-Level-Zielarchitektur als gemeinsames Zielbild des zukünftigen Systems zu entwerfen. Genau das haben wir bei einem unserer Kunden getan und möchten in diesem Artikel unseren Ansatz beschreiben.

Im vorliegenden Fall gab es in den einzelnen Teams selten bis nie Architekturüberlegungen. Die organisatorischen Teamschnitte waren technisch begründet und verliefen z. B. zwischen Frontend und Backend. Die tatsächliche Systemarchitektur folgte Conway’s Law und richtete sich dementsprechend nicht an den wirklichen Anforderungen aus.

Unser Ansatz dient dazu, in einem solchen Umfeld ein erstes gemeinsames Zielbild einer Architektur auf hoher Flughöhe zu schaffen.

Der Weg zu dieser High-Level-Zielarchitektur erfolgte in 5 Schritten:

1. Systemkontext verstehen
2. Anforderungen sammeln
3. ISO-Qualitätsanforderungen priorisieren
4. Themengruppen bilden
5. Teilsysteme skizzieren

Eine detaillierte Analyse der bestehenden Architektur des Legacy-Systems (Ist-Architektur) haben wir bewusst auf später verschoben. Unserer Erfahrung nach kann man die Anforderungen eines Systems objektiver bewerten, wenn man den aktuellen Stand zunächst außen vor lässt. Ansonsten wird man zu früh von historischen Kompromissen und Zugeständnissen beeinflusst, wodurch man von einer idealen Soll-Architektur abgelenkt wird. Das heißt nicht, dass man auf eine solche Analyse verzichten sollte! Allerdings kommt sie in einem späteren Schritt und dient dann dazu, die Zielarchitektur nachzujustieren und einen Transitionsplan vorzubereiten.

Um unsere Planung strukturiert anzugehen, haben wir bestehende Standards herangezogen:

• C4 Modell – dieses Modell bietet einen einheitlichen aber pragmatischen Satz von Abstraktionen, um Software-Architektur grafisch zu beschreiben. Es fokussiert sich nicht auf die genaue Darstellung der Diagramme, sondern definiert 4 Detailgrade. Level 1 (Systemkontext) und Level 2 (Container) waren ausreichend für unsere High-Level-Zielarchitektur, Level 3 (Komponenten) und Level 4 (Code) bieten sich für eine spätere, detailliertere Planung der Mikroarchitektur an.
• ISO 25010 – der ISO-Standard definiert universelle Qualitätsanforderungen, wonach man die Qualitätsaspekte eines bestehenden oder zukünftigen Systems bewerten kann

Systemkontext verstehen

Im ersten Schritt ging es uns darum, den Kontext des Systems zu verstehen. Welche Rollen haben Benutzer*innen des Systems? Welche anderen Anwendungen greifen auf das System zu? Das Verständnis des Systemumfelds hilft dabei, Anforderungen zu identifizieren, die bestimmte Rollen und Drittsysteme an das System haben.

Wir haben den Systemkontext nach Level 1 des C4-Modells visualisiert. Dazu haben wir einen Workshop mit verschiedenen Stakeholdern durchgeführt, die sowohl die Business-Sicht als auch die Blickwinkel von Kund*innen und Benutzer*innen vertreten konnten. Im Idealfall sind alle Stakeholder unmittelbar involviert.

Das Ergebnis einer solchen Visualisierung für ein fiktives Beispiel sieht so aus:

In der Mitte befindet sich das System als Blackbox, außen werden verschiedene Rollen und deren Use-Cases aufgetragen, ebenso wie Verbindungen zu und Interessen von Drittsystemen.

Anforderungen sammeln

Mit Hilfe des Systemkontexts haben wir begonnen, nähere Anforderungen an das System zu sammeln. Die involvierten Rollen und Drittsysteme werden dazu genauer betrachtet: Was erwarten sie vom System? Welche Annahmen stehen hinter den einzelnen Use-Cases?

Wir haben hier die Beobachtung gemacht, dass Anforderungen vorschnell aus der eigenen Sicht formuliert werden, und die tatsächlichen Use-Cases in den Hintergrund geraten. Dies ist insbesondere gefährlich wenn nicht alle Stakeholder persönlich vertreten sind. Der Systemkontext hilft dabei, die Fragestellungen auf die richtigen Akteur*innen zu lenken.

Die gesammelten Anforderungen müssen in dieser Hinsicht gefiltert und eingeordnet werden. Wenn rein technische Wünsche geäußert werden, gilt es genau zu hinterfragen, welches Problem damit eigentlich für welche Rolle gelöst werden soll. Unsere Erfahrung hat gezeigt, dass die Teilnehmer häufig schon von technischen Lösungen überzeugt sind, die sie als Anforderungen verkleiden, aber die von den eigentlichen Anforderungen ablenken. Solche Lösungen sollen erst in einem späteren Schritt erarbeitet werden.

Beispiele für „Anforderungen“, die weiter hinterfragt werden müssen:

• „Wir brauchen Microservices“ -> Warum? Welches zugrundeliegende Problem soll gelöst werden?
• „Die Software muss schnell sein“ -> Wer erwartet wo eine wie schnelle Reaktion?
• „Wir brauchen eine moderne API“ -> Wer ist wir? Welche anderen Systeme müssen angebunden werden? Was erwarten diese?

Beispiele für Anforderungen die in diesem Schritt erarbeitet werden:

• Kund*innen wollen zeitnah über Terminänderungen informiert werden.
• Der Außendienst muss auch ohne Netzverbindung Arbeitsprotokolle anfertigen können.
• Die IT erwartet, dass die Software einfach installiert werden kann.
• Die Software muss Daten an externe ERP-Systeme senden.
• …

Bei der Ermittlung des Systemkontextes und der Anforderungen können bewährte Methoden wie User Story Mapping oder Event Storming helfen. In unserem konkreten Fall hatten wir nicht die nötige Zeit, diese zur Anwendung zu bringen.

ISO-Qualitätsanforderungen priorisieren

Die gesammelten Anforderungen haben wir mit den Qualitätsanforderungen aus der ISO 25010 abgeglichen. Welche Qualitätsanforderungen stechen besonders hervor? Auf diese gilt es sich dann zu konzentrieren. Eine Softwarearchitektur kann unmöglich alle Anforderungen gleichzeitig bzw. gleich gut erfüllen. Eine gute Architektur geht daher die Trade-Offs an den richtigen Stellen ein, um das beste Ergebnis im jeweiligen Kontext zu erzielen.

Die bislang gesammelten Anforderungen konnten uns einen guten Überblick geben, welche der über 30 ISO-Anforderungen besondere Beachtung verdienen. Wir konnten uns auf 12 ISO-Anforderungen festlegen, die wir in einem weiteren Workshop näher betrachtet haben.

Jede dieser Qualitätsanforderungen haben wir im Workshop kurz vorgestellt. Dabei haben wir auch erläutert, zu welchen anderen ISO-Anforderungen sie ggf. in Konkurrenz stehen kann.

Für jede Qualitätsanforderung haben wir 3 Punkte behandelt:

1. Wo ist sie wichtig?
2. Wo ist sie weniger wichtig?
3. Aussagen formulieren

Wo ist die Anforderung wichtig? Bei welchen Use-Cases ist z. B. das Zeitverhalten relevant? Welche Daten müssen interoperabel sein? Welches UI muss besonders bedienfreundlich sein?

Wo ist eine Anforderung weniger wichtig? Klar, alles soll „schnell“ sein, aber vielleicht gibt es ja einen Bereich, wo es weniger darauf ankommt?

Im 3. Schritt haben wir zu jeder ISO-Anforderung konkrete Aussagen erarbeitet in der Form:

Im <Bereich> soll <Anforderung> erreicht werden, auch wenn <Trade-Off>

Durch die konkreten Aussagen sollen die abstrakten ISO-Anforderungen greifbarer gemacht und mögliche Trade-Offs aufgezeigt werden. Das heißt nicht, dass in der Zielarchitektur all diese Trade-Offs zwangsläufig eingegangen werden. Es zeigt jedoch, wo bei den Architekturüberlegungen ein Spielraum besteht und wo nicht.

Hier ist ein fiktives Beispiel für die ISO-Anforderung Zeitverhalten:

Zeitverhalten	Wichtig bei	Weniger wichtig bei
	Produktanzeige	Bestätigungsmail
	Ergebnisberechnung	Archiv
	…	…
	…	…

Aussagen
Die Produktanzeige soll innerhalb 1 Sekunde laden, auch wenn dann ggf. nicht alle Daten aktuell sind.
Archivdaten unterliegen strengen Zugriffsregeln, sie müssen nicht in Echtzeit abgerufen werden können
Es müssen schnelle Ergebnisse geliefert werden, auch wenn diese dann nicht zu 100 % exakt sind

Themengruppen bilden

Aus den Antworten auf die Fragen „Wo ist es [weniger] wichtig?“ und den konkret formulierten Aussagen zeichneten sich bestimmte wiederkehrenden Themengebiete ab, z. B.:

• Kundenportal
• Verwaltung
• Produktkatalog
• Archiv
• API Schnittstellen
• …

Wir haben nun alle Aussagen und zugehörigen ISO-Anforderungen nach diesen Themen gruppiert. Dabei wurde deutlich, dass bestimmte ISO-Anforderungen nur bei bestimmten Themen relevant sind, während andere übergreifend Beachtung finden. Bei manchen Gruppen wiederum stachen bestimmte ISO-Anforderungen als möglicher Trade-Off hervor.

In den einzelnen Themengruppen begannen wir dann Lösungsideen zu formulieren, die die entsprechenden Anforderungen und Trade-Offs berücksichtigten. Wichtig ist, dass man die Tendenz „One architectural pattern fits all“ vermeidet, und dass die verschiedenen Themengruppen unabhängig voneinander betrachtet werden.

Teilsysteme bilden

Aus den Themengruppen und unseren Lösungsideen formten sich dann recht offensichtlich einzelne Teilsysteme, die in der Zielarchitektur eine Rolle spielen könnten. Bei dem Schnitt dieser Teilsysteme achteten wir darauf, dass die Qualitätsanforderungen erfüllt werden und machten bewusst dort Trade-Offs, wo es notwendig und gleichzeitig aber auch erlaubt war, diese einzugehen.

Das Zielsystem skizzierten wir wieder im C4-Modell, auf Level 2. Hier zeigen wir einen Ausschnitt einer Skizze für ein fiktives Beispiel:

In dieser Skizze sieht man, wie die relevanten Anforderungen als Grundlage für technische Entscheidungen genutzt werden können. Die grünen Haftnotizen stellen dabei erfüllte Qualitätsanforderungen dar, während die orangenen für bewusste Trade-Offs stehen. In dem Beispiel ist es für Lieferant*innen besonders wichtig, dass der Lieferungscontainer permanent verfügbar ist und schnell auf Anfragen reagiert, so dass sie Aufträge ohne Wartezeiten weiter abarbeiten können, auch wenn andere Teile des Systems ausfallen.

Wir nehmen dabei in Kauf, dass der Container eine eigene Datenhaltung erhält, so dass seine Kopie der Aufträge nicht unbedingt den aktuellsten Zustand vorhält und Lieferdaten erst verzögert in der Verwaltung ankommen (eventual consistency). Gleichzeitig sorgt die Trennung der Daten für den gewünschten höheren Zugriffsschutz auf Verwaltungsseite.

Es wurde also versucht, die Kompromisse möglichst da anzusetzen, wo sie zu verschmerzen sind und so die gewünschten Qualitätsanforderungen an den wichtigen Stellen zu erreichen.

Und nun?

Warum haben wir das Ganze gemacht? Was folgt daraus? Ausgehend von der vorgefundenen Ist-Architektur, ist die erarbeitete Zielarchitektur zum einen utopisch und zum anderen entspricht sie sicherlich nicht zu 100 % dem, was tatsächlich gebraucht wird. Eine gute Architektur muss sich aus unserer Sicht langfristig und iterativ entwickeln. Ein gutes Verständnis der Fachdomäne ist ebenfalls wichtig, damit die sich daraus ergebenden Architekturanforderungen hinreichend beachtet werden. Die High-Level-Zielarchitektur kann nur als Beginn eines Prozesses gesehen werden.

Weiterhin sollte nun begonnen werden, sich näher mit der Ist-Architektur auseinander zu setzen und genau zu prüfen, welche dort getroffenen Entscheidungen auch zukünftig wichtig sind, im Idealbild jedoch übersehen wurden.

Fazit

Softwareentwicklung ist zu komplex, um vorab eine fertige Blaupause eines Systems liefern zu können. Es können nicht alle Anforderungen vorhergesehen werden und Bedürfnisse ändern sich im Laufe der Zeit. Unser Ziel war, ein lebendes Dokument gemeinsam mit einer Bandbreite von Stakeholdern beim Kunden zu entwickeln, welches als Ausrichtung für weitere Diskussionen dient und die agile Weiterentwicklung des Produkts unterstützt.

Das hier beschriebene Vorgehen bietet einen unmittelbaren Wert, wenn, wie in unserem Fall, kein einheitliches Architekturverständnis in der Organisation vorliegt und schnell eine brauchbare Diskussionsgrundlage geschaffen werden soll.

Die gemeinsamen Workshops und das entstandene Zielbild haben ein besseres gemeinsames Verständnis für Architektur geschaffen. Man hat nun eine fundierte Grundlage, auf deren Basis man diskutieren und die Architektur evolutionär fortsetzen kann. Die Zielarchitektur hat zudem aufgezeigt, wo Refactorings oder ggf. Neuentwicklungen nötig sind, welche davon innerhalb der Organisation stattfinden müssen und wo auch an Outsourcing gedacht werden kann. Auf Basis der Architekturüberlegungen können auch neue, sinnvollere Teamschnitte angedacht werden.

Zu guter Letzt möchten wir noch Uwe Friedrichsen unseren Dank aussprechen, für das theoretische Fundament unseres Vorgehens, sowie Christian Langmann für die praktische Unterstützung bei der Planung und Durchführung der Workshops.