Heute geht es um den ATAM-Workshop. Wir nehmen an, wir möchten ein neues Softwareprodukt bauen oder ein bestehendes Produkt weiterentwickeln. Zwei Szenarien, die unterschiedlicher nicht sein könnten … glauben wir zumindest. Doch was haben die beiden Szenarien gemeinsam?
Nun, in beiden Szenarien gibt es etwas, das sich Softwarearchitektur nennt. Gibt es nicht schon fertige Konzepte, die man einfach übernehmen könnte? Das schon, nur leider ist es nicht ganz so einfach. Denn eine Softwarearchitektur sollte immer zu den verschiedenen Anforderungen der Business- und auch Technikseite passen. Und das können eine Menge Anforderungen sein, wie zum Beispiel: die Verfügbarkeit der Plattform, die Skalierbarkeit, die verschiedenen 3rd-Party-Systeme und so weiter; ich könnte die Liste hier jetzt ewig weiterführen.
Architektur vs. Anforderungen
Warum ist es so wichtig, dass die Architektur zu den Anforderungen der Software passt?
Die einfache Antwort: Softwarearchitektur ist das grundlegende Gerüst und die Struktur für das gesamte System. Etwas ausführlicher lässt sich das so beantworten, dass die Architektur auf verschiedene Bereiche direkt oder indirekt Einfluss nimmt.
Da wären beispielsweise funktionale und nicht-funktionale Anforderungen. Architektur muss sicherstellen, dass alle funktionalen Anforderungen (d.h. die spezifischen Funktionen und Leistungen, die das System erbringen muss) erfüllt werden können. Gleichzeitig sind nicht-funktionale Anforderungen wie Performance, Skalierbarkeit und viele andere Faktoren entscheidend für den Erfolg eines Software-Projekts.
Hinzu kommen zahlreiche weitere Faktoren, auf die Softwarearchitektur Einfluss nimmt: Effizienz, also die Vermeidung von Ressourcenverschwendung, Skalierbarkeit, Wartbarkeit, um nur einige zu nennen.
Eine passende Architektur stellt sicher, dass diese Anforderungen von Anfang an berücksichtigt und erfüllt werden können.
Nehme ich jetzt zum Beispiel eine Architektur oder eine Software von der Stange, dann muss ich mich auch an die jeweiligen Gegebenheiten des “Fertigprodukts” anpassen. Möchte ich aber eine individuelle Lösung, die meine eigenen Anforderungen so gut wie möglich abdeckt ohne das ich mich an irgendwas anpassen muss, sollte die Architektur zu meinen Anforderungen passen
ATAM to the rescue!
Was ich aber zeigen wollte, ist, dass die Komplexität der Findung einer guten Softwarearchitektur weitaus größer ist als die meisten denken. Doch was machen wir denn nun mit diesem Wissen und wie kommen wir zu einer vernünftigen Entscheidung?
Worum es geht, ist die Tatsache, dass die Komplexität der Findung einer guten Softwarearchitektur weitaus größer ist als die meisten denken. Doch was machen wir denn nun mit diesem Wissen und wie kommen wir zu einer vernünftigen Entscheidung?
Genau das möchte ich in diesem Artikel klären. Es gibt da eine Methode in Form eines Workshops, die uns genau bei dieser “Entscheidung” unterstützen kann. Es ist die sogenannte Architecture Tradeoff Analysis Method, oder kurzgesagt: der ATAM-Workshop. Was genau der Workshop ist, wie man ihn vorbereitet und durchführt, welche Ergebnisse er bringt und was man damit macht, das möchte ich in den folgenden Absätzen erklären.
Was sollte vor einem ATAM-Workshop passieren?
Zunächst einmal sollte ich darauf hinweisen, dass der ATAM-Workshop ein Teil einer ganzen Workshop Reihe ist. Der erste Workshop sollte ein Business Driver Workshop sein, um die Business-Anforderungen an die Software zu erfassen und anschließend die einzelnen ATAM-Szenarien zu bilden.
Als nächstes sollten in einem Lösungsarchitektur-Workshop die verschiedenen möglichen Lösungsarchitekturen gesammelt und am besten in ARC42-Diagrammen festgehalten werden. Der letzte Schritt vor dem ATAM-Workshop ist das Ermitteln der aktuellen Softwarearchitektur mit Hilfe des Ist-Architektur-Workshop. Auch das Ergebnis aus diesem Workshop ist in einem ARC42-Diagramm festzuhalten. Zu beachten an dieser Stelle ist vielleicht die Tatsache, dass der Ist-Architektur-Workshop natürlich nur notwendig ist, wenn es sich um eine bereits existierende Software handelt. Nun kann der eigentliche ATAM-Workshop mit den erarbeiteten Vorbereitungen starten.
Doch warum sind diese ganzen Workshops denn nun so enorm wichtig? Wir erinnern uns an die Aufzählung weiter oben: die Software soll euren Ansprüchen an Resilienz, Skalierbarkeit, Wartbarkeit und ganz vielen anderen Dingen gerecht werden. Dafür ist es unerlässlich, diese Punkte zu beleuchten und zu erarbeiten, denn nur so könnt ihr sicherstellen, dass ihr zumindest hier alles dafür notwendige unternommen habt. Denkt daran: Lieber am Anfang ein klein wenig mehr in die Planung investiert, als später ganz ganz viel in das Ummodeln des bereits umgesetzten zu investieren.
Vorbereitung des ATAM-Workshops
Einer der ersten Schritte sollte das Aufbereiten der im Business Driver Workshop erstellten NFR’s (Non Functional Requirements) sein. Diese wurden im besten Falle bereits mit Hilfe von Gherkin (Given, When, Then) und einer Fitness Function zu Szenarien umgewandelt. Falls dass noch nicht passiert ist, muss es spätestens jetzt geschehen. Denn diese Szenarien sind für den ATAM-Workshop essenziell.
In einem weiteren Schritt macht man sich Gedanken über die mögliche Agenda des Workshops. An dieser Stelle sollte man definitiv auf genügend Pausen achten, da der Workshop sehr fordernd sein kann. Des weiteren sollte man den Workshop auch nicht zu straff planen, da es wichtig ist, manche Dinge tiefgreifender zu diskutieren. An dieser Stelle ist es Zeit für einen groben Vorschlag für eine Agenda:
- Begrüßung und Einführung (ca. 30 min)
- Vorstellung der Teilnehmer und der moderierenden Personen
- Kurze Einführung in die ATAM-Methode
- Erläuterung der Ziele des Workshops
- Vorstellung und Beschreibung der aktuellen Systemarchitektur (ca. 1 h)
(nur notwendig, wenn es um eine bereits bestehende Software geht)- Präsentation der aktuellen Systemarchitektur
- Diskussion über die wichtigsten Herausforderungen
- Vorstellung möglicher Zielarchitekturen (ca. 1 h)
- Präsentation der im Lösungsarchitektur-Workshop erarbeiteten möglichen Architekturen
- Vorstellung und Anpassung der Szenarien (ca. 30 min)
- Vorstellung der Szenarien aus dem Business Driver Workshop
- Bei Unklarheiten eventuelle Anpassung der Szenarien
- Analyse von Trade-Offs (ca. 1-2 h)
- Identifizierung von Trade-Offs zwischen verschiedenen Architekturansätzen
- Abschluss (ca. 30 min)
- Zusammenfassen der Ergebnisse
- Feedbackrunde
Dieses Beispiel soll veranschaulichen, wie eine Agenda für einen ATAM-Workshop aussehen könnte – ihr solltet sie immer an eure Anforderungen und Umständen anpassen. Darüber hinaus weicht die Agenda auch ein klein wenig von der Vorlage ab, wie sie von der Carnegie Mellon University gemacht wird, weil hier bereits eigene Erfahrungen mit einfließen.
Teilnehmer im ATAM-Workshop
Aus welchem Teilnehmerkreis setzt sich der ATAM-Workshop zusammen? Nun, ein paar Antworten liefert bereits die Agenda. Wir benötigen zumindest die verantwortlichen Personen, die die Architektur-Themen vorstellen und ihr Know-how in die hoffentlich entstehenden Diskussionen einfließen lassen.
Des Weiteren werden die Personen benötigt, die das Ganze später entwickeln dürfen, da auch diese weiteren wertvollen Input vor allem von der technischen Seite einfließen lassen können. Die für das Produkt Verantwortlichen dürfen natürlich auch nicht fehlen, um die eine oder andere Business-Entscheidung zu erklären – oder aber auch direkt zu treffen.
Auch gern gesehene Gäste sind Entscheider. Da sie maßgeblich an der Erstellung der Businesstreiber und somit an den ATAM-Szenarien beteiligt waren, ist es von großem Vorteil, wenn auch diese Personengruppe anwesend sind.
Soweit zu den “wichtigsten” Teilnehmenden für diesen Workshop, doch natürlich dürfen auch alle an dem Produkt interessierten Personen teilnehmen und lauschen. Und um das Ganze für euch (da ihr das ja moderieren dürft) etwas zu vereinfachen, wäre jemand sinnvoll, der beim Moderieren unterstützt. Und falls ihr von den ganzen technischen Dingen die hier passieren werden nicht so viel Ahnung habt, ist es ebenfalls von Vorteil, jemanden mit dem passenden Know-how dabei zu haben.
Die Durchführung des ATAM-Workshops
Ich halte mich hier mal an meine oben dargestellte Agenda und werde das Ganze nun ein bisschen mit Leben füllen.
1. Begrüßung und Einführung
An dieser Stelle werden die Teilnehmer begrüßt und für den Workshop abgeholt. Hierbei ist es von zentraler Bedeutung, das Vorgehen tatsächlich zu erklären. Der ATAM-Workshop ist kein Workshop, der sehr häufig stattfindet, da er ja nur bei der Entscheidung für die richtige Architektur eingesetzt wird. Idealerweise wird diese ja nicht sehr häufig umgekrempelt …
Ebenfalls sollte die Agenda – und was in den einzelnen Punkten passiert – erläutert werden. Ganz wichtig ist der Outcome des Workshops, damit klar ist, was genau das Ziel des ganzen Hokus Pokus hier ist.
2. Vorstellung und Beschreibung der aktuellen Systemarchitektur
An dieser Stelle ist es wichtig, die Architektur vorzustellen sowie die wichtigsten Hürden, die genommen werden müssen, zu erklären. Diese Hürden können spezielle Prozessschritte oder aber auch Drittanbieter-Software sein. Es sollte zumindest jeder Aspekt beleuchtet werden und die daraus entstehenden Diskussionen kann man ruhig laufen lassen, da sie unter Umständen wertvoll für den weiteren Verlauf sein können.
Ach, und vielleicht sollte ich nochmal erwähnen, dass dieser Punkt nur notwendig ist, wenn es sich um ein bereits existierendes Produkt mit einer existierenden Architektur handelt. Wenn dem nicht so ist, könnt ihr diesen Punkt natürlich auslassen und habt etwas Zeit gewonnen.
3. Vorstellung möglicher Zielarchitekturen
Nach einer kurzen Pause geht es mit der Vorstellung der möglichen Zielarchitekturen weiter. Diese Vorschläge sind bereits in dem vorgelagerten Lösungsarchitektur-Workshop entstanden und sollen hier nun erklärt werden.
Dabei ist es wichtig, die Gründe, die zu den verschieden Architektur-Vorschlägen geführt haben, zu erläutern und Unklarheiten zu beseitigen. Falls hier bereits Diskussionen entstehen, kann man diese gerne auf später verschieben, um sie dann in Teil 5. – Analyse von Trade-Offs – zu besprechen und zu klären.
4. Vorstellung und Anpassung der Szenarien
Je nachdem wann man mit dem Workshop begonnen hat, kann man vor der Mittagspause die im Business Driver Workshop entstanden Szenarien vorstellen und bei Bedarf noch etwas anpassen. Hierbei ist es essenziell, dass alle Teilnehmenden den Inhalt und die Bedeutung der Szenarien verstanden haben und alle Unklarheiten beseitigt wurden. Ebenfalls sollte man nochmal auf die Prio und den Business Value (die ja bereits im Business Driver Workshop vergeben wurden) eingehen und diese eventuell auf die architektonischen Anforderungen abstimmen.
5. Analyse von Trade-Offs
Ab hier kommen wir zur “Magie” des Workshops und der ganze “Hokus Pokus” der Vorbereitung beginnt, Sinn zu ergeben. Nein, Spaß beiseite. Jetzt werden Business-Anforderungen und Softwarearchitektur zusammen gebracht. In diesem Abschnitt des Workshops werden nämlich die Szenarien mit den möglichen Architekturen auf Umsetzbarkeit und Sinnhaftigkeit verglichen.
Um dabei nicht zu viel Zeit zu verlieren und um mehr Beteiligung und Wissen der Teilnehmenden zu erreichen, würde ich empfehlen, die Teilnehmer des Workshops in Gruppen einzuteilen. Jede Gruppe darf eine der möglichen Architekturen behandeln. Man sollte hier allerdings beachten, dass in jede Gruppe jeweils eine Person mit Architektur-Wissen und eine Person mit Wissen über die Szenarien eingeteilt werden.
Nach 30 Minuten kommen alle wieder zusammen und stellen ihre Ergebnisse in der “Großen Gruppe“ vor, um eventuell nochmal in der ganzen Gemeinschaft darüber zu diskutieren. Das Vorgehen wird nun wiederholt, bis alle Architekturen einmal mit den Szenarien abgeglichen wurden und alle Ergebnisse allen Teilnehmenden vorgestellt wurden.
Der letzte Schritt in diesem Abschnitt ist das Finden einer “Siegerarchitektur”. Das sollte die Architektur sein, die am besten zu den Szenarien passt und in der man die wenigsten Kompromisse eingehen muss, um sein Ziel zu erreichen.
6. Abschluss
Die “Magie” ist vorbei, die Luft ist raus und die Leute sind platt.
Herzlichen Glückwunsch. Ihr habt euer Ziel erreicht und müsst jetzt nur noch die Ergebnisse kurz zusammenfassen. Holt euch auch Feedback von allen Beteiligten ein, damit Ihr den nächsten Workshop vielleicht +1 besser machen könnt. Danach dürft Ihr die Meute in ihren wohlverdienten Feierabend schicken.
Nach dem ATAM-Workshop …
Doch was nun? Ihr habt jetzt eine Handvoll Dinge wie die Businesstreiber und eine grobe Vorstellung davon, wie die Architektur aussehen soll. Doch was sollt ihr damit machen?
Die Businesstreiber, da sie ja die Non Functional Treiber (NFR’s) sind, sollten regelmäßig betrachtet und auf ihre Aktualität geprüft werden. Weiterhin sollte dafür gesorgt werden, dass jede am Projekt beteiligte Person die NFR’s auch kennt.
Noch wichtiger ist nach diesem Workshop aber die Kenntnis darüber, wie die “neue” Architektur aussehen soll. Nachdem dieser Workshop die grobe Richtung der Architektur vorgegeben hat, muss diese natürlich noch detaillierter geplant und ausgeschmückt werden. Dies geschieht – wer hätte es gedacht – in einem weiteren Workshop: dem Detail Architecture Workshop.
Dieser nachgelagerte Workshop findet im vergleich zum ATAM-Workshop nur noch mit den oder dem Architekten und den Devs statt. Denn das was in diesem Workshop passiert ist einfach zu technisch für die nicht-“Techies”.
Resümee
Das war zwar jetzt viel Text, aber ich hoffe, er hat die eine oder andere Wissenslücke geschloßen. Ich möchte an dieser Stelle noch mal daran erinnern, dass der hier vorgestellte Plan lediglich ein Vorschlag ist und keine Garantie auf Erfolg enthält. Also fühlt euch frei, bei der Planung dieses sehr umfangreichen Workshops eure eigenen Erfahrungen einfließen zu lassen und den Tag so zu planen, wie er zu euch und den Teilnehmenden am besten passt.
Was bleibt, ist euch noch viel Spaß bei der Durchführung wünschen. Und genießt die Magie, die dabei entsteht.
Schreibe einen Kommentar