Effektive Umsetzung von Architektur-Entscheidungen - Qvest Tech Connect

Transcript

1. Experience the Next. Experience the Next.
2. QVEST TECH CONNECT Effektive Umsetzung von Architektur-Entscheidungen 20.02.2024
3. Was leistet Software Architektur? Konzeptionelle Integrität Qualitäts- anforderungen Verständ- lichkeit Lifecycle Anforderungen können auf ähnliche Weise wiederkehrend gelöst werden. Lösungen müssen nicht immer neu er/gefunden werden. Qualitätsstandards werden übergreifend definiert. Z.B. CleanCode, Domain Driven Design, Test Driven Development, Codemetriken Überschneidet sich mit der QA. Minimierung von Komplexität und Erhöhung der Lesbarkeit. Einfache Onboarding neuer Kolleg*innen Verständlichkeit auch auf heren Flylevel Die Zielarchitektur als Moving Target. Von der Konzeption, über die Entwicklung bis zur Wartung und Änderung. Gernot Starke, Effektive Software-Architektur, 2014 Definition einer langfristigen Zielarchitektur mit Blick auf gleichbleibender Änderbarkeit und Agilität. Langfristigkeit
4. Probleme und Implikationen Wildwuchs • fachlicher vs. technischer Schnitt • Bildung von hoher technischer Komplexität • (Distributed) “Big Ball of Mud” • verschiedene Sprachen / Frameworks • unterschiedliche API / UI Stile → unzufriedene Kunden
5. Probleme und Implikationen Whack-a-Mole Syndrom • Systemänderungen führen mit hoher Wahrscheinlichkeit zu Folgefehlern. • Der Aufwand einer Risikoabschätzung übersteigt den Aufwand der fachlichen Änderung. • Abschätzungen werden schwer bis unmöglich. • schlechte Prediction in der Projektplanung. • → geringe Time-To-Market → Release-Verzögerungen
6. Probleme und Implikationen Shared Kernel (DDD) • hoher Kommunikationsaufwand zwischen Teams. • Änderungen betreffen mehrere Teams. • Typisch im Kleinen: Utils, Helper, Libs, … • Typisch im Großen: (Process) Engines, Master Data, … • Releases müssen abgesprochen werden. → führt zu Verzögerungen → geringe Time-To-Market
7. technische Komplexität Komplexitätsreduktion fachliche Komplexität organisatorische Komplexität
8. technische Komplexität Komplexitätsreduktion Fachliche Komplexität minimieren
9. Komplexitätsreduktion
10. Gernot Starke, Effektive Software-Architektur, 2014 Architektur im Spannungsfeld
11. Gernot Starke, Effektive Software-Architektur, 2014 Wenn es schlecht läuft Architektur im Spannungsfeld Elfenbeinturm- Effekt Backpressure Effektlosigkeit Unsichtbarkeit Sinnfrage
12. Gernot Starke, Effektive Software-Architektur, 2014 Verständnis und Wissen fördern Architektur im Spannungsfeld fachlicher Kontext Kunden / Stakeholder Kosten & Termine Top-Down Planung / Roadmap technischer Kontext agile Entscheidungen Technische Innovation kontinuierliche Verbesserung
13. Gernot Starke, Effektive Software-Architektur, 2014 Vertrauen, Argumentieren und Überzeugung Architektur im Spannungsfeld Zielarchitektur Vereinfachung weniger Komplexität Autonomie bessere Time to Market weniger Kommunikations- overhead Wiederverwendbare Konzepte
14. Werkzeuge und Hilfsmittel Zielgerichtete Dokumentation Die Lesende Person im Fokus halten Dokumentation nicht als Selbstzweck Auf Allgemeingültigkeit achten Automatisieren, Living Documentation Dokumentation ist oft schon beim Schreiben veraltet! Ziele fachliche, technische und monetäre Dimensionen abbilden Den aktuellen Zustand darstellen Die zukünftige Entwicklung verständlich machen Entscheidungsbäume abbilden Aufs Flylevel achten!
15. Werkzeuge und Hilfsmittel Architecture Decision Records Context Decision Status Consequences Ziele Ist-Zustände abbilden Probleme deutlich machen Lösungsansätze dokumentieren Entscheidungen festhalten 4-Augen Prinzip Entscheidungsverlauf abbildbar machen
16. Werkzeuge und Hilfsmittel Leitplanken / Guides An die Entwicklung direkt gerichtet Must / Should / Could - Pattern Immer mit Argumentation! verschiedene Themengebiete APIs, Eventing, Testing, Coding, … Ziele Hilfestellung Verständnis - Das “Warum” im Fokus halten Teams Entscheidungsfreiheit geben
17. Architekt*innen benötigen die “Insignien der Macht” Entscheidungen treffen können. Themen und Zielzustände in Backlogs / Projektpläne einweben. Einfluss auf die Prioritäten im Prozess nehmen. Missstände in Teams ansprechen Wer entscheidet eigentlich?
18. Problem: Je mehr Detailvorgaben gegeben sind: Risiko von Micromanagement Backpressure weniger Eigeninitiative wenig bis keine Eigenverantwortung im Team Wissen und Lösungskompetenz geht verloren Wer entscheidet eigentlich?
19. Potentielle Lösung: Architekt*in als Teil des Teams (bei 1 - 2 Teams) “Ohr an der Maschine haben” Themen im Team besprechen und Lösungen erarbeiten Problembewusstsein erzeugen Vertrauen aufbauen Das Team entscheiden lassen Wer entscheidet eigentlich?
20. Potentielle Lösung: Architektenteam + Teamarchitekten Themen werden eingebracht Diskussion und Entscheidung werden getroffen ADRs und Leitplanken werden bestimmt Gemeinsamer Konsens Wer entscheidet eigentlich?
21. Zusammenfassung Architektur … ist nie Selbstzweck muss immer argumentiert werden. ADRs, Arc42, etc. helfen dabei. findet im Spannungsfeld statt braucht Unterstützung aus dem Management muss überzeugen. Leitplanken helfen hierbei. 21 Die Entwicklung und das Management sind nicht die Feinde, sondern haben ähnliche Ziele. Kommunikation ist wichtig Es gibt viele Menschen, die die Architektur unterstützen können Kollaboration hilft stark in der Argumentierung und in der Vertrauensbildung.
22. Christian Schmidt IT Consultant / Software Architect Qvest Digital AG Am Dickobskreuz 10 53121 Bonn, Deutschland c.schmidt@qvest-digital.com christian-schmidt-it darktoast social/@DarkToast speakerdeck Vielen Dank