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

Vom Elfenbeinturm zur Agilen Architektur #Basel...

Vom Elfenbeinturm zur Agilen Architektur #BaselOne23

Architektur für agile Projekte muss anders definiert, beschrieben und kontinuierlich weiter entwickelt werden. Nicht alle Entscheidungen werden auf einmal getroffen, noch werden sie alle getroffen, wenn das Projekt beginnt. Dieser Vortrag beschreibt verschiedene Methoden, Tools und Team Topologien die auch in großen agilen Projekten erfolgreich angewendet werden können um Architektur Erosion und Wildwuchs entgegen zu wirken. #qaware #BaselOne23

M.-Leander Reimer

October 19, 2023
Tweet

More Decks by M.-Leander Reimer

Other Decks in Programming

Transcript

  1. Holistic Software Product Quality is a lot of work! QAware

    | 11 Software Product Quality (ISO 25010) • Modularity • Reusability • Analysability • Modifiability • Testability Maintainability • Confidentiality • Integrity • Non-repudiation • Authenticity • Accountability Security • Adaptability • Installability • Replaceability Portability • Co-existence • Interoperability Compatibility • Maturity • Availability • Fault Tolerance • Recoverability Reliability • Time Behaviour • Resource Utilization • Capacity Efficiency • Completeness • Correctness • Appropriateness Functional Suitability • Operability • Learnability • UI Aesthetics • Accessibility Usability Safety Deployability
  2. The Anatomy of an Architecture Decision Records (ADR) QAware |

    19 # Title ## Context ## Decision ## Status ## Consequences ▪ Short text file; 1-2 pages long, one file per decision ▪ Simple format like Markdown, Asciidoc, TXT, etc. Short noun phrase and number, e.g. ADR 5: AWS as preferred cloud provider Proposed, Accepted, Deprecated, Superseded Describes the forces at play: technology, political, project local. Value neutral, simple facts. Response to the forces with justification. Stated in full sentences, with active voice. "We will …" Describe context, after applying the decision. All consequences should be listed here, not just the "positive" ones.
  3. The Last Possible Moment != The Last Responsible Moment QAware

    | 20 ▪ Welche Fragen sind für verantwortungsvolle Entscheidungen relevant? – Muss ich die Entscheidung jetzt treffen? – Kann ich es noch aufschieben? – Was passiert, wenn ich es nicht mache? – Wann wird die Komplexität zu hoch? – Welche Alternativen gibt es? – Was sind die Trade-Offs der Entscheidung? – Kann die Entscheidung rückgängig gemacht werden? ▪ The Last Responsible Moment ist die bessere Wahl! ▪ Keine Angst vor suboptimalen Entscheidungen. ▪ Iterative Entwicklung, Tests, Refactoring, Continuous Integration und Architecture Fitness Functions helfen das Risiko beherrschbar zu machen
  4. Architecture Fitness Functions validieren die geforderten (nicht)-funktionalen System-Eigenschaften kontinuierlich. 21

    https://www.thoughtworks.com/de/radar/techniques/architectural-fitness-function
  5. Fitness-function Driven Development QAware | 22 ▪ Architektur ist wie

    ein Produkt mit User Journeys ▪ Anforderungen werden von den Stakeholdern eingesammelt – Business – Compliance – Operations – Security – Infrastructure ▪ Das sind häufig unsere „-illities“ und Qualitätsmerkmale ▪ Die Akzeptanz-Kriterien werden mit einem BDD Test Framework formuliert. ▪ Tests werden als Teil der CI/CD Pipeline ausgeführt, und anschließend verifiziert https://www.thoughtworks.com/de/insights/articles/fitness-function-driven-development
  6. Beispiel: Security 25 describe "Security" do describe “Static Analysis” do

    it "should not have plaintext secrets in codebase" do expect(code.has_secrets_in_codebase()).to_not be(true) end end describe “Dynamic Analysis” do it "should not have any of the OWASP Top 10" do expect(zap.has_owasp_top_10_vulnerabilities()).to be(false) end end end
  7. Menschen machen Fehler. Von der Clean Architecture zum Big Ball

    of Mud geht’s schneller, als man glaubt! QAware | 28
  8. ArchUnit ermöglicht die einfache automatisierte Prüfung einer Software-Architektur in Form

    von Unit Tests. ▪ https://www.archunit.org/ ▪ Freie (Apache v2), einfache und erweiterbare Bibliothek zur Prüfung der Architektur von Java Code. Gibt es auch für .NET/C#. ▪ Alle gängigen Build Tools und Unit Test Frameworks werden unterstützt ▪ Das ArchUnit Library API bietet eine Sammlung an vordefinierten Regeln für wiederkehrende Architektur-Prüfungen – Architectures: Regeln zur Überprüfung von Layered und Onion Architectures – Slices: Erkennung von “Cycles” auf unterschiedlichen Ebenen – General: Sammlung von Regeln für Good Coding Practices (z.B: Logging, Exceptions, …) – PlantUML: Regeln zum Abgleich der Codebase mit einem PlantUML Modell – Freezing Arch Rules: Erlaubt die Definition einer Baseline für Violations, besonders nützlich um Technische Schulden in Altprojekten zu managen QAware | 29
  9. Nur wenige Zeilen Code validieren unsere Clean Architecture kontinuierlich und

    wiederholbar bei jedem Build. 30 @AnalyzeClasses(packages = {"de.qaware.archunit.example.onion"}) public class OnionArchitectureFitnessTest { @ArchTest static final ArchRule onion_architecture_is_respected = onionArchitecture() .domainModels("..domain.model..") .domainServices("..domain.service..") .applicationServices("..application..") .adapter("cli", "..adapter.cli..") .adapter("persistence", "..adapter.persistence..") .adapter("rest", "..adapter.rest.."); }
  10. aim42 ist super nützlich um technische Schulden regelmäßig und strukturiert

    zu begegnen und abzubauen. QAware | 32 https://www.aim42.org/
  11. “Too much cognitive load will become a bottleneck for fast

    flow and high productivity for many agile teams.” QAware | 33 ▪ Intrinsic Cognitive Load Relates to fundamental aspects and knowledge in the problem space (e.g. used languages, APIs, frameworks) ▪ Extraneous Cognitive Load Relates to the environment (e.g. console command, deployment, configuration) ▪ Germane Cognitive Load Relates to specific aspects of the business domain (aka. „value added“ thinking)
  12. Die Architekturarbeit kann und sollte auf verschiedenen Ebenen und verschiedenen

    Teams passieren. QAware | 34 https://martinfowler.com/bliki/TeamTopologies.html
  13. qaware.de QAware GmbH Aschauer Straße 32 81549 München Tel. +49

    89 232315-0 [email protected] twitter.com/qaware linkedin.com/company/qaware-gmbh xing.com/companies/qawaregmbh slideshare.net/qaware github.com/qaware