Get a Free Deliverable

Business Capability Modeling – Best Practices for Capability Mapping

What is Business Capability Modeling? 

Capstera defines business capability modeling as an art and science to encapsulate the essence of an enterprise by way of elemental building blocks – the business capabilities.  A business capability map is a comprehensive and cohesive set of business abilities of an enterprise. Each capability is a manifestation of what a business does and can do.  The mutually exclusive and collectively exhaustive set of business capabilities are an abstraction of the underlying functions and may include current as well as target capabilities. An enterprise capability model is a powerful tool in conducting a current state assessment and facilitate future state envisioning and crafting a transformation roadmap with an incremental maturity of capabilities to achieve the desired target state. 

A purpose-built enterprise business capability model is an essential tool in business architecture and helps to align business and technology and translates strategic intent into operational and IT enablement parameters.

What are the benefits of Business Capability Modeling?

  • Common language: Business capabilities act as a common language between business and technology teams minimizing ambiguity between business and technical speak.
  • Silo’ed Development: Aligning requirements to capabilities will decrease the likelihood of building fragmented functionalities which are compartmentalized in different business units. Enterprises benefit by 15-20% savings on overall discretionary budgets through rationalization of requirements at a capability-cluster level (platforms).
  • Technical Debt: Capabilities provide transparency and look through to help minimize unintended technical debt. The spiraling of technical debt is crippling large organizations with legacy IT landscapes and this is a significant benefit and ranges from 10%-20% of discretionary spend.
  • Application Portfolio Rationalization: A footprint analysis of capabilities use (which business units and operational entities use what capabilities) and which systems/services support (which systems/services power what capabilities) provides clarity on redundant and multiple systems for some capabilities and allow for rationalization of the portfolio and retirement of systems. These savings can be funneled to a discretionary project.
  • Shaping the API/Microservices Architecture: A well-defined capability model at lower levels of granularity can form, influence, and modulate the Microservices that power them. This avoids either too coarse-grained or fine-grained services and the proliferation thereof.
  • Future Orientation: Instead of thinking about technologies (digital and cognitive technologies for example), conceptualizing the needs of business in capability terms (what is required) allows for technologists to define how (which concept/solution/technology to use) to power the business need.
  • Capability-based Budgeting: A capability-centric capital budgeting allows focusing on what is essential for the firm and investing for the long-term, rather than funding annual projects with piecemeal functionality across multiple divergent capabilities.
  • Target Operating Model: Capabilities can operationalize and realize the target operating model
  • Product Model Linkage: Capabilities or more importantly, clusters of capabilities, can map to an IT product model.

While a business capability model can be a swiss army knife regarding its utility and value, several firms make the following mistakes:

  • The Capability Model is not granular enough to be practical and actionable.
  • The Capabilities do not conform to the principles of MECE (mutually exclusive and collectively exhaustive)
  • The capability model is a checklist item done by IT teams for business

 If you are trying to solve these BHAGs (Big, Hairy, Audacious Goals), then there will be a support for not only crafting an enterprise business capabilities map but other components of the business architecture as well.

These are fatal flaws and can severely impede the value of a business capabilities map.  Here are some do’s and don’ts that could help your enterprise business architecture team in building a business capabilities model that extends beyond the necessary boxes and arrows diagram.

Sample Business Capability Modeling Exercise: Capturing high-level capabilities

The following is a Level 1 representation of an enterprise business capability model. 

Business Capability Modeling - Sample Level 1 capabilities

Business Capability Modeling – Eight Do’s and Don’ts:

Think Strategic, not focus on tactics:

If business architecture and building a capability model were to become “another thing,” it would diminish the value of the endeavor.  Instead look at specific strategic lacunae in the enterprise. For example, is there a gap between strategic intent and operational execution?  Is there a general dissatisfaction about the IT enablement efforts in that they do not indeed solve the business need and are a day late and a dollar too expensive? Alternatively, is there a proliferation of applications causing redundancy and replication – in perhaps more than ten ways to enable a simple business need?  Is there a constant accumulation of technical debt making the IT operation burdensome?  If you are trying to solve these BHAGs (Big, Hairy, Audacious Goals), then there will be a support for not only crafting an enterprise business capabilities map but other components of the business architecture as well. 

Engage the business in Business Capability Modeling, don’t do it for them:

