Bevor wir die Reise Richtung "Cloud Nativeness" tatsächlich antreten, soll der folgende Abschnitt dazu dienen, ein Gefühl zu bekommen, wie die Reise ablaufen wird.
Auch ist es sicher interessant zu wissen wann die Reise angetreten werden soll (die Frage ob sie angetreten werden soll, stellt sich anno 2023 defacto nicht mehr 😉). Dazu gibt es von der CNCF eine Referenzübersicht die unter folgenden Link abgerufen werden kann: https://github.com/cncf/cartografos/blob/main/reference/prologue.md#when-is-the-right-time
Allgemeines zum Ablauf der Reise
Wie bereits im einleitenden Post beschrieben, ist der Startpunkt ein "Discovery Workshop". Ziel des Workshops ist es zu folgenden Themen genug Informationen zu sammeln, um die weiteren Schritte planen zu können:
Übersicht über die fachlichen Herausforderungen
Architekturziele
Der aktuelle System Context
Security-Governance-Risk-Compliance
Basierend auf den Ergebnissen des Workshops, erfolgt eine Planung über die Abfolge der einzelnen Themenblöcke / Zwischenstopps der Cloud Native App Journey. Ein Assessment auf Basis des CNCF Maturity Model ist dabei optional, hilft aber wesentlich bei der Priorisierung der Zwischenstopps.
Natürlich werden nur die Zwischenstopps "besucht", die tatsächlich erforderlich sind, um die gewünschten Dimensionen (lt. CNCF Maturity Model) auf ein neues Level zu heben. Die Zwischenstopps dienen dabei nur als grobe Leitlinie, es ist natürlich so, dass Themen aus anderen Zwischenstopps flexibel bearbeitet werden, wenn es zum jeweiligen Zeitpunkt sinnvoll oder sogar notwendig ist.
Sollte kein Assessment durchgeführt worden sein, haben wir zwei allgemeine Empfehlungen für die Reiheinfolge der Zwischenstopps:
Greenfield Projekte: Architect - Experience - Exchange - Interact - Communicate - Protect - Observe - Deliver
Brownfield Projekte: Observe - Deliver - Protect - Experience - Architect - Interact - Communicate - Exchange
Nachdem nun der Reiseablauf bekannt ist, können wir uns zum ersten Zwischenstopp unserer Reise begeben 😉: Dem Architect Zwischenstopp.
Was kann ich mir von diesem Zwischenstopp erwarten
Im Architect-Zwischenstopp sind folgende Themen enthalten:
Anforderungen & Architekturziele
Domänenmodell
Teams & Kollaboration
Randbedingungen & Konventionen
Übergreifende/Querschnittskonzepte
Lösungsstrategie
Basierend auf Anforderungen und Architekturzielen wird die Architektur des Systems entworfen und dokumentiert. Dabei unterscheiden wir zwischen strategischen Design und taktischen Design.
Das strategische Design kann man sich wie die Planung einer Stadt (dem System) vorstellen, bei der es wichtig ist, die Stadtviertel (die Subsysteme) im groben zu kennen und wie diese miteinander verbunden sind (umgelegt auf ein Software System: es geht darum festzustellen welche Subsysteme es geben wird und wie diese miteinander kommunizieren).
Das taktische Design wiederum kümmert sich um den inneren Aufbau eines Subsystems. Wichtig ist dabei, dass sich der Code, der die Fachlogik darstellt, niemals mit technischen Gegebenheiten verschmischen darf. Wir raten daher in der Regel dazu auf eine leichtgewichtige Abwandlung der Clean Architecture zu setzen.
Aus dem strategischen Design in Kombination mit den Architekturzielen lässt sich dann in weiterer Folge eine Lösungsstrategie für das Gesamtsystem ableiten.
Die Entwicklung und Dokumentation der Architektur ist jedoch keine einmalige Geschichte. Es geht dabei nämlich nicht darum, im Vorfeld bereits alles auszudefinieren, vielmehr sollen Entscheidungen zu dem Zeitpunkt festgehalten werden, an dem sie getroffen wurden. Die Architektur ergibt sich dann aus architekturrelevanten Entscheidungen und diese wiederum werden laufend getroffen und iterativ überarbeitet.
Durch dieses Vorgehen ist die Dokumentation kein statisches "Papier", das bald nach der Veröffentlichung bereits veraltet ist, sondern eine Sammlung von dokumentierten Prinzipien und Entscheidungen, die dabei hilft den Aufbau des Software Systems zu verstehen und zu kommunizieren.
Warum soll ich bei diesem Zwischenstopp halt machen
Die Architektur eines Systems ist in der Regel nur mit viel Aufwand zu ändern. Daher lohnt sich Aufwand der nicht nur initial, sondern über den gesamten Lebenszyklus des Gesamtsystems, in die Architekturentwicklung und -dokumentation gesteckt wird in der Regel mehrfach. Das Gesamtsystem bleibt wartbar, die Motiviation der Entwickler hoch (da sie nicht mit einem "Legacy System" arbeiten müssen), eventuelle Stolpersteine können frühzeitig erkannt werden und die Qualität verbessert sich kontinuierlich.
In vielen Unternehmen werden zudem Lastspitzen oftmals mithilfe von externen Entwicklern abgefedert, Systeme externen Überprüfungen unterzogen oder das Unternehmen ist einer erhöhten Fluktuation und im schlimmsten Fall dem "Verlust" von Wissensinseln ausgesetzt. Ohne Entscheidungen transparent und nachvollziehbar zu dokumentieren, kann man diesen Herausforderungen nicht gerecht werden.
Die Architektur darf dabei nicht nur Einzug in die Software finden, sondern muss im Einklang mit Teams und deren Zusammenarbeit untereinander erfolgen. Andernfalls wird man ganz schnell von Conways Law eingeholt und die "schöne neue Architektur" findet entweder gar keinen Einzug oder führt im schlimmsten Fall zu einem Big Ball of Mud.
Das bedeutet, dass nicht nur das Software System einen Wandel erfährt, sondern auch die Team- und Kommunikationsstrukturen sich weiterentwickeln müssen. Ansonsten werden Teams überlastet und/oder die weitere Entwicklung durch nicht angepasste Strukturen und Prozesse gelähmt.
Wie läuft dieser Zwischenstopp ab
Egal ob eine bestehendes System Re-Architected oder eine neues System umgesetzt wird, ist es essentiell das wie bereits erwähnt, die Architekturentwicklung und -dokumentation von Anfang an kollaborativ und iterativ durchgeführt wird. Wir empfehlen dazu auf die Konzepte und Ideen der folgenden defacto Standards zu setzen:
arc42 liefert einen nachvollziehbaren und transparenten Leitfaden für das Vorgehensmodell und die Dokumentation
Domain Driven Design für die Entwicklung eines cloud nativen Software Designs basierend auf fachlichen Problemstellungen, sowie die Einführung eines tatsächlich allgegenwärtigen Sprachmodells (konsistente und kontextabhängige Bezeichnung von Begriffen der fachlichen Problemstellung bis hin zum Code)
Team Topologies für die Optimierung der Teamstrukturen inklusive deren Interaktionen untereinander, in gegenseitiger Abstimmung mit der Architekturentwicklung
Architectural Principles und/oder Architectural Decision Records in Kombination mit einer "Community of Architecture Practice" (CoAP), um die kollaborative, iterative und nachvollziehbare Architekturentwicklung langfristig sicherzustellen
Wann und Wie Architekturprinzipien zum Einsatz kommen, hängt oftmals von der Unternehmensgröße und -struktur ab. Ein mögliches Szenario wäre beispielsweise, dass sich die CoAP mit Architekturprinzipien beschäftigt und die Teams abgeleitet davon selbstständig konkrete, für das Team maßgeschneiderte, Architekturentscheidungen treffen
Die Auflistung skizziert den vorgeschlagenen Ablauf:
Um ein gemeinsames Verständnis für die fachliche Problemstellung (Domäne) zu erhalten, starten wir mit einem Event Storming Workshop
Die Ergebnisse des Workshops werden mithilfe des arc42-Templates dokumentiert, das Template kann in weiterer Folge als Leitfaden für die weitere Architekturentwicklung genutzt werden
Basierend auf den Ergebnissen des Workshops werden die Adaptierungen bei den Teams mithilfe der Ideen von Team Topologies gestartet
Etablierung der "Community of Architecture Pratice", sodass von Anfang jedes Architekturprinzip und/oder Architekturentscheidung gemeinschaftlich definiert wird
Nachdem die ersten Entscheidungen getroffen wurden, können diese bereits in den Code einfließen und das Feedback daraus kann wiederum "zurückfließen"
Der weitere Ablauf ist im Grunde eine Wiederholung der vorherigen Schritte, bei dem das System und die Teams immer weiter verfeinert werden (refactoring toward deeper insight)
Somit sind wir bereit uns auf dem Weg zum nächsten Zwischenstopp zu machen. Ganz nach dem Motto der Individualität, würde ich mich freuen wenn ich Vorschläge für die nächsten Zwischenstopps erhalte 🤓.
Ganz einfach per Mail an: konrad.renner@fullstacks.eu
Comments