Value Chains - A Great Scoping and Positioning Tool

Enterprise architecture covers: business, information, applications & infrastructure.  With all this to cover how can we maintain agility. A signficant danger in enterprise architecture is getting caught up in analysis paralysis or being overwhelmed by scope.

Value Chains (as defined by Porter) provide a good way to quickly define scope of activities within an organisation. The structure is clear and easily grasped:

• Core Activies: Inputs + Value Add Activities + Sales + Service
• Supporting Activities: Facilities & Infrastructure + People + Technology + Procurement

While Porter's orginal value chain was concerned with the activities within the organisation, "Industry Level" value chains actually predate these and provide view of broader eco-system.

Within business architecture community a "Capability Model" has mostly equivalent content (in terms of activities identified) though it has a different struture than an Organistional level Value Chain.  Other variations such as value streams, chains and business component models also contain simillar content.

The important thing to remember is that each of these are either organisational or eco-systems models and the model in itself is just a starting point.

The model must have a clear audience and purpose, typically these can be:

• Rapidly communicate scope of business activities across a broad audience
• Provide a framework for comparitive analysis across organisations within the same business segment,
• Provide a framework for quantitiative analysis of business performance (investment allocation, hot spot analysis, maturity analysis, portfolio analysis),
• Provide a framework to capture performance measures, point of interaction and coupling / dependencies across processes and organisational units

There are a number approaches to developing value chains:

• Leverage existing asset - faster, likely more mature but potentially confronting to audience
• Craft one - slow, frustrating to participants, can get lost in the modelling,
• Generate it - as part of data analysis not as input into data analysis

The "Generate it" approach has distinct advantage as it drives toward using the model for analytical purposes, rather than as an end in itself.

If you are intending to do cross organisational analysis then leveraging an existing asset is essential as this is likely to provide a consistency (immutability) across the different organistions required for comparitive analysis.

"Crafting one" runs into danger of only being applicable to current context and not supporting impact of transformation on the organistional structure.

Some advise to practitioners to meet the goals of "Just Enough Architecture"...

1. Don't fall in love with your model ;-) ...

Here are examples of three industry value chains that cover the same industry (Media / Telco):

The important thing about the value chain is that is is mostly right and at this level they generally are. The value in the value chain is the analysis that sits behind it. Adopt one and do minimal updates.

2. Plan to keep the time in developing the first draft of the model short and sharp.

Remember the value chain and associated capability or compoment models are in themselves not the prime objectives. So keep time in developing a first cut (no more than a single "Sprint") to a minimum with clear aims for its target use and attribution.

3. The value of value chain is its use to support quantitiative analysis and fact based decision process. So expect that this is where most of the time will be spent

The collection of data and infomation to establish a fact base, do analysis and render this via the value chain is what takes time and brings the insight. So you need to allow for this. It is also during this time that you can get to establish relationships with component owners and get insight on information. This is essential to get traction on objectives and analysis.

4. Iterative Elaboration is key to doing "Just Enough". It is better to get first cut in place and then iterate to bring in addtional details and further attribution for next level of detailed analysis. Typically this iterative elaboration is also used to develope a more complete "capability" or "component" view of the business landscape.

This is all simple and sound advise, but to often Enterprise Architecture looses sight of goals and gets mired in obsession around details, modelling concerns and internal bluster.

Just Enough Architecture requires that architecture is grounded in providing valuable input into decision making process and helping in a timely manner.

A goal of data driven organistion is establish a process that is able to collect the analytical data in repeatable manner and re-render the analysis against this on an ongoing basis. Right now most organistional still rely on very labour intensive collection and analysis process using spreadsheets.

References:

Value Chains - originally defined by Michael Porter - "Competitive Advantage". 1985, Ch. 1, pp 11-15. The Free Press. New York.

Value Chains, Value Stream & Value Nets - Componentisation, service orientation, disaggregation & platforms drive dis-intermediation based models which view eco-systems as set of interacting and collaborating parts, which can be wired together in many ways.

Capability Model  & Planning - TOGAF defines capabilities across mutiple layers and recognises that the creation of capabilies is a process of evolution with increments and planning

Component Business Model - A modelling technique defined by PWC/IBM consultant Guy Rackham,  which views business as a set of components, which encapsulate: people, process & technology and expose service interfaces to support their interaction

NOTE 1: See Industry Pages - for an example analysis use in Media / Communications..