Wenn es bei der Software-Architektur nicht passt, drohen immer ernsthafte Probleme

Die Software-Architektur umfasst vor allem die Entscheidungen, die für ein Software-System weitreichende, querschnittliche Auswirkungen haben und später schwer zu ändern sind. Und jedes System hat eine Software-Architektur, egal ob sie bewusst geschaffen wurde oder nur unbewusst. Egal ob sie dokumentiert ist oder nicht.

Wenn also etwas bei der Software-Architektur nicht passt, dann kann das große Probleme verursachen. Die Bandbreite der möglichen Probleme ist riesig, wir nennen hier einige häufige Beispiele:

• Qualitätseigenschaften des Systems werden nicht erreicht (z.B. Performance, Verfügbarkeit, Sicherheit) und damit erfüllt das System nicht die gestellten Ansprüche bei Nutzung und Betrieb. Bis hin zur vollständigen Unbrauchbarkeit.
• Entwicklungsteams können nicht effizient arbeiten, weil Entwicklungs- oder Änderungsaufgaben sehr aufwändig sind und das System schwer zu verstehen ist. Bis hin zu so hohen Änderungsaufwänden, dass es defacto einem Weiterentwicklungsstopp gleichkommt.
• Es wird viel Zeit und Geld investiert, ohne den adäquaten Wert mit einem Software-System generieren zu können. Bis hin zur Notbremse.

Je länger es mit der Software-Architektur nicht passt und trotzdem weitergearbeitet wird, desto größer werden die Probleme und desto teurer wird eine Korrektur. Es wird immer mehr Aufwand versenkt und niemand will die Fehler korrigieren, weil das das Projekt weit im Zeitplan zurückwerfen würde.

Schon zahlreiche Systeme sind daran komplett gescheitert und wurden schon vor Fertigstellung oder irgendwann während der Lebenszeit eingestellt. Davon gelangt aber meist kaum etwas an die Öffentlichkeit und niemand redet gerne darüber.

Defizite in der Software-Architektur bleiben oft lange unentdeckt

Software-Architektur ist meist schwer zu greifen. Sie ist als Abstraktion bzw. sogar Kombination von vielen Abstraktionen oft auch schwer vorstellbar und vermittelbar. Oft ist Software-Architektur auch nicht klar herausgearbeitet und gut dokumentiert. Das macht sie noch schwerer zu greifen. Darin ungeeignete Entscheidungen zu finden, deren Auswirkungen vielleicht erst viel später spürbar werden, ist extrem schwierig.

Dazu kommt auch noch, dass viele Beteiligte in der Software-Entwicklung ziemlich unterschiedliche Vorstellungen haben rund um Software-Architektur. Was genau mit den Begriffen rund um Architektur gemeint ist. Wie Architektur designt wird. Wie Architektur dokumentiert wird. Wie eine dokumentierte Architektur zu lesen ist. Wie viel Architektur genug ist. Oft genug gibt es aber kein Bewusstsein für diese unterschiedlichen Sichtweisen oder es ist zu anstrengend, sich an der Klärung abzuarbeiten.

Und deshalb bleiben Defizite in der Software-Architektur oft lange unentdeckt. Oder unausgesprochen. Oder sie werden einfach nicht sauber auf den Punkt gebracht, sodass Gegenmaßnahmen möglich wären.

Wenn hinreichend viel Zeit vergangen ist, werden die daraus resultierenden Probleme (siehe oben) sichtbar. Das passiert gleichermaßen bei Neuentwicklungen, in der Weiterentwicklung oder bei einer Migration. Die Defizite in der Software-Architektur sind dann aber trotzdem oft noch nicht klar analysiert und als Ursache identifiziert.

Das ist insbesondere deswegen tragisch, weil Software-Architektur als Disziplin im Software Engineering ja gerade dafür steht, Defizite in der Gestaltung eines Systems frühzeitig zu finden und zu vermeiden. Insbesondere bevor zahlreiche weitergehende und aufwändige Aktivitäten durchgeführt wurden.

Genau hier setzt Architekturbewertung an!

Architekturbewertung hilft, ein System und seine Architektur besser zu verstehen, Defizite aufzudecken und Entscheidungen abzusichern

