Auf meinem Weg zum Softwarearchitekten hatte ich einige große Aha-Momente, die mich schlagartig zu einem besseren Architekten gemacht haben. Dabei ging es jedes Mal um das Erlernen bzw. das besser Verständnis einer neuen Arbeitsmethode. Diese Methoden sind die Modellierung, das strukturierte Treffen von Entscheidungen und der richtige Umgang mit Qualitätsanforderungen.

In diesem Artikel beschreibe ich, wie ich diese Methoden erlernt habe, warum ich denke, dass sie mich als Architekten besser gemacht haben und wie auch Sie von diesen Methoden profitieren.

Die Methoden

Software modellieren

Relativ früh in meiner Tätigkeit als Architekt war ich mit der Art, wie ich Architektur kommuniziert habe, nicht zufrieden. Mir fehlte es an geeignete Mittel, um meine architektonischen Überlegungen effizient und methodisch an andere Personen weiterzugeben. Meistens habe ich meine Architekturüberlegungen mit Striche und Kästchen am Whiteboard aufgezeichnet und dann habe ich versucht, das Ganze mehr schlecht als recht in einem Zeichenprogramm nachzuzeichnen.

Zu diesen Zeitpunkt war ich weder mit meinem Tooling noch mit den Diagrammen an sich zufrieden. Meine Ausbildung habe ich in der Elektronik gemacht. Von dort war ich es gewohnt, Blockdiagramme einzusetzen und habe diese auch intensiv für meine Architekturvisualisierung verwendet. Blockdiagramme werden zwar durchaus im Softwareentwurf eingesetzt, aber es ich war trotzdem mit den syntaktischen Möglichkeiten nicht zufrieden. Wie ich später verstanden habe, habe ich in diesen Diagrammen auch Verteilungs- und Bausteinsicht vermischt. Zu allen Überfluss ist ab und an auch eine Verhaltenssicht mit reingemischt worden.

Getrieben von diesen zwei Faktoren (schlechtes Tooling und schlechte Diagramme) bin ich auf die Suche nach Lösungen gegangen. Nach einiger Recherche über verschiedene Alternativen bin ich bei der UML gelandet. Grundsätzlich war die UML nicht neu für mich, aber so richtig warm bin ich damit nie geworden. Auch bei diesen Versuch, die UML zu lernen (bzw. den richtigen Einsatz zu lernen), war ich weniger erfolgreich.

Also habe ich meine Aufmerksamkeit Richtung Tooling gerichtet. Hier stellte sich schnell raus: Es gibt ein paar gute Werkzeuge, aber die verlangen, dass man entsprechende Modellierungssprachen einsetzt. Ich musste also wohl doch dieses UML lernen. 🤷‍♂️

Das Tool, das mir am besten gefallen hat, war Enterprise Architect von Sparx Systems. Passenderweise hat Sparx Systems auch Schulungen zu Enterprise Architect und UML angeboten. Also habe ich zwei Kurse gebucht, mit dem Ziel, das Werkzeug zu erlernen und vielleicht die UML besser einsetzten zu können.

Was ich aber in diesen Schulungen tatsächlich gelernt habe, war die Methode der Modellierung. Modellierung meint hier den Prozess der Erstellung eine Abstraktion des Systems mittels einer Modellierungssprache. Diese Modellierungssprache beinhaltet Syntaxelemente und Regeln, wie diese Elemente interagieren können. Klassischerweise kommt bei Softwaresystem die UML zum Einsatz, wobei die Modellierung oft in grafischer Form durch Diagramme geschieht. Dies ist aber keine reine visuelle Zeichnung, sondern die erstellten Elemente können wiederverwendet werden und müssen sich an die Regeln der Modellierungssprache halten. Dadurch können konsistente Darstellungen des Systems erreicht werden.

Ein wichtiger Punkt ist hierbei der Prozess an sich. Wenn man ein System modelliert, ist man fast schon gezwungen, das System methodisch und strukturiert vom großen Ganzen in die einzelnen Teile zu zerlegen. So erhält man Komponenten und saubere Schnittstellen.

Dieser Ansatz half mir auch die Struktursicht, Verhaltenssicht und Verteilungssicht zu trennen. Jede Sicht beschreibt das System aus einem bestimmten Blickwinkel. Aspekte, die nicht zu der jeweiligen Sicht gehören, werden weggelassen. Somit wird die Verständlichkeit der Sichten gefördert, auf das Wesentliche fokussiert und keine Aspekte vermischt.

