Twelve-Three-One: Getting There
This post is currently only a draft. Input on how to improve the structure is very welcome
“A journey of a thousand miles begins with a single step.” - Lao-Tzu
When doing architecture, we always have to content with the present state of the system. It is extremely tempting to ignore this picture of the ugly system and create your vision of how things should be in the future. It is also very easy to get people to agree on such a vision. But somehow, we never get there. Have you ever wondered why that is?
Most people are pretty good at making a plan for how things should be in the far future. But we’re not sufficiently prepared to make a plan about how things should be right now. This is what I mean when I say we suffer from too little myopia.
As a tool to get there, I have found the Twelve-Three-One paradigm useful: We have a goal for what we should achieve in twelve months, three months and one month. The twelve month perspective is our goal - for example to change from EJBs to POJOs, to consolidate four applications on one server, or to deliver our big project. When you’re planning, this can be extremely fuzzy without putting you at risk. The three month perspective shows the direction we’re going to get there, for example, exchanging your entity beans with Hibernate, or duplicating all applications to the target server and slowly moving all dependencies to it, or to put a limited part of our system into production. This can be vague, but should represent our current working hypothesis on how to get there. The one month perspective shows the next step. It should be as finely planned as you require to get anything done in our organization (for example: copy the foo.cfg file to server-1 and modify these settings).
The questions you ask for the different planning horizons are very different:
- One: Is this task absolutely required right now? Is the one-month goal a step in the right direction? How will we make sure it doesn’t break stuff?
- Three: Is our goal feasible (cost)? How will this step improve the lives of our stakeholders (benefit)?
- Twelve: Where do you want to end up? Why is this a good destination? What is of value to our stakeholders?
The two most important lesson I learned when I started thinking in terms of Twelve-Three-One is that the one-month goal is usually ignored, and secondly it doesn’t need to deliver value. We just need to make sure it’s a step in the right direction to deliver value. For a huge project, it is usually extremely hard to take small steps. When I realized that it’s okay to take a step that doesn’t provide value, as long as it is in the right direction, I started noticing more things that can be done right now. The three-month goal is extremely important because it ensures that the one-month goal is a step in the right direction. Especially if when I’m in a bad situation (and when am I not?) this is vital. If my system is barely hanging together with scotch-tape and shoestrings, making changes can be extremely costly and risky. But any single (one-month) change I make is likely to be more cost-effective on the current architecture (or lack thereof) than it will be to improve the architecture. By keeping the three-month and twelve-month goals in mind, chances are that I can avoid making my one-month goals hurt the architecture even more. The hard question is never “where do you want to go” (Twelve). Neither is it “how are we going to get there” (Three). The hard question is “what do we do right now” (One).
Comments:
Anders Norås - Mar 7, 2007
Interesting, it reminded me of one of my favorite quotes:
Would you tell me, please, which way I ought to go from here?’ - Alice speaks to Cheshire Cat `That depends a good deal on where you want to get to,’ said the Cat. `I don’t much care where–’ said Alice. `Then it doesn’t matter which way you go,’ said the Cat. `–so long as I get somewhere,’ Alice added as an explanation. `Oh, you’re sure to do that,’ said the Cat, `if you only walk long enough.'