Versetze dich in die folgende Situation: Du bist kein erfahrener Software-Architekt, benötigst aber kurzfristig Hilfestellungen zum Thema Software-Architektur in deinem Projekt. Wie kannst du vorgehen? Wie kann dir geholfen werden? Welcher Architekturstil ist am besten geeignet, um dein Problem zu lösen? Diese und weitere Fragen beantworten wir im folgenden Blog Post. Hierbei verfolgen wir das Ziel, strukturiert und iterativ bei der Entscheidung für einen Softwarearchitekturstil zu helfen.
Eine Entscheidung zu treffen, ist kompliziert
Sich für oder gegen verschiedene Architekturstile zu entscheiden, ist kompliziert. Wenn etwa in einem Projekt mit sehr dynamischen Anforderungen Änderungen an diesem – aus welchen Gründen auch immer – längere Zeit oder komplett ignoriert werden, dann ist es ziemlich wahrscheinlich, dass die entwickelte Softwarearchitektur nicht zu den aktuellen Anforderungen passt. Ähnlich dynamisch können auch die Anzahl und Skillsets der verfügbaren Entwickler im Projekt sein. Wenn mitten im Projekt einige Senior-Devs das Projekt verlassen, dann kann das zu großen Schwierigkeiten führen.
Derweil sind dynamische Anforderungen und Fluktationen innerhalb des Dev-Teams nur zwei von vielen Möglichkeiten, weshalb man als Softwarearchitekt die getroffene Architekturstilentscheidung regelmäßig hinterfragen sollte. Auch argumentieren Mark Richards, Neal Ford und Jørgen W. Lang in ihrem Buch „Handbuch moderner Softwarearchitektur: Architekturstile, Patterns und Best Practices“ in der aktuellen Ausgabe von 2020, dass das „Warum“ wichtiger sei als das „Wie“. Die Begründung für eine Architekturentscheidung ist also wichtiger also die Entscheidung an sich. Natürlich fallen Entscheidungen am Anfang eines Projekts anders aus als gegen Ende, weil man zu Beginn eines Projekts viel weniger weiß als zum Projektende. Man sollte aber trotzdem zu jedem Zeitpunkt einen sinnvollen Plan haben, in welche Richtung man die Softwarearchitektur entwickeln möchte.
Anlehnend an den NoSQL Decision Tree haben wir deshalb eine Entscheidungshilfe gesucht, mit deren Hilfe wir einen Architekturstil schnell und fundiert auswählen können, ohne dabei wichtige Punkte zu vergessen. Dazu haben wir uns überlegt, wie wir ein möglichst vollständiges Bild von verschiedenen Klassen an Anforderungen bekommen und abbilden können, um zu jedem Zeitpunkt im Projekt gut dokumentiert und begründet eine Architekturstilentscheidung treffen und danach die Entscheidung sinnvoll begründen zu können.
Unser Ergebnis ist der Architekturentscheidungstrichter.
Warum ein weiteres Vorgehensmodell für Architekturstile?
In der Literatur zu Softwarearchitektur gibt es bereits unzählige und beliebig komplexe Vorgehensmodelle. Doch genau hier liegt das Problem: Der nötige Zeitinvest, um ein ausreichendes Verständnis für diese Methodiken zu erreichen, ist hoch.
Die zwei wohl bekanntesten Schulen für Softwarearchitektur sind das TOGAF-Framework und ISAQB. Sie sind jeweils nicht nur eine eigene Methodik, sondern eine Sammlung aus einer Vielzahl von Vorgehensweisen. Wer ein Zertifikat in einer dieser beiden Schulen erworben hat, kennt den hohen Zeitaufwand, der hierfür nötig ist.
Aus unserer Sicht ist der Zeitaufwand gerechtfertigt, wenn man eine Karriere als Softwarearchitekt anstrebt und sich dafür fundiertes und breites Know-How aneignen möchte. Wir empfehlen für Softwarepraktiker insbesondere die ISAQB Zertifizierung. Denen von euch allerdings, die akut in einem Projekt eine Hilfestellung brauchen, um eine Architekturentscheidung zu treffen, bleibt meist keine Zeit für eine umfangreiche Schulung.
Wir als Autoren dieses Artikels waren in den letzten Monaten in genau dieser Situation und suchten nach einer Hilfestellung, die mit begrenztem Zeitinvest verständlich und gleichzeitig ausreichend vollständig ist. Leider vergeblich. So haben wir uns selbstständig einen Werkzeugkasten gebaut, der uns ohne aufwändige Zertifizierung bei Architektur-Themen tatkräftig geholfen hat. Und genau den möchten wir mit euch teilen.
Update: Wir haben in diesem Zuge an dem Thema Softwarearchitektur Freude gefunden. Manche von uns haben später selbst u. a. die ISAQB Zertifizierung durchgeführt. Vielleicht fühlt ihr euch dazu auch ermutigt, wenn ihr dazu weiterlest!
Wie funktioniert der Architekturentscheidungstrichter?
Zur Erstellung des Vorgehensmodells haben wir aus unseren Erfahrungen die wesentlichen Fragestellungen geclustert, die für eine Architekturentscheidung betrachtet werden sollten. Wesentlich dafür war u. a. die DIN ISO/IEC 25010 über nicht-funktionale Anforderungen, denn diese Qualitätskriterien sind für den Erfolg einer guten Softwarearchitektur sehr wichtig.
Unser Modell umfasst vier Cluster an Anforderungen, die vom Abstrakten bis ins Detail alles Wesentliche betrachten:
- regulatorische,
- organisatorische,
- produktbezogene und
- technische Anforderungen.
Jeder Cluster besteht aus einer Reihe an Fragen, die der Reihe nach beantwortet werden. Diese Antworten sind der Input für den Entscheidungstrichter:
Anhand der Antwort werden im Trichter alle möglichen Architekturstile dahingehend bewertet, ob sie für das vorliegende Projekt mehr oder weniger geeignet sind. Im Ergebnis fällt unten am Ausgang des Trichters dann der eine Architekturstil heraus, der am besten passt. Das kann auch eine Mischung aus zwei Stilen sein, wie wir später noch sehen werden.
In der Praxis sehen wir, dass sich Anforderungen im Projektverlauf noch ändern. Wir haben das Modell deswegen als zyklisches Modell entworfen: Es erlaubt also Iterationen. Teilschritte, die sich nicht geändert haben, können dabei einfach auf dem alten Stand belassen werden, ohne dass man Informationen vergisst.
Ein weiterer Vorteil: Die Beantwortung der Fragen der vier Cluster unterstützt die Dokumentation und Begründung von Entscheidungen. So lässt sich später im Projektverlauf jederzeit nachvollziehen, warum (!) eine bestimmte Entscheidung getroffen wurde. Die sich daraus ergebenden Vorteile kann man nur unterschätzen:
- So erhält man nach der Analyse der regulatorischen Anforderungen bereits eine fundierte Erkenntnis darüber, ob ein Projekt rein gesetzlich umsetzbar ist oder ob es bspw. gegen den Datenschutz verstoßen würde und so das Produkt von vornherein nicht gebaut werden darf.
- Ein Nebenprodukt des Durcharbeitens der organisatorischen Anforderungen ist die Stakeholderanalyse, welche im gesamten Projekt sehr nützlich ist. Darüber hinaus erhält man hier bereits eine grobe Preisindikation auf Basis der Anforderungen, welche im weiteren Verlauf auch wichtig sein wird.
- Anhand der produktbezogenen Anforderungen erhält man darüber hinaus eine Endnutzeranalyse und eine grobe Skizze darüber, welche Kontexte und Use Cases bedient werden müssen. Das zu lösende Problem wird schon mal auf Basis der Anforderungen fachlich zerlegt und Anforderungen an die Qualität werden geschärft.
- Zuletzt bekommt man durch die Bearbeitung der technischen Anforderungen bereits eine High-Level-Sicht auf die Architektur: Einzelne Komponenten und deren Schnittstellen gliedern sich heraus, man bekommt Klarheit über die Programmiersprachen, Testing-Konzepte, das Deployment, etc.
Im folgenden Abschnitt gehen wir nun auf die einzelnen Cluster an Anforderungen im Detail ein.
Die vier Cluster des IT-Architekturentscheidungstrichters
Regulatorische Anforderungen/externe Rahmenbedingungen
Ohne regulatorische Anforderungen zu beachten, ist es sinnlos, Software zu bauen. Falls diese sich ändern oder die geplante Software direkt vor ihrer Entwicklung verboten ist, sollte sie nicht implementiert werden.
Regulatorische Anforderungen umfassen für das jeweilige Projekt relevante externe Rahmenbedingungen wie bspw. die Gesetzgebung im Rahmen von etwa Finanz-, Arbeits- und Datenschutzrecht.
Organisatorische Anforderungen/interne Rahmenbedingungen
Organisatorische Anforderungen betreffen stattdessen die internen Rahmenbedingungen. Diese haben wir folgendermaßen eingeteilt:
- Zeitliches Budget und Kosten. Wie viel Zeit und Geld habe ich zur Verfügung?
- Verträge und Partnerschaften. Sind zum Beispiel durch Partner gewisse Standards vorgegeben? Welche SLAs müssen beachtet werden?
- Prozesse. Gibt es beispielsweise Vorgaben oder Best Practices im Unternehmen wie Scrum?
- Personalressourcen und Arbeitskultur. Welches Skillset haben meine Entwickler, welche Stakeholder gibt es etc.?
Abhängig vom Kunden schlagen wir vor, die organisatorischen Anforderungen in angepasster Reihenfolge abzuarbeiten. Es gibt Projekte, in denen höherer Kostendruck bei Entwicklern mit sehr hohen Skills herscht, aber auch Projekte, in denen die Situation genau umgekehrt ist. Je nach Ausgangslage gilt es, die unterschiedlichen Anforderungen unterschiedlich zu priorisieren.
Produktbezogene Anforderungen
Wir unterteilen produktbezogene Anforderungen in zwei Unterpunkte: funktionale und nicht-funktionale Anforderungen. Wie aus der Literatur bekannt, umfassen dabei funktionale Anforderungen die Anforderungen, welche beschreiben, was die Software am Ende des Tages leisten soll.
Nicht-Funktionale Anforderungen umfassen hingegen generelle Faktoren, die im Entwicklungsprozess beachtet werden müssen. Aufgrund der großen Menge an nicht-funktionalen Anforderungen haben wir diese nochmal in drei Unterpunkte unterteilt: Sicherheit, Flexibilität und Einfachheit, welche Anforderungen wie bspw. Verfügbarkeit, Skalierbarkeit und Benutzbarkeit enthalten.
Technische Anforderungen
Technische Anforderungen sind unterteilt in:
- Technisch externe Umgebung: Beispielsweise muss hier geklärt werden, an welche Bestandssysteme die neue IT anschlussfähig sein muss und mit welcher Technologie?
- Deployment und Release: Wie ist zum Beispiel der automatisierte Deployment-Prozess gestaltet?
- Betrieb: Auf welcher Hardware soll die Software laufen und wer ist für deren Betrieb verantwortlich?
- Qualitätssicherung: Das umfasst zum Beispiel Punkte wie welcher Automatisierungsgrad und welche Testabdeckung angestrebt werden.
Nachfolgend werden diese Fragestellungen weiter detailliert:
Schwächen des Architekturentscheidungstrichters
Der vorgeschlagene Architekturentscheidungstrichter ist nur für grundlegende Architekturstilentscheidungen gedacht. Für Detailentscheidungen sollten zum Beispiel Architectural Decision Records (https://adr.github.io/) genutzt werden. Außerdem sind die genutzten Anforderungen mit Sicherheit nicht vollständig oder könnten anders klassifiziert und genutzt werden. Darüber hinaus haben wir das Modell noch nicht für ein neues Projekt „from scratch” genutzt, sondern nur anhand von zwei aktiven Projekten ge-backtestet.
Ausblick
Der Architekturentscheidungstrichter bietet eine Möglichkeit, um geordnet und zügig zu einer Architekturentscheidung zu kommen. Durch seine iterative Bauweise kann man ihn im Projektverlauf jederzeit erneut durchlaufen, die einzelnen Anforderungen abarbeiten und die getroffene Architekturstilentscheidung kritisch hinterfragen. Um seinen Nutzen noch besser zu validieren, sollte er für ein neues Projekt von Beginn an in regelmäßigen Abständen verwendet werden. Die saubere Dokumentation während der Nutzung vorausgesetzt, können somit Projektzwischenstände dokumentiert und die Architekturstilentscheidung jederzeit stichhaltig begründet werden. Und genau das ist im Bereich Softwarearchitektur essenziell. Denn es zählt nicht das „Was“, sondern das „Warum“.
