Iterative... agile... architecture

re: Iterative... agile... architecture

bryanallott — Fri, 17 Nov 2006 23:47:50 GMT

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! :)

New and Notable 126

Sam Gentile — Sat, 18 Nov 2006 17:12:33 GMT

I have lots of stuff collected up today. Software Architecture/SOA Arnon Rotem-Gal-Oz has made available

re: Iterative... agile... architecture

Uncle Chutney — Mon, 20 Nov 2006 17:29:09 GMT

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.

re: Iterative... agile... architecture

Sam Lowe — Sat, 25 Nov 2006 18:07:34 GMT

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.

New and Notable 126

Sam Gentile — Sat, 20 Oct 2007 22:32:10 GMT

I have lots of stuff collected up today. Software Architecture/SOA Arnon Rotem-Gal-Oz has made available