Architekturbewertung – keine Noten aber mehr Durchblick

Stefan Toth

Softwarearchitektur ist die Brücke zwischen den Zielen der Auftraggeber und der fertigen Software. Die getroffenen Strukturentscheidungen sind von großer Tragweite, erfordern ein hohes Maß an Erfahrung und müssen darüber hinaus zum richtigen Zeitpunkt und unter den richtigen Voraussetzungen getroffen werden. Trotz dieser Bedeutung ist Architektur zu oft das Werk von Einzelnen und meistens zu weit von der Umsetzung und den eigentlichen Bedürfnissen entfernt. Die Architekturbewertung hat sich zum Ziel gesetzt, das zu ändern. Der Weg dazu führt über transparente Architekturentscheidungen – eine gläserne Architektur.

Wie hätte Winnetou entschieden? Diese Frage stellt der Titel eines kleinen Managementleitfadens, den ich neulich in einem Museumsshop entdeckte. Tipp Nr.4 rät: „Leg dein Ohr auf die Schienen“. Ich spreche ganz klar keine Kaufempfehlung für das Büchlein aus – die Frage wie sich andere bei schwierigen Entscheidungen verhalten hätten, ist aber eine gute. Architekturbewertung macht genau das – auch wenn nicht zwangsläufig Indianer sondern eher gute Entwickler im Fokus stehen und der Prozess ein wenig systematischer anmutet. Ein Teil dieses Prozesses ist es, sein Ohr auf die Schienen zu legen, um zu erfahren, welche Auswirkungen Entscheidungen nach sich ziehen, an welchen Stellen die Software modifizierbar gehalten werden muss und als Wichtigstes: Was der Kunde tatsächlich will. Weil man sich in solchen Themen leicht verliert, sollte man jedoch eines ganz im agilen Sinn nicht vergessen: rechtzeitig aufzustehen bevor der Zug kommt. Moderne Bewertungsmethoden setzen all diese Aspekte um und sorgen dafür, dass entscheidende Attribute erfolgreicher Projekte greifbar werden:

  • Klare und verwertbare Anforderungen
  • Gute Bindung zu wichtigen Stakeholdern
  • Frühe Klärung essenzieller Fragen
  • Umsetzbarkeit und Angemessenheit der Architektur
  • Breites Verständnis für Architektur und Probleme

Dass diese Ziele nicht durch die Anstrengung einzelner Projektmitglieder erreicht werden können, ist klar. Szenariobasierte Bewertungsmethoden, wie sie heute üblich sind, stellen deshalb einen geleiteten Gruppenprozess dar, der viele agile Prinzipien unterstützt und umsetzt. Entwickelt werden solche Methoden seit Anfang der 90er Jahre. Federführend ist dabei, das Software Engineering Institute der Carnegie Mellon Universität, das auf einem wissenschaftlichen Fundament die meisten in der Praxis erprobten Methoden konzipiert hat (Kasten: „Die wichtigsten Bewertungsmethoden“). Im Folgenden werden die Kernthemen dieser Methoden beleuchtet und gezeigt, wie man die enthaltenen Ansätze zusammen mit agilen Prinzipien erfolgreich kombinieren kann, um Architekturen sinnvoll zu bewerten.

Die wichtigsten Bewertungsmethoden
Die hier aufgeführten Methoden unterscheiden sich hauptsächlich durch ihre Ausrichtung. Die eingesetzten Techniken sind sehr ähnlich – Szenarien, Bewertungsworkshops und qualitative Durchsprachen sind dabei üblich. Weitere, spezielle Bewertungsmöglichkeiten wie Fragebögen, Checklisten oder Metriken würden den Rahmen dieses Artikels leider sprengen.

– ATAM – Architecture Tradeoff Analysis Method: Die bekannteste und ausgereifteste Methode, die detailliert auf die Beziehung zwischen Entwurfsentscheidungen und den beeinflussten Qualitätsmerkmalen eingeht.
– SACAM – Software Architecture Comparison Analysis Method: Eine Methode zum Vergleich mehrerer Architekturalternativen. So genannte „Extraction Directives“ definieren Artefakte und Ansätze, die verglichen werden sollen.
– CBAM – Cost-Benefit Analysis Method: Neben Qualitätsmerkmalen wird die Architektur hier auch auf Wirtschaftlichkeit geprüft. Nutzen und ROI sind wichtige Themen beim Durchsprechen.

