Working Draft

This site is currently a working draft of the ITABoK 3.0. Release date is planned for beginning of 2018. In the meantime please utilize the current ITABoK version 2.0 

Business Capabilities

  • Represent something the business does to create value, regardless of organization or implementation
  • The model for the capability view is a hierarchical map
  • Capability maps usually go three to five levels, depending on needs
    • Most of the interest is at level three, many maps stop here
  • One of the most common uses is to indicate via color those capabilities that need the most investment
    • This is done for every investigation

The scheme used to organize the hierarchy need not be fixed. In fact, it’s convenient to use multiple hierarchies that organize the capabilities in different ways. Some schemes include

  • Functional decomposition (tends to reflect and be influenced by the org chart – this should be reversed)
  • Shared characteristic (e.g. owner, consumer, user of a resource, etc.)
  • Subway routes on the process map (covered in module 6)
  • Level of investment required
  • Maturity
  • Do not reflect variations due to channel, business unit, or location
  • Describe the “what” not the “how”
  • There is a raging debate about naming capabilities
    • Noun-phrase (eg Customer Information Capture)
    • Verb-phrase (eg Capture Customer Information)
    • Note that names that contain “Manage” or “Process” are generally poor names (but you see them a lot!)
      • Usually indicates a group of capabilities
    • Provide the business with a common vocabulary
    • Enable highly-focused investment decisions
    • Serve as a baseline for strategic planning, change management, and impact analysis
    • Serve as the basis for transformational design and deployment

Figure 1 Example

 

Identifying Business Capabilities

  • Build stakeholder experience maps
  • Identify touch points
  • Identify value-delivering capabilities
  • Identify supporting capabilities

Identify Touch Points and Value-Delivering Capabilities

Some people call these “core” capabilities, but they may or may not be. Core capabilities are those that distinguish one business from its competitors. In contrast, value-delivering capabilities are simply those that deliver value to an external stakeholder. Within a single industry, different businesses will have different core capabilities, even though they might have the same services and value-delivering capabilities.

  • A touch point is a point of interaction on an experience map
  • Each touch point is a business service provided by a capability
  • These are your value-delivering capabilities
  • These capabilities are supported by other capabilities, sometimes with time or other types of dependencies

Identify Supporting Capabilities

This is the easiest way to capture the entire scope of a capability model.

  • Support capabilities can be proprietary or generic
    • Proprietary work needs to be owned or licensed
  • Support capabilities should be owned only if it’s cheaper than buying it
  • Direct support capabilities help the value-delivering capabilities run more smoothly
  • Essential support capabilities are required in order to stay in business but don’t directly benefit the service delivery
  • IT can be direct support if it provides systems that directly support value-delivery (such as assist or deliver)

 

You may also find capabilities that do not appear on a map. These are prime candidates for elimination as they don’t provide value or support providing value to external stakeholders (so who benefits from them? You may have missed a stakeholder, too).

  • The Ishikawa (“fish bone”) diagram is a convenient way to indicate dependency of one capability on another
    • The value-delivering capability is the arrow
    • The branches are supporting capability upon which it depends
    • You can indicate the kind of dependency if desired
  • Many capabilities will show up on multiple fish bones as they support multiple touch points
  • Taken across all experience maps, these networks represent all of the capabilities you need to provide as a business

 

  • Service touch-points give you enabling or value-delivering capabilities
  • Build networks of supporting capabilities that deliver everything required to deliver the service

For example, to be able to sell an item to a customer in a store, the following process, among many others, need to have been completed:

  1. You need a certain number of employees to be on the floor when the customer walks in
  2. The product needs to be on the floor as well – this is the result of a whole host of merchandising and inventory capabilities
  3. To get customers in the door, you probably had to do some marketing and create some offers
  4. To know who to aim the offers at, you had to have a strategy and customer segments
  5. To pull any of this off, you had to have financing
  6. You need to be able to record the sale and use of inventory and to comply with all regulations and laws
  7. And so on…
 

Proprietary

Generic

Direct

Provide – do it yourself

Broker – develop on-going access to the best capabilities possible

Indirect

Maintain – manage internal capability to meet cost and quality standards

Contract out – monitor to ensure compliance

Figure 2 Perry, Stott, and Smallwood, Real-Time Strategy: Improvising Team-Based Planning for a Fast-Changing World, New York, NY: Wiley, 1993.

To provide means both owning and developing support capabilities

To maintain means that capabilities can be owned, but downplays the importance of improvement

To broker means to outsource it, but pay careful attention to make sure the work is done to specification

To outsource means to enter into a contractual relationship with a supplier, but not pay much attention to it

 

Classes of Capabilities

  • Value-delivering
    • Provide services visible at touch points on experience maps
  • Direct support (value-added to some people)
    • Enable value-delivering services
    • Main branches on supporting capability diagram
    • Examples
      • Merchandising in a retail business
      • Network provisioning in a telecom
    • Indirect support or essential support
      • Provide indirect or far-removed support
      • Examples:
        • Most functions in Finance
        • Most functions in HR
        • Corporate strategy

 

Assessing the Impact of Change

One of the tasks of the business architect is to determine the scope of a change

Simply, this means looking at the capability model and identifying those capabilities likely to be affected by a change

If you don’t have a capability model, this is anything but simple

Building architects use a technique called “red-lining”

They take a set of blue prints that are updated to match the current building configuration

They then use a red marker to indicate the changes on the drawings

It’s a very effective practice that results in a clearly defined scope of change

Indicate on the subway map which capabilities will change. Do this separately for each proposed capability change. Relies on the notion that subway stops are also capabilities.

References

Perry, Stott, and Smallwood, Real-Time Strategy: Improvising Team-Based Planning for a Fast-Changing World, New York, NY: Wiley, 1993.

Business Architecture Guild, A Guide to the Business Architecture Body of Knowledge, v3.1.1, (BIZBOKTM), 2013.