Elaborating user stories: what about architecture?

Some people worry that in our rush to become more agile we might be leaving good architecture behind. So I often reassure with the following statement:

Don’t worry – There is no doubt that the system’s architecture will emerge from what we are doing. The only question is whether it will be the architecture we want.

This is rarely a reassuring thought for a team that is hurtling along with no time to contemplate and understand the complexity of what they are creating.

Recently, I have been sharing some of my thoughts on how to elaborate stories on agile projects and I guess this might bring up the question of architecture again.

I believe the approaches I discussed help to create a shared understanding of the holistic system (IT architecture, user experience, alignment to business goals and integration with business processes). I also believe that they can help to inform a discussion about whether the project team is creating or destroying business value.

The topic of how we know we are creating (or destroying) business value is something I am still pondering. So I would be happy to hear your views on this, and in turn I will be commenting further as my own thinking evolves.

But my views on good architecture comes have probably remained constant for a little while.  I believe good architecture in any system is created through a mixture of:

• Conversations among the entire team (including trainers, marketing people and others you may not think of as part of an IT team);
• One or more people (architects) who can conceptualise the solution beyond today and beyond the simple plugging together of the components; and
• Good craftsmen (developers) who know their own craft, really know how to build quality into their own components and realise that the overall solution is more important than achieving perfection in their patch.

Therefore my simple advise on architecture is get good craftsmen who know their stuff and someone whose craft is integrating the whole thing into one solution and ensure they have time to focus on integrating their work.

Thus my leading measures of successful architecture are:

• Do the developers want more time from the architects than they can get?
• Do the architects believe that the developers know more about their specialty than the architect does?
• Do the junior developers see their role as being key members of the design team?
• Are you being asked for clarification of business drivers, customer preferences or market segmentation and value when techos debate technical solutions?
• Do the team think that the time they spend debating technical options and design principles is real work?
• Can you get a straight answer to the question “what happens after we deploy this?”

But if you want a little more comfort around the integration of architecture with story elaboration, then you might ask how the approaches I have described in recent posts will generate a sound, holistic architecture on your agile project.

Sadly the answer is that they won’t.

In my defence I was focussed on how to better understand the stories your team works with rather than how to architect a good solution. Similarly in my defence, I do believe the approaches I discussed enable the discussion that will lead to good design and good architecture.

But the comments I have made do not really cover the discussion of business value or the creation of cohesive and sustainable architectures.

So if you want to strive for the architecture you want rather than the architecture that just happens to evolve from building, then you will need to spend time addressing this.

I have not found a lot of good links on that topic, but I did recently stumble on this one:

http://saturnnetwork.wordpress.com/2010/11/22/crosstalk-enabling-agility-through-architecture/

Hopefully that’s a start, though I do think there is room for a lot more discussion around architecture, user design, process integration and particularly the creation of business value on agile projects.