Eine Architekturbewertung (auch Architektur-Review genannt) hilft dabei, Klarheit zu schaffen und zu verhindern, dass Defizite zu lange verborgen bleiben. Letztendlich geht es mit Architekturarbeit immer darum, die (Weiter-) Entwicklung eines Softwaresystem zu unterstützen, das die konkreten Anforderungen angemessen umsetzt. Dafür muss die Architektur für die Anforderungen angemessen sein und die Implementierung des Systems muss der geplanten Architektur folgen. Und damit sauber gearbeitet werden kann, müssen die Beteiligten die Architektur verstehen können, was durch die Dokumentation ermöglicht wird.

Deshalb sollten die folgenden Aspekte überprüft und bewertet werden, im Hinblick auf die konkreten Bewertungsziele:

• Angemessenheit der Architektur: Ist die Architektur mit ihren Entscheidungen angemessen für die Anforderungen (vor allem auch die Qualitätsanforderungen) an das System? Welche Kompromisse wurden gemacht und zu welchen Risiken führt das? Ist die Architektur in sich schlüssig und konsistent?
• Angemessenheit der Dokumentation: Ist die Dokumentation angemessen für die Entwicklungsorganisation und die beteiligten Personen? Ist die Dokumentation in sich schlüssig, konsistent, aktuell, vollständig, …?
• Konsistente Umsetzung in der Implementierung: Ist die Architektur mit ihren Konzepten präzise und konsistent im Code umgesetzt? Wie viele Abweichungen im Code gibt es und welche Konsequenzen haben diese?

Es gibt zahlreiche Anlässe und Zeitpunkte für eine Architekturbewertung

Architekturbewertung sollte immer zielgerichtet vorgehen. Sie ist nie ein Selbstzweck. Es geht immer darum, in einer bestimmten Situation und mit einem bestimmten Anlass ein klar gefasstes Ziel zu verfolgen. Das geht immer damit einher, das System besser zu verstehen, die Architektur klar herauszuarbeiten und bestimmte Aspekte zu analysieren. So können wichtige Entscheidungen abgesichert werden.

Architekturbewertung hat nicht den einen festen Platz und Zeitpunkt in der Software-Entwicklung. Vielmehr gibt es zahlreiche unterschiedliche Anlässe, Motivationen und Zeitpunkte, eine Architekturbewertung oder einzelne Aktivitäten daraus durchzuführen:

• Bei einer Neuentwicklung kann das initiale Architekturdesign (völlig unabhängig vom Entwicklungsprozess) bewertet werden. So wird direkt klar, ob die Anforderungen präzise genug sind und der erste Wurf des Designs angemessen ist.
• Während der Weiterentwicklung eines Systems passiert im ganz normalen Alltag sehr viel. Es kommen immer wieder neue Anforderungen dazu und es werden kontinuierlich weitere Entscheidungen getroffen. Architekturbewertung kann prüfen, ob die Architektur immer noch passt. Und sie kann prüfen, ob die entwickelte Implementierung zur Architektur passt.
• Bei der Modernisierung eines Systems, der Ablösung von Technologien oder bei größeren Umbauten z.B. hin zu SaaS gibt es immer wieder den Bedarf, Klarheit über das aktuelle System herzustellen und Entscheidungen für die Zukunft abzusichern. Architekturbewertung ermöglicht genau das.
• Wenn Probleme auftreten (vor allem bei der Erreichung von Qualitätseigenschaften), oder ganze Projekte und Produkte in Schieflage geraten sind, kann Architekturbewertung beim Verständnis des Big Pictures und der Analyse der Ursachen helfen.
• Wenn neue Trends aufziehen und ein Unternehmen wissen möchte, ob ein bestimmter Trend mit dem eigenen System verträglich wäre und Vorteile bringen könnte, dann hilft eine Architekturbewertung und lichtet den Nebel der Marketingversprechungen.

Je nach Zeitpunkt und Bewertungsziel können auch sehr unterschiedliche Stakeholder eine Architekturbewertung initiieren. Das kann vom Top-Management eines Unternehmens bis zum Entwicklungsteam gehen, auch Kundenunternehmen können Architekturbewertungen anstoßen, um mehr Konfidenz in ein Softwaresystem zu erhalten.

Architekturbewertung bringt vielfältigen Nutzen