[ header = Seite 2: Was bewerten? ]

Was bewerten?

Um zu verstehen, wie Architekturbewertung funktioniert, beschäftigen wir uns zunächst mit ihrem Umfeld: der Architektur, den Personen und Institutionen, deren Bedürfnisse umgesetzt werden sollen – kurz den Stakeholdern – und den Anforderungen. Beginnen wir mit dem Bewertungsgegenstand: Der Architektur. Sie wird oft als Rückgrat des Systems gesehen, als Fundament. Beides lässt darauf schließen, dass Architektur im Nachhinein nur sehr schwer änderbar ist. Das gilt in der Praxis jedoch nicht für alle Teile einer Architektur. Betrachten wir z. B. eine einzelne Architekturentscheidung wie den Einsatz von ResultSets, die persistente Daten im Client verfügbar machen, um Warenbestände eines Lagerhauses anzuzeigen. Ist diese Entscheidung schwer änderbar? Pauschal kann man diese Frage nicht beantworten. Wird direkt auf den ResultSets gearbeitet, ist das sicher der Fall, durch die Kapselung der Zugriffe kann man aber für etwas mehr Flexibilität sorgen. Die moderne Softwareentwicklung nennt so etwas „gutes Design“ und nutzt für diese und ähnliche Aufgaben Schnittstellen, Entwurfs- und Architekturmuster oder auch explizites Abhängigkeitsmanagement. Gutes Design lässt sich selbst nicht aus den Anforderungen begründen, hält die Software aber modifizierbar und sorgt so dafür, dass die Korrektheit der getroffenen Entscheidungen nicht mehr so kritisch ist. Entscheidungen können tendenziell später und unter besseren Voraussetzungen getroffen werden.

Sowohl Design als auch Entscheidungen werden in Architekturbewertungen untersucht. Design sollte konsistent und nicht zu kompliziert sein. Die Architektur wird sonst fehleranfällig, schlecht wartbar und schwer umsetzbar. Aus den Anforderungen abgeleitete Entscheidungen werden zunächst auf ihre spätere Abänderbarkeit untersucht. Ist die zu bewertende Entscheidung von Haus aus leicht zurückzunehmen, begnügt man sich mit einer sehr einfachen oder gemütlichen Lösung, um erst bei Bedarf zu einer ausgefeilteren Lösung zu wechseln. Diese Vorgehensweise hält das System übersichtlich und einfach. Der agile Leitsatz „Do the simplest Thing that could possibly work“ (Ward Cunningham, Kent Beck) wird dabei sehr gut auf Architekturprobleme übertragen.

Erst schwer änderbare Entscheidungen versucht man abzusichern und detailliert zu bewerten. Dabei muss es sich nicht zwangsläufig um die größten Entscheidungen mit den komplexesten Lösungen handeln. Im realen Leben ist das schließlich auch nicht so. Nehmen wir beispielsweise eine Heirat. Die Optionen könnten einfacher nicht sein: Ja oder nein. Dennoch gewinnt die Entscheidung an Wichtigkeit, weil sie im Nachhinein nur schwer geändert werden kann, sehr langfristig wirkt und nur schwer abgeschätzt werden kann, wie gut das System in einigen Jahren läuft.

Wen einbeziehen?

Wie geht man nun am besten mit Heiratsentscheidungen um? Aus erster Hand weiß ich, dass es sich empfiehlt, die Bedürfnisse möglichst gut zu kennen und schon vor der Entscheidung engen (Kunden-)Kontakt zu pflegen. Vorher zu fragen, kommt auch gut an. Bei Softwaresystemen ist der Sachverhalt praktisch derselbe. Um gute Entscheidungen zu treffen, muss man die Bedürfnisse der Stakeholder möglichst gut kennen und die getroffenen Entscheidungen auch von ihnen auf fachlicher Ebene begutachten lassen. Man öffnet die Architektur, macht Entscheidungen transparent und bezieht alle wichtigen Stakeholder ein. Als Wichtigstes: den Kunden.

[ header = Seite 3: Bedürfnisse festhalten ]

Bedürfnisse festhalten