Modellierung ist nach wie vor für mich die stärkste Arbeitsmethode, wenn ich eine Architektur entwerfe.

Methodisches treffen von Entscheidungen

In der Softwareentwicklung müssen wir ständig Entscheidungen treffen. Das fängt bei Kleinigkeiten wie der Benennung einer Variable oder Methode an und geht zu kritischen Entscheidungen wie der Wahl von Architekturstielen. Vieler dieser Entscheidungen sind wir uns gar nicht richtig bewusst. Wir machen sie einfach nebenläufig in unserer Arbeit mit. Wenn wir dann doch bewusst Entscheidungen treffen, geschieht dies oft aus der Intuition heraus, oder weil wir uns denken „Naja, wenn wir XYZ einsetzten, wird dadurch ja die Skalierbarkeit der Software steigen“. Was fehlt, ist aber ein strukturiertes Erarbeiten von Entscheidungen.

So ging es mir auch lange. Ich habe zwar versucht, gute Entscheidungen zu treffen, aber für mich war es ein langer Weg des Ausprobierens, bis ich einen Prozess gefunden habe, den ich auf alle Entscheidungen anwenden kann und der mich methodisch zu einem Ergebnis bringt.

Eine erste Erkenntnis war, dass es keine „guten“ Entscheidungen per se gibt. Die meisten Architekturentscheidungen sind immer ein Kompromiss zwischen verschiedenen Eigenschaften (meistens Qualitätseigenschaften des Systems). Eine Entscheidung kann beispielsweise gut für die Sicherheit einer Software, aber schlecht für ihre Benutzbarkeit sein. Um hier also eine „gute“ Entscheidung treffen zu können, müssen wir bewerten, ob uns Sicherheit oder Benutzbarkeit für die jeweilige Entscheidung wichtiger ist.

Meine Methode zur Entscheidungsfindung besteht im wesentlichen aus vier Schritten:

1. Formulierung der Frage, für die ich Entscheidung treffen möchte.
2. Ermittlung aller relevanten Einflussfaktoren wie Randbedingungen und Annahmen.
3. Finden und Bewerten von Alternativen.
4. Entscheidung treffen.

Ob eine Entscheidung die gewünschten Ergebnisse bringt, lässt sich oft erst im Nachhinein bewerten. Dementsprechend ist ein Feedback zu Architekturentscheidungen außerordentlich wichtig. Schließlich wollen wir ja kein Elfenbeinturmarchitekt werden, der seine Entscheidungen hoch oben im Elfenbeinturm abseits der Realität trifft. Als Architekt sollten wir uns nicht darauf verlassen, dass das Feedback unserer Entscheidungen uns auch erreichen wird. Stattdessen sollten wir Feedback aktiv einholen! Dazu ist es wichtig, zuerst die Personen zu identifizieren, von denen wir Feedback können. Je nach Entscheidung können dies Entwickler genauso wie Product Owner, Fachexperten oder andere sein.

Gerade bei großen Entscheidungen ist es empfehlenswert, eine nachträgliche Analyse der Entscheidung durchzuführen. In dieser Analyse können Fragen geklärt werden, wie beispielsweise:

• Wurden die Ziele mit der gewählten Lösungsalternative tatsächlich erreicht?
• Wurden Lösungsalternativen übersehen?
• Gab es Konsequenzen, die beim Treffen der Entscheidung nicht beachtet wurde?
• Sind die getroffenen Annahmen eingetreten? Wenn nicht, wie können zukünftig bessere Annahmen getroffen werden?

Durch diese Analyse kann man Erkenntnisse gewinnen, die uns helfen, zukünftig bessere Entscheidungen zu treffen. Es ist hierbei hilfreich, auf die Erkenntnisse der Analyse zurückgreifen zu können. Dokumentieren Sie deshalb alle Antworten der nachträglichen Analyse in schriftlicher Form. Schreiben Sie keine Prosa. Eine knappe Beschreibung der Antworten ist ausreichend.

