Part of the problem is a failure to understand the difference between a maturity model and a roadmap. While a roadmap is (or at least should be) a practical template plan, based on a consolidation of experience from many organizations, a maturity model is a more theoretically grounded framework, based on a logical analysis of capabilities and their dependencies.
The essential tone of a roadmap is supportive, helpful. It gives you permission to tackle things in a manageable sequence. Start here, it says, and feel free to defer these more advanced matters until later.
The essential tone of a maturity model, on the other hand, is parental. Don't imagine you can get anywhere with X until you have mastered Y. Don't walk until you can run. You're not old enough to buy alcohol, cigarettes, knives or glue. Have you finished your homework? Eat your greens, and be home before ten.
One of the strongest messages that came out of the SEI's earliest process improvement work was a negative one - don't even think about implementing tools until you've sorted the process out. These are the kind of statements from which a maturity model is built.
In order to substantiate such statements properly, you need a model of capabilities and their dependencies. (For example, what capabilities are dependent upon a given set of metrics.) This is why a maturity model (of the kind we're talking about here) is always (implicitly if not explicitly) a capability maturity model. (I have been talking to Microsoft recently about their Capability Modelling method, known as Motion, which has some interesting uses for service-oriented analysis and design, but is also relevant for building maturity models.)
And this is the source of confusion behind some of the SOA Maturity Models that are being disseminated. What exactly are the capabilities that are being referenced here - capabilities in developing service-oriented solutions, or the service capabilities themselves? (If both, how tightly coupled are they?) Whose maturity are we talking about - the IT development organization or the whole service-oriented business?
At the end of the 4vendor white paper, each vendor provides a summary of its own tool capability in respect of the so-called maturity levels. After comparing these summaries carefully, I got a strong impression that each of the four vendors has interpreted the levels in a different way. In any case, what is the correct marketing strategy for a vendor - to support Level 5 (and imply that customers shouldn't implement these tools until they have reached the right maturity level) or to support Levels 1 and 2 (and imply that the tools are only good for beginners)?
No doubt some vendors like to appeal to the ego of their customers. ("Only the most clever and sophisticated user can deploy our tool successfully.") But this sounds like adolescents selling to adolescents.
“Adolescence is a series of unsuccessful attempts to skip adolescence.” [Jon Elster, Making Sense of Marx (Cambridge University Press, 1985) p 306]Perhaps vendors would be wiser to stick to Roadmaps. Or better still, leave the Roadmaps to the industry analysts (click here for the CBDI Roadmap) and stick to implementing products and solutions.
Technorati Tags: capability maturity maturity model roadmap SOA service-oriented
No comments:
Post a Comment