Die richtige Erhebung, Betrachtung und Dokumentation der Bedürfnisse von Stakeholdern ist entscheidend für eine gute Umsetzung. Im Hinblick auf die Architektur dürfen vor allem nicht funktionale Anforderungen nicht vernachlässigt oder zu unkonkret beschrieben werden. Nicht funktionale Anforderungen beeinflussen das gesamte System und können meist nur auf architektonischer Ebene effektiv behandelt werden. Um Architekten die nötige Konkretheit zu geben und Stakeholdern zu ermöglichen, sich natürlich auszudrücken, empfiehlt sich die Beschreibung in konkreten Beispielen. So kann man, ähnlich wie bei Anwendungsfällen oder User Stories, konkrete Verwendungen des Systems festhalten, in denen sich bestimmte Qualitätsmerkmale zeigen. Ein Beispiel wäre: „Ein Lagerhausmitarbeiter fragt bei Hochauslastung einen Datenbankreport an und erhält den Report innerhalb von 2 Sekunden“. Damit kann ein Architekt besser arbeiten als mit der üblichen Angabe „Performanz ist uns wichtig“. Die meisten Architekturbewertungsmethoden haben diese Beschreibungen als wichtig erkannt und bezeichnen sie als Szenarien (mehr dazu im nächsten Abschnitt).

Der konkrete Bewertungsprozess

Es gibt also eine ganze Reihe von Ansatzpunkten, Schwächen des architektonischen Prozesses mit der Architekturbewertung zu überwinden. Wenn es darum geht, eine angemessene Architektur zu entwickeln, ist es neben der genaueren Betrachtung des Umfelds von Entscheidungen und der Einbeziehung von Stakeholdern vor allem wichtig, die konkreten Anforderungen zu kennen. Bewertungsmethoden wie ATAM sorgen dafür, dass der Architekt mit all diesen Dingen nicht allein gelassen wird. Abbildung 1 zeigt, wie ein konkreter Architekturbewertungsprozess, angelehnt an ATAM, aussehen kann. Die Grundprinzipien sind klar definierte und kommunizierte Anforderungen, gemeinsame Arbeit am Problem, Kommunikation sowie frühes und regelmäßiges Feedback von allen Stakeholdern.

Abb.1: Der Architekturbewertungsprozess

Kundenziele

In Abbildung 1 grün dargestellt, finden Sie die Anforderungsarten, die für die Entwicklung einer Architektur wichtig sind. Neben den allgemeinen Zielen der Auftraggeber sind das Qualitätsmerkmale, Rahmenbedingungen und konkrete Szenarien. Die Erhebung dieser Anforderungen beim Kunden wird meist durch den Requirements Engineer unterstützt. Die nötige Schärfung erfolgt durch die Einbeziehung des Architekten. Erst dadurch findet eine entsprechende Untersuchung der Umsetzbarkeit statt, die dem Kunden auch sofort zurückgespiegelt wird.

[ header = Seite 4: Architekturentscheidungen ]

Architekturentscheidungen

Haben die ersten Szenarien eine entsprechende Qualität und sind die initialen Rahmenbedingungen klar, beginnt der Architekt auf dieser Basis, die Architektur zu entwickeln (blauer Bereich in Abb. 1). Die klaren Anforderungen ermöglichen fokussierte Arbeit. In Zusammenarbeit mit guten Entwicklern detailliert er entsprechende Entscheidungen. Für obiges Datenbankreportszenario wird der Architekt z. B. entscheiden, den Report vorgeneriert in einer zentralen Datenbank abzulegen, um die maximalen 2 Sekunden einhalten zu können. Messergebnisse von Durchstichen und Prototypen liefern in kritischen Fällen zusätzliche Sicherheit und werden vom Architekten auch dokumentiert. Da jedoch weder Szenarien noch Rahmenbedingungen in einer frühen Phase vollständig sind, ist der Architekt gezwungen, Annahmen zu treffen. Bei unserem Report nimmt der Architekt etwa an, dass die Aktualität des Reports keine allzu große Rolle spielt. Die Dokumentation solcher Annahmen bei der jeweiligen Entscheidung ist essenziell. Insgesamt ergibt sich so eine langfristige Nachvollziehbarkeit von kritischen Entscheidungen, die auch das Verständnis der Architektur erhöht und langfristig die Qualität der Software steigert. In welcher Form die Entscheidung selbst dokumentiert wird, ist dann eher zweitrangig. Textuelle Beschreibungen sind oft ausreichend, manchmal sind auch Architekturmodelle in grafischer Form sinnvoller und verständlicher. Verteilungsdiagramme der UML erweisen sich beispielsweise als hilfreich, wenn redundante Hardware oder Datenbank-Backups geplant werden, um Verfügbarkeitsszenarien umzusetzen.