In vielen Fällen ist es hilfreich, andere Personen bei der Entscheidungsfindung mit einzubeziehen. Eine Kollaboration kann in verschiedenen Bereichen helfen. So können unterschiedliche Personen Lösungsoptionen einbringen, an die Sie alleine vielleicht nicht gedacht hätten. Auch die Bewertung der Lösungsoptionen werden durch verschiedene Blickwinkel besser. Und schließlich haben Entscheidungen Auswirkungen auf verschiedene Stakeholder. Ein frühes Einbeziehen erhöht typischerweise die Akzeptanz der Entscheidung.

Qualitätsanforderungen als Treiber für Architekturentscheidungen

Die letzte Arbeitsmethode bezieht sich auf die Umsetzung von Qualitätsanforderungen.

Wenn man sich etwas mir Architektur beschäftigt, erkennt man schnell, dass Qualitätsanforderungen oftmals einen starken Einfluss auf den Architekturentwurf haben. Die meisten Architekturansätze werden gewählt, um eben jene Qualitätsanforderungen zu erfüllen. Zumindest sollte das der Fall sein. Ich weiß, dass in der Praxis oft eine Entscheidung für einen Architekturansatz getroffen wird, weil es gerade Trend oder „Best Practice“ ist. Auch ich bin diesen Irrweg in der Praxis schon oft genug gefolgt. 🤷‍♂️

Für mich war es eine ganz entscheidende Erkenntnis, dass Architekturentscheidungen in der Regel durch Qualitätsanforderungen motiviert sind. Durch die Anwendung dieser Methode vermeidet man es, unnötige Komplexität durch Architekturmuster und Lösungsansätze zu erhalten und das System bleibt möglichst schlank und einfach.

Um den Zusammenhang zwischen Architekturentscheidungen und Qualitätsattribute besser zu verstehen, betrachten wir die nachfolgenden Beispiele:

• Microservices können Modularisierung und Skalierbarkeit eines Systems unterstützen.
• Durch die Anwendung der SOLID-Prinzipien kann die Wartbarkeit, Verständlichkeit und Flexibilität verbessert werden.
• Die Umsetzung von loser Koppelung hilft, skalierbare und interoperable Komponenten zu erzeugen.
• Mit Containern kann die Deploybarkeit positiv beeinflusst werden.
• Der Einsatz von Redis kann das Zeitverhalten für Datenabfragen positiv beeinflussen.

Doch wie kommen wir am besten zu den Qualitätsanforderungen? Zuallererst sollten die Qualitätsanforderungen von allen Stakeholder eingeholt werden. Stakeholder sind nicht nur die Benutzer, die Kunden oder ein Produkt Owner, sondern auch Entwickler, Tester und andere Mitglieder des Entwicklungsteams. Diese letzte Gruppe wird oft übersehen, aber von ihnen können sehr wohl Qualitätsanforderungen wie Testbarkeit, Deploybarkeit oder Lesbarkeit des Codes kommen.

Die Qualitätsanforderungen sollten hier nicht zu umfangreich sein. Die bekannte ISO 25010 führt 40 Qualitätskriterien an. Wenn man hier alle hinreichen erfüllen möchte, ist das de facto ein Ding der Unmöglichkeit. Ich empfehle gerne, die Qualitätskriterien im Idealfall auf 3 bis 5 zu beschränken, jedoch nicht mehr als 10 zuzulassen. Diese Qualitätskriterien sollten auch in eine eindeutige Prioritätsreihenfolge gebracht werden. Dies hilft auch ungemein beim Treffen der Architekturentscheidungen, da hier in der Regel Kompromisse zwischen den Qualitätskriterien eingegangen werden muss.

Qualitätsanforderungen können über Qualitätsszenarien präzisiert werden. Dies sind konkrete und messbare Aussagen zur Qualität. Qualitätsszenarien können über einen Qualitätsbaum im Zusammenhang mit den Qualitätskriterien gebracht werden. (Es gibt hier auch alternative Darstellungsformen wie eine Mindmap.)

Bei der Angabe eines Qualitätsszenarios wird ein Stimuli beschreiben, der eine Reaktion erzeugt. Diese Reaktion muss messbar sein.

Ein Beispiel für ein Qualitätsszenario könnte lauten: „Beim Klicken auf den Export-Button muss innerhalb von 3 Sekunden eine CSV-Datei erzeugt werden.“

