Beim Architect-Zwischenstopp haben wir uns mit Software- und Teamarchitektur beschäftigt, dieser Zwischenstopp ist eine ideale Überleitung zu eher technischen Themen.
Auf der einen Seite beschäftigt sich dieser Zwischenstopp nämlich in einer höheren Detailstufe mit architektonischen Themen (bspw. Service orientierte Architekturen) und auf der anderen Seite wird definiert, wie man von den Überlegungen des Architect-Zwischenstopps zu konkreten Umsetzungen kommt.
An dieser Stelle ist vermutlich auch die Abgrenzung zum Communicate-Zwischenstopp interessant. Wie der Name schon sagt, liegt der Fokus dieses Zwischenstopps auf der Interaktion mit dem Gesamtsystem bzw. den Teilsystemen untereinander, es geht dabei nicht im Detail darum wie Systeme miteinander kommunizieren.
Am Beispiel des Themas "API Design" wird die Abgrenzung konkret. Dieser Zwischenstopp fokussiert sich unter anderem darauf, wie die Interaktion zwischen Systemen über APIs gestaltet wird. Dazu zählt bspw. die Entwicklung eines API Design Guides. Die Definition der Kommunikation bzw. Kommunikationstechnologie zwischen System liegt dabei nicht im Fokus.
Oder anders formuliert:
Es geht darum zu beschreiben wie bspw. APIs gestaltet werden (also wie mit einem System interagiert wird), aber nicht darum was die konkrete Kommunikationstechnologie (bspw. "HTTP") sein wird.
Wobei sich diese beiden Zwischenstopps natürlich in der Regel ergänzen, die Praxis hat allerdings gezeigt, dass vor allem bei Brownfield-Projekten die Themen eines Zwischenstopps oftmals bereits vorgegeben sind und daher die Fokussierung durchaus Sinn macht.
Was kann ich mir von diesem Zwischenstopp erwarten
Im Interact-Zwischenstopp sind folgende Themen enthalten:
API Design & Management
Design Guide
API Gateway
Backend-For-Frontend
UI Rendering
Server Side
Client Side
Hybrid
Service Oriented Architectures
Microservice
Self-Contained-System
Microlith
Data Oriented Architectures
Job-Handling & Orchestration
Online Analytical Processing
Batch Processing
Dank den Ergebnissen aus dem Architect-Zwischenstopp ist klar, welche Arten von Interaktion ein System und dessen Subsysteme unterstützen muss. D.h. die grundsätzliche Fragestellung ob ein System bspw. für die Interaktion mit Menschen und/oder Maschinen ausgelegt ist, ist bereits geklärt.
Daher kann sich in diesem Zwischenstopp zum einen darum gekümmert werden, welche Art von Interaktion die höhere Priorität aufweist und wie das System intern aufgebaut wird.
Sollte ein System beispielsweise nahezu ausschließlich als Backend-System dienen und nur minimale Administrationsoberflächen benötigt werden, so wird das Hauptaugenmerk auf API Design und Management liegen.
Weiters wird im Zuge dieses Zwischenstopps entschieden, wie die konkrete Ausprägung einer Service-Orientierten- und/oder einer Daten-Orientierten-Architektur aussehen wird.
Warum soll ich bei diesem Zwischenstopp halt machen?
Eine - die Bedürfnisse des Benutzers - erfüllende Erfahrung mit dem System ist essentiell für den Erfolg des Systems und damit ausschlaggebend für den Geschäftserfolg. Das gilt unabhängig davon, ob die primäre Benutzergruppe des Systems Maschinen oder Menschen sind.
Der interne Aufbau eines Systems wiederum hat massive Auswirkungen auf die Resilienz, Skalierbarkeit, Interoperabilität, Verfügbarkeit und Performance eines Systems und ist daher unbedingt in Einklang mit den Architekturzielen zu halten/bringen.
Wie läuft dieser Zwischenstopp ab?
Der Architect Zwischenstopp bildet den Ausgangspunkt dieses Zwischenstopps. Insbesondere folgende Themen des Architect Zwischenstopps müssen geklärt sein, um diesen Zwischenstopp erfolgreich zu bewältigen:
Architekturziele
Technische Lösungsübersicht / System Context
Fachliche Lösungsübersicht / Context Map
Klarheit über die Bezeichnung fachlicher Begriffe / Ubiquitous language
Die konkrete Zielarchitektur wird auf Basis der zu erfüllenden Architekturziele definiert. Anhand von Qualitätszenarien ist die Überprüfung - ob die Ziele erfüllt wurden - möglich.
Aus dem Systemkontext wird eine Strategie für die Interaktion von außen und aus der Context Map wird eine Strategie für die Interaktionen innerhalb des Systems abgeleitet.
Die Read-Model, welche im Zuge von Event Storming Workshops "entdeckt" wurden, geben Aufschluss darüber, wann und wie ein Benutzer mit dem System interagiert.
Das API-Design erfolgt im Einklang mit der Ubiquitous language. Ein API-first Ansatz rendiert sich in der Regel, da dieser beispielsweise die Implementierung von API Consumer und Producer parallel ermöglicht.
Am Ende dieses Posts gibt es dieses mal einen kleinen Teaser zum nächsten Blog-Post 😎:
Um die Inhalte dieses Zwischenstopps noch greifbarer zu machen, werden wir im nächsten Post in das Thema "Interact: ServiceMesh und MultiCloud demystified" eintauchen.
コメント