We need a new definition of what “business maturity” is

Dean Kamen recently commented on the topics of industrial competitiveness and agility

“I think what Darwin really was saying was: It’s not the fittest, not the smartest, not the strongest; it’s the ones that can adapt to change. And big industries that have long histories, particularly successful long histories, and a lot of ingrained infrastructure become the least adaptable to change.

“And when a disruptive opportunity comes along, they are the last that are capable of dealing with it.”

It’s the ones that can adapt to change.

Interesting: if true, this calls into question the significant placed on organizational “maturity”, which focuses on complete definition of business processes and their optimization. What about agility?

Proponents of the maturity scale claim that by defining processes, one is in a better position to change those processes. However, that is not necessarily true, and I claim that in a complex organization, having extensive process definitions actually impedes change. It is similar to the situation in which one takes unit testing of software to its logical extreme: one gets to a point where one doesn’t want to change anything, because the cost of updating all the tests is so high.

Balance is necessary, and in Value-Driven IT, I make the argument that we need to re-define the very term “business maturity” to mean that the organization is capable of change, while staying in control: that it has the ability to retain strategic alignment of what matters, while making a substantial course change - and can accomplish this quickly. Because that is what is needed in a dynamic industry, and so many industries are becoming dynamic.

It has been a little while since I have updated this blog, and that is because I have been very busy working on improving the Expressway tool (described in the frame to the left). The version that is currently available is very crude from a usability standpoint, and the new version will be much improved. You will see!

Happy Holidays!

- Cliff

Slashdot It! Digg It!

How value-driven IT can show that IT matters.

Nicholas Carr’s controversial article (and later his book) asserting that IT doesn’t matter struck a chord with many people. There certainly is a feeling that IT is a burdensome cost, and that it has been ineffective in many ways. On the other hand, IT provides the critical plumbing for many business models, including Google and most financial services companies.The increasing pressure for IT to drive down costs is a symptom that IT’s value is not appreciated. IT does matter. Certainly the waterline on the IT stack of what is a commodity and what is not is always rising, but the highest levels are rising too - perhaps at some point IT systems will surpass our own abilities as humans! - but that is not the point. The point is that even if some kinds of IT services are commodity infrastructure, other parts are extremely important differentiators. And this is true even if IT is not your main business: if your IT systems are so inter-woven that you can’t change anything without changing everything, then you can’t introduce new products, and so your business agility is dead, and soon your business will be dead too. IT matters.

The dilemma for today’s CIO is that it is really hard to show benefits except in terms of cost savings. So if IT’s applications are extremely nimble and reliable, and enable the business to expand and deliver scalable services to more and more kinds of customers, IT doesn’t get credit. Instead, it gets a mandate to reduce costs, to be more efficient. The value provided by IT is not traced back to the decisions about how the IT systems were built, and it is these decisions that resulted in the agility that is enjoyed later.

Any IT architect knows that how systems are built is as important as what systems are built. The how is usually left to IT, and there is pressure to build systems for the lowest cost. It is hard to justify doing things the “right” way, because IT seldom provides a credible argument for building a system one way versus another. And when the budget is limited, which solution do you think will win: the more flexible one, or the lowest cost one?

In order to stand a chance when the IT portfolio is reviewed, IT arguments must be tangible. Motherhood will not prevail: “this solution will be more flexible” is not tangible, and so it will not receive much attention. If indeed the solution will be more flexible, why is that even a good thing? Will that flexibility ever be used? If so, how much value will be derived from that?

In order to answer such a question, one can turn to stochastic modeling. You might think that this is an esoteric approach, but it is used in countless industries - except for IT. For example, stochastic modeling is standard practice in most segments of the financial services industry. That is why the insurance industry employs so many actuaries, and it is why banks have sophisticated mathematical models of their investments.

An argument often heard form IT architects is that IT architecture is inherently technical, and does not involve analysis of business benefits. However, IT is often compared with the building profession, and it is noteworthy that building architects do concern themselves with business benefit: in fact, business benefit is what it is all about. A building is an investment. The builder expects to lease the building, and a building lease is based on a return on investment (ROI) analysis. The architect is very, very concerned with the kinds of ROI analysis that future tenants will do. Building architects must know financial analysis, and that is why building architects are always thinking about cost and value. IT architects also should think about tangible business value - they simply are not accustomed to doing so.

If IT architects developed value models of their systems, that account for the sources of value added by IT - things such as flexibility, reliability, extensibility, security, etc. - then CIOs would have something to support their claim that they add value to the organization. IT would then not be thought of as simply a cost center, and perhaps the constant pressure to drive down costs would wane. If IT were seen as valuable, there would be pressure to increase that value, rather than to drive down costs - and salaries.

IT does matter, but we have to prove it.

Slashdot It! Digg It!