Why Agile Development Requires Agile Architecture

The dark cloud of the economic downturn has produced a silver lining within Microsoft IT: an increased emphasis on Agile development techniques.  This does not mean that MS IT is new to using Agile.  Far from it.  Agile development practices have been used in various IT groups here for nearly a decade. 

What is new is the desire to address the basic development and governance processes themselves to remove the “Bias towards Waterfall” that exists in many of them.  That bias can create a situation where someone can choose to be Agile or choose to comply with corporate policy.  That’s a devil’s choice. 

For example, we have a governance point that is used throughout all levels of the IT organization called “Baseline” where all design and specification (and estimation) is done, and signed off.  This is supposed to occur before software is delivered.  Does that favor waterfall?  You betcha.  This governance point is mentioned in one of the metrics all the way up to the CIO scorecard!  BDUF is built in to the DNA itself.

But if you look at the reasons that people give for requesting BDUF (Big Design Up Front), it goes like this: you can reduce risks by requiring that everyone understands and agrees with the requirements, features, scope, timelines, responsibilities, deployment model, etc…

Right.  Pigs fly.

I do see the intent, and it is honorable.  Reducing risk is a good thing and we want to increase the number of systems that are delivered on time and on budget with fewer defects.  But I think that Agile methods have proven that there is another way to accomplish the goal of “improved delivery.” Unfortunately, they do not fit into the same neat little box. 

Where waterfall requires 600 pages of documentation to be written up front, Agile requires that most of those pages are never written.  It is not correct that Agile methods produce design documents “as you go.”  That is nonsense.  Agile methods produce 10 pages of diagrams, and nearly no accompanying text. 

So is architecture a BDUF process? 

Some of it is.  If you follow the RM-ODP model or 4+1 views, you are going to be tempted to over-specify and over-architect.  After all, the 4+1 views present a mechanism for creating a “complete” model of a software system.  That’s great, if you want to create a complete model of a software system.  But why would you want one?  Why would it be a goal to have a complete description of a software system outside the software itself?  Would a “partial” description serve the needs more effectively?

BDUF architecture is rarely a good thing.

Agile architecture, however, is often a good thing.  Agile architecture is the act of producing enough architecture to meet the needs of the project, and nothing more, and producing it in a timely fashion, with a minimum of effort.  Agile architecture RARELY produces a detailed class model in advance. 

Agile architecture often produces a high-level component model and context model to establish the existence of components, their names, and perhaps even the division of responsibilities in the dev team itself.  (think: Scrum of Scrums).  Agile Architecture nearly never produces diagrams of technical things, like the structure of a message.  Dev tools do that, from the code itself.

Agile architects will produce models using a dev environment tool, like Visual Studio or Sparx Enterprise Architect, not a diagramming tool like Visio that cannot easily be connected with the code. 

Agile architects will use diagrams to communicate between people and to express artifacts into code where developers have real freedom to make the magic happen.

Agile architects will not only leverage patterns, but also complete reference models.  They will consume a well-built reference model, inject the components that will be developed for the application, and get the team off on the right start.  They will not “craft a new architecture” for every need, but will build-from-pre-existing-designs 80-90% of the time using frameworks that produce maintainable, secure, reliable, and easily deployed systems.

Failure to architect a system is a failure to deliver.  On the other hand, hand-crafting every system is also a failure to deliver.  The difference between the two, and the middle-way that defines success, is agile architecture.