On technology roadmaps

A carpenter is not usually aware of the hammer in their hand.   They are immersed in their environment.  They are engaged in the task at hand.   They only notice the hammer if it is too heavy, or if the head flies off, or if the handle is awkward in their hand.

When a tool is right for a job, the tool disappears from the user’s active experience.

Our goal in IT is to equip our business users with disappearing tools.

Our goal as IT architects is to anticipate the needs of the business accurately, and with enough lead time, so that we can buy – or build – and integrate tools into the business work experience…so those tools, too, can disappear.

This is the very definition of ‘aligned.’

A technology roadmap is the enterprise architect’s forecast of the information tools needed at certain times in order to support the business’s anticipated tasks.

Today’s rumination is about how to make such a roadmap.

I am a chess player.  Somewhere in the family store of dusty stuff there may still be the trophy I won for finishing second in the Indiana Junior (under 18) Chess Championship in 1977 (I think it was ‘77.)  Which I mostly only say to give some weight to what follows.  (And for what it’s worth I should have finished worse…in the five round Swiss system tournament I drew my fourth round game from a won position – connected passed pawns – and so did not have to play The Prodigy in the final round.   So I won my last round game, and instead of finishing 4-1 – The Prodigy would have eaten my lunch – I finished 4 1/2 – 1/2, good for second.  If I had known the outcome in advance I might have thrown the fourth round win to get the draw I ended up with.  I was saved from the moral quandry by ignorance of the overall picture.  And fwiw the memory of drawing with connected passers grates more than not winning.)

Aaaaanyway, one of the best chess instruction books ever is Jeremy Silman’s ‘How to Reassess Your Chess.’  In it, the International Master (the best teachers are not the best players – Silman is not a Grandmaster) outlines the Silman Thinking Technique.

Paraphrasing broadly, here ’tis. In your mind’s eye, take all of the remaining pieces off the board, leaving only the pawns.  Now arbitrarily place your pieces anywhere you want.  Can you find a way of placing your pieces that gives you a marked advantage?  Can you create a checkmate?  Can you create a preponderance of force against a key point?  Understanding the optimal placement requires not only an understanding of the rules of the game, it also requires an understanding of tactical patterns.   Is there a last rank mate by a rook?  A windmill?  A discovered check?

Having placed your pieces in an optimal configuration, you then need to figure out if you can achieve it…how long will it take to you get there from where you are at now?  And remember, your opponent will be working against you all the while.

Finally, given the constraints in your position – the slow to change pawn structure – and given your opponent’s best efforts to foil your plan, can you achieve your objective?  If so, rock on.  If not, go back to the beginning and make a less ambitious objective.

So what is your best plan?  And given that, what is the best first move to effect that plan?

Roadmapping is like that.

Keeping our chess analogy in mind, let’s look at roadmaps.

Remember we have said that a technology roadmap is the enterprise architect’s forecast of the information tools needed at certain times in order to support the business’s (an awkward possessive)’s anticipated tasks.

The business’s anticipated tasks obviously must be inferred from their goals and objectives.  Not so obvious, perhaps, is that they must also be inferred from the career expertise of the business users and from their training plans.  The tool an expert finds ready-to-hand and that of a beginner are not the same tool.  Tiger Woods plays with forged irons which permit precise control, but are not forgiving of error.  The amateur on the other hand plays with cavity back irons which assume off center hits, and minimize their impact.

So this is where our roadmap starts. We must work with the business to capture their goals and objectives.  There may be more or less work to do in this regard depending on the maturity of the business’s planning approach.  And we must work with the business to understand the nature of their expertise, their professional development plans, and their future expectations with respect to their tools.

From their goals and objectives we synthesize a picture of the business enterprise at some future date.  Providing the tools to support the business processes in that picture is our objective.  The full picture, including the tools, is where our roadmap leads.

We must pick a waypoint far enough in the future to make it possible for us to steer our ship toward that star.   Turning a supertanker involves holding the tiller hard over..and waiting, and waiting, and waiting for the ship to turn.  Turning an enterprise is even harder.  Project plans, with rare exception, will only take us out a year or eighteen months.   To make informed decisions about which projects to approve as aligned we need to go further out on the timeline.

If we get too far out, on the other hand, we obviously lose the ability to describe the expected future environment with any degree of accuracy.  In 1999 there was no MySpace, no Facebook, no Twitter.   But in 2004 all existed in some nascent form and a wise and careful observer might have projected their success with some confidence.

For the same reasons, existing corporate strategic plans are likely articulated over five years, or sometimes three years in rapidly changing industries.

So our first task is to take the business’s strategic plan (or if needed to help the business to create that plan), turn it into a to-be process picture, and figure out what the technology picture needs to be at that time to support those processes.

High level business use cases suggest themselves for the to-be process picture, following the familiar goal-driven approach espoused by Alastair Cook.  Which naturally leads us to describing our tools in the form of the ‘4′ in Phillipe Krutchen’s 4+1 architecture approach, where the ‘1′ is the use cases.

Having done so (ok, some handwaving here), we are ready to turn out attention to the roadmap.

We are not starting with a blank slate.  Not only do we have an existing IT infrastructure that represents our starting point, there are a number of constraints of which we must be cognizant and to which our roadmap, and our destination, must conform.

Nothing in the corporate existing or ‘as-is’ environment is fixed.  All is malleable.

But the cost and impact of changing a given feature varies.

Those things that are slower to change, and less likely to be changed, act as constraints on our changing other, more malleable features which are dependent on them.

Many of these are features that are managed in lifecycles, where there are changes punctuated with some rhythm or frequency:

• Hardware->Depreciation.  Lease terms.  End of life of support.
• Software->Licensing. Compatibility. End of life of support.
• Contracts->Terms and conditions
• Laws->Elections.

And of course Trends, Buzz, Fashions…those things with mind share in our decision makers.

We should model our constraints in terms of their speed of change, and the punctuation of their change, in order to determine…their contribution to the viscosity of our environment, and their projected influence at a given waypoint.  This approach to constraints should be part of the requirements assessment on every project.

In reality, of course, there is a continuous capability technology provides the business.

That technology evolves as new capabilities are brought on line, old ones are retired, problems are fixed, functions refined.

But as we have described, we know that our budget cycles are generally yearly.

So rather than an continuous roadmap, we should consider a series of one year roadmaps, each simply articulating the sub-goals, the sub-objectives, that add up to our overall goal.  We can then speak to the alignment of the slate of potential projects fielded for the next year.

This is arguably the path to an intelligent enterprise.  As we have seen in our earlier rumination on BI, the ability to create and work toward new sub-goals when faced with obstacles – including our evolving constraints -  is the very definition of business intelligence.