Philippe Kruchten’s keynote talk from the SATURN conference has been posted at the SEI. His slides are worth taking a look at: moderate in the agile architecture debate but full of real ideas, not just best hopes of compromise.
Thanks to my friend Alan Birchenough explaining the RUP to me, I was able to see how this presentation hinted at Kruchten’s ideas about risk and architecture (p 17 of the slides). In the RUP, a software project has four phases – not because you impose them, but because they almost always end up that way. The first phase is inception, where you are just trying to understand what the project is about. The second phase is elaboration, where you are deciding how to build it. The third phase is construction, where each iteration focuses on delivering new features. The fourth phase is transition, where the software is introduced into the end-users.
Kruchten points out that risks must be addressed early, in the inception and elaboration phases. When you hear architects worried about agile practices, you can usually decode what they are saying into “a pure feature-focus lets risks linger”. It may sound like this, “If you don’t design for security (or scalability, etc.) then when a user story asks for it, in the 20th iteration, you may find it difficult or impossible to add”. Kruchten quotes Tom Gilb, saying “If you do not actively attack the risks in your project, they will actively attack you”.
It’s easy to see how this kind of risk aversion can slide into Big Design Up Front. I was on a project where one of the designers decided that logging was a risk, so he’d best design the logging framework first. The way off of this slippery slope is to brainstorm then prioritize all your risks (this can be just a 10 minute activity). Some risks will “make the cut” while others will not. And it’s no substitute for good judgment, only a technique that informs your good judgment – so if you believe logging really will sink your project, brainstorming and prioritizing risks won’t change your mind.
The slides include his 4-color backlog idea, where user-visible features, bugs, technical debt, and hidden architectural features are all on the backlog. I like this idea a lot because it helps reveal dependencies, as in “we cannot build that user story until this architectural feature is in place (or this technical debt is removed)”.
subscribe via RSS