iSAQB Software Architecture Gathering – Digital 2023, November 2023 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 presents 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.

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