Easing CIOs` Pain for Meeting Business Expectations - ' Common Vs'

Common Vs. Unique

Now, the architecture must be spun away from the business domain and into the technology domain. Knowing what technologies are available and what they can deliver in technical capability, performance and scale, a group of technology architects is asked by the CIO to select the minimum number of technologies needed to implement the solution architecture—in essence to design an optimized technology provisioning strategy. Here again, CIOs must look hard at what can be common and what must be unique, and examine the cost and value of uniqueness. To keep things manageable, the common and unique portions of the work must be split, but as a series of platform architectures is developed, the individual architectures must be recombined to ensure that the teams achieve overall coherence and consistency.

It generally takes several attempts to get consensus on all this, and CIOs often have to cycle back to the business domain, sometimes negotiating with solution architects serving as proxies for business managers—sometimes negotiating with the business managers directly—before the work is finally done.

The final step is to make detailed provisioning decisions—build vs. buy, for example—for the technologies that have been selected.

Along the way, CIOs can create a comprehensive map, from capability requirements to solution elements to implementation technologies, that will be used to support continuing solution lifecycle management and technology refresh efforts.

Because they know what business capabilities depend on what solutions and what solutions require which enabling technologies, CIOs are able to conduct a reliable impact analysis to determine how to make the changes and upgrades simpler and less disruptive. When changes are necessary, they know who might be affected and can communicate and plan accordingly.

Once the portfolio of work has been identified, there's one final check to make: determining the appropriate ROI model and level of expectation for each element of the portfolio.

Not every project—however critical to the overall plan—yields the same level of return, and every business justification must reflect that: Who gets the benefit? How much will the benefit be and what will it take to achieve? CIOs need to be able to answer all these questions before the work is complete.

This is a tough discipline that a good many IT ships do not enforce very well. Too many projects get launched despite failing the "good for someone" test, a sure route to eventual failure.

Veteran IT consultant John Parkinson is a columnist for CIO Insight.