Jacek Majchrzak
  • Home
  • About
  • Work with me
  • Blog
  • Contact
28 December 2020 by Jacek Majchrzak

Business Capability in-depth explanation

Business Capability in-depth explanation
28 December 2020 by Jacek Majchrzak

Links to articles from series:

Business Capability Modelling Overview (article 1)
Business Capability in-depth explanation (article 2)
Business Capability Model and its use cases (article 3)
Business Capability Modelling workshop recipes (article 4)

What exactly is Business Capability?

Business Capability is an abstraction that represents the ability of the business to achieve a specific outcome or value. Capability is a potential that the business possesses. Business Capability is a way to encapsulate business volatility inside of the abstraction. By encapsulating volatility, we are creating stable connections and dependencies between parts of the model. Business Capability remains stable if we focus on the question ‘what?’ and not on questions: ‘how?’, ‘who?’ and ‘to whom?’. But what does it mean?

Ability To

Business Capability is the ability of a business to achieve a specific outcome or value. You should be able to describe business capability with a sentence that starts with: “It is an ability to…”, like, “Apartment Handover is an ability to accommodate a person efficiently and smoothly on demand.”

Abstraction

Business Capability is not precise. Its outcome defines it, and you can achieve the same outcome in different ways or for other purposes. Due to that, Business Capability could be instantiated in many different ways. We could achieve efficient person accommodation by delivering keys by a property manager or by sending SMS with a password to the electronic lock. The outcome would stay the same so that we can develop an abstraction like Apartment Handover.

Outcome not output

The capability should be defined by its outcome. We should not differentiate two capabilities when they result in different outputs but the same outcome; in this case, we should merge them into one abstraction. The outcome is not equal to the output. The output is only quantitative when the outcome is also qualitative. If you are organizing a birthday party, then a successful party & happy kids are the outcomes you would like to achieve. Organizing a clown or cooking a birthday cake might help, but those are one of many possible outputs. There are other ways to make kids happy; ten small puppies should do the work too! Focus on those things that matter, like happy kids, and not how you will achieve it.  When you are modeling capabilities, you should try to build them around expected outcomes, not outputs.

Product or a service

You should think about Business Capability as a complete whole or something autonomous. You should be able to sell your capabilities as a product or service outside of your own company, or other way around, you should be able to outsource it.

Interior

Let’s look closer at what we can find inside a single capability. Business Capability is a combination of Roles, Processes, Information, and Tools. To be able to deliver capability, you have to utilize many company resources. First of all, you need to have the right people with the skillset. Usually, those people have some processes around their work, and they also need access to some pieces of information and tools. 

A good example is a capability like “Cleaning services.” You need to have a cleaning staff (roles), they should perform their work in a specific order to make it more efficient (process), they also need to know what and how to clean it (information). And finally, to do their work, they require a vacuum cleaner (tools).

Capability is stable, unique, lacking purpose & decomposable 

Stability 

The adequately designed capability should not change in time. If you would travel ten years back or into the future, your company should still contain the same capability. The capability should also not depend on the people performing it or those on the receiving end.

 Uniqueness

Capabilities in the organization should follow the MECE principle. MECE stands for: mutually exclusive and collectively exhaustive. It means that inside your organization, capabilities should not be duplicated, there should be only one instance of each of them, and capabilities should not overlap.

MECE principle - mutually exclusive and collectively exhaustive
MECE principle

Lack of purpose

Capabilities should be created in isolation from the context in which they might be used. The capability should be reusable in a different contexts.

Decomposable

Capabilities can form a hierarchical structure. Higher-level capabilities can be decomposed into lower-level capabilities. 

Capability verification – 4-step validation

How would you know if your capability is a true capability designed by definition? You can apply 3-step validation.

Step 1: Time travel 

Ask yourself questions: how this capability was done 10-20 years ago? How this capability will be done, or the same outcome will be delivered 10 years from now? Use your imagination. Your answers should not change the name and meaning of business capability. If you noticed that your capability was changing in time, you probably miss some better abstraction.

Time travel

Step 2: Ask for a favor

Could I ask some other role/person/actor/system/robot to deliver the same outcome? Has it changed the name or meaning of your capability?

Step 3: Different customer and different context

Can you imagine using your capability in a different situation/setting/context? Could you use a cleaning service, not in the apartment but also in the office? You should be able to do that.

Step 4: Capability as a product

Could you create a small company that has a purpose to provide just this one capability? Can you imagine how you will market it as a product? Could it be outsourced to another company?

Key takeaways:

Business Capability

  • can be described with the sentence: “X is an ability to…”
  • is an abstraction
  • is defined by its outcome
  • is a standalone product or service
  • is a combination of Roles, Processes, Information, and Tools
  • is stable, unique, lacking purpose & decomposable
  • can be verified with 4-step validation

Links to articles from series:

Business Capability Modelling Overview (article 1)
Business Capability in-depth explanation (article 2)
Business Capability Model and its use cases (article 3)
Business Capability Modelling workshop recipes (article 4)

Previous articleBusiness Capability Modeling OverviewNext article Business Capability Model and its use cases

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

About Me

Jacek Majchrzak is hands-on Software Architect and Technical Leader. He is specialised in organising and facilitating Architecture Design Workshops and Software Project Kick-offs using techniques like Event Storming, Design Studio, Risk Storming and User Story Mapping.

Recent Posts

Business Capability Modelling – workshop recipe28 December 2020
Business Capability Model and its use cases28 December 2020
Business Capability in-depth explanation28 December 2020

Categories

  • Architecture
  • Facilitation
  • Technology

Tags

architecture Business Capability Model Business Capability Modelling data architecture Domain Storytelling event-driven data mesh EventStorming Example Mapping Facilitation Impact Mapping User Story Mapping

All rights reserved © 2020 Jacek Majchrzak

Except where otherwise noted, drawings on this site are licensed under a Creative Commons Attribution 4.0 International license

LinkedIn – Twitter