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.
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 TheoryRWR 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)
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?
DifferentiationRWR 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 ServicesOne 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.