Alexander Kaserbacher
18.07.2023
Alle drei Architektur-Frameworks sind durch ihren Umfang kompliziert in der Anwendung. Es gibt allerdings einige Kniffe, die Ihnen helfen, diese Werkzeuge effektiv und effizient einzusetzen.
Alle Frameworks bestehen jeweils aus hunderten von Best Practices und einer zweistelligen Anzahl an Designprinzipien. Das macht sie schwergewichtig in der Anwendung. Nicht zuletzt, weil die Masse an Information die Review-Durchsprachen langwierig macht. In diesem Blogpost stelle ich Lösungsoptionen vor, wie Sie das Framework Ihrer Wahl effizienter einsetzen können. Hierbei diskutieren wir sowohl die Anwendung der Frameworks im Kontext von Architektur-Reviews als auch zur Unterstützung, wenn Sie eine wichtige Architekturentscheidung treffen.
Reviews mit den Architektur-Frameworks basieren auf einer Durchsprache von Best Practices. Stellen Sie sich vor, Umsetzungsteams und relevante Stakholder diskutieren über eine Best Practice. Ziel der Durchsprache ist eine gemeinsame Meinung, ob die Best Practice erfüllt ist. Dieses Vorgehen skaliert sehr schlecht. Allein das AWS Well Architected Framework umfasst mehr als 300 Best Practices.
Sie können davon ausgehen, dass Sie sich bei einigen Best Practices im Team uneinig sind, ob Sie diese erfüllen oder nicht. Nehmen wir zum Beispiel eine Best Practice aus dem AWS Well Architected Framework: „Build services focused on specific business domains and functionality” [ASB]. Diese Best Practice sagt, dass Sie ihr System fachlich/vertikal modularisieren und diese Module durch unabhängig deploybare Services abbilden sollen. Halten wird diese Best Practice gegen ein hypothetisches System, das erst teilweise fachlich/vertikal modularisiert ist und zum Teil noch auf einer monolithischen, technisch modularisierten Architektur basiert. Eine Durchsprache wird in diesem Fall zu Diskussionen führen und viele Teams wären unsicher, ob diese Best Practice in diesem Fall zutrifft.
Gerade wenn Sie damit beginnen, die Architektur-Frameworks einzusetzen, lohnt es sich, einen fokussierten Ansatz zur Durchsprache zu wählen.
Abbildung 1 zeigt einen Überblick über den Review-Prozess. Er besteht aus vier Schritten, die iterativ fortgesetzt werden können.
Abbildung 1: Prozess für ein fokussiertes Architektur-Review mit einem Architektur-Framework
1. Best Practices priorisieren
Bevor Sie mit der Durchsprache beginnen sollten Sie Best Practices auswählen und priorisieren. Ziel dieses Schrittes ist es, wichtige Best Practices zu identifizieren, deren Durchsprache fundamentale, wichtige Entscheidungen absichert.
Legen Sie zuerst einen Termin und die Dauer für einen Durchsprache-Workshop fest. Starten Sie mit einem fixen Zeitslot und Teilnehmerkreis, beispielsweise: „erster Review-Workshop über 6 Stunden mit Entwicklungsteams, Product Owner und Leiter unserer Business Unit”. Daraus abgeleitet können Sie abschätzen, wie viele Best Practices Sie in diesem Workshop realistisch schaffen. Eine gute Daumenregel ist: zwei pro Stunde. Für unser Beispiel wären das also 12 Best Practices.
Wählen Sie dann gezielt Best Practices aus einem Architektur-Framework aus und bringen Sie diese in eine Reihenfolge. Ihr Ziel ist es erstmal, genügend Best Practices auszuwählen, um den Workshop zu füllen. Abbildung 2 hilft Ihnen beim Aussortieren und Priorisieren der Best Practices.
Abbildung 2: Eine Checkliste für die Priorisierung von Best Practices
2. Review vorbereiten
Wenn Sie Best Practices identifiziert haben, die Sie im folgenden Workshop besprechen möchten, dann starten Sie mit der Vorbereitung.
Insbesondere sollten Sie zu den Best Practices passende Architekturdokumentation heraussuchen und zum Workshop mitbringen. Dokumentierte Architekturentscheidungen eignen sich hier neben Konzepten oder Übersichtsbildern besonders gut. Verteilen Sie diese Artefakte vorab im Teilnehmerkreis, sodass sich alle gut vorbereiten können.
3. Best Practices durchsprechen
Kümmern Sie sich um die Moderation des Workshops. Für besonders große Workshops lohnt es sich, eine:n (Team-)externen Moderator:in einzuladen.
Moderator:innen kümmern sich um die Vorstellung der Best Practices und eine zielorientierte, fokussierte Diskussion. Außerdem haben sie ein Auge auf der Timebox (mein Vorschlag: 30 Minuten pro Best Practice).
Notieren Sie die Best Practices, die Sie als „nicht erfüllt” deklariert haben. Diese sind für den nächsten Schritt wichtig.
4. System verbessern
Nehmen Sie Ihre „unerfüllten” Best Practices in eine Liste auf. Diese sollte nach Wichtigkeit sortiert sein. Setzen Sie sich nicht zum Ziel, alle Best Practices zu erfüllen – aber setzen Sie zumindest 2-3 Best Practices um, bevor Sie wieder mit Schritt 1 starten und neue Best Practices zur Durchsprache definieren.
Unterfüttern Sie die (eher technischen) Verbesserungs-Tasks aus der Best Practice-Liste mit fachlichen Anforderungen. Dies hilft Product Ownern und anderen Produktverantwortlichen die Verbesserungsinitiativen einzupriorisieren.
Das können Sie beispielsweise damit erreichen, dass Sie den monetären Aufwand, der bei Nichtumsetzung entsteht, abschätzen und kommunizieren [EVA]. Eine andere Möglichkeit ist das Formulieren eines Qualitätsszenarios, das Sie nach der Umsetzung der Verbesserung realistisch erreichen können [QSZ].
Im Anschluss
Starten Sie danach wieder mit Schritt 1. Markieren Sie sich idealerweise regelmäßige Intervalle im Kalender, zu denen Sie eine neue Iteration anstoßen und zu Workshops einladen.
Wenn Sie für Ihr System Architekturentscheidungen treffen bzw. Konzepte und Prinzipien ausarbeiten, dann können Ihnen die Architektur-Frameworks durch ihre inhaltliche Breite sehr von Nutzen sein.
Auch hier ist es durch den Umfang der Frameworks schwierig, viele Best Practices gleichzeitig im Kopf zu behalten und alle Lösungsoptionen damit abzuwägen. Sinnvoller ist es, sich erstmal die Designprinzipien aus den Pillars zu verinnerlichen und ein mentales Model davon abzuleiten. Dieses Modell hilft Ihnen dabei, ein Bauchgefühl zu entwickeln, was gute Lösungsoptionen im Cloud-Umfeld ausmacht.
Haben Sie dann erstmal eine favorisierte Lösungsoption identifiziert, dann können Sie diese wiederum einfacher gegen wichtige Best Practices halten. Abbildung 3 illustriert diese Ideen.
Abbildung 3: Architektur-Frameworks als Unterstützung bei Architekturentscheidungen
Das war der letzte Beitrag der Blogreihe “Well Architected Cloud”. Wenn Sie sich zu den Architektur-Frameworks, deren Pillars oder Anwendung in der Praxis austauschen möchten, dann melden Sie sich gerne. Meine Kontaktdaten finden Sie hier.
“Well Architected Cloud: ein Überblick über drei Architektur-Ratgeber”
‘Well Architected Cloud: die “Operational Excellence”-Pillar’
“Well Architected Cloud: die Security-Pillar”
“Well Architected Cloud: die Reliability-Pillar”
‘Well Architected Cloud: die “Performance Efficiency”-Pillar’
“Well Architected Cloud: die Pillars “Cost Optimization” und Sustainability”
[ASB] “Beispiel einer Best Practice”
[EVA] “Abschätzung von technischen Schulden”
[QSZ] “Qualitätsszenarien anhand von Beispielen erklärt”