Agility in its
various guises
This page is
published under the terms of the licence summarized in the footnote.
All free-to-read materials at http://avancier.website are paid for out of
income from Avancier’s training courses and methods licences.
If you find the web site helpful, please
spread the word and link to avancier.website in whichever social media you use.
This paper points out that agile development, agile operations, agile systems and agile architecture are different things.
At the extremes, agile development and agile systems are opposites.
Contents
There is a well-established body of knowledge about agile development.
It encourages small teams of skilled professionals to proceed by making small-scale incremental changes.
There is a resistance to top-down planning, command and control.
Principles include "you ain't gonna need it" and "do the minimum required".
The result is a system that does the minimum to implement currently-defined rules.
Subsequently,
incremental changes can turn that system into an unmodifiable
mess.
Continual refactoring is needed, as changes are made, to optimise the overall system design.
Without any overarching EA, agile development tends to produce silo systems that are not standardised or integrated.
People are naturally agile; businesses people often make and change business rules in an ad hoc way.
The more this is allowed or encouraged, the less there is by way of tractable "systems” for EA to work with.
However, digitisation of business operations constrains the ability of people to change systems.
And EA is concerned with these systems, which are under change control.
The notion of an agile system is not a simple or single idea, since a system can be flexible in at least four ways.
|
A system that is |
can |
yet might also be |
its architecture is likely to
be |
|
versatile |
do many different
things |
rigid and hard to change or extend. |
large or complex |
|
malleable |
be readily
changed to a new version |
limited and not
versatile |
slight or simple |
|
extendable |
be extended with
extra features |
not malleable (the Open-Closed principle
in OO design). |
fixed (must be
right first time) |
|
self-directing |
change its own
roles and rules |
reliant on human
ability, barely a system at all |
slight and simple |
Systems are not naturally agile; they have to be designed so.
Making a system flexible, with configurable rules, takes more time and money, and system performance is generally less efficient.
So architecting to
facilitate change imposes costs on the design process and the run-time
execution.
It also implies we can predict what kind of changes are to come.
Enterprise architecture is the meta system to business operations.
This grand-sounding term has no agreed meaning; three possible meanings are outlined below.
Guerrilla EA (aka
agile business operations
EA can be about making small steps towards the vision of digitised, standardised, integrated business processes and data.
“Guerrilla EA” does what it can, when and where it can, to these ends.
It may socialise solution architects into a group that cooperates by aligning solutions in the directions of standardisation and integration.
If Agile Architecture means that, then OK.
Agile architecture
documentation (aka evolutionary design)
Of course you can work iteratively and incrementally, develop your architectural documentation alongside your system.
Years ago, Scott Ambler called this Agile Model-Driven Development, but his guidance is for software development teams.
Today it is called evolutionary design, but is it design at all?
Isn’t it agile documentation rather than agile architecture?
Surely, an enterprise architect must describe a system's structure and behaviour at a level of abstraction that is as stable as possible?
If that highest-level architecture is continually changing, doesn’t that undermine the notion of architecture?
Architecting for a business
system to be agile
The notion of an agile system is not a simple or single
idea, since a system can be flexible in at least four ways.
Building flexibility into a non-human system can be difficult and costly, and make the system more complex.
So, agile system architecture is challenging for all these reasons.
Avancier’s papers on this topic propose some preconditions for agility in large systems:
- Optimal modularisation
- Will to sacrifice integrity temporarily
- Human resources dedicated to understanding a system’s configuration
- Ongoing effort to refactor and restore lost integrity.
Footnote: Creative Commons Attribution-No Derivative Works
Licence 2.0 07/01/2016
16:01
Attribution: You may copy, distribute and display this copyrighted
work only if you clearly credit “Avancier Limited: http://avancier.co.uk” before the start and include this
footnote at the end.
No Derivative Works: You may copy, distribute, display
only complete and verbatim copies of this page, not derivative works based
upon it.
For more information about the licence, see http://creativecommons.org