Subscribe to Updates

Capability Model: Do’s and Don’ts

A Capability Model or Capability Architecture or Business Capabilities Model or Business Capability Map are all synonymous with the same concept – defining an abstract model that encapsulates the essence of what business does and can do.  (Please check here for the definition of a capability map.) A 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.

While a 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.

Capability Model – Eight Do’s and Don’ts:

Capability Model Sample

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, 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 nomenclature and the structure of the model, it is imperative that they participate, if not lead.

Think broad and granular, 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.

Capability Model - Decomposition to granular level

 

 

 

 

 

 

 

Focus on outcomes, not artifacts:

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.

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.

Deliver Incremental Value, 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.

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 strategy is defined by the corner office along with the strategy development team.  The operating model is determined by the C-Suite, 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 Architecture Value Stream 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.  (Well, here is a pitch for using Capstera for building and managing a capability model and other artifacts.)

Capability Model Software

If business architecture teams keep these 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

[mc4wp_form]

If you wish to align your Business and IT, and link Strategy to Execution, please subscribe to Capstera’s robust business architecture and capability modeling software.