Setting off Towards the Data-Driven Business

In an earlier post Towards the Data-Driven Business, I talked about the various roles that data and intelligence can play in the business. But where do you start? In this post, I shall talk about the approach that I have developed and used in a number of large organizations.

---

To build a roadmap that takes you into the future from where you are today, you need three things.


Firstly an understanding of the present. This includes producing AS-IS models of your current (legacy) systems, what data have you got and how are you currently managing and using it. We need to know about the perceived pain points, not because we only want to fix the symptoms, but because these will help us build a consensus for change. Typically we find a fair amount of duplicated and inconsistent data, crappy or non-existent interfaces, slow process loops and data bottlenecks, and general inflexibility.

This is always complicated by the fact that there are already numerous projects underway to fix some of the problems, or to build additional functionality, so we need to understand how these projects are expected to alter the landscape, and in what timescale. It sometimes becomes apparent that these projects are not ideally planned and coordinated from a data management perspective. If we find overlapping or fragmented responsibility in some critical data areas, we may need to engage with programme management and governance to support greater consistency and synergy.


Secondly a vision of the future opportunities for data and intelligence (and automation based on these). In general terms, these are outlined in my earlier post. To develop a vision for a specific organization, we need to look at their business model - what value do they provide to customers and other stakeholders, how is this value delivered (as business services or otherwise), and how do the capabilities and processes of the organization and its partners support this.

For example, I worked with an organization that had done a fair amount of work on modelling their internal processes and procedures, but lacked the outside-in view. So I developed a business service architecture that showed how the events and processes in their customers' world triggered calls on their services, and what this implied for delivering a seamless experience to their customers.

Using a capability-based planning approach, we can then look at how data, intelligence and automation could improve not only individual business services, processes and underlying capabilities, but also the coordination and feedback loops between these. For example in a retail environment, there are typically processes and capabilities associated with both Buying and Selling, and you may be able to use data and intelligence to make each of them more efficient and effective. But more importantly, you can improve the alignment between Buying and Selling.

(In some styles of business capability model, coordination is shown explicitly as a capability in its own right, but this is not a common approach.)

The business model also identifies which areas are strategically important to the business. At one organization, when we mapped the IT costs against the business model, we found that a disproportionate amount of effort was being devoted to non-strategic stuff, and surprisingly little effort for the customer-facing (therefore more strategically important) activities. (A colour-coded diagram can be very useful in presenting such issues to senior management.)

Most importantly, we find that a lot of stakeholders (especially within IT) have a fairly limited vision about what is possible, often focused on the data they already have rather than the data they could or should have. The double-diamond approach to design thinking works here, to combine creative scenario planning with highly focused practical action. I've often found senior business people much more receptive to these kind of discussions than the IT folk.

We should then be able to produce a reasonably future-proof and technology independent TO-BE data and information architecture, which provides a loosely-coupled blueprint for data collection, processing and management.


Thirdly, how to get from A to B. In a large organization, this is going to take several years. A complete roadmap cannot just be a data strategy, but will usually involve some elements of business process and organizational change, as well as application, integration and technology strategy. It may also involve outside stakeholders - for example, providing direct access to suppliers and business partners via portals and APIs, and sharing data and intelligence with them, while obtaining consent from data subjects and addressing any other privacy, security and compliance issues. There are always dependencies between different streams of activity within the programme as well as with other initiatives, and these dependencies need to be identified and managed, even if we can avoid everything being tightly coupled together.

Following the roadmap will typically contain a mix of different kinds of project. There may need to be some experimental ("pioneer") projects as well as larger development and infrastructure ("settler", "town planner") projects.

To gain consensus and support, you need a business case. Although different organizations may have different ways of presenting and evaluating the business case, and some individuals and organizations are more risk-averse than others, a business case will always involve an argument that the benefits (financial and possibly non-financial) outweigh the costs and risks.

