Es freut mich natürlich, dass das Thema Softwarearchitektur an Sichtbarkeit gewinnt. Doch irgendwie will mir nicht ganz schmecken, was da jetzt unter “Agile Softwarearchitektur” in Umlauf gebracht wird. In dem Topf wird schnell alles verrührt, was irgendwie im Umlauf ist: User Stories + TDD + DIP + CQRS, fertig ist die Architektursuppe. Hm… Aber darüber ein andermal mehr. Hier will ich mich auf die Architekturvision konzentrieren.
Auf Seite 27 des genannten Heftes findet sich eine Beispielarchitekturvision (ohne nähere Angabe einer Problemdomäne):
“1. Es handelt sich um eine Internetanwendung.
2. Als Programmiersprache wird Java verwendet und JavaScript für das Frontend.
3. Im Backend wird Spring als Dependency-Injection-Container verwendet.
4. Für die Persistenz wird ein relationales Datenbanksystem verwendet und Hibernate für die Anbindung an das Datenbanksystem.
5. Als View-Framework wird Spring Web MVC mit JSPs verwendet.
6. Quasar ist unser Architekturstil.”
Der Zweck dieser Architekturvision:
“In dieser sollten genau die technischen und architekturellen Eigenschaften des Produktes beschrieben sein, die sich im weiteren Entwicklungsgeschehen far nicht mehr oder nur sehr schwer ändern lassen.”
Die Architekturvision soll sich also mit nicht-funtkionalen Belangen der Aufgabenstellung befassen. Und sie soll sich auf Fixpunkte konzentrieren. Bei beidem stimme ich zu. Eine Architekturvision ist also von Natur aus auf einem hohen Abstraktionsniveau. Die Beispielvision konzentriert sich auf das Was und nicht auf das Wie. So weit so gut.
Was ist aber mit dem Warum? Das halte ich für sehr wichtig gerade bei Architekturentscheidungen. Der vorgestellte Architekturvision fehlt jede Begründung, warum die Entscheidungen so ausgefallen sind. Weder enthält sie eine Erklärung, noch enthält sie einen Kontext, aus dem eine Erklärung später abgeleitet werden könnte.
Mir ist das zuwenig. Und auch die rein textuelle Fassung finde ich wenig hilfreich. Da gibt es zwar eine verbale Verortung von Technologien, doch letztlich muss sich jeder die Topologie des Systems zusammenreimen. Missverständnisse sind da vorprogrammiert.
Auch mit dieser Aussage stimme ich nicht überein:
“Folglich hängt der konkrete Umfang der Architekturvision von den Fähigkeiten des Entwicklungsteams ab.”
Das würde ja die Architekturvision von der Selbsteinschätzung eines Teams abhängig machen. Damit wäre letztlich jedes Team grundsätzlich legitimiert, die Architekturvision dünn zu halten, weil es sich einfach für erfahren und fähig hält. “Ach, das haben wir schon so oft gemacht. Das müssen wir jetzt nicht nochmal diskutieren und aufschreiben.” Ich höre sie schon die Teammitglieder, die alles lieber tun, als über eine Architekturvision zu diskutieren und sich dann auch noch festzulegen. Das ist doch einengend; wer weiß schon, was in der Zukunft kommt? Besser man spart die Zeit und hält sich alle Optionen offen.
Nein, mit so einer relativierenden Empfehlung bin ich gar nicht zufrieden.
Das soll natürlich nicht heißen, dass man Architekturvisionsdokumentenberge erzeugt. Doch ein wenig immer gleiche Systematik kann nicht schaden. Ich verstehe schon, dass die Architekturvision keine Doktorarbeit werden soll. Natürlich soll sie zügig hergestellt werden können. Dem dient aber die Reduktion von Missverständnissen. Und das kann erreicht werden, indem Sie sich eine kleine Checkliste für Architekturvisionen zurechtlegen. Die besteht für mich aus zumindest zwei Oberpunkten:
Architekturvision I – Das Big Picture
Zuerst sollten Sie sicherstellen, dass Sie das Big Picture vollständig im Blick haben. Darin betrachten Sie das zu realisierende Softwaresystem als Ganzes in seinem Umfeld.
Fragen Sie:
1. Wer benutzt das Softaresystem? Welche Rollen arbeiten damit, welche anderen Softwaresysteme benötigen seine Dienste? Es geht darum, wer von Ihrem Softwaresystem abhängig ist.
2. Wovon ist Ihr Softwaresystem abhängig? Auf welche Ressourcen greift es zu, seien das Dateien, Datenbanken, andere Softwaresysteme, Drucker, Maschinen usw.?
Mit diesen Information erstellen Sie ein erstes System-Umwelt-Diagramm:
Damit bekommt die Architekturvision eine erste grobe Form. Sie wird visuell, wie es sich für eine anständige Vision gehört ;-) So lässt sich eine Architekturvision auch viel besser kommunizieren – am Whiteboard oder auf einer PPT-Folie.
Daran hangeln Sie sich anschließend weiter, Rolle für Rolle, Ressource für Ressource. Zu jedem Umweltelement stellen Sie Fragen wie:
a. Mit welcher Technologie findet die Interaktion statt? Das können bei Rollen z.B. sein Desktop-Client, Smartphone App, Web-Client oder auch Webservice. Bei Ressourcen kämen z.B. in Frage ORM, Webservice, ESB.
a.1. In welchem Modus werden die Interaktionstechnologien betrieben, z.B. zustandslos/zustandsbehaftet, REST/SOAP, unterbrechungsfreie Verbindung usw.
a.2. Gibt es Vorgaben für das Format der Datenrepräsentation bei Rollen und Ressourcen? Dialogskizzen und Datenformate können wichtige Hinweise für Architekturentscheidungen sein. [1]
b. Welche nicht-funktionalen Anforderungen sind an die Interaktionen gestellt? [2]
b.1. Gibt es Geschwindigkeitsanforderungen (Performance)?
b.2. Gibt es Lastanforderungen (Skalierbarkeit)?
b.3. Ist die Interaktion abzusichern (Security)?
b.4. Soll die Interaktion eine bestimmte Form haben (Usability)?
Das sind nur einige nicht-funktionale Anforderungen, die in den meisten Fällen relevant sind. Andere könnten sein Internationalisierbarkeit, Austauschbarkeit oder Ausfallsicherheit.
Lassen Sie sich nicht irritieren, wenn Sie nicht zu allen Antworten gleich genau wissen, wie Sie sie genau umsetzen sollen. Darum geht es bei der Architekturvision nicht. Sie können sich für Internationalisierung eines WP7-Clients entscheiden, ohne eine Ahnung zu haben, wie das mit Sliverlight geht; oder Sie setzen auf REST-Kommunikation mit einer Ressource, auch wenn Sie noch nicht recht wissen, mit welchem API Sie das in der Software bewerkstelligen.
Bei der Architekturvision geht es um Entscheidungen für Prinzipien und Paradigmen und Techniken zur Bewältigung von nicht-funktionalen Anforderungen. Solange Sie beurteilen können, dass eine Entscheidungsoption in dieser Hinsicht etwas bringt, wählen Sie sie.
Je mehr Erfahrung Sie damit haben, desto besser natürlich. Hier haben Teams mit Übung natürlich einen Vorteil; sie können Entscheidungen schneller und besser fällen. Explizit fällen sollten sie sie aber nichtsdestotrotz.
Dokumentieren Sie anschließend Ihre Entscheidungen im System-Umwelt-Diagramm. Hier eine Umsetzung der Architekturvision aus dem it-agile Heft (inkl. einiger Angaben, die dort explizit nicht zur Architekturvision gezählt wurden, mir jedoch wichtig erscheinen):
Ist doch nicht schwer zu malen, so ein Diagramm, oder? Aber es bringt soviel mehr als eine simple Liste wie im Heft. Es macht Annahmen expliziter, es lässt sich besser kommunizieren und überblicken und es ist auch noch ausführlicher, ohne überladen zu sein. Das Diagramm kostet keinen Mehraufwand gegenüber einer Spiegelstrichliste. Also nehmen Sie den Kommunikations- und Erinnerungsvorteil mit.
Am besten fragen Sie sich bei jeder Entscheidung immer sofort: Wo in einem Diagramm verorte ich die Entscheidung? Wo hat die Technologie, das Paradigma, die nicht-funktionale Anforderung ihren Platz? Ich behaupte, dass Ihnen damit Architekturentscheidungen auch leichter fallen. Sie werden nämlich greifbarer.
Architekturvision II – Das System
Das System-Umwelt-Diagramm bietet allerdings noch nicht für alle Entscheidungen einen passenden Ort. Oben haben Sie sicher schon ein paar Punkte aus der Architekturvision vermisst.
Deshalb sollten Sie das System-Umwelt-Diagramm noch etwas verfeinern. Zoomen Sie hinein in das Softwaresystem und bestimmen Sie in einem ersten Schritt grob die beteiligten Maschinen und/oder Betriebssystemprozesse. Was läuft wo? Diese Frage sollten Sie beantworten.
Hört sich nach Detailarbeit an, aber mir geht es nicht um Details, sondern nur eine zunächst grobe Vorstellung und ausdrückliche visuelle Formulierung von Fixpunkten. Um eine erste Idee von der Verteilung Ihres Softwaresystems auf Maschinen und Prozesse zu bekommen, sollten Sie nicht lange nachdenken müssen.
Fällt es Ihnen leicht, ist alles in Butter. Detaillieren Sie das System-Umwelt-Diagramm. Fällt es Ihnen nicht leicht, können Sie überhaupt noch keine Architekturvision haben. Ihnen fehlen dann Informationen, um zentrale, “visionäre” Entscheidungen fällen zu können.
Für das Beispiel sähe das Systemdiagramm aus meiner Sicht so aus (Kleinigkeiten habe ich dazu erfunden, um die Vision etwas spannender/vollständiger zu machen) [3]:
Auch hier sind die Annotationen wichtig. Assoziieren Sie soviele Entscheidungen wie möglich mit distinkten Bildelementen. Lassen Sie sich von den Bildelemente sogar leiten. Nehmen Sie jede Linie, jeden Kreis als Anlass sich zu fragen: Was könnten hier für nicht-funktionale Anforderungen relevant sein? Müssen wir etwas jetzt entscheiden, weil es grundlegend und später schwer zu verändern ist?
Ja, das meine ich so: Nutzen Sie die obige Liste und die Bilder als Checkliste. Arbeiten Sie die Spiegelstriche ab und gehen Sie dann nochmal durch die Grafiken und schauen Sie, ob Ihnen bei diesem zweiten Durchlauf noch etwas einfällt.
Die Grafiken sind insofern nicht nice to have, sondern Denkhilfe. Ich garantiere Ihnen, wenn Sie solche Grafiken als Visionsdokumente an der Wand Ihres Teamrooms haben, fällt es allen leichter, sich an der Architekturvision auszurichten.
Bottom line: Architekturvision ist gut und agil. Wunderbar. Doch machen Sie sich das Leben leichter mit systematischem Vorgehen anhand von Checklisten. Nutzen Sie die “Kraft des Visuellen”, um das mentale Modell von Ihrer Software auch schon in einem frühen Stadium möglichst leicht im Team homogen zu entwickeln.
Vsisionen dienen der Kohärenz. Sie sollen Kräfte bündeln und auf ein gemeinsames Ziel ausrichten. Was könnte dem besser dienen, als ein wahrhaft sichtbares Ziel, also eine Visualisierung der Architekturvision?
Spendieren Sie mir doch einen Kaffee, wenn Ihnen dieser Artikel gefallen hat…
Fußnoten
[1] Bei der Architekturvision sollte vor der Entscheidung eine Auslotung der Entscheidungsspielräume stehen.
[2] Je genauer und quantifizierter die Angaben, desto besser, z.B. bei Skalierbarkeit die Transaktionen pro Sekunde oder Benutzer pro Stunde oder bei der Performance die maximale Antwortzeit.
[3] Halten Sie sich übrigens nicht lange mit komplizierten visuellen Sprachen auf. Standardkonforme UML ist hier nicht nötig. Die visuelle Sprache, die ich hier und auch sonst benutze, besteht aus 4 Symbolen für Funktionseinheiten, Rollen, Ressourcen und Abhängigkeiten. Das war´s.