Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


In Search of Agile Architecture

As you know, the Agile movement was formulated as a response to the perceived need for an approach to software development that could easily accommodate change. It was presented as an improvement to the so-called waterfall model, which was predicated on an extensive design cycle that defined fairly unchanging requirements and designs. Because of this, waterfall models tended to deliver software that was out of sync with the user's needs due to the evolution of the latter during the development cycle.

At its inception, the Agile movement was not about techniques, but about principles. However, extreme programming (XP) was one of the most established set of Agile practices at the time and so it provided the body of practices with which Agile came into incarnation. For many years, XP practices and Agile approaches shared a great deal of overlap. Later they would become more differentiated, but early on they were essentially the same.

XP, as the P implies, is focused on low-level work. It consists of 12 practices, seven of which are exclusively about coding-related work: pair programming, test-driven development (TDD), refactoring, small releases, coding standards, collective code ownership, and system metaphor. The remaining five practices barely hover above this level: planning game (weekly iteration planning), whole team, continuous integration (building the code trunk repeatedly), simple design, and sustainable pace. This makes XP a great solution if only your coding or implementation pipeline need remediation. But experience tells me that sites with faulty downstream processes often suffer from problems further up the line than what can be addressed by practices such as TDD and CI.

For these challenges, you need to go to a different branch of Agility — the one that focuses on process, design, and team interaction. This higher branch comprises lean development, kanban, and to some extent, scrum. (Scrum is sort of a hybrid, it can be viewed as high level or low level; while lean development is a true systematic attempt to bring Agility to the larger processes where development teams first become tangled up.) Lean development derives from a just-in-time manufacturing approach, and it was adapted to software development in the classic Lean Software Development by Mary and Tom Poppendieck. It relies on seven precepts, not one of which deals directly with code, although being true guiding principles, they can be applied to coding.

While this higher level is undeniably agile, the term "Agile" refers largely to the coding practices that are low-level and stay down at the bits and bytes. The best summary of them, in my opinion, is Robert Martin's Agile Software Development from 2003.

The book perfectly illustrates the "in the small" aspect of Agile development. The subtitle is "principles, patterns, and practices," but the book is mostly filled with diagrams and code. The Poppendiecks' book, in contrast, does not contain a single line of code. 

The problem caused by these two divergent paths is that there are key issues that fall through the gap between them. I am talking about a level that should ride between lean development and Agile coding: architecture and design. "Agile design" are two words you rarely see together. Even more rarely read is: "Agile architecture." Go to the proceedings of almost any Agile conference and you'll be hard-pressed to find a single session with architecture in its title. Yet, as Mary Poppendieck affirms: "[project] architecture must support incremental development." How is this architecture developed? It's not easy to know. The Poppendiecks' book has no entry for architecture in its index. And Martin's 500-page work has a short 10-page section in an appendix, most of it dedicated to explaining UML notation. Clearly, architecture is a significant omission of the Agile approach.

Many enterprises don't buy into the entire Agile prescription. Despite my high esteem for Agility, there is a certain prudence to this restraint. Even after these many years, Agile still has gaps. It does not account sufficiently for architecture and only minimally understands design — two practices crucial to enterprises. Because of these unaddressed needs, enterprises are better off weaving Agile practices with other familiar methodologies and finding a blend that works for them rather than transforming their processes to adopt an approach that, while commendably good at many tasks, remains distressingly incomplete. 

— Andrew Binstock
Editor in Chief
[email protected]
Twitter: platypusguy

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.