Business Capabilities (a practical guide)

 In my last post about using enterprise architecture to create long term IT planning, I argue that business capabilities are crucial for this work but I didn't explain in details what are business capabilities and what need to be done to collect and model them. As I promised this post is dedicated to business capabilities.

First of all let me explain what are business capabilities (at least as I see them). Business capabilities describe WHAT the business is doing to reach the business goals and objectives. Each business capability should have an input and it must generate value to the business. Although business capabilities can be used in business processes that describe HOW the business is doing daily work, business capabilities never deal with HOW (just WHAT). Each business capability might have corresponding business process that describes how the capability being done (people, data, events, decision points, capabilities and relations between all mentioned elements)

I tend to order business capabilities in hierarchal manner, starting form high level business functions and breaking them to low level functions. Some people tend to break business capabilities by organization structure. Although this is very convenient and easy way, it creates a twisted view of the business capabilities (usually because capabilities are cross organization). In an hierarchal view of business capabilities low level capabilities could be duplicated and exist in several high level capabilities (Sometimes this scenario is bad sometimes it good).

[figure 1 - Business Capabilities map]

Business capabilities are a way to model your business, but they are also one of the best way that I know to bridge between business and information technologies. To create the bridge we simply use business capabilities as a hook that we want to hang on all of the IT assets that we have (as you can see in the below figure).

[Figure 2 - EA meta model]

In addition to hooking capabilities to IT assets we keep certain amount of properties for each capability. Keeping many properties might be very impressive, but always remember that you need to maintain the data that you entered as well. The trick here is to understand what it the purpose of your enterprise architecture work and to collect just the needed data for this propose.

Common usage of business capabilities:

• Create alignment between Business and IT
• Enable creation of business oriented IT roadmaps
• A tool that helps business improvement efforts
• Services identification
• What are the services that the business need
  • In the right level of granularity
  • To enable business agility
  • To be implement by IT

• Validation of vendor’s packages to business needs

A common list of properties that I'm usually using:

• Name
• Description
• Used by
• Owned by
• Input (data)
• Output (data)
• Availability
• Response Time
• Reference to documents (plus relevant paragraph)
• In service date
• Childs (BC)

One of biggest advantage of business capabilities is that they required much less resources and effort to maintain, while bringing the same ROI for enterprise architecture as business processes will generate. Focusing on the what reduce significantly the amount of resources needed to maintain them.

Business capabilities effort can be spitted into 5 main steps:

• Initial collection of dada. Collect all the data that you can by yourself and try to build first version of the business capabilities map and use it in the next step. The most common resources that you can get to build the map are:
  • Job Description
  • Internal procedures
  • Business Reference Models
    • SCOR
    • VCOR
    • SAP Business scenarios

• Interviews. After you have some starting point as a reference, start to interview business users to validate and change the map. This is iterative process that might take some time and usually involved usage of your soft skills.
  • Don’t come to interviews with empty hands! Use collected data to create initial model. Use them to facilitated interviews
    • Use Nylon cover and camera to take interviewees comments and compare them
  • Valid and augment initial map

[figure 3 - Using capabilities map in an interview]

• Formal approve (By Biz management). If you can get CxO level approve you are on the right path to success. If not try to get any high level management approve, just make sure that business management participant.
• Relate IT to Business Capabilities. I already discuss it in my previous post. Ask business users to set what are the IT resources that they are using to carry on capability and to what extent IT assets are helping them. IT assets should include:
  • Application
  • Technology
  • Services

• Relate business capabilities to Business objectives. While low level capabilities mapped to IT, high level should be mapped to business objectives. Relating capabilities to business objectives will help us to understand what is the Wight of each capability from business point of view.

Useful tips (or what I learned from mistakes :-) ):

• Don’t use one big bang approach, Do it in phases!
• Always work on two levels of hierarchies. While going through the interview process, lower level capabilities helps (both you and the interviewee) to understand higher capabilities.
• Get agreement on capabilities before defining capabilities attributes. Collecting capabilities attributes is a process which takes time. Don't invest this time until you sure that you have a list of the agreed capabilities.
• 5-6 level of hierarchies are magic number where all of my clients stop. It doesn't matter the client size or location, we always stop in this level. The granularity of Level 5-6 enable us to hang several applications on each capability. In Higher level you'll find yourself hanging tens of applications on each capability. In lower level you'll find yourself drown in tones of details.
• Start from the first two high level. Then focus on one of the second level capabilities and drill down to the 5-6 level.
• Face to face or group approach: I found out that face to face is much better. Face to face reduce the "I need to show how smart I am" syndrome, thus reducing the time it takes to reach common understanding and agreement.
• Don’t fall into the organization structure trap. Follow roles, not their location in the organization structure.
• Each capability name should be a combination of one Verb and one Noun.
• Each capability should have different combination of functionality, input and business value as outcome.
• Use an EA tool to do the mapping. Tool has many advantage such:
  • One place to see all architecture components and relations between them
  • Ability to run impact analysis scenarios
  • Ability to run “What-If” scenarios
  • Use reporting (textual, hit-map, etc’)
  • Integrate capabilities with SDLC

Business capabilities are very powerful both for business, information, applications and technology architecture. Once you went through the process of collecting them you have an important asset that will serve you as enterprise architect in most of your tasks. Business capabilities won't just help you in your tasks they will also give you much more time to do your work, because they demand much less resources for maintenance (if you looking for an analogy, business process are like dogs while business capabilities are like cats).