• Abgesicherte Entscheidungen: Entscheidungen sind nicht nur getroffen, es ist auch klar warum und wie sie zu den Anforderungen beitragen. Risiken und Tradeoffs werden explizit gemacht.
• Klarere Architekturanforderungen: Architekturanforderungen werden mit Stakeholdern erfasst, präzise und einheitlich als Qualitätsszenarien dokumentiert und mit den Stakeholdern validiert. Somit wird kompensiert, was oftmals fehlt.
• Mehr aktive Involvierung von Stakeholdern: Unterschiedlichste Stakeholder werden aktiv involviert und spüren ihren Einfluss auf die Architektur.
• Mehr Architekturwissen und Architekturbewusstsein: Architekturbewertung ist eine Aufgabe mit oft vielen Beteiligten. Im Zuge der Architekturbewertung lässt sich das allgemeine Architekturwissen verbessern, eine gemeinsame Sprache finden und das Bewusstsein für die Wichtigkeit von Architektur schärfen.
• Klareres und gemeinsames Wissen über die Architektur: Mehr Stakeholder wissen mehr über die konkrete System-Architektur und profitieren davon bei ihren zukünftigen Aufgaben.
• Bessere Architektur: Durch die klare Herausarbeitung der Architektur werden meist Verbesserungsmöglichkeiten direkt klar und somit verbessert sich die Architektur.
• Bessere Dokumentation: Im Zuge von Architekturbewertung wird meist auch zumindest ein Teil der Architektur (nach-)dokumentiert. Das kommt direkt der Dokumentation zugute.
• Deutlich erhöhte Erfolgswahrscheinlichkeit für Gesamtvorhaben: Die zahlreichen Verbesserungen in den genannten Aspekten führen dazu, dass das Gesamtvorhaben deutlich profitiert.

Qualitätseigenschaften brauchen besonderen Fokus bei der Architekturbewertung

Qualitätseigenschaften wie Performance, Verfügbarkeit, Sicherheit, Wartbarkeit, Flexibilität hängen ganz besonders von den getroffenen Architekturentscheidungen ab. Und bei den Qualitätseigenschaften gibt es auch meist größten Probleme.

Qualitätseigenschaften müssen aber klar gefasst werden. „Das System muss schnell, hoch-verfügbar und flexibel sein“ reicht bei weitem nicht als Anforderungen. Vielmehr muss präzise herausgearbeitet werden, was Qualitätseigenschaften konkret für das vorliegende System bedeuten. Diese Anforderungen müssen mit Stakeholdern erhoben und präzise dokumentiert werden. Dazu eignet sich das Konzept der Qualitätsszenarien (auch Architekturszenarien genannt) besonders gut. Sie geben ein Template an die Hand, mit dem Qualitätsanforderungen einheitlich dokumentiert werden können.

Ein Beispiel für ein Qualitätsszenario, hier für das Qualitätsattribut „Performance“:

• Eine Bibliothekarin öffnet die Anwendung „Bücherverwaltung“ in ihrem Webbrowser. Zu der Zeit arbeiten nicht mehr als 100 gleichzeitige Nutzer mit der Anwendung. Die Anwendung öffnet sich in weniger als 1s im Browser und ist vollständig geladen, sodass die Bibliothekarin mit ihrer Sachbearbeitung beginnen kann.

• Das Qualitätsszenario beinhaltet die Bestandteile „Stimulus“ auf das System (hier die Aktion der Bibliothekarin), die aktuelle „Umgebung“ (hier die Zahl der gleichzeitigen Nutzer) und die „Systemantwort“ (hier die geladene Anwendung). Außerdem wird alles, was möglich ist quantifiziert, hier die parallele Nutzerzahl und die Antwortzeit.

Gleichzeitig muss sich Architekturbewertung aber auch zu einem gewissen Grad mit der Fachlichkeit des Systems auseinandersetzen. Nur wenn klar ist, wie die Fachlichkeit in Software-Elemente dekomponiert wird, kann auch sauber analysiert werden, wie die querschnittlichen Konzepte und Entscheidungen zur Erreichung von Qualitätsanforderungen wirken.

Viele Methoden bieten Guidelines für Architekturbewertung

Es gibt zahlreiche Methoden für Architekturbewertung. Die wohl bekannteste und meistzitierte ist ATAM (Architecture Tradeoff Analysis Method) vom Software Engineering Institute. Es gibt zahlreiche weitere Methoden (teils Vorläufer, teils Derivate), die sich jeweils besonders um bestimmte Aspekte der Architekturbewertung kümmern. Deshalb gibt es auch nicht DIE EINE Methode oder DIE BESTE Methode. Es ist sinnvoll, etliche Methoden und ihre Grundprinzipien und Bestandteile zu kennen und dann im konkreten Bewertungsprojekt ein sinnvolles Vorgehen abzuleiten.

