Differentiation and Integration 2

In my previous post on Differentiation and Integration, I mentioned the Operating Model propounded by Jeanne W. Ross, Peter Weill and David C. Robertson in their book Enterprise Architecture as Strategy (Harvard Business School Press 2006). I shall continue to refer to this book as RWR.

The publisher offers a pdf extract from the book, in which you will see the following diagram, depicting what RWR call a “traditional” approach to IT solutions. (It's a secure pdf, so I've had to scan my library copy instead.)

According to RWR, the “traditional” approach is characterized as follows

• Each strategic initiative results in a separate IT solution, each implemented on a different technology, producing a set of silos.
• The company’s data is patchy, error-prone, and not up-to-date.
• Companies often extract from silos to aggregate data from multiple systems in a data warehouse; but the warehouse is useful only as a reference – it does not offer real-time data across applications.

RWR cite a company whose systems were linked together so effectively that no human being ever touched a transaction (straight-through processing - sounds pretty integrated to me) but for some unspecified reason this provided “a lack of foundation for execution”.

Sounds like there is “good integration” and “bad integration”. Which brings us to the squiggles in the diagram. RWR appear to have adopted a notation in which “good integration” is denoted by straight lines and “bad integration” is denoted by squiggly lines. As far as I am aware, this notation has not been not formally defined, and is therefore purely a rhetorical device.

While I accept the need for enterprise architecture to create a powerful strategic narrative, I fear that these rhetorical devices permit and even encourage a kind of woolly uncritical thinking, which is not capable of dealing with the real challenges of enterprise strategy, and could easily be dismissed as intellectually lightweight by sharp CEOs presented with this kind of stuff. Vague diagrams with undefined notation are no substitute for proper analysis.

It doesn't matter how often the three characteristics identified by RWR above are found together, the key question is whether it is possible and practical to separate them. Is data sharing (as RWR believe) the only way to achieve “good integration”, or are (as I believe) other aspects of integration (coordination, organizational intelligence) more strategically important?

Contingency Theory

RWR identify two key questions for determining your organization’s strategy.

• To determine your organization’s integration requirements, ask yourself to what extent the successful completion of one business unit’s transactions is dependent on the availability, accuracy and timeliness of other business units’ data. (RWR p30)

• To determine your organization’s standardization requirements, ask yourself to what extent the company benefits by having business units run their operations in the same way. (RWR p30)

These would appear to be critical questions for enterprise architects to consider, so it would surely be useful to have some rigorous methods for analysing these questions systematically, instead of merely a few pen pictures of companies that have followed one or other path.

Furthermore, both questions seem to be questions of degree ("to what extent") rather than questions of kind (either/or) - so where are the examples of companies whose rightful place is half-way along the path, rather than at one or other extreme?

Differentiation

RWR then introduce the notion of strategic differentiation. "The operating model concept requires that management put a stake in the ground and declare which business processes will distinguish a company from its competitors." (RWR p43).

I find this statement puzzling, because there is no obvious connection between the two dimensions of the operating model identified by RWR (viz standardization and integration qua data sharing) and the idea of competitive differentiation.

There are methods that focus on identifying which business processes will distinguish a company from its competitors, such as the method developed by my former CBDI colleagues out of the ideas of Geoffrey Moore (see my post Tesco Outsources Core ECommerce) but this is not the same as the RWR method.

Shared Services

One way of achieving some kinds of standardization is through shared infrastructure. When talking about shared services, RWR implicitly shift the scope of “the enterprise” from a single organization to a partnership ecosystem.

“A strategic partnership forces a shared-services mentality, requiring business leaders to come to agreement on which services will be provided centrally and which will be provided locally.” (RWR p148)

The decision of which services will be provided centrally or locally is a matter of standardization, and therefore an aspect of enterprise-architecture-as-strategy.

Enterprise Architecture as Quantitative Practice

What I find troubling in many popular accounts of enterprise architecture, including RWR, is the apparent disregard for economics. RWR talk glibly about the costs and benefits of standardization, but they are not willing to explore the economies and diseconomies of scale, or the distribution of fixed and variable costs, and there isn't much meaningful quantification. Handwaving as strategy?