Agile 5 – What is agile architecture?
Copyright Graham Berrisford. One of several hundred papers at http://avancier.website. Last updated 03/07/2019 12:25
This is the fifth in a series of mostly short papers.
What architecture means is less clear.
For some software developers, the architecture of a system is found in the code itself.
It is the stable abstractions – classes, interfaces and data types – around which the code is written.
For enterprise and solution architects, architecture is higher level design-time description - rather than code.
It is an architecture definition, written in natural language or near to it, that communicates the intent of the architect.
Either way, if the architecture changes much or often, you’ve got a problem.
To use a metaphor: the architecture of a concrete building should allow for the fittings to be changed.
But to change the architecture might well mean discarding the fittings and re-building from scratch.
The term “Agile Architecture” is used with several meanings.
1. Intentional architecture
This is an up-front architecture drives the development of a system.
It may be revised iteratively and/or expand incrementally.
2 Emergent architecture
This architecture is documented after a system has been built or changed.
This turns the architect from a designer to a recorder.
Of course, this is contrary to the classical notion that an architect draws diagrams that builders follow.
Why do we need some up-front intentional architecture?
Somebody has to identify and prioritise the epics or use cases to be developed.
And before that, identify the roles and processes to be supported and enabled by those use cases.
And define the non-functional requirements and physical qualities that shape key system design decisions.
Also, agilists recommend stabilising the “infrastructure” in advance of software development, including platform technologies and any persistent data structure that must be populated and maintained.
Methods with a mix of 1 intentional + 2 emergent architecture
The architecture is documentation of:
· features (small, client-valued functions)
· domain objects (high-level class diagram and supporting artifacts).
The architecture is a Solution Outline which may identify:
· roles and processes to be supported and enabled
· key use cases
· major components of the solution (and their interfaces).
Surely, an architect must describe a system's structure and behaviour at a level of abstraction that is as stable as possible?
If that abstract architecture is continually changing, doesn’t that undermine the notion of architecture?
3 Lean (high-level, light) architecture
This need not be changed because it is so abstract.
The trouble is, the more abstract it is, the less helpful it is (which is why EA needs solution architects.)
“While we must acknowledge emergence in design and system development, a little planning can avoid much waste.” James O. Coplien.
“Lean architecture comes from applying the principles of the Toyota Production System to software architecture.
Lean architecture is both about an architecture with no fat, and about the consistency and reduction of waste in the process surrounding its creation and use.”
Read this article for more http://leanmagazine.net/lean/lean-architecture/.
4 The architecture of an agile system
This need not be changed because it defines a flexible or configurable system.
The difficulty: the complexity/flexibility trade off.
E.g design patterns for extreme scalability tend to increase complexity - contrary to KISS & YAGNI
Agile system principle
Agile development principle
Keep the system simple (KISS)
Design for future flexibility
You ain’t gonna need it (YAGNI)
5 Architecture that facilitates agile development
Scaling up from one team to a wider organisation.
In recent years, a primary concern of “agile architecture”.
Principles to scale up agile development
· modularise the architecture into subsystems, assignable to (relatively) autonomous development teams.
· decouple subsystems, so teams can work (relatively) autonomously
· release a “minimum viable product”, followed by short-cycle releases that extend the system’s capability
· use agile development methods and practices, such as SCRUM and Kanban.
All of this must be subordinate to the need to support and enable whatever roles and processes feature in the request for architecture work.
You’ll find more here – though more for large-scale solution/system architecture than EA?
DSDM for portfolio management http://www.agilebusiness.org
Scaled Agile Framework (SAFE) http://www.scaledagileframework.com
Supports building large integrated solutions that require hundreds of people to develop and maintain
People organisation: Squads, Tribes, Chains, Guilds.
Product organisation: Clients, Features, Infrastructure.