Architekturbewertung wird schneller, fokussierter und präziser mit mehr Erfahrung

Methoden für die Architekturbewertung bieten Guidelines für das Vorgehen. Was sie meist weniger bieten, ist fundiertes Erfahrungswissen:

• Erfahrungswissen über bestimmte Domänen und Technologien.
• Erfahrungswissen darüber, welche Lösungsstrategien für Anforderungen häufig funktionieren und in welcher Kombination. An der Stelle können eher Werke über Architekturstile, Architekturmuster und Architekturtaktiken hilfreich sein.
• Erfahrungswissen über die Dynamik und Zusammenarbeit zwischen den Beteiligten in Architekturbewertungen.

Es ist wie mit vielem anderen auch: Man macht in jeder weiteren Architekturbewertung neue Erfahrungen und lernt dazu. Ein breites Erfahrungswissen aus vielen Architekturbewertungen mit unterschiedlichsten Kontexten ist also extrem hilfreich bei zukünftigen Architekturbewertungen und kann durch Methoden nur eingeschränkt vermittelt werden.

Es hilft insbesondere auch bei der Interpretation und Aufbereitung der Bewertungsergebnisse und bei der Umsetzung in notwendige Verbesserungsmaßnahmen.

Bei kritischen Situationen ist es unerlässlich, Experten mit Erfahrung in Architekturbewertung hinzuziehen.

Architekturbewertung ist sehr skalierbar

Architekturbewertung kann und muss sehr stark auf den gegebenen Kontext angepasst werden. Architekturbewertung und der spendierte Aufwand können sehr gut skaliert werden. Durch starke Priorisierung und striktes Time-Boxing ist es möglich, sehr schnell einen ersten Eindruck zu gewinnen.

Innerhalb eines eingespielten Entwicklungsteams und mit fokussiertem Scope kann so eine Architekturbewertung mit wenigen Stunden Aufwand durchgeführt werden.

Natürlich gibt es aber auch andere Situationen, die eher kritisch, organisatorisch komplex und auch politisch aufgeladen sind. Für solche Situationen muss dann natürlich viel mehr Aufwand eingeplant werden, um zu einem belastbaren Ergebnis zu kommen.

Die wesentlichen Einflussfaktoren auf die Skalierung und den Aufwand von Architekturbewertungen sind die folgenden:

• Zielstellung der Bewertung und konkrete Fragen
• Kritikalität der Situation
• Zeithorizont für die Fertigstellung der Bewertungsergebnisse
• Benötigte Konfidenz der Bewertungsergebnisse
• Systemgröße und -komplexität
• Organisatorische Komplexität
• Anzahl der zu involvierenden Stakeholder
• Unklarheit in den Aussagen und der Dokumentation

Egal wie die Situation und der Anlass ist: Wichtig ist es, eine pragmatische Vorgehensweise zu wählen, die der Situation gerecht wird.

Noch mehr Infos zu Architekturbewertung

In diesem Artikel geben wir einen Überblick für alle, die verstehen wollen, was Architekturbewertung ist und leisten kann. Darüber hinaus gibt es aber natürlich noch viel mehr …

Du schaust gerne ein Video?

Wenn du erfahren willst, wie du eine Architekturbewertung selbst durchführen kannst, dann empfehlen wir dir das Webinar „Architekturbewertung“, das Dominik in unserer Zeit bei Fraunhofer zusammen mit unserem ehemaligen Kollegen Balthasar Weitzel gehalten hat.

Du liest gerne und möchtest es genau wissen?

Wenn du es noch genauer wissen willst, empfehlen wir dir das Buch „Pragmatic Evaluation of Software Architectures“, das Matthias in unserer Zeit bei Fraunhofer zusammen mit unserem ehemaligen Kollegen Jens Knodel geschrieben hat. Das Buch strukturiert das komplette Thema Architekturbewertung anhand von mehr als 100 Fragen und Antworten und teilt zahlreiche praktische Erfahrungen aus Architekturbewertungen.

Du möchtest dir live einen Vortrag von uns zum Thema ansehen?

Am 23.10.2024 halten wir einen Vortrag auf der Konferenz Software Architecture Alliance in München. Das Thema wird sein „Plaudern über Architektur-Reviews – unsere Erfahrungen als Ergänzung zum Methodenwissen“.

Du möchtest deine Erfahrungen aus Architekturbewertungen mit uns teilen? Oder du hast Fragen zu Architekturbewertung? Schreib uns gerne einen Kommentar.