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 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 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.


Agile system development 1

Agile business operations. 1

Agile business systems. 1

Agile architecture. 2


Agile system development

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.

Agile business operations

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.

Agile business systems

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


yet might also be

its architecture is likely to be


do many different things

rigid and hard to change or extend.

large or complex


be readily changed to a new version

limited and not versatile

slight or simple


be extended with extra features

not malleable (the Open-Closed principle in OO design).

fixed (must be right first time)


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.

Agile architecture

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:” 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