Jaa

Iterative... agile... architecture

  • Artikkeli

A salesman walks into a bar near Microsoft. He sees that there is no where to sit, but he's dying for a drink. After waiting a few minutes patiently for a barstool to become available, he loses his patience.  

So he climbs up on top of the bar and announces that he's a salesman, and he's got a great idea for a software system, and it can be written in a week by any programmer with a brain.

The bar clears out.

The fact is that we've all been victims of a WAMI, (Wild-A**ed Marketing Idea).  Some of us more than others.  It's not that these ideas are bad.  In fact, they are usually quite good.  It's that they usually come with a wildly unreasonable expectation of how "easy" it will be to bring them to life.

And there's the rub.  In the initial impression and early agreements made on a project, dealing with expectations of cost and capability, a lot of architectural assumptions are made, and then estimates are based on those assumptions.

But if you don't write them down, how will those assumptions be reviewed?  How meaningful are they?  How can they be challenged, or validated, or even reused? 

One idea that I heard lately goes like this:  when a business leader describes a problem and proposes a solution, to internal IT groups, the group should NOT respond with an estimate.  They should respond with a high-level architecture, complete with assumptions and potential tradeoff decisions for the business leader to validate.  (a couple of pages of diagrams, and a single page of assumptions and tradeoffs).

Once he or she says "yes" to those constraints, then (and only then), provide an estimate.

This way, the architecture starts as soon as the idea does.  For those folks who work in the Waterfall model, the architecture exists (at a vague level) before the requirements document is completed.  At each stage, the architecture is updated to reflect things that were not known before.

For those folks working in agile projects, you don't have Big Design Up Front, but you don't have Zero Design Up Front either.  You have something small, something light, and hopefully, something that directly emits code or tests along with those diagrams.

Point is that the initial architecture doesn't have to be 'right' but it can form the basis for understanding the system, its assumptions and constraints.  It is updated with each sprint, or reworked with each phase or whatever your SDLC process calls an 'iteration.' 

At least then, hopefully, an IT team gets away from the notion of "t-shirt size project estimation" and towards the notion of transparent assumptions, managed expectations, and realistic costs.

Comments

  • Anonymous
    November 17, 2006
    funny thing happened today almost subconsciously while discussing development requirements today [we're an agile team]:: business is talking away and while they're talking- i'm sketching datamodels, interfaces, class relationships, use cases- so "i" can understand the problem [for now and later]- inadvertently half-architected the system upfront- and now i've gone away to estimate a solution. by which time, i'll have the rest of architecture figured out before i've written my first test :) [ and i still let the tests shape the design ] i find it's just a natural way to work without trying to force methodolgy, so what you're saying is spot on! nice post! :)

  • Anonymous
    November 18, 2006
    I have lots of stuff collected up today. Software Architecture/SOA Arnon Rotem-Gal-Oz has made available

  • Anonymous
    November 20, 2006
    ah lak away you tawk. It took me years to discover that I am an agile programmer, and the discovery was like discovering that I was a swan, not an ugly duckling. Experience tends to make agile programmers/architects of us all. The game of development is far from a fixed playing field, and anticipation of changing requirements, conditions, etc., tends to discipline one to adapt agile techniques, or live a life of frustration and anxiety. More or less constant feedback between dev team and management is key. But the real skill lies in the balance between planning, developing an intuitive anticipation of likely change points, and adapting to changes, while maintaining a reasonable set of goals, and working within time and budget constraints. It is not something that can be perfectly achieved, but can constantly be improved.

  • Anonymous
    November 25, 2006
    Nick, you make a good point. It is one of my favourite soap-boxes that most of current IT thinking is too preoccupied with the concept of satisfying requirements, when actually there almost always are key architecture implications and decision points that need to be described in terms they understand to the people with the 'requirements' before they can make an informed decision about what they actually want/need. Without this step in my experience you can't help but end up with non-ideal, or even non-viable solutions, no matter how precise you try and make the language in the hand-off. It really has to be a collaborative effort using people who are able to use the language and work with the culture of the other side. This isn't really 'agile' in the context IT use the term today, but there are similarities, and it certainly is a move away from the requirements-time equivalent of waterfall where things come over-the-wall to IT with no context and little opportunity to push-back constructively. I blogged about this a while back at <a href="http://sol1.blogspot.com/2006/05/what-can-agile-tell-us-about-how.html">">http://sol1.blogspot.com/2006/05/what-can-agile-tell-us-about-how.html">  http://sol1.blogspot.com/2006/05/what-can-agile-tell-us-about-how.html </a>. Regards, Sam.

  • Anonymous
    October 20, 2007
    I have lots of stuff collected up today. Software Architecture/SOA Arnon Rotem-Gal-Oz has made available