Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Effektive Umsetzung von Architektur-Entscheidun...

Effektive Umsetzung von Architektur-Entscheidungen - Qvest Tech Connect

Christian Schmidt

February 22, 2024
Tweet

More Decks by Christian Schmidt

Other Decks in Technology

Transcript

  1. 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
  2. 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
  3. 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
  4. 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
  5. Gernot Starke, Effektive Software-Architektur, 2014 Wenn es schlecht läuft Architektur

    im Spannungsfeld Elfenbeinturm- Effekt Backpressure Effektlosigkeit Unsichtbarkeit Sinnfrage
  6. 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
  7. 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
  8. 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!
  9. 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
  10. 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
  11. 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?
  12. 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?
  13. 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?
  14. Potentielle Lösung: Architektenteam + Teamarchitekten Themen werden eingebracht Diskussion und

    Entscheidung werden getroffen ADRs und Leitplanken werden bestimmt Gemeinsamer Konsens Wer entscheidet eigentlich?
  15. 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.
  16. Christian Schmidt IT Consultant / Software Architect Qvest Digital AG

    Am Dickobskreuz 10 53121 Bonn, Deutschland [email protected] christian-schmidt-it darktoast social/@DarkToast speakerdeck Vielen Dank