Agile 5 – What is agile architecture?
Copyright Graham Berrisford. One of several hundred papers at http://avancier.website. Last updated 04/04/2019 17:28
This is the fifth in a series of mostly short papers.
Agile means willing and able to speedily respond to change.
What architecture means is less clear.
For some software architects, the architecture of a software system is its basic structure - in the code.
It is the stable abstractions people writing the code depend on.
The abstractions include a domain-specific vocabulary, starting with the names of data types.
Along with some stable compositions, interfaces and generalisations.
For enterprise and solution architects, architecture is higher level design-time description - rather than code.
It is some kind of architecture definition documentation.
It is usually intentional (an output of up-front planning) but can instead be emergent (reverse-engineered from code).
It is written in natural language – or near to it - and communicates the intent of the code.
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 that might be more clearly called something else.
1 Intentional (up front) architecture that is revised in response to changing requirements
Architecture frameworks like TOGAF presume this will be the case.
It isn’t a common meaning of “agile architecture”.
2 Intentional (up front) architecture that expands incrementally to drive incremental software development
An architecture framework like TOGAF can be used in this way.
It isn’t a common meaning of “agile architecture”.
3 Emergent (post hoc) architecture
Software development teams contain bright people who can do more than programming and testing.
In the agile development world, they do analysis and project/product management.
In the dev/ops world, they deploy applications into the production environment, and manage that.
In the agile architecture world, architecture is said to “emerge” from modularisation of the software system.
An emergent architecture reflects modularisation decisions made in software development, and is documented afterwards.
Some say architectures best emerge from this way, from incremental development, with no up-front architecture or architect.
This means architectural documentation is reverse-engineered from an emergent design, and maintained in step with software development.
Of course this is contrary to the classical notion that an architect draws diagrams that builders follow.
“One of the more persistent myths of agile development is that up-front architecture and design are bad …” Bob Martin
4 High-level (light or lean) architecture
Some say up-front architecture effort should be minimal.
The architecture should be so abstract that (in effect) many design decisions are delegated to software developers.
“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/.
5 Architecture that enables scaling up systems
This means scaling up to very high throughput, e.g. by enabling parallel processing
Some promote design patterns used by the internet giants in extreme scale systems.
Note here that those design patterns have downsides.
6 Architecture that facilitates scaling up agile development from a team to the wider system or enterprise.
This means a particular (relatively stable) high level design that facilitates agile software development.
It typically assumes
· modularising the architecture into subsystems assignable to (relatively) autonomous development teams.
· decoupling subsystems so teams can work (relatively) autonomously
· using design patterns used also in extreme scale systems (5 above)
· releasing a “minimum viable product” followed by short-cycle releases that extend the system’s capability
· using agile development methods and practices such as SCRUM and Kanban.
7 The architecture of an agile (flexible or configurable) system
Some assume the architecture that emerges from incremental software design will of an agile system.
However, thus runs counter to the agilist’s exhortation to produce “the simplest system that can possibly work”
Agile development does not necessarily produce an agile system.
Because there is a trade off between design for simplicity and design for flexibility.
Authors often mean 6 above, a particular architecture that facilitates agile software development.
This may mean mandating loose coupling as a principle, and design patterns used in extreme scale systems (5 above).
Authors tend to deprecate what they see as current EA practices.
There is indeed some EA bad practice out there; so what is good EA?
See the next paper in the series