Today’s mainstream acceptance of Agile+DevOps as the preferred way of working once again raises questions of what architecture work is and who does it. It simultaneously challenges much of our previously accepted wisdom, preferring architecture to be a “shared commons” across the development organisation, while demanding a sophisticated level of software architecture practice to deliver on the promises of Agile+DevOps. One way of describing this situation is the need to “democratise” software architecture so it becomes a shared responsibility rather than a centralised impediment to rapid delivery. In this talk we’ll examine the challenges of software architecture in today’s modern distributed teams and ask how we might make the architecture of their systems a shared responsibility to allow them to achieve the software architecture that they need at the speed that they need it.

1. Democratising
Software Architecture
Eoin Woods
Endava
@eoinwoodz
ICSA 2019, Hamburg, March 2019
1

2. Eoin Woods
• Endava’s CTO, based in London
• 10+ years in product dev - Bull, Sybase, InterTrust
• 10 years in capital markets applications - UBS and BGI
• Software engineer, then architect, now CTO
• Software engineer in theory & practice (BSc, MSc, recently PhD)
• Author, editor, speaker, community guy

3. 3
DISCLAIMER
These are my views based on my experience
in the domains I have worked in.
Others may differ in their views !

4. EVOLVING SOFTWARE ARCHITECTURE
4

5. 5 ages of software Systems
Intelligent
Connected
(2020s)
Internet
is the System
(2010s)
Internet
Connected
(2000s)
Distributed
Monoliths
(1990s)
Monolithic
(1980s)

6. Architecture has changed too
Computing Era Architecture Concern
Monolithic Era => Structuring programs
Distributed Monoliths Era => Architecture emerges
Internet-Connected Era => Quality properties
Internet-is-the-System Era => Architecture at speed
Intelligent Connected Era => … ?

7. Historical Context
• Central small group
• Organisation of large pieces
• Relatively static connections
• Largely completed before
implementation
• Structures, qualities,
stakeholders, technology choices
7
https://donmaclennan.com/

8. What has changed?
8
FLUID
EVOLVING
ARCHITECTURE
DevOps
Microservices
Cloud
Agile

9. What is the problem?
9
? ?
!!
?
!!
!! ? !!

10. Our traditional model is of less value
• Constant evolution => less ”certainty” early in lifecycle
• Less decided early in lifecycle =>
less value in thorough ”up front” architecture
10
• Autonomous teams => independent activity
• Independent activity => constant parallel decision making
• Constant decisions => architect overload => blocks progress

11. Is architecture still needed?
11
• Difficult quality attributes
• Stakeholders don’t go away
• Still have tradeoffs
• Cross cutting concerns across
many independent elements
• BUT traditional ”structural”
focus may need to change
Cross-Cutting Concerns
Tradeoffs
Stakeholders
Quality
Attributes
Yes!

12. WHAT PRACTITIONERS DO
12

13. Software Architecture in Practice
• Empowered cross-functional teams
• Less “architects” more “engineers”
• Lightweight description – C4, ADRs
• Code Analysis – dependency visibility
• Runtime Analysis – dependency visibility, trends
• Informal description – Wiki, PowerPoint, Visio
• Modelling – occasional use of UML and Archimate
13

14. C4 Model
• Simon Brown’s accessible 4-view
model for software architecture
• Context
• Containers
• Component
• Code (class diagram - optional)
• Optional Landscape, Dynamic
and Deployment views
• Structurizr tool
• Widely recognized in industry
14
c4model.com

15. Architecture Decision Records
• Old idea “rediscovered” by
Michael Nygard in 2011
• Simple textual decision records
using templates
• Stored with the code
• Nygard’s form:
• Title, Status, Context, Decision &
Consequences
15
thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions
github.com/joelparkerhenderson/architecture_decision_record

16. Code Analysis
• Generally static code analysis
• Open source tools dominate
• SonarQube in particular
• “Code doesn’t lie”
• Main architectural aspect is
dependency analysis
16

17. Runtime Analysis
• Response to dynamic nature of
microservices
• Distributed monitoring & tracing
• Jaeger, Zipkin
• Prometheus + Grafana
• Log aggregation & analysis - ELK
• AppDynamics & NewRelic
• “Production is reality”
17

18. Visio, PowerPoint, Wiki, …
• Where most ADs end up
• Quality varies from useless to
very valuable
• Familiar & highly accessible
• Usually custom syntax and
semantics
• Interpretation, precision and
consistency often limited
18

19. Modelling: UML and Archimate
• Rare choice today
• Their genericity is a difficulty
• UML good base for a DSL … but
significant investment needed
• Archimate useful for EA but not
really solution or software arch
• Tools can get in the way
• Can actually be a
communication barrier
19

20. A NEW APPROACH
20

21. 21
Architecture is a skill not a role
Principles, styles & patterns over structures
Delegate & share wherever possible
”Little and often” (and adapt)
Aim for “shared commons”
Stream of decisions, not “one off” architecture
Architecture
Work in the
New World

22. 22
Architecture work in every sprint
Decisions, principles, styles, patterns
Deliver decisions as they are needed
Form an inclusive architecture group
Practical tests to validate architecture work
Keep the architecture ”close to the code”
Key
Practices

23. 23
RDCA
(Risk & Cost
Driven
Architecture)
Eltjo Poort, CGI
eltjopoort.nl

24. Architecturally Evident Code
• George Fairbanks
• Code reflects the architecture
• Names, structures line up
• Changes code packaging
• Can affect testing
• Often “messes up” architecture!
• Can be hard to check
• ArchUnit
24

25. Common Problems
• Sharing and managing architecture information (AKM)
• Lack of artefacts => misunderstanding, knowledge loss
• Understanding the system-wide view
• Resistance to any design work (“we’re agile”)
• Desire for a ”complete” architecture up front
• Enterprise architects (!)
25

26. FOR RESEARCH
26

27. Research vs Practice Disconnection
RESEARCH PRACTICE
Models and theories Technologies, patterns, code
Architecture as separate activity Architecture as dev activity
Completed architecture Just enough architecture
Solving idealised problems Focus on today’s delivery
Papers, academic conferences Github, blogs, conferences
Validation via small survey Validation by production operation27

28. Some Suggestions
WHILE PLANNING WHILE RESEARCHING
Link to industry projects Prioritise flow of change to
production
Understand practice through OSS Codify ideas in code, patterns,
templates
Watch industry event topics* Be sensitive to adoption effort vs
validation level
Attend industry events* Be aware of standard tools
Consider motivation & validation
28
* QCON, SATURN, DevTernity, JAX, NDC, …

29. TO CONCLUDE
29

30. Software development is changing:
so will software architecture
30
Agile + DevOps
change how we WORK
Cloud + Containers
change how we BUILD
Less “Upfront” Architecture
Quality Attributes, Tradeoffs, Stakeholders
Flow Of Decisions & Guidance
Changes to Architect’s Work
Changes to Architect Training

31. Architect: From Purveyor of Wisdom …
31

32. … to Trusted Leader and Advisor
32

33. Eoin Woods
Endava
eoin.woods@endava.com
@eoinwoodz 33
THANK YOU …