Generally, people like to see some short-term benefits ("quick wins" or the dreaded "low-hanging fruit") as well as longer-term benefits. A well-balanced roadmap spreads the benefits across the phases - if you manage to achieve 80% of the benefits in phase 1, then your roadmap probably wasn't ambitious enough, so don't be surprised if nobody wants to fund phase 2. 


Finally, you have to implement your roadmap. This means getting the funding and resources, kicking off multiple projects as well as connecting with relevant projects already underway, managing and coordinating the programme. It also means being open to feedback and learning, responding to new emerging challenges (such as regulation and competition), maintaining communication with stakeholders, and keeping the vision and roadmap alive and up-to-date.

---

Related posts

• Embedding Intelligence into a Business Capability (December 2010)
• Organizing Business Capabilities (February 2012),
• Towards the Data-Driven Business (August 2019)
• Developing Data Strategy (December 2019)

See also

• Design Council: Double Diamond
• TOGAF: Capability-based planning

The Enterprise Architect of Hamelyn

Stakeholder Concern	Enterprise Focus	Project Focus
The city of Hamelyn is plagued with rats.	This indicates a serious problem with the “Public Health and Hygiene” capability.	We just need a quick project to eliminate the rats. So we buy some “Eliminate Creature” capability from an external vendor.
The Pied Piper gets rid of the rats.	Real business problem has not been addressed. Let’s now push on with the next phase of solving the problem.	Project successful.
The Pied Piper is too expensive.	We need a careful transition plan while we build an in-house capability.	Let us immediately renegotiate our contract with the vendor.
The Pied Piper gets rid of the children.	It turns out that the Pied Piper can reuse his “Eliminate Creature” capability for other purposes.	!*!?**!
Which Role?	Enterprise Architect? Strategic Procurement?	Solution Architect? Tactical Procurement?

See also my article “Requirements Engineering as if Stakeholders Mattered” (Requirenautics Quarterly, Issue 29, August 2003, pdf)

Not your grandpa's functional decomposition

Is there a difference between function and capability? You can find endless debate about this on the Internet (yawn). One of the reasons business architects often prefer the word capability is that the word function can become extremely overloaded - sometimes equivalent to organizational unit, sometimes equivalent to long-running process, sometimes equivalent to purpose. Whereas the word capability seems to focus our attention more clearly on the WHAT rather than the HOW or WHO or WHEN or WHERE or WHY.

But even when people insist that a capability is not the same as a function, they still seem to use the same approach for identifying and modelling capabilities as was once popular for functions. So they draw capability models as simple hierarchies, either as trees or as boxes within boxes. There are many valid uses for these models, including heat-mapping.

One such approach to capability modelling was popularized by Ric Merrifield and others at Microsoft in the mid 2000s. The methodology was originally called Motion, then Motion Lite, and is now known as Microsoft Services Business Architecture. It includes a Business Dependency Network diagram, but this is used to show the dependencies between the business architecture and IT, rather than the dependencies within the business. In fact, it looks remarkably similar to IBM's Business Component Model.

Despite the limitations of a hierarchical methodology, there are some useful guidelines on separating WHAT from HOW, and on the segue from capability to service, as well as a wealth of examples.

In the early 2000s, I started working on an alternative approach to capability modelling in collaboration with the CBDi Forum. This approach, which is loosely aligned with Stafford Beer's Viable Systems Model, concentrates on understanding the dependencies between core capabilities, and the role of key management capabilities such as coordination and intelligence. One of the key drivers for this work was the belief that a network view of capabilities provided a good starting point for developing a shared service architecture (both business and IT). This topic has gone off the radar lately, but I think it remains important. 

---

Denise Cook, Business-Capability Mapping: Staying Ahead of the Joneses (MSDN March 2007)

Ulrich Homann, Jon Tobey, From Capabilities to Services: Moving from a Business Architecture to an IT Implementation (MSDN April 2006)

Ric Merrifield, Rethink (FT Prentice Hall 2009) (pdf intro)

Ric Merrifield and Jon Tobey, Motion Lite: A Rapid Application of the Business Architecture Techniques Used by Microsoft Motion (MSDN May 2006)

