Architektur-Governance - Daumenschrauben für Softwareentwickelnde (Digital Crafts Day 2025)

Hach, Softwareentwicklung könnte so einfach sein, wenn es keine Regeln gäbe. Alle könnten in der Programmiersprache ihrer Wahl coden, so deployen, wie es der neueste Artikel im Fachmagazin erzählt, und generell tun und lassen, was der eigenen Stimmungslage gerade beliebt.

Doch wie lange könnte dieses scheinbare Paradies gutgehen? Chaos und Frust wären die unvermeidliche Folge, da irgendwann nichts mehr zusammenpasst. Was anfangs als kreative Freiheit erscheint, entwickelt sich schnell zu einer schwer zu bändigenden Hydra aus Bugs, unklaren Zuständigkeiten und zerstreuten Systemkönigreichen.

In diesem Vortrag zeige ich, wie man Vorgaben und Freiheiten bei der Evolution von Softwaresystemen passend ausbalanciert. Wir sehen uns an, wann, wo und wie welche Daumenschrauben gedreht werden sollten, um das richtige Maß an Architektur-Governance zu finden, die Softwareentwicklende ohne Schmerzen zum Ziel führt

Transcript

1. Architektur-Governance: Daumenschrauben für Softwareentwickelnde Markus Harrer Software Evolutionist D i g i t a l C r a f t s D a y 2 0 2 5 , 4 . A p r i l 2 0 2 5 , W e i d e n
2. Architektur- Governance? 2
3. 3 Als Entwickler:in möchte ich doch kreativ, frei und selbstbestimmt arbeiten Regeln? WtF! WTF: Welch’ törichte Frage
4. Hallo, agil? 4 Manifest für Agile Softwareentwicklung Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt: Individuen und Interaktionen anstatt Prozesse und Werkzeuge Funktionierende Software anstatt umfassende Dokumentation Zusammenarbeit mit dem Kunden anstatt Vertragsverhandlung Reagieren auf Veränderung anstatt das Befolgen eines Plans mehr als mehr als mehr als mehr als Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.
5. 5 = Department Of No Enterprise Architects Softwarearchitekten Information Security Officer naysayers Regel das
6. 6 Alerting Logging Monitoring Continuous Delivery Code-Doku API-Dokumentation Datenverschlüsselung Authentifizierung Input Validation Gitflow Commit Messages Code Reviews Performance-Tests Domain Driven Design Microservices RESTful APIs AI
7. Architektur-Governance ist wichtig 7 Wir hatten eine State of the Art Cloud Native App geschrieben, konnten sie aber dann nicht produktiv nehmen, da der Produktivbetrieb in der Cloud von der IT untersagt war. damit sowas nicht passiert … Wir haben uns Kafka auf AWS geklickt, aber die Admins wollten uns dann keine Firewall-Frei- schaltung dafür geben. Wir können jetzt innerhalb von 30 Minuten auf Prod deployen, aber die Release-Manager tagen nur alle 6 Monate.
8. Wo dürfen wir regieren? 8 Adaptiert von Sam Newman: Monoliths to Microservices Umstellung des Hosting Providers Änderungen an der Public API Einführung einer neuen Programmiersprache im Unternehmen Anpassungen im eigenen Datenbank-Schema Auswahl einer Open-Source-Bibliothek Kleine Experimente mit einer neuen Programmiersprache Irreversibel • Globaler Konsens notwendig • (Fast) Unmöglich zu ändernde Festlegungen • Gut durchdachte Lösungen notwendig Reversibel • Lokale Entscheidung • Niedrige Kosten beim Zurücknehmen einer Entscheidung • Ad-Hoc-Entscheidungs- findung akzeptabel Entscheidungsband Wer darf was entscheiden? Konkrete Umsetzung von Features im Code
9. Ziel dieses Vortrags 9 „Geregeltes Quälen“ Mehr Infos: https://wissen.schloesserland-sachsen.de/blog/detail/sprichwoertlich-die-daumenschrauben-anlegen/ Spoiler: kann weh tun Das richtige Drehmoment für die Daumenschrauben finden
10. 10 Woher kommen denn diese ganzen Regeln?
11. Mögliche Einflüsse von außen 11 • Gesetzgebung • Normen / Standards • Regulatorische Anforderungen (z. B. DSGVO, BaFin, HIPAA) • Sicherheitsrichtlinien (z. B. ISO/IEC 27001, OWASP, BSI) • Branchenspezifische Vorschriften (z. B. BAIT/VAIT, Medizinproduktegesetz, Luftfahrtstandards) • Industrie-Konsortien und -Allianzen (z. B. W3C, GAIA-X) • …
12. Mögliche Einflüsse von innen 12 • Wachstumspläne (z. B. Internationalisierung, neue Märkte) • Digitalisierungsstrategie / Cloud Transformation • Erfahrung und Skills im Team • Verfügbare Kapazitäten (FTEs, Zeit, Geld, …) • Erwartungen von Fachabteilungen, Controlling, Legal, … • Vorhandene andere Systeme, Plattformen und Infrastruktur • …
13. 13 Einfluss Einfluss Einfluss Einfluss Einfluss Einfluss Einfluss Einfluss Einfluss Einfluss Einfluss Einfluss Einfluss Einfluss Das adressieren wir in unseren Softwaresystemen jetzt so und so! Einfluss
14. Was bedeutet das für uns? 14 Wir müssen uns damit leider auseinandersetzen!
15. 15 Stile der Architektur-Governance
16. 16 “to rule without sovereign power and usually without having the authority to determine basic policy” “to manipulate” “to control” “to direct, or strongly influence the actions and conduct of” “to serve as a precedent or deciding principle for” Definitionen: Merriam Webster bestimmend begleitend
17. Extrinsisch motiviert 17 Geld Ehre Ruhm Intrinsisch motiviert Purpose Autonomy Mastery bestimmend begleitend
18. 18 Prinzipien Werte Praktiken Regeln Vorgaben Verfahren Strafen Feedback bestimmend begleitend hart & detailliert Weich & offen
19. Stile der Architektur-Governance 19 Ziel: Maximale Effizienz und Produktivität Ganzheitliche Aufgaben im Team, Verantwortung über Features oder User Stories Integrierte Verantwortung (Team denkt und handelt selbst) Selbstorganisation des Teams, über Prinzipien, Ziele, Vertrauen Tayloristisch Zerlegung von Arbeit in kleinste, standardisierte Einzelschritte Trennung von Denken (Planung) und Handeln (Ausführung) Vorgaben und Kontrolle durch Management Agile / Lean
20. Dreyfus-Modell / Kompetenzstufen 20 Anleitung Fähigkeiten Hoch Hoch Experte Gewandter Kompetenter fortgeschrittener Anfänger Neuling Intuitives Handeln, gibt strategische Orientierung Passt Pläne an, erkennt Pro- bleme mit ganzheitlichem Blick Plant Aufgaben, setzt Prio- ritäten mit wenig Anleitung Beginnt Aufgaben zu verstehen, benötigt noch etwas Unterstützung Braucht klare Regeln und Anleitungen Angelehnt an https://www.brainbok.com/guide/pm-fundamentals/interpersonal-and-team-skills/dreyfus-model-of-skill-acquisition/ Niedrig Tayloristisch Agile / Lean
21. Was bedeutet das für uns? 21 Das richtige Drehmoment hängt von Fähigkeiten ab! Experte Gewandter Kompetenter fortgeschrittener Anfänger Neuling
22. 22 Evolution der Governance
23. Falls Software erfolgreich ist … 23 Software- system Genesis Custom Built Product Commodity Evolution „Alles entwickelt sich durch den Wettbewerb von Angebot und Nachfrage“ – Simon Wardley Genesis Custom Built Product Commodity Evolution
24. Wer will unsere Software? Nachfragewettbewerb (oder: Technology Adoption Curve FTW) Genesis Custom Built Product Commodity Evolution % Marktsättigung 24 Innovators (2,5%) Early Adopters (13,5%) Early Majority (34%) Late Majority (34%) Laggards (16%) % Marktwachstum Software- system
25. Wer muss mitarbeiten? Angebotswettbewerb: Lieferfertigkeit muss nachziehen Genesis Custom Built Product Commodity Evolution 25 Entwicklungskapazität % Marktsättigung Software- system
26. Wie stark müssen wir regeln? Daumenschraubendrehmoment Genesis Custom Built Product Commodity Evolution 26 Entwicklungskapazität Einflüsse Erste, zarte Pflänzchen der Architekturarbeit Gestandene, erfahrene Engineering Teams Architekturarbeit im Großem Ganz interes- sant regle- mentiert
27. Was bedeutet das für uns? 27 Das richtige Drehmoment für die Daumenschrauben zu finden, ist eine kontinuierliche Aufgabe! t
28. 28 Governance-Strategien
29. Governance-Strategien 29 Fixe Vorgaben Bis ins Detail durchentschiedene Lösung Paved Roads Angebot von alternativen Lösungen Multi Level Verteilte, hierarchische Standards API Mandate Individuelle Standards, aber standardisierte Schnittstellen zentral dezentral Stark angelehnt an Mark Richards “Software Architecture Monday, Lesson 62 - Enterprise Architecture Strategies”
30. Unternehmen Harte Festlegungen 30 Fixe Vorgaben zentral + reduziert Komplexität + weniger Zeitbedarf bei Entscheidungen + hohe Wiederverwendung + kostengünstig - passt evtl. nicht überall - schwer, Akzeptanz zu schaffen - nicht jede(r) ist glücklich - starke Kontrolle notwendig Zentrales Architekturteam Standards Geschäfts- einheit Geschäfts- einheit
31. 31 Flexible Entwicklungs- planung Standards Alle Entwicklungsteams müssen Oracle JDK 21.0.6 verwenden Fixe Vorgaben zentral
32. 32 Hohe Code- Qualität Standards Der Default-Regelsatz von SonarQube meldet keine Major und Critical Findings Fixe Vorgaben zentral
33. 33 Funktionierende Software Standards Die Test-Coverage der Unit-Tests muss min. 70 % betragen. Fixe Vorgaben zentral
34. Was soll schon schief gehen? 34 Teams könnten fangen an zu cheaten Foto: Kantenflimmern CC BY-SA 2.0 https://www.flickr.com/photos/kantenflimmern/3078108108/ Fixe Vorgaben zentral
35. 35 protected void processRequest1(HttpServletRequest request,¬ HttpServletResponse response) throws Exception { locale = LocaleResolver.getLocale(request); EventCRFBean ecb = ¬ (EventCRFBean)request.getAttribute(INPUT_EVENT_CRF); SectionBean sb = (SectionBean)request.getAttribute(SECTION_BEAN); <496 Lines of Code> processRequest2(request, response, fp); } protected void processRequest2(HttpServletRequest request, ¬ HttpServletResponse response) throws Exception { Boolean b = (Boolean)¬ request.getAttribute(INPUT_IGNORE_PARAMETERS); isSubmitted = fp.isSubmitted() && b == null; int eventDefinitionCRFId = 0; ... Nachgestelltes Beispiel (weil man sowas nicht in freier Wildbahn finden kann) Methoden müssen <= 500 Teilen lang sein Source-Code-Auszug-Basis von OpenClinica
36. 36 https://github.com/auchenberg/volkswagen
37. Tipps 37 • Das „Warum“ deutlich machen • Ausgeschlossene Varianten kennzeichnen (ADRs) • Regelmäßig Feedback einholen (oder Entscheidungen selbst ausbaden) • Bei Bedarf anpassen ADR: Architecture Decision Record Fixe Vorgaben zentral
38. Mehrere Alternativen 38 Paved Roads eher zentral + richtiges Werkzeug für den Job + mehr Kontrolle der Auswahl + bessere Zufriedenheit - braucht Zeit für Auswahl - Wahl / Zusammensetzung könnte nicht die richtige sein - höhere Kosten Unternehmen Geschäfts- einheit Geschäfts- einheit Zentrales Architekturteam Standard A Standard B
39. 39 Paved Roads eher zentral Standards Wir entwickeln unsere Enterprise-Applikationen mit Java und unsere Datenanalysen mit Python / Pandas Flexible Entwicklungs- planung
40. Mögliche Paved Roads 40 Attraktive Defaults statt harter Vorgaben Tooling✓ CI/CD-Pipeline✓ Infrastruktur✓ Guidelines✓ Automatisierung✓ …✓
41. Tipps 41 • Alle Alternativen gleichwertig behandeln und weiterpflegen • Ausnahmeregelungen dennoch zulassen • Feedback-Loop einbauen Paved Roads eher zentral ADR: Architecture Decision Record
42. Unternehmen Verteilte, hierarchische Standardisierung 42 Multi Level eher dezentral + richtiges Werkzeug für den Job + Geschäftseinheit hat Kontrolle + minimale, zentrale Vorgaben + bessere Gesamtzufriedenheit - fehlende Abstimmungen - hohe Kosten - erschwerte Kostenkontrolle - schwer global zu steuern Geschäfts- einheit Lokaler Standard Geschäfts- einheit Lokaler Standard Geschäfts- einheit Lokaler Standard Geschäfts- einheit Lokaler Standard Gemeinsame Standard Globaler Standard
43. (Architektur-)Prinzip 43 „Ein Architekturprinzip ist eine deklarative Aussage, die mit der Absicht getroffen wird, architektonische Designentscheidungen zu leiten, um eine oder mehrere Qualitäten eines Systems zu erreichen.“ - Eoin Woods
44. Leitplanken 44 = Universell nützliche High-Level-Prinzipien • Legen die wichtigsten Prioritäten fest • Helfen dem Team, auf Kurs zu bleiben → Vermeidet auch, dass es wider- sprüchliche Interessen gibt
45. 45 Multi Level eher dezentral Standards Uns ist wichtig, dass wir Entwicklerinnen und Entwickler schnell auf alle anderen Projekte einarbeiten können Flexible Entwicklungs- planung High level Lass mal Java nehmen Low level Alles auf der JVM ist OK Mid level
47. 47 https://github.com/Scout24/scout24-engineering-values-and-principles/
48. 48 Multi Level eher dezentral Funktionierende Software Standards Design für Testbarkeit Wir setzen für kritische Komponenten Mutation Testing ein High level Low level
49. Beispiel Architekturprinzip 1/2 49 Prinzip: Design für Testbarkeit Die Lösungen sollten so konzipiert - und der Code so strukturiert - sein, dass die Ausführung der Tests einfacher und schneller erfolgt. Begründung Lösungen, die unter Berücksichtigung von Testaspekten entwickelt werden, ermöglichen ein schnelleres Feedback und können letztendlich häufiger und sicherer an die Kunden weitergegeben werden. Eine testorientierte Entwicklung führt automatisch zu einer besseren Verständlichkeit und Evolvierbarkeit.
50. Beispiel Architekturprinzip 2/2 50 Auswirkungen • Strukturiere deinen Code so, dass die Komponenten isoliert ausgeführt werden können, um ihr Verhalten bei der Überprüfung und beim Testen zu beobachten. • Stelle sicher, dass die Komponenten eines Systems in klar definierte Verantwortlichkeiten aufgeteilt sind. • Die Komponenten eines Systems sollten leicht zu verstehen sein, d.h. der Code sollte so geschrieben sein, dass er sich selbst erklärt und durch seine Tests oder, falls nötig, durch eine separate Dokumentation dokumentiert wird. Weitere Informationen • Testability blog post von Michael Bolton. • Team Guide to Software Testability von Ash Winter and Rob Meaney. Übersetzt in Auszügen übernommen von https://engineering-principles.jlp.engineering/
51. Architecture Decision Record (ADR) 51 Entwurfsentscheidungen nachvollziehbar dokumentieren • Titel: Um welche Entscheidung geht es? • Kontext: Was waren die Rahmenbedingungen? • Entscheidung: Was war die Entscheidung, was waren die Alternativen? • Status: Wie steht es um das ADR? • hier auch abgelehnte oder überholte ADRs aufführen • Konsequenzen: Mit welchen Vor- und Nachteilen wollen wir jetzt leben? Beispiele unter https://github.com/arachne-framework/architecture
52. Beispiel Monzo (Bank aus UK) 52 Shared Core Library Layer Aus dem Vortrag ”Modern Banking in 1500 1600 Microservices” https://www.infoq.com/presentations/monzo-microservices/ Hart standardisiert Macht, was ihr wollt
53. Beispiel Monzo (Bank aus UK) 53 Engineering Principles 1. Ship it and iterate. 2. Make changes small, make them often. 3. Technical debt is a useful tool. 4. Solve problems at the root. 5. Do not accept deviant system behaviour. 6. Write code to be read. 7. Write code to be debugged. 8. If you can’t show it’s a bottleneck, don’t optimise it. 9. Unblock others whenever you can. 10. Leave the codebase better than you found it. https://monzo.com/blog/2018/06/29/engineering-principles
54. Tipps 54 • Fäden ziehen: Was wollen wir erreichen? Warum? • Konkret beschreiben / kein Blabla • Lokale Entscheidungen/ Best Practices kommunizieren • Austauschformate einsetzen (CoP) • Spezialistinnen und Spezialisten benennen als Ansprechpartner Multi Level eher dezentral CoP: Community of Practice
55. Individuelle Standards mit definierten Schnittstellen 55 API Mandate dezentral + richtiges Werkzeug für den Job + Geschäftseinheit hat Kontrolle + Synergien zwischen Einheiten + bessere Zufriedenheit - braucht Zeit für Auswahl - höchste Kosten - schwerste Kostenkontrolle Unternehmen Geschäfts- einheit Individueller Standard Geschäfts- einheit Individueller Standard Geschäfts- einheit Individueller Standard Geschäfts- einheit Individueller Standard Schnittstellen- standard
56. 56 API Mandate dezentral
57. 57 “With great power comes great responsibility” Aus dem Vortrag “From Gates to Guardrails - Alternate Approaches to Product Security” von Jason Chan https://www.youtube.com/watch?v=geumLjxtc54
58. Was bedeutet das für uns? 58 Daumenschrauben lassen sich auch so anziehen, so dass man sie gar nicht bemerkt.
59. 59 6 Tipps zur Gestaltung einer angenehmen Architektur-Governance
60. Moderne Governance-Meta-Prinzipien 60 1. Weg vom Gesetz, hin zu Vision und Prinzipien (und Leitplanken) 2. Compliance automatisieren und delegieren 3. Gatekeeper zu Mitarbeitende machen 4. Gepflasterte Straßen bereitstellen 5. Informationen offen teilen / Kommunikationsmuster überdenken 6. An Evolution gewöhnen Quelle: https://www.thoughtworks.com/insights/articles/lightweight-technology-governance
61. 61 Beispiel Compliance automatisieren und delegieren
62. Schlaue Architekturdokumentation 62 https://github.com/st-tu-dresden/salespoint Direkt aus dem Code erzeugte Doku
63. Schlaue Architekturdokumentation 63
64. 64 Schlaue Architekturdokumentation
65. ArchUnit – Left Shifting Governance 65 Eine entwicklungsnahe Variante von Architektur-Governance Erstellung von Architekturregeln mittels eigener domänenspezifischer Sprache (DSL) Prüfung von Entwurfsregeln zur Testzeit Mehr Informationen unter https://www.archunit.org/ public class MyArchitectureTest { @Test public void some_architecture_rule() { JavaClasses importedClasses = new ClassFileImporter().importPackages("com.myapp"); ArchRule rule = classes()...; } }
66. ArchUnit Code-/API-Beispiel 66
67. 67 Fazit
68. Was bedeutet das für uns? 68 Geschicktes Daumenschrauben muss nicht nerven!
69. Bildnachweise 69 • Bitmap-Grafiken wurden mit OpenAI GPT 4o (March 25, 2025 Release) erzeugt • Vektorgrafiken kommen von Streamline
70. 70 Danke! Fragen? Diskussion!
71. KLIENTEN Finance • Telko • Logistik • E-Commerce • Fortune 500 • KMUs • Startups FAKTEN ~160 Mitarbeitende 1998 gegründet 9 Standorte in D & CH UNSER ANGEBOT Produktkonzeption & Design Software-Entwicklung & -Architektur Technologie-Beratung Infrastruktur & Betrieb Wissenstransfer, Coaching & Trainings FOKUS Webapplikationen SaaS IoT Produktentwicklung ML/AI Blockchain TECHNOLOGIEN (Auswahl) Java/Spring Ruby/Rails Scala AWS Kubernetes Azure JavaScript Python C# ML/AI Blockchain 71 71