Bewertungsworkshop

Der Austausch mit anderen Stakeholdern stellt eine zentrale Aufgabe des Architekten dar. Nur auf diese Weise können Konzepte mit der Realität konfrontiert werden, bevor es zu teuer wird, sie zu ändern. Nur so kann das vorhandene Know-how geteilt und multipliziert werden. Nur so lassen sich getroffene Annahmen schnell überprüfen. Die Architekturbewertung erreicht dieses Ziel durch das Abhalten von Bewertungsworkshops. Wie im Zentrum von Abbildung 1 zu sehen, werden die geschärften Anforderungen in diesen Workshops den detaillierten Entscheidungen des Architekten gegenübergestellt. Neben dem Architekten, den Entwicklern und Anforderern nehmen auch Kunden teil. Nur sie können fachliche Fragen, Konflikte oder Kompromisse effektiv klären. Mehr als einmal kommt es vor, dass Kunden technische Diskussionen zwischen Architekt und Entwicklern abbrechen, um kundzutun, dass eine bestimmte Anforderung nicht so unumstößlich ist, wie angenommen, und der Punkt somit hinfällig ist. Auch unausgesprochene Anforderungen werden so leichter aufgedeckt. Um die Sichtweisen auf das System zu vervollständigen, werden meist auch Wartungspersonal oder Integrationsverantwortliche miteinbezogen.

Der Ablauf eines Bewertungsworkshops ist immer ähnlich. Um alle Teilnehmer ins Boot zu holen, ist es in den ersten Workshops eines Projekts sinnvoll, die Ziele aus Sicht des Kunden zu präsentieren und die grundlegende Architektur vorzustellen. Bei der Architekturvorstellung sind vor allem die grobe Gliederung des Systems, die verwendeten Technologien und die anzubindenden Fremdsysteme interessant, auch hierfür sind u. a. Verteilungsdiagramme geeignet. Der eigentliche Kern des Workshops beginnt aber mit der Priorisierung der Szenarien durch alle Anwesenden. Ein spezieller Priorisierungsmechanismus sorgt für eine eindeutige Reihenfolge, in der die Szenarien anschließend durchgearbeitet werden. Zu jedem Szenario zeigt der Architekt die geplante Umsetzung in entsprechenden Entscheidungen und Maßnahmen. Wie intensiv die anschließende Betrachtung der einzelnen Entscheidungen ausfällt, hängt maßgeblich davon ab, wie leicht sie später noch geändert werden können. Die individuelle Bewertung einer Entscheidung beinhaltet die fachliche und technische Beleuchtung, inklusive der Identifizierung von etwaigen Kompromissen, Risiken oder Nicht-Risiken (Kasten: „Ergebnisse einer Bewertung“).

Ergebnisse einer Bewertung
– Kompromisse (Trade-off Points): Eine Eigenschaft, die mehrere Qualitätsmerkmale oder Szenarien widersprüchlich beeinflusst
– Nicht-Risiken: Gute, oft implizit gegebene Entscheidungen oder auch abgesicherte Erkenntnisse (Erfahrung, Messergebnisse)
– Risiken: Entscheidungen, die noch nicht getroffen wurden oder deren Konsequenzen nicht klar sind (fehlende Anforderungen, fehlendes Know-how)

Ein guter Bewertungsworkshop lässt sich daran erkennen, dass die Beteiligten das Meeting mit einer ganzen Reihe an Aufgaben verlassen. Kompromisse und erkannte Nicht-Risiken interessieren vorrangig den Architekten. Vor allem die identifizierten Risiken bilden aber wertvolles Feedback für Architekt und Kunde. Hat unser Beispielarchitekt im Workshop etwa herausgefunden, dass die abgefragten Datenbankreports nicht älter als 2 Minuten sein dürfen, nimmt er ein Risiko mit. Nun muss er untersuchen, ob sich das mit seinem Vorgenerierungsansatz vereinbaren lässt, oder ob eine teilweise Livegenerierung möglich ist. Auf Kundenseite muss untersucht werden, welche Daten unbedingt aktuell sein müssen und wie wichtig diese Anforderung im Vergleich zur Performanzfrage ist. Wichtig ist, dass man nur durch das Zusammenspiel der beiden Seiten größere Probleme effektiv lösen kann. Fehlt die Kundenseite, werden Probleme vielleicht an der falschen Stelle adressiert. Das führt zu komplizierten Lösungen, längeren Entwicklungszeiten, schlechterer Wartbarkeit und letztendlich zu Unverständnis beim Kunden – „Warum haben sie dafür so lange gebraucht, es wäre doch …“.

