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?

Ecosystem SOA

The SOA world is finally catching up with some of the ecosystem ideas that I published in my 2001 book on the Component-Based Business (see my Slideshare presentation) and developed further in several articles and presentations for the CBDI Forum over a number of years.

• Supply and Fit (September 2000)
  
• Identifying Components 2 (October 2001)
• Opportunities in the Insurance Ecosystem (December 2004)
• Business Strategy Planning for the Service Economy (May 2006)
  

The biological approach to creating business and software services is radically different to the solution-driven approach, and is based on biological and ecological metaphors.

• First we identify an ecosystem, which may contain both human users and existing artefacts.
• Then we identify services that would be meaningful and viable in this ecosystem.
• Then we procure devices that enable the release and delivery of these services into the ecosystem.

I previously defined Three Types of Requirements Engineering, and we can map these onto different styles of SOA.

Solution-Driven (Specific)	Solution-Driven (General)	Evolution-Driven
Identify Business Problem Identify "Users" Negotiate Requirements Define Solution	Identify Domain Identify Domain Experts Define Requirements Design Solution Kit	Identify Ecosystem Identify Services Procure and Release Devices
Experimental SOA	Enterprise SOA	Ecosystem SOA

(Some people use the term Web Oriented Architecture (WOA) for what I'm calling Ecosystem SOA.)


If we regard these as phases of maturity, then we can have a straightforward roadmap from left to right, as in for example the CBDI SOA Roadmap. However, some organizations may need to tackle these styles of SOA in parallel rather than in sequence.

---

A service portfolio plan for Enterprise SOA can be based on an enterprise model that identifies the capabilities of the enterprise and clusters these into domains. In the CBDI Forum's SAE methodology, the domains are classified as Core and Contextual according to a matrix derived from Geoffrey Moore. (Note how the domains migrate around the matrix over time.) See for example my blogpost Tesco outsources core eCommerce.



A similar model, derived from Amin and Cohendet's book Architecture of Knowledge, explicitly describes Core and Periphery in terms of knowledge intensity. In other words, the reason something is classified as Core is because it encapsulates some important (strategic) knowledge.

For example, an insurance company knows more about insurance than about cars, so when providing car insurance it may decide to partner with other organizations that know more about cars than about insurance. This results in a composition of insurance-related services and car-related services (for example, determining the insurable value of a used car). Such compositions can be either directed (in other words, composed by a single dominant player) or collaborative (in other words, emerging from the interaction between multiple players within the ecosystem).

For example, an online retailer knows about her products and services, but doesn't wish to become an expert in credit card handling, or to be responsible for data protection and security, so she delegates these concerns to a specialist provider that knows more about these matters.

Similar considerations can apply to industry consortia, such as ACORD (for the insurance market). ACORD can define generic service-based assets (such as models, schemas, interfaces and so on) for insurance. However, insurance companies will also wish to use generic service-based assets to cover requirements that are not insurance-specific, such as customer management or complaints handling, where ACORD may not be able to add any knowledge-value, and it would be appropriate for ACORD to regard these as peripheral to its own activities rather than core.

---

So one approach to Ecosystem SOA is to push out from the enterprise into the ecosystem. John Hagel calls this Inside-Out Architecture, which he contrasts with Outside-In Architecture. (See my post on Outside-In Architecture.)


An Outside-In Architecture starts with a model of (the flows of) knowledge and value in the ecosystem as a whole. The strategic question for an enterprise is how to find way of both contributing value to the ecosystem, and drawing value from the ecosystem, through the provision of ecologically viable services.



For example, a telecoms company might reasonably consider that its core competence is something to do with communications. So a positional strategy would drive it to a dominant position in the middle of a large communication ecosystem, providing a platform of services that add value to a diverse range of communication activities by other people. The dominant position would allow it to negotiate a strong share of the value generated.

However, respect for the ecosystem would lead it to leave sufficient value to third parties to maintain the economic health of the remainder of the ecosystem. Instead of a simple positional strategy, a relational strategy (based on mutual trust with ecosystem partners) should produce a more sustainable and ecologically sound ecosystem.

---

Service Ecosystem from Richard Veryard


Related post: Ecosystem SOA 2 (June 2010)

Tesco outsources core eCommerce

In March 2009, Nick Lansley explained the background to Tesco.com adopting ATG e-commerce platform.

Here are some of the key points.

1. For years Tesco differentiated itself from the competition by writing its own e-commerce software that fitted in perfectly with its processes.

2. Competitors who tried to copy this software were unable to replicate its internal functionality. (Nick refers to "special algorithms".)

3. But the "core systems" are not Tesco's "core business". So Tesco has decided to outsource.

4. Tesco selected an e-commerce software platform that matches its core systems the closest.

5. With the core already there, Tesco will devote its IT staff to designing and developing new business improvements and ideas.

---

Analysis

This story fits with the view of "services on the fault line", which the CBDI Forum adopted and adapted from Geoffrey Moore. Capabilities migrate around the grid. The core e-commerce platform is migrating from top-left to bottom-right; meanwhile Tesco is devoting its internal IT resources to generating new functionality from bottom-left.



The classification of capabilities depends partly on the link to business outcomes / value. It also depends on the knowledge associated with each capability. Correct decoupling between capabilities depends on encapsulating the knowledge (know-how) embedded in each capability. (This is a version of the well-known architectural principle: separation of concerns.)

So we can understand the strategic cycle of capabilities (core and contextual) proposed by Geoffrey Moore, by reference to a model of the knowledge cycle proposed by Max Boisot.



I don't know whether the "special algorithms" remain proprietary to Tesco, or whether they (or at least the "commodity" provided by these algorithms) become available to other users of the same platform. In any case, I guess Tesco will be looking to develop new and more sophisticated algorithms.

---

See also

CBDI Forum, SOA Fundamentals (2009) - key extract from page 222

Richard Veryard and Philip Boxer, Metropolis and SOA Governance (Microsoft Architecture Journal 5, July 2005). Philip Boxer and Richard Veryard, Taking Governance to the Edge (Microsoft Architecture Journal 6, August 2006)

Richard Veryard, Business Strategy Planning for the Service Economy (CBDI Journal May 2006)

In his post Managing over the whole Governance Cycle (April 2006), Philip Boxer extends the Boisot model to produce a governance cycle appropriate for the platform-based business. See also my post on Knowledge and Culture (April 2006).

Related posts: Service Planning (December 2006), Ecosystem SOA (October 2009) Ecosystem SOA 2 (June 2010)

Updated 13 October 2015. Links updated 18 November 2019

Semantic Ambiguity

Here's a neat little example of semantic ambiguity.

The UK supermarket Tesco has bowed to a campaign by grammatical purists, who object to people saying "less" when they should say "fewer". Tesco boss Sir Terry Leahy has written to the Plain English Campaign announcing the intention to replace checkout signs reading "Ten Items Or Less" [Tesco Checks Out Wording Change, BBC News 31st August 2008].

The BBC claims that this will "avoid any linguistic dispute".

Actually, the biggest ambiguity remains unaddressed, because this is not in the choice of "less"/"fewer", but in the word "item". The Plain English spokesman uses plain english apples as an example. Tesco sells plain english apples by weight. So if I buy a dozen loose apples, does this count as one item (allowing me to go to the "up to ten items" checkout) or twelve items (forcing me to queue behind someone with a full trolley)?

I am hopeful that the humans in Tesco would take the common sense view, and allow me to regard a dozen apples as a single item. But would the pedants at the Plain English Campaign, or for that matter a fully computerized system, take the same view?

What's particularly interesting here is the fact that even the plain english campaigners can't spot a simple ambiguity. So what chance for the rest of us?

(Meanwhile, the BBC has apparently given up distinguishing between "less" and "fewer". See my recent comment Follow Me Follow on Twitter)

Lightweight Enterprise

One of the interesting divisions of opinion at the SPARK workshop (and surfacing afterwards in the blogs of some of the participants) was about something we might call the weight of the enterprise.

Dare Obasanjo asserts My Website is Bigger Than Your Enterprise. And Jeff Schneider retorts My Enterprise Makes Your Silly Product Look Like A Grain of Sand. So who is right?

The basic issue here seems to be the relative amounts of complex engineering required to produce enterprise-grade software versus web-grade software. Dare (and some other participants at the SPARK workshop, including the guys from mySpace) are producing web software with staggering user volumes - much greater than most enterprises have to deal with.

Dare is scornful of enterprise architects, who (he says) "tend to seek complex solutions to relatively simple problems". He and David Heinemeier Hansson are particularly rude about James McGovern.

But as Jeff points out, "most people who have never seen a large enterprise architecture have no concept of what it is". CIOs and enterprise architects generally regard enterprise software (their own realm) as much more challenging than web software, involving much higher levels of complexity, and much stricter "non-functional" requirements (security, robustness, and so on). Are they right, or is this just narrow self-interest?

Size, complexity, weight - these are basic architectural concepts. Part of the difficulty with this debate is that we simply don't have an agreed language for discussing architecture properly. In my opinon, IT education is very deficient in this area. (See Footnote 1.)

Enterprise Mashup

One way of thinking about enterprise mashups is that they provide a way of achieving enterprise-grade systems without enterprise-heavy engineering. Let me give an example of something I regard as a business mashup. My example doesn't involve Ruby, it doesn't involve web services, and many people might say it doesn't even count as SOA. But it has always been my favourite example of the "plug-and-play" business that I describe in my book on the Component-Based Business.

Tesco Personal Finance (TPF) is an example of what I would now regard as a business mashup. It combines (mashes together) banking services (provided by the Royal Bank of Scotland) with retail services (provided by Tesco).

From Tesco's perspective, this mashup provides an extremely lightweight way of entering the banking business. In the old days, if you wanted to open a bank, you had to collect a large amount of gold, which you had to deposit with the banking regulators to satisfy them of your financial stability. Then you had to open a number of branches, and employ a small army of clerks and managers. This represented a considerable investment and risk - which meant that the existing banks could earn high profits behind high entry barriers.

In contrast, TPF represented for Tesco a low-cost, low-risk way of entering the banking industry. Simply plug in some external banking services (which already satisfy all the necessary banking regulations), and a humble retailer can become a bank overnight.

SOA

Although the Tesco Personal Finance initiative predated the SOA and Web 2.0 technologies we have today, we can now interpret it as a precursor or harbinger of these technologies - almost a non-technical proof-of-concept. (See Footnote 2.)

SOA enables the lightweight enterprise. It does this not through services but through architecture. (That, in my view, was the primary justification of SPARK.)

The challenge of architecture is to deconflict the enterprise software space - to create a genuine separation of concerns. This is easier said than done, and it requires some complex architectural thinking. One of the products of this thinking may be platforms on which developers may use small-scale and simple development techniques to produce large-scale and complex solutions.

See my recent posts on the Business Stack (SPARK Workshop 2) and Enterprise Mashups and Situated Software.

---

Footnote 1 - I have always been critical of university IT courses that teach students to write small programs, and fail to teach them the differences between small stand-alone programs and large interconnected suites of programs. If you go to architecture school, you may never build anything larger than a garden shed with your own hands. But you will have looked at skyscrapers and understood the relevant design and construction principles. You won't qualify as an architect without understanding the scale differences between garden sheds and skyscrapers. But in IT there is no such educational requirement. Vast numbers of people get university degrees in IT-related subjects, and even fancy job titles including the word "architect", without having a clue about effects of scale on software.

Footnote 2 - Sometimes technology seems to make new things possible. But we often find that these things were possible all along, they were just too difficult or expensive or risky. In the 1950s, Stockhausen was producing music that predated the modern synthesizer - and it took him months to produce music that later composers would produce with a few quick knob-twiddles. Some might argue that Stockhausen's achievement was all the greater because of his lack of tools. Similarly, many Renaissance painters might have been able to produce their pictures more efficiently if they had had digital cameras. But perhaps their paintings (and their artistic innovations) were all the greater for being done without modern technology. See my post on Art and the Enterprise.

---