One of the cardinal sins committed by business and enterprise architects is to do a capability model on behalf of the business.  It becomes an IT deliverable and never really will resonate with the business teams. Instead, collaborating with the business is better, and business teams are leading the development of a capability map is even better.  If the goal is for the company to speak the same language and embrace the terminology and the structure of the model, it is imperative that they participate, if not lead. 

A simple but effective tool is to engage the business with a business capability model template, instead of whiteboard elicitation. 

Think broad and granular level capabilities, not super high-level:

A pet peeve of us at Capstera is that many a time, capability maps are at level 1 or level 2 which are an essential strategic artifact, but not sufficient for some of the operational and IT purposes. A box for “Human Capital Management” is right but does not show what human resources function does and what services it fulfills and what features it provides.  This approach makes it a deliverable that immediately makes good Wall Art but not necessarily useful on a daily basis.

(A sample Gartner business capability model or a Forrester Capability Model are meant as a starting point and hence are typically at a high-level. While they are useful for strategic conversations and having a holistic snapshot of the enterprise, they are not in-depth enough for operational and technology enablement use cases.)

Sample Business Capability Modeling to a Granular Level: 

Business Capability Modeling - Decomposition to granular level

 Focus on outcomes from capability mapping, not artifact generation:

If you ask a business architect, she or he may say “We build a capability model,” “We map Value Streams,” and “We develop Heat Maps.”  Instead, a strategic business architect will say something like “We are building a digital capability map and a  transformation roadmap with business capabilities as an anchor” or “We are analyzing the footprint of capabilities and systems to analyze the need for an application portfolio rationalization.”  Whether it is linking strategy to execution, strengthening the operating model, assisting in the digital transformation, optimizing the speed, usability, and utility of the IT enablement – all of these are focusing on outcomes not just artifacts.  The deliverables are a means to an end, not an in themselves. One can create a simple business capabilities model Wiki with nothing but a nested list of capabilities and achieve significant benefits. 

Solve practical problems, not develop esoteric models:

If the company is in middle of a transformation, the business architecture team drawing boxes and arrows for an interminable time does not sit well. If on the other hand, if the capability model is a deliverable that directly adds value and contributes to the advancement of a particular corporate strategic goal, then there will be a synergy with the overall organizational efforts and the business architecture deliverable becomes an integral part of the global effort. Instead, artifact development that is devoid of specific value-add takes always deemed as an ivory tower deliverable – important perhaps but not invaluable. 

Derive incremental value from a capability model, not boil the ocean:

In one of our consulting assignments, one of the reasons the company soured on capability modeling and business architecture is due to a prior attempt that took 2-years to develop and covered only a portion of the enterprise business units. There was much ambiguity, lack of depth, and terminology was alien to what was the standard lingua franca in the firm.  So, no wonder, the endeavor went nowhere.

To avoid focusing on artifact development, a simple capability model framework which lists essential components, critical views, and key relationship mappings will help keep the focus on moving the needle. 

Leverage Other teams’ work, not reinvent the wheel:

What elements of business architecture are the exclusive purview of a business architect and what are other aspects where the system of the record belongs to a different team? More than one can imagine.  For example, a capability model should be a business-driven endeavor facilitated by the business architecture teams.  The IT systems are typically a part of the enterprise architecture team or the CIOs office.  The data entities or subject areas are a part of the work by the data architecture team.  The processes, which are typically a step below the value streams, are done by process architects and business analysts. The corner office defines the strategy along with the strategy development team.  The C-Suite determines the operating model, and the organizational structure is an HR-driven deliverable.  So, all in all, the business architecture team should consider themselves a conductor of a symphony, not a solo act. The value is in integration, preparing views and viewpoints, mapping relationships, identifying patterns, and unearthing opportunities.  

Business Capability Modeling  - Value chain example

Design for change, nothing is set in stone:

Any diagram or artifact does change before even the ink dries. So, the business architects must be aware of the dynamic nature of the enterprises today and design for constant change – minor and major.  Hence, artifacts in office productivity applications such as Excel, PowerPoint, Visio, and Word are not conducive to easy maintenance.  For capability models to be alive and ongoing, it is essential to use a business capability modeling tool. (Well, here is a pitch for using Capstera business capability mapping software for building and managing a capability model and other artifacts. Of course, in addition to Capstera Capability Mapping tool, there are many different business architecture and capability model tools in the market.)

Capability Model Software

If business architecture teams keep these best practices, and the do’s and don’ts in mind, they can elevate their craft to be an integral and vital part of the organizational transformation. 



Related Products: 


Sign up for Newsletter