Wir haben das TrustYou CXP-Plattform von Grund auf neu, wobei wir unterwegs eine Menge architektonischer Entscheidungen getroffen haben.
Mit mehreren Produktteams und temporäre Teams Da unsere Ingenieure parallel an voneinander abhängigen Subsystemen arbeiten, brauchen sie viel Freiraum, um schnell voranzukommen. Aber Freiraum ohne Abstimmung führt zu Chaos. Eine solide Strategie für den Aufbau einer evolutionären Architektur war entscheidend, um die Abstimmung aufrechtzuerhalten und gleichzeitig Freiraum zu schaffen.
“Architektonische Entscheidung” ist ein Sammelbegriff, der eine ganze Reihe von Entscheidungen darüber umfasst, wie wir Software entwickeln. In diesem Artikel teile ich ein paar Gedanken dazu, wie wir architektonische Entscheidungen über die Struktur der Software und die Technologie-Roadmap für die TrustYou CXP-Plattform treffen.
Entscheidungen zur Architekturstruktur: Begrenzte Kontexte
Der begrenzte Kontext ist ein wichtiges Konzept aus dem Domain-Driven Design (DDD). Du findest formale Definitionen sowohl im “roten Buch” als auch im “blauen Buch” sowie in vielen tollen Artikeln und Ressourcen.
Abgegrenzte Kontexte waren die Basis für unsere Architekturentscheidungen, die die Struktur der Plattform beeinflussen. Wir haben damit angefangen, die Subsysteme zu identifizieren und für jedes einzelne abgegrenzte Kontexte zu definieren.
Klar, unsere Definitionen umfassen die gängige Sprache des Domänenmodells – aber wir haben uns noch mehr auf die eingehenden und ausgehenden Daten und Aktionen für jeden Kontext konzentriert.
Wir dokumentieren unsere begrenzten Kontexte mit einer gemeinsamen Vorlage und speichern sie alle zusammen auf einem gemeinsamen online Board für die Bereiche Produkt und Technik.
Da wir uns auf die Grenzen zwischen den Subsystemen und die Details ihrer Schnittstellen konzentrieren, haben wir die begrenzten Kontexte gemeinsam definiert. Ingenieure, Teamleiter und ich haben zusammengearbeitet, um ein gemeinsames Verständnis für jeden begrenzten Kontext, seine Grenzen und seine Schnittstellen zu entwickeln.
Wir haben Workshops mit Leuten aus allen Produktteams gemacht, um wichtige Fragen zu klären:
- Was sind die Subsysteme der Plattform?
- Was sind die Aufgaben und Ziele der einzelnen Teilsysteme?
- Was sind die wichtigsten Entitäten und Objekte in jedem Domänenmodell?
- Was ist die gängige Sprache für jedes davon?
- Was sind die Eingangs- und Ausgangsschnittstellen – also Daten und Aktionen – von jedem Teilsystem?
Dieser Top-Down-Ansatz mit Workshops hilft uns, isoliertes Denken zu vermeiden. Außerdem können wir so versteckte Annahmen früh erkennen und bessere Entscheidungen treffen.
Wir nutzen die Stufen 1 und 2 von C4, um unsere Systemarchitektur zu dokumentieren. Nachdem wir unsere begrenzten Kontexte definiert hatten, dienten sie als Hauptgrundlage für unser Systemkontextdiagramm. Dieses Diagramm erfasst Subsysteme, externe Abhängigkeiten und Akteure sowie alle Schnittstellen – interne und externe. Es ist eine solide Grundlage, um technische Entscheidungen auf jeder Skalierungsebene zu treffen.
Die wichtigsten Zutaten? Zusammenarbeit, die richtige Zielgruppe und ausreichend Zeit für die Workshops.
Entscheidungen zur Architektur von Technologien: Technologie-Roadmaps
Technologische Entscheidungen waren genauso wichtig wie strukturelle, um die Architektur von TrustYou CXP zu gestalten.
Wir nutzen Technologie-Roadmaps, um zu besprechen und zu zeigen, welche Tools, Techniken und Frameworks wir einführen, auslaufen lassen oder bewerten. Wir haben sogar verschiedene Technologie-Roadmaps für verschiedene Bereiche in unserer Abteilung, die sich alle unabhängig voneinander entwickeln.
Obwohl der ThoughtWorks Tech Radar das beliebteste Format ist, haben wir festgestellt, dass die Technologie-Einführungskurve von Rogers für uns besser funktioniert.
Unsere Technologie-Roadmap hat sechs Phasen:
- Finde es
- Probier's mal aus
- Entwickle es
- Schürfe es
- Priorität herabsetzen
- Außer Betrieb nehmen
Jede Phase hat Richtlinien, die zeigen, was es bedeutet, dort zu sein. Diese Bilder und Tipps unterstützen gute Gespräche, helfen dabei, Doppelarbeit zu erkennen, und finden Möglichkeiten zum Wissensaustausch.
Wenn wir neue Technologien checken oder verschiedene Optionen vergleichen, machen wir Testläufe mit klaren Vorgaben und Erfolgskriterien. Die Ergebnisse werden festgehalten und unterstützen die endgültige Entscheidung.
Wir haben die ersten Versionen dieser Roadmaps erstellt, bevor wir überhaupt mit der Umsetzung von CXP angefangen haben – und jetzt wollen wir sie zweimal im Jahr aktualisieren.
“Schreibst du keine ADRs?”
Kurz gesagt: Auf jeden Fall.
Ja, wir machen ADRs. Manchmal für Entscheidungen über begrenzte Kontexte und Technologie. Aber wir nutzen ADRs auch für viele andere Arten von Architekturentscheidungen.
Wir zwingen aber nicht jede einzelne Entscheidung in eine ADR. Uns geht's darum, die richtigen Gespräche mit den richtigen Leuten zu führen. Wenn eine ADR die Diskussion bereichert (und die Entscheidung verbessert), machen wir sie. Manchmal ist eine Entscheidung schnell, wird von einer kleinen Gruppe getroffen und wir legen direkt los mit der Umsetzung.
Diskutieren, visualisieren, Feedback sammeln, wiederholen
Letztendlich geht es darum, solide Prinzipien und Best Practices anzuwenden.
Architektur ist was, das man mit seiner Plattform weiterentwickelt – nicht was, das man einmal festlegt und dann für immer so lässt. Schau dir auf jeden Fall Alternativen an. Mach die Vor- und Nachteile klar. Hol dir Feedback von Leuten mit und ohne technischen Hintergrund. Und am wichtigsten:, bewusste Entscheidungen treffen.
Die Dinge werden sich ändern. Fang klein an, probier es immer wieder aus und lass dich nicht in endlosen Diskussionen über eine “wasserdichte” Lösung festfahren. Spoiler: Du wirst in zwei Jahren nicht wissen, was wasserdicht ist.
Abgegrenzte Kontexte, Technologie-Roadmaps und ADRs helfen uns, diese Prinzipien zu befolgen – und vielleicht helfen sie auch dir.
