Down the Ivory Tower towards Agile Architecture #JCON23

Architecture for agile projects must be defined and described differently, as well as continuously developed and evolved. Not all decisions are made at once, nor are they all known right from the start of the project. This sessions describes various useful and lightweight methods, tools and team topologies that can be applied in (large) agile projects to avoid uncontrolled growth and architectural erosion but without acting from the ivory tower and thus suffocating team autonomy.

Transcript

1. qaware.de Down the Ivory Tower towards Agile Architecture Mario-Leander Reimer mario-leander.reimer@qaware.de @LeanderReimer
2. 2 Mario-Leander Reimer Managing Director | CTO @LeanderReimer #cloudnativenerd #qaware #gernperDude
4. 1st commandment Thou shalt not use other databases than Oracle!
6. 6 QAware
7. 7 QAware The Wild Agile West
8. QAware | 8 Architecture in Agile Projects
9. 1st commandment Thou shalt sprint 2 weeks, no less or more!
10. 10 QAware https://arc42.org/download arc42 based documentation addresses many important quality and architecture aspects.
11. 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
12. Q42. A simple and pragmatic quality modell. QAware | 12 https://quality.arc42.org/
13. The required quality attributes can be found on all layers of your software architecture. 13
14. 14 QAware Architecture Diagrams
15. Diagrams as Code using C4: Context. Container. Component. Code. 15 QAware
16. 16 Decisions
17. The Last Possible Moment != The Last Responsible Moment QAware | 17 ▪ The Last Responsible Moment what you should aim for! ▪ Useful questions for responsible decision making – Do we have to take the decision now? – Can we postpone the decision? – What are the consequences if we postpone? – When will the overall complexity become to high? – What are the alternatives? – What are the trade-offs of our decision? – Can we revert a decision? At which costs? ▪ Have no fear of suboptimal decisions! Be brave! ▪ Iterative development, TDD, refactorings, continuous integration and deployment, architecture fitness functions can help to address and reduce the risks involved
18. QAware | 18 https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
19. Architecture Decision Records (ADR) QAware | 19 https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records
20. The Anatomy of an Architecture Decision Record (ADR) QAware | 20 # 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.
21. Architecture fitness functions continuously validate the desired software quality attributes. 21 https://www.thoughtworks.com/de/radar/techniques/architectural-fitness-function
22. Fitness-function Driven Development QAware | 22 ▪ Architecture is like a product with user journeys ▪ Requirements are defined by all relevant stakeholders – Business – Compliance – Operations – Security – Infrastructure ▪ Often these are exactly the „-illities“ and quality attributes ▪ Acceptances criteria are the formulated using a BDD approach and framework ▪ Fitness tests are executed and validated as part of CI/CD pipelines (continuously or ad hoc) https://www.thoughtworks.com/de/insights/articles/fitness-function-driven-development
23. Example: Code Quality QAware | 23
24. Example: Performance QAware | 24
25. Example: 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
26. Example: Operability 26 QAware
27. 27 QAware +
28. Conceptual Architecture QAware | 28 Packages Package publish update Run deploy watch Deploy watch Dev GitOps Build push Checkout Build Test Quality Package Dev Test (E2E, NFA) trigger test Tests Quality Cockpit report PO report Build Status Code Quality Test Results fitness test promote ?
29. The path from a conceptually clean architecture towards the big ball of mud is shorter than you think! QAware | 29
30. ArchUnit enables easy, automated testing of your software architecture in the form of simple unit tests. ▪ https://www.archunit.org/ ▪ Apache v2 licensed. Simple and extensible open source library for software architecture validation as code: Java and .NET/C# are supported. ▪ All major build tools and unit test frameworks are support out-of-the-box. ▪ The library provides a collection of predefined rules for recurring architecture validations: – Styles: rules to validate common architectures (e.g. layered, onion, hexagon) – Slices: detect “cycles” on various layers (e.g. classes, packages, modules) – General: collection of rules for good coding practices (e.g. naming, logging, exceptions) – UML: rules to validate the codebase with a given PlantUML architecture model – Freezing: allows the definition of a violation baseline, especially useful to manage the technical debts of legacy projects QAware | 30
31. Just a few lines of code allow to validate your architecture continuously and repeatedly with every build. 31 @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.."); }
32. QAware | 32 Where wood is chopped, splinters must fall!
33. aim42 can be used to analyse and assess any technical debt and improve the software architecture in a structured way. QAware | 33 https://www.aim42.org/
34. “Too much cognitive load will become a bottleneck for fast flow and high productivity for many agile teams.” QAware | 34 ▪ 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)
35. Collaboration is key. Software architecture should be defined and work on at all teams and layers. QAware | 35 https://martinfowler.com/bliki/TeamTopologies.html Architecture
36. Beyond Agile Architecture. My personal book list for inspirations and new approaches. 36 QAware
37. qaware.de QAware GmbH Aschauer Straße 32 81549 München Tel. +49 89 232315-0 info@qaware.de twitter.com/qaware linkedin.com/company/qaware-gmbh xing.com/companies/qawaregmbh slideshare.net/qaware github.com/qaware