The Foolhardy Rush to Consolidation

Is your organization under a mandate to consolidate some aspect of IT?

Most likely it is. Consolidation is a mania that has spread across organizations of all kinds, in all sectors. It is usually driven by the business or financial side, and approved by the CIO - after all, who can argue with cutting costs through economies of scale?

But in the process, are we losing some important advantages of decentralization? Is this even part of the business case? That is, did the business case even attempt to account for the enterprise value of the existing decentralization?

Most likely not, since those benefits are usually somewhat intangible, and business cases for consolidation almost always focus on direct costs: the costs of servers, IT personnel, and software licenses.

Recently I was involved with two different calls for consolidation. One was a consolidation of IT operations: for IT to take ownership of all of the computing applications in the field and move them into a single data center, and have IT take over the apps and combine them when possible. The field is no longer allowed to write their own apps. The other effort sought to consolidate all HR functions and create a single "self-service" system: field HR personnel were eliminated or moved to the central location. The business case was based on reduced direct cost of HR personnel.

These looked compelling on paper, but both efforts foundered. Let's look at the HR effort. It turned out that people in the field did not want a self-service approach: they were accustomed to having someone to ask about HR matters. This allowed the people in the field to focus on their primary jobs. In the new approach, line of business managers found that they were spending all of their time working HR functions and were not able to focus on their own respective missions. The business case did not account for this loss of mission effectiveness, but in the words of one of the senior field managers, "the business case is flawed".¹

In the case of the IT systems consolidation effort, the same mistake was made: the value of decentralization was not accounted for. As a result, people in the field will no longer have the flexibility to respond tactically to meet their own needs. The effort is still underway so we shall see what happens, but the symptoms are all looking familiar....

1. See chapter 11 of my book for techniques on how to model the value of "intangibles".

Slashdot It! Digg It!

Enterprise Architecture is Broken

There are so many discussions going on about what IT architecture is, and the most confused seem to be those surrounding enterprise architecture.

The IT profession has the dilemma that it is continuously inventing itself and evolving, and terminology is not standardized as a result. However, many organizations have “enterprise architecture” groups. It is also generally recognized that IT needs to be more business-centric, but seldom does one see a description of what that means. What should IT do differently? What should business do differently?

Recently I proposed an experiment to the online Google group “Enterprise Architecture Network“, as follows: ask a business architect (typically trained in the IT camp) for a model of the architecture of the business: they will likely show you a process flow diagram, showing the DATA flows. Then ask a business person for a model of the same business, and they will show you a model that captures the CASH flows.

My point was that there is a great disconnect between what IT and business each consider to be the business architecture. And I claim that an EA should be able to explain each model, and inter-relate them.

Karl Garrison of that group then responded, “I quite like Cliff’s comments - particularly that EA is about process modeling, while executives think in terms of cash flow. And that they are completely different. This is really right on the mark and explains why many executives may support EA, but don’t want EA to define their business…As a side note, when I’ve worked closely with executives to help identify and analyze acquisitions or define new organizational structures, I’ve found it very helpful to just shut up about EA since it often alienates business folks.” (Emphasis added.)

Well yes, I have found the same thing. Executives don’t see the relevance of enterprise architecture to their plans, because its tangible value has not been articulated. It doesn’t appear in the cash flow model!

In other words, for EA to be relevant to executives, it will have to appear in their models.

And to accomplish that, it will take someone who understands both IT and business well enough to link the IT models with the business models.

Is that person the enterprise architect? You tell me.

- Cliff

Slashdot It! Digg It!

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!