Ric Merrifield, Jack Calhoun and Dennis Stevens, The Next Revolution in Productivity (Harvard Business Review, June 2008) (pdf)

Martin Sykes and Brad Clayton, Surviving Turbulent Times: Prioritizing IT Initiatives Using Business Architecture (Microsoft Architecture Journal, June 2009)

Richard Veryard, Business Modelling for SOA - Capabilities and Events (CBDI Journal January 2006), Capability Dependency (CBDI Journal May 2007)

Richard Veryard, Six Viewpoints of Business Architecture (LeanPub 2012)

Related posts: IBM's Component Business Model (March 2005), Merging Capability Modelling with Process Modelling (April 2008), Business Capability Modelling (March 2009), Organizing Business Capabilities (February 2012)


Updated 31 July 2014

Organizing Business Capabilities

#entarch #bizarch Following a Linked-In discussion on business architecture and capability modelling, I was slightly alarmed to see how many contributions to the discussion were based on an argument from authority: IBM says this, Michael Porter says this, Forrester/Gartner says this.

Obviously these are all clever guys, but does that mean they have all the answers? Someone claimed that IBM's model was based on something called "natural clustering", but I don't know what he thinks that means. The only clustering I've ever seen used in architectural contexts has been artificial, meaning that what you get from clustering depends a lot on what algorithm or mechanism you use, as well as when (at what stage in the process, the level of granularity) you choose to carry it out.

In any case, I am sceptical of generic architectures. If I want a house that is exactly the same as everyone else's house, I don't really need an architect at all - I just need a structural engineer to calculate the strength of the beams and align the plumbing. I don't expect an architect to spend months just giving me a slightly modified copy of something he found in a textbook.

I think the interesting question is how to derive a capability map from the particular behaviours of an organization and the particular intentions of its leadership, rather than just imposing some off-the-shelf business school or vendor nostrum.

