An emergent architecture is only half the story

I have heard many stories of architects supposedly working in agile environments that suggest these architects aren't maximising their agile potential. These stories often describe architects who believe that an evolving architecture is simply one that in which the emergent decisions are made in parallel with development;  they neglect continuously refactoring the architecture to ensure that the architecture always represents the best design for the product as it is understood at that time.

In my thesis I define an evolving architecture as:

"An evolving architecture consists of emergent decisions, in which the architecture emerges as architecture design decisions are made, and refactored decisions, in which previous architecture decisions (whether up-front or emergent) are changed." (page 41)

 Yes, it is difficult to refactor architecture – many definitions of architecture include the decisions that are hard to change (including my own) – but agile architects use a number of tactics to increase agility:

1. Keep designs simple 
2. Prove the design with code iteratively
3. Use good design practices
4. Delay decision making (aka "just enough anticipation")
5. Plan for options.

These tactics all make it easier to either continuously refactor the architecture or reduce the need to refactor (see my earlier post).

I wish to mention two important implications of an agile architecture here:

Firstly, agile development is all about delivering a value stream. The customer does not receive the whole product at once at the end of the project: the product is delivered in regular increments from as early as possible in development. This does not only let them deliver feedback to the team; it may also allow them to start using the product early and get income or value from it.  Even what the traditional software development lifecycle would call the maintenance phase is just another part of the value stream.

Consider: how would you design your architecture differently if you took into account what you know about the whole agile development cycle, including maintenance? If you knew that the product may change drastically over its lifetime in ways that cannot be imagined at the start? An agile architecture looks different from one that is not designed to evolve and be refactored.

For more on value streams, take a look at the "NoProjects" movement, such as Allen Kelly's recent "#NoProjects/#BeyondProjects" blog post and the related presentation. 

Secondly, note the term is value stream – not cost. Value to the customer may be at the expense of increased cost: that is, they may be prepared to suffer higher overall cost if it means more value in the form of earlier and/or more income.

Consider: would you be prepared to (and able to) continuously refactor the architecture, perhaps multiple times, as the product evolves, if it means delivering more value to the customer? In particular, this may mean initially designing a much reduced and simplified architecture that will be suitable for a much shorter period of time, but allows an initial release to be made  much sooner, and which will need to be refactored (perhaps completely) as the product matures.

See also Martin Fowler's recent blog post on Sacrificial Architecture.