[ header = Seite 5: Bestehende Architekturen bewerten ]
Wann und wie oft?

Bewertungsworkshops werden in regelmäßigen Abständen abgehalten, um den Architekten kontinuierlich zu unterstützen und Architektur langfristig positiv zu beeinflussen. Bei iterativem Vorgehen bietet es sich an, in jeder Iteration eine feste Timebox für Workshops vorzusehen. Dabei wird die Dauer der Bewertungsworkshops fixiert und nicht erzielte Ergebnisse werden in den nächsten Workshop verschoben. Durch diese Technik werden lange und ineffektive Diskussionen verhindert und Aufwände fokussiert. Die Dauer der geplanten Timebox hängt von der Iterationslänge ab, nur bei sehr architekturrisikoreichen Projekten oder in frühen Projektphasen, sind Längen über einen Tag sinnvoll. Je nach Bedarf kann dieser Wert natürlich angepasst werden.

Bestehende Architekturen bewerten

Der Prozess der Architekturbewertung, wie er bis hier hin beschrieben wurde, richtet das Augenmerk auf neu entwickelte Architekturen. Bei bestehenden Architekturen ändert sich am grundsätzlichen Vorgehen nicht sonderlich viel, Ansätze der Architektur und die getroffenen Entscheidungen müssen aber herausgearbeitet werden. Der sauberste Weg hierfür ist, zunächst die vorhandenen Anforderungen des Projekts auf einen guten und konsistenten Stand zu bringen. Auch die nachträgliche Entwicklung von Szenarien kann überlegenswert sein. Auf dieser Basis werden nun, ähnlich dem bereits beschriebenen Vergehen, mehrere Bewertungen durchgeführt. Es wird überprüft, welche Lösung(en) eine Anforderung umsetzen und ob die getroffenen Entscheidungen noch in vertretbarem Aufwand änderbar sind. Besonders komplizierte Bereiche oder solche, die nicht aus den Anforderungen zu rechtfertigen sind, werden dann einer genaueren Prüfung unterzogen. Das geschieht wieder in Bewertungsworkshops. Ergebnis sind vollständigere und geprüfte Anforderungen sowie eine klarere, zielgerichtete und konsistente Architektur. Auf dieser Basis sind Weiterentwicklungen oder auch Wartungsaufgaben leichter zu erfüllen und qualitativ höherwertig möglich. In den allermeisten Fällen sind jedoch Projekte, die von Anfang an auf ein Bewertungsverfahren setzen, im Vorteil, sowohl beim Gesamtaufwand als auch bei der letztendlich erreichten Qualität.

[ header = Seite 6: Fazit ]

Fazit

Die Architekturbewertung ist eine wissenschaftlich fundierte und in der Praxis erprobte Methode, um Architekturen zu entwickeln, die sich näher an den tatsächlichen Anforderungen orientieren und besser umsetzbar sind. Der gezeigte Prozess unterstützt viele agile Prinzipien, wie direkte Kundenzusammenarbeit, Feedback, Kommunikation oder einfache und möglichst späte Entscheidungen im Architekturumfeld. Diese Prinzipien werden dabei auch Projekten zugänglich, die sonst nicht effektiv agil arbeiten könnten, weil sie zu groß sind, deren Kunden nicht jederzeit verfügbar sind oder deren Entwickler und Designer sich nicht alle auf ähnlichem Level befinden. Durch die Öffnung der Architektur sorgt man für Transparenz von Entscheidungen, verhindert effektiv Missverständnisse und ermöglicht breite Kenntnis der Architekturkonzepte. Wiederholte Workshops mit fixierten Dauern sichern dabei Qualität und Effizienz. Und, wie entscheiden Sie?

Stefan Toth arbeitet als Softwarearchitekt, Berater und Trainer bei oose. in Hamburg. Seine Schwerpunkte liegen in der Konzeption und dem Entwurf mittlerer bis großer Softwarelösungen, der modellgetriebenen Softwareentwicklung sowie der Verbindung dieser Themen zu agilen Vorgehen. Er hat diesen Sommer geheiratet.
Geschrieben von
Stefan Toth
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.