So, what kind of capability map do we need to understand the organization of capabilities? Many people think all we need to do is identification and classification - decomposing the enterprise into a set of independent capabilities. Business analysts can then document each capability separately (I sometimes use a capability canvas that is adapted from Osterwalder's business canvas), decide which capabilities are of greatest strategic importance, and produce a plan for business improvement. (The UK MOD practises a methodology called Through-Life Capability Management, and a casual Internet search will identify several large consultancies and systems houses that claim expertise in this area.)

This is all well and good, but it misses what I regard as the critical architectural point - the relationships between capabilities. Business analysts may be happy with capability decomposition, but I think business architects also need a capability dependency diagram, which shows, among other things, how one capability creates or modifies, coordinates or governs other capabilities. Many of the popular capability modelling methods concentrate on modelling the operational capabilities only, but I prefer to produce a model that includes the higher level development and management capabilities.

Fans of Stafford Beer's Viable Systems Model (VSM) will regard the operational capabilities as corresponding to what Beer calls System One, while the higher level capabilities correspond to Systems Two through Five. (For many purposes, I find a simpler three-level schema is enough.)

Another schema for modelling different classes of capability can be found in the draft Systems Engineering Body of Knowledge: Enterprise Systems Engineering Background. This schema is useful in recognizing the distinction between operational capabilities and other classes of capability, but I think it is limited by its strong engineering bias and is probably insufficient for the purposes of business architecture.

Marketing genius Seth Godin once reported a conversation with a publishing executive: "People ask me what the hardest thing is... is it finding authors? I tell them that the two hardest things are hiring great people and watching the cash flow." [The Hardest Thing, April 2006] Things like these are not just hard but critically important to the success of an enterprise - because so many other things are dependent upon them.

It is these dependencies that the business architect must understand - in order to see how improvements in one area may or may not ripple through the rest of the organization, sociotechnically as well as technically. That's why I think capability mapping is more than just engineering.

Embedding Intelligence into a Business Capability

In some recent posts, I have talked about embedding different forms of intelligence in a business process. Intelligence may make the process more powerful, or it may merely make it more internally efficient. But in the examples I've looked at so far, the essential purpose of the process remains the same.

• Embedding Intelligence into the Business Process
• Embedding Intelligence into the Business Process 2
• Joined-up collaboration

In this post, I'm going to look at something more radical. Prompted by a blog on the Death of Market Research from Tamara Barber of Forrester, I'm going to show how a basic business capability such as market research can be transformed into something else by introducing new forms of intelligence.

Barber's basic premise appears to be that in a complex world, it isn't enough for market research merely to gather information to be fed into business strategy and tactics. Instead, market research needs to be fully engaged in the intelligence loops of business decision-making and innovation. The challenge is not collecting information - there is already more than enough raw data - the key value-adding activity is in interpretation and insight.

In terms of organizational intelligence, this means extending from information gathering into active participation in the intelligence loops - from sense-making and decision-making to experimentation and learning. Barber defines this new role as follows.

"This role will be responsible for collecting and analyzing both internal and external sources of data, analyzing it, and presenting a unified view of the truth on customer/consumer wants and needs, as well as the market conditions and health of the brand within that market. In order to do this, leaders of today’s market research departments will need to consider how they can organize their teams, scope their capabilities, and collaborate with internal teams (customer intelligence, anyone?) and external vendors in order to come to the table with relevant insights and recommendations — all based on business objectives."

There have been many criticisms of intelligence organizations such as the CIA whenever they have apparently failed to "connect the dots", and there are probably some useful lessons here for civilian organizations as well. One of the common problems appears to be a bureaucratic separation between the information gathering, sense-making and policy-making activities, which may cause insight to be fragmented or lost. It is surely better to build business capability around the whole intelligence loop, rather than chop it into separate pieces and hope that it all somehow works.

---

Places are still available for my Organizational Intelligence Workshop on December 8th.

Coherence Premium

Interesting article by Paul Leinwand and Cesare Mainardi, The Coherence Premium. HBR June 2010 http://www.booz.com/media/uploads/HBR_Coherence_Premium.pdf

The authors define the "coherent company" as one that "has aligned its differentiating internal capabilities with the right external market position". They claim that most companies lack coherence because they pay too much attention to the external and not enough to the internal. "We are suggesting that companies start from the opposite direction, figuring out what they're really good at and then developing those capabilities (three to six at most) until they're best in class and interlocking. From there, strategy becomes a matter of aligning that distinctive capabilities system with the right marketplace opportunities."


We may observe in passing that enterprise architects are often criticized for the opposite tendency - paying too much attention to internal structure without knowing how to align this to external demand. 



The authors offer two examples of enterprise models that could be expressed as an interconnected set of capabilities, although the detail of the interconnections are not described in the paper.

Retail (based on Wal-Mart)

• vendor management
• point-of-sale data analytics
• logistics
• working capital management

Consumer healthcare (based on Pfizer)

• Science-based innovation (I interpret this to be "technology" rather than "product")
• Influencing regulation and government policy
• New product development (including licensing and acquisition)
• Claims-based marketing (in other words, giving the consumer verifiable and relevant chunks of knowledge)
• Channel management
• Portfolio management

The authors claim to have a procedure for quantifying something they call "Coherence Premium" for a company.

1. Define the segments the company serves
2. Identify the capabilities that drive value for the company in each segment
3. Determine the number of common capabilities across all the segments the company serves.

They have calculated the coherence premium for a number of large companies including Campbell's, Clorox, Coca-Cola, ConAgra, General Mills, Heinz, Kimberly-Clark, Kraft, Nestlé, PepsiCo, Procter&Gamble, Sara Lee, Unilever and Wrigley's. These are then mapped against EBIT margin%, showing a very rough correlation.

Unfortunately, however, this graph doesn't show the two companies that they examined in greatest detail earlier in the paper, namely Wal-Mart and Pfizer. This may be because these companies face complex multi-sided markets, and this would cause difficulties for their simple procedure. It would seem that the kind of coherence they praised in these two companies would not be adequately represented by their simplistic "coherence premium" metric.


There have been many previous attempts to address the issues raised by Leinwand and Cesare Mainardi. In her blogpost Coherence - the new alignment, commenting on a Booz presentation of their concepts, Naomi Stanford recalls an earlier book on The Power of Alignment by George Labovitz and Victor Rosansky. Also see the discussion of cohesion costing in Nicholas Whittall and Philip Boxer, Agility and Value for Defence (pdf).

Loose Coupling: Innovation and the Web

"Cosy social networks are stifling innovation", according to an article in the New Scientist (5 August 2009).

This is a familiar argument in a new context. It has often been argued that corporate culture can inhibit innovation, and that groups responsible for experimental products and processes tend to perform better if they are put into a separate organization unit at some distance from the main offices. In recent years, many companies have set up R and D units in special science parks, co-located with similar units from other companies, usually with links to a nearby university. This is essentially applying architectural thinking to the geographical location and distribution of certain classes of capability, and reflects a common belief in the importance of these factors.

But interaction and clustering is nowadays much less dependent on physical geography, and much more dependent on virtual online communities and networks. The New Scientist article quotes Viktor Mayer-Schönberger of the National University of Singapore, who argues that today's software developers work in social networks in which everyone is closely linked to everyone else. "The over-abundance of connections through which information travels reduces diversity and keeps radical ideas from taking hold."

What Mayer-Schönberger sees as an over-abundance of connections is actually another form of tight coupling. If we want to build the capability for radical innovation, we need to create a decoupled space to support a loosely coupled knowledge cycle. Which means careful attention to the effects of social networking and organizational intelligence.

Business Capability Modelling

Picked up some fragments of a discussion between Colin Jack and Udi Dahan (Twitter, March 3rd-4th).

Colin Jack: Somehow our attempts at business capability modelling ended up producing a list of entities (Customer/Order). Meh.

Udi Dahan: When doing BC modeling, focus more on use cases

Colin Jack: I think I see what you mea, but I still think complexity cost of BC's is rel high so sometimes modules are enough

Udi Dahan: Complexity of BCs isn't that high - simple, straightforward pub/sub

I may be missing some of the pieces and context that might make these fragments more intelligible, but I'm going to comment anyway, on what I imagine they might be talking about.


A key challenge of any kind of business modelling or system model is to decompose into things that make sense. For many analysts, the things that make most sense are ... things. Objects. Entities. Assets.

If these things are important to the business, they need to be looked after. So when Colin identifies Customer and Order as business capabilities, he presumably means customer-management and order-management. The customer-management capability is typically going to be responsible for discovering and managing all aspects of all instances of CUSTOMER; and the order-management similarly for all instances of ORDER.

(Gunnar Peterson adopts a similar approach for security requirements - understanding security as the protection of a range of assets. Thus security capabilities are all asset-related. See my discussion Business Model Drives Security.)

Is there anything wrong with this as a capability model? Well, it tells us what needs to be managed or protected, but doesn't exactly tell us what needs to be done.

Udi offers a radically different approach: look at the process model. Not the whole processes, but broken down into Use Cases. What we'd expect from this approach is a much larger number of much smaller and simpler capabilities, and this is confirmed by the exchange between Colin and Udi.

When I do business capability model, I want to identify capabilities with certain characteristics - meaningful and self-contained chunks, with high cohesion and low coupling. Generally this means looking at both the entities and the process. In a complex situation it is useful to draw a matrix of the interactions between entities and processes, in order to work out the clusters.

There is growing interest in capability modelling and capability management, including through-life capability management, and the capability model is a powerful tool for thinking strategically about the loosely-coupled enterprise, so I guess I shall need to write some more on this topic soon.

Business Capability Management

Mexican consulting firm TCDS defines Business Capability Management as a holistic management model as follows.

A Business Capability is a comprehensive ability of an organization required for meet customer expectations without exception. If an organization is going to develop sustainable competitive advantages in terms of agile core business capabilities, four strategic business capabilities need to be developed. We called them BCM Metacapabilities:

1- Value Proposition Creation (VPC)
2- Business Capability Development (BCD)
3- Capability Operation Management (COM)
4- Managed Capability Evolution (MCE)

I'm not sure about the detail of their approach, but I like the overall message, in particular the concept of metacapabilities.

What counts as holistic is of course open to debate. One obvious dimension is timescale, as in Through-Life Capability Management (AOF). But there are other dimensions.

Merging Capability Modeling with Process Modeling

Nick Malik asks about the relationship between capability model and process modelling. "If your company is a process oriented one (or becoming a process oriented one), how do you fit in capability modeling? Do these two methods conflict?"

Nick suggests two answers. In this post I want to offer a third answer. But first we have to understand the purpose of each type of modelling.

Nick mentions two purposes for capability modelling - project planning and service design.

• Project Portfolio Alignment - "With capability modeling, you create a hierarchy of the company's capabilities. You then identify the capabilities that best align to corporate strategy, and which one of them need the most work. Focus your work there, and you get a big payoff through focused investment."

• Service Design - "The activities are where you actually perform automation. You connect services to these activities. This is where work is done."

Nick's first answer is that a capability is a top-level chunk of business, while processes are at a lower level. In a later post, Nick says this is how FEA handles capability and process modelling. As Nick acknowledges, FEA actually calls them business areas (or Lines of Business) rather than capabilities. In my 2001 book on the Component-Based Business, I called these things Business Components, and this terminology is still used by IBM in its Component Business Model. I think this is a useful construct, but that's not exactly what I call capability.

Nick's second answer is that a capability corresponds to the objectives of a specific organizational unit. Capabilities are not directly linked to processes; both capabilities and processes use and share atomic-level activities. This is better, but I am uncomfortable with the organizational tie-up.

Meanwhile, the latest version of MODAF does explicitly include "capability" as a first class construct. MODAF includes a hierarchical decomposition of capabilities, and a many-to-many mapping between capabilities and processes (which it calls "operational activities"). This is a lot closer to my notion of capability.

Another way of getting to my notion of capability is to take Nick's second answer and remove all mention of organization units. While the organization structure may give us some important clues about what an organization does and how it does it, I am careful to avoid hard-coding the organization structure into my business models.

So what is the point of modelling capabilities as well as processes? To justify capability modelling, I want to articulate two additional purposes.

• Management of Variation - Capabilities can often be decomposed into highly generic elements and asset-specific elements. (See my example of Green Coffee Beans.) Decoupling these capabilities helps to drive higher levels of cross-process and cross-organizational sharing.

• Viable System Design - A complete system needs to include management capabilities such as planning and coordination as well as operational capabilities. With a capability model, I find it much easier to check for completeness than with a process model.

So I end up with a notion of business capability which maps easily onto business services, supported by information capabilities which may be implemented as software services. This notion allows for a much finer level of granularity than Nick's first answer, but I think it is much more flexible and powerful than Nick's second answer.

The capability defines WHAT the business does; the process defines HOW the business does it (and the organization structure defines WHERE the business does it). So we expect the capability to be more stable than the process; many capabilities should be shareable not only between different processes within a single enterprise, but between multiple enterprises.

This then raises the question of capability modelling techniques - how do we analyse capabilities? We certainly need to map capabilities onto outcomes (as in Nick's second answer) , but we also need to analyse commonalities and variations within and between capabilities, as well as other dependencies between capabilities. In fact the diagram I find most useful, both for planning and for service design, is the capability dependency diagram. MODAF V 1.1 includes a suggested notation for capability dependency diagrams, but I use a slightly different notation.

Sources

• MODAF Version 1.1 (April 2007)
• L. Cherbakov et al, Impact of service orientation at the business level (IBM Systems Journal, 44/4, 2005)
• M. Dodani, The Architecture of Business (JOT 17/4, 2008)
• R. Veryard, Component-Based Business: Plug and Play (Springer, 2001)
• R. Veryard, Capability Dependency (CBDI Journal, May 2007)

Capability and Business Strategy

In their book The Only Sustainable Edge, John Hagel and John Seely Brown describe two main schools of business strategy: the Core Competence school and the Leverage school. The approach advocated by Hagel and Seely-Brown represents a synthesis of these two schools. A closely related approach is advocated by David Alberts ("Power to the Edge").

	Core Competence	Leverage	Sustainable Edge
Focus	Resource-Based	Network-Based	Edge-Based
Source of Strategic Advantage	Identifying and strengthening core competences within the firm	Mobilizing resources outside the firm	Taking power to the edge of the organization.
Key advocates	Gary Hamel and C.K. Prahalad	Adam Brandenburger and Barry Nalebuff, James Moore	John Hagel and John Seely Brown, David Alberts.

Whereas the Core Competence school operates with a fixed notion of the required capability of the firm, the Sustainable Edge school involves dynamic specialization, connectivity and leveraged capability building. In other words, a successful business organization requires meta-capability – the capability to build capability, and the capability to build capability-building partnerships.

In our view, this kind of meta-capability is essential for the adaptive enterprise – after all, the defining capability of the adaptive enterprise is the capacity to adapt. However, in order to implement the adaptive enterprise, it is necessary to be specific about the nature of adaptation and adaptive capability required in a given context.

The capability model allows us to reason about which capabilities (or meta-capabilities) should be regarded as core competences.

 

Extract from Business Modeling for SOA - Part 1 What the Business Does (January 2006). See also Business-Driven SOA (May 2004), Business-Driven SOA 2 (June 2004), Business Systems Planning for SOA (May 2006). All available from CBDI Journal Archive.

Green Coffee Beans

Here's a little gem from page 26 of the SAP Magazine (November 2005), talking about the Global Business Services (GBS) division of Proctor and Gamble.

To obtain high economies of scale, GBS models the entire process flow but handles only those processes that are not part of the company's core business. For example, procurement of green coffee beans is managed as part of snacks and beverages purchasing, while GBS assumes responsibility for the P2P system and the vendor accounting involved.

As I interpret this, the process is decomposed into asset-specific tasks (those that are specific to green coffee beans) and generic tasks (those that are common across all purchased items).

The purpose of decomposing in this way is quite explicit. There is no stated intention of outsourcing the generic tasks, and there is no suggestion that they are not part of Proctor and Gamble's core competences. But there is a strong economic argument for managing these tasks as shared (reusable) services; and establishing these as shared services allows Proctor and Gamble to strengthen the underlying competences. The basis for this split (despite what it says in the article) is not core/noncore but asset-specific/generic.

To design services with significant levels of sharing (reuse), it is important to separate the asset-specific elements of the service from the generic elements. Asset specificity is a key determinant of service value. But here's the problem. The models that are commonly used within IT for designing component and services are type models. This means that they are already generic, they are at a level of abstraction at which asset specificity is not visible. (You don't see green coffee beans on a type model, you just see PRODUCT. You might happen to know that green coffee beans is a specific instance of PRODUCT. But you cannot use the type model to design a service that is specific to green coffee beans - or even to analyze a possible requirement for such a service.) This argument applies equally to process models or capability models, to the extent that they reference abstract types such as PRODUCT.

Thus although the Proctor and Gamble solution appears intuitively reasonable, it is not the solution that would be produced naturally and unforced by following any of the popular service-oriented design methods. (Of course, if you impose an arbitrary apriori separation of core/noncore on the problem space, you can produce pretty much any result you like, but that's not the point.)

The popular design methods (and tools) are geared for efficient solution of fixed problems, and do not provide a sufficient basis for reasoning about reuse, adaptability, complexity, and all the other things that service-orientation is supposed to bring. Asset-specificity is an important economic aspect of a service, and service engineers need ways of understand this aspect.

---

updated to remove the little symbol between "Proctor" and "Gamble" which caused problems with my XML feed earlier - sorry