Agile 5 – What is agile architecture?

Avancier’s agile papers

This is the fifth in a series of mostly short papers.

1. On the beginnings of agile

2. On agile software development

3. On agile businesses and systems

4. On systems thinking ideas used in agile

5. What is agile architecture?

6. EA in the world of agile architecture

For a slide show that conveys some some of the above email me here.

What does agile architecture mean?

Agile means willing and able to speedily respond to change.

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.

“One of the more persistent myths of agile development is that up-front architecture and design are bad …” Bob Martin

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

In Ambler’s agile (software) modeling http ://agilemodeling.com/essays/fdd.htm.

The architecture is documentation of:

· features (small, client-valued functions)

· domain objects (high-level class diagram and supporting artifacts).

In Avancier Methods for solution architects http ://avancier.webssite

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
Decouple subsystems	contrary to	Keep the system simple (KISS)
Design for future flexibility	contrary to	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

Spotify-engineering-culture https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

People organisation: Squads, Tribes, Chains, Guilds.

Product organisation: Clients, Features, Infrastructure.

Further agile papers

1. Commentary on “Agile Architecture in the Digital Age”

2. Commentary on “SAFe”