Oder: „Wenn ein neues Release erzeugt wird, muss dieses in einem Standardcontainerformat zur Verteilung bereitgestellt werden.“.

Das Messen der Stimuli ist nicht immer trivial und sollte möglichst exakt definiert werden, damit auch eine sinnvolle Messung vorgenommen werden kann. Wenn man beispielsweise Lastverhalten messen möchte, sollte man als Messgröße ein Quantil der Antwortzeit (z. B. 95%-Quantil oder 99%-Quantil) sowie das Lastszenario angeben.

Beispiel: „Der Loginservice muss bei 1.000 Anfragen pro Sekunde in 95% der Fälle innerhalb von 500ms eine Loginanfrage bearbeiten können.“

Übrigens würde ich auch empfehlen, genau zu spezifizieren, welche Zeit gemessen wird. Wird z. B. die Ladezeit einer Webseite gemessen, so setzt sich diese aus der Zeit für die Anfrage der Bearbeitungszeit des Servers und der Antwortzeit zusammen. Anfrage- und Antwortzeit sind aber unter anderem vom Client und von der Netzwerkverbindung abhängig.

Stakeholder-Management

Das Einbeziehen von Stakeholder ist insbesondere für das Treffen von Entscheidungen und die Umsetzung von Qualitätsanforderungen von Bedeutung. Stakeholder sind alle Personen oder Personengruppen, die ein Interesse an dem Projekt haben oder von dessen Ergebnissen betroffen sind. Dazu gehören unter anderem Kunden, Benutzer, Entwickler, Projektmanager, Produkt Owner und die Geschäftsführung. Der erste Schritt im Stakeholder-Management besteht darin, alle relevanten Stakeholder zu identifizieren und ihre jeweiligen Interessen, Erwartungen und Einflussmöglichkeiten zu verstehen. Dies ermöglicht es dem Softwarearchitekten, deren Bedürfnisse und Anforderungen in die Architekturentscheidungen oder Qualitätsanforderungen einzubeziehen und so die Akzeptanz und Zufriedenheit zu maximieren.

Eine zentrale Methode im Stakeholder-Management ist die regelmäßige und transparente Kommunikation. Dies umfasst sowohl formelle Meetings und Präsentationen als auch informelle Gespräche und Updates. Durch einen kontinuierlichen Austausch können Missverständnisse vermieden, frühzeitig Feedback eingeholt und das Vertrauen der Stakeholder in das Projekt und in den Architekten gestärkt werden. Ein gutes Kommunikationsmanagement stellt sicher, dass alle Beteiligten stets über den aktuellen Stand des Projekts informiert sind und etwaige Bedenken oder Änderungswünsche rechtzeitig geäußert werden können.

Ein weiterer wichtiger Aspekt ist das Stakeholder-Engagement. Dabei geht es darum, die Stakeholder aktiv in den Entscheidungsprozess einzubeziehen und ihnen das Gefühl zu geben, dass ihre Meinung geschätzt wird und sie Einfluss auf die Entscheidungen haben. Ein solches Engagement fördert nicht nur die Zufriedenheit der Stakeholder, sondern kann auch wertvolle Einblicke und Ideen für die Weiterentwicklung der Softwarearchitektur liefern.

Werkzeuge

Für alle genannten Methoden kann man entsprechende Werkzeuge als Unterstützung einsetzen. Es gibt Tools für Softwaremodellierung, die Dokumentation von Entscheidungen und die Anforderungsverwaltung. Über deren Funktionen und Möglichkeiten habe ich bereits einen eigenen Artikel geschrieben. Dort stelle ich auch die konkrete Software vor, die ich in meiner Arbeit einsetze.

Auf gehts in die Praxis

Ich hoffe, dass meine häufig unterschätzten Methoden zumindest Anreiz noch Nachdenken schaffen konnten. Die beschriebenen Methoden sind natürlich weder ein Hexenwerk noch eine neue Erkenntnis in der Softwarearchitektur. Diese Methoden in der Praxis umzusetzen, kann aber durchaus herausfordernd sein.

Damit die Umsetzung in der Praxis gelingt, helfe ich Ihnen gerne mit Rat und Tat! Nehmen Sie noch heute Kontakt mit mir aufnehmen und wir besprechen, wie wir die genannten Arbeitsmethoden in Ihren Alltag integrieren können.