What Agile Architecture and Hurricanes have in Common

Posted by Michael Stal on May 20, 2011

Sections

Process & Practices,

Architecture & Design

Topics

Continuous Delivery ,

Continuous Integration ,

Agile Techniques ,

Continuous Improvement ,

Software Craftsmanship ,

Software Engineering ,

Architecture ,

Design ,

Agile ,

Craftsmanship

Share |

RELATED Research

In a recent presentation at SATURN 2011 Eric Richardson has drawn some analogies between architects in an agile environment and hurricane meteorologists. For example, both produce various forecasts respectively documents, use many kinds of data sources as inputs, and employ different techniques to acquire data. According to the author, there are only few agile architecture practices available. And the practices differ drastically from those of traditional architecture. Nonetheless, there exist some reliable methods for defining an agile architecture plan as well as dealing with preparation and update.

Richardson is an architect for editorial systems at CAS, a division of the American Chemical Society where chemists analyze and index scientific information to ensure their databases are authorative, and IT specialists create software to support delivery of these databases as well as products to search them.

He introduces the analogy between meterology and architecture, because both are similarly complex, but meterologists have dealt with uncertainty far longer. In addition, parts of both systems interact in surprising ways, so that precice predictions are almost impossible. At first view, the principles of agile development and software architecture seem to contradict each other, according to Richardson. That's why there might be some tensions between agile practioners and architects. However, Big Design Up Front leads to the wrong direction as does No Design Up Front.

To address this challenge, he proposes to introduce an architecture in the beginning but treat it as a forecast which will inevitably turns out to be wrong in the long term, but should at least be accurate for the near term. Thus, agile architects are responsible to assess and change their forecasts. The agile architecture has to be mutable in order to achieve desired goals so that changes will be inevitable whenever the forecasts become inaccurate. As technology evolution has proven, there is some uncertainty in evolving architectures which can only be addressed by architects who accumulate experience. 

To deal with change, architects need to create a projected path where they decide about changes and the order of these changes. These changes are supposed to bring architects closer to the target, but being a little wrong is OK, as Richardson emphasizes. Projected paths deal with evolution, are flexible, address the risk of revolutionary change, and serve as a hedge against surprises.

In this context, architects need help. They should know what is being implemented to check the feasibility of their plans. Occasionally they should dive into code, given they are able and willing. Getting help from others can be more effective than do-it-yourself.

Agile architects are in charge of identifying and recruiting a team of hurricane hunters. For example, people best suited should do the jobs. Another responsibility is to build a decision network of weather stations, i.e. a network with development, sales, and marketing. And last-but-not-least, they should monitor and adjust to recover from wrong decisions early, and get the buy-in of otrher stakeholders for major architectural decisions.

The presentation gives a very refreshing and entertaining insight into the commonalities between agile architectures and metereology. Hence, looking at the detailed presentation is highly recommended.

RelatedVendorContent

Five Key Practices to Agile ALM

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Agile Maturity Model Applied to Building and Releasing Software

Agile assessments for your team

Agile workshops and training

Related Sponsor

Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.

1. Back to top

   Isn't this what JEDI is all about?

   by Nathan Gloyn

   Surely what Eric is talking about is the practice of Just Enough Design Initially which has been an agile practice for a while now and intends to bridge the gap between BDUF and No design. More details here

   Reply