Modelling with Business Capabilities

We probably can all agree that modularisation of a large complex system into smaller and more manageable parts is an actual best practise, not only for lowering the cognitive load for each part, but also for team independence and operational resiliency. The tricky bit is how one can go about drawing the boundaries, making a stable and sustainable structure of the overall system. Domain-Driven Design with its Bounded Contexts is one approach, where the language of the domain is used as a guide, another is taking inspiration from the capabilities defined by the business model to find the natural seams in your domain.

"A business capability is a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome." –Ulrich Homann

This is an abridged version of the chapter on Business Capability Modelling published as part of the free Visual Collaboration Tools book on Leanpub.

What Business Capabilities are

Business capability models are frequently used in enterprise architecture as a way to describe a company in a holistic way, representing the organisation’s business model independent of the structure, processes, people, or resources like IT systems, buildings, materials, hardware, tools, know-how etc. Everything is included, every nut and bolt; nothing belongs outside of the model, and its premise is an outside-in perspective of the company as it strictly describes what the company is capable of – its abilities.

Business capability modelling is related to the resource-based view of the firm and often regarded as an extension to it as it also supports other value configurations in addition to classical value chains, like value networks and value shops. This type of modelling may sound academic and something that only the business and enterprise architects care about, but it is quite tangible and widely applicable. Simply put, the capabilities are what the business regard itself to be capable of, what its competence is, both for internal and external parties. What makes the concept a bit hard to grasp is that they inherently describe what the company does, not how. It is an abstraction of the business reality that sets them apart from classical business process modelling, which usually focuses on how things are done. This abstractness also makes the capabilities inherently more stable than other approaches as they do not change when their implementation does, like automation using the software. The only reason for them changing is company strategy adjustments, such as deciding to pivot, extend, or moving out of some business area.

This strict and abstract business view gives its enabling components, be it roles (people), processes, information, and resources, an explicit business context. An interesting aspect of this vantage point is that the capabilities need to be fairly self-contained, meaning it must be able to deliver on that capability in relativity independent manner. Furthermore, the capabilities are naturally hierarchical and decomposable, meaning that one top-level capability, e.g. Sales, will contain a number of capabilities which again will contain another set. The number of levels differs based on the size and complexity of the enterprise, but 3-4 levels are common. 

Although it may seem that business capabilities are something that only business and enterprise architects care about, they can be used to a lot more than strategic planning and documentation, some of which may even be relevant for developers and software architects. Especially their inherent independence and logical boundary fits well with the SOA/microservices principles of autonomy and explicit boundaries, as well as the concepts of bounded contexts from domain-driven design. Even without having a defined business capability model at hand, the concept can be used to identify those services as a heuristic. If you can match the suggested boundary to something that can be characterised as a business capability, you may be on to a good autonomous service.

What makes business capabilities so versatile is their descriptive nature, that they define the problem space well and says nothing about the solution space. They are a good foundation for a lot of more detailed modelling, being stable from the business perspective and only change when the business itself changes.

How to create the model

Typically, this modelling is done collaboratively, getting all the people with the right business knowledge into the same room. This is not something a few people do on their own in isolation, but it may be advantageous sometimes when starting from scratch for somebody to build a straw model before inviting busy people to contribute to it in the workshop.

Before inviting people to participate in a workshop, it is always important to be explicit about the expectations. Whether the goal is to define a big picture map of the whole enterprise or if it is detailing the lower-level capabilities indicates who needs to be involved. For the top-level mapping senior business leaders, enterprise architects, and business architects from across the enterprise are needed, while for the detailing of specific capabilities people with deep knowledge of that part is required, like product managers, system matter experts, and software architects. Although it can seem sensible to try to create a full capability map, going all the way from the top to the lower levels of the hierarchy, the effort will most likely overshadow the benefits. Therefore adjust the initiative to the specific goal at hand, be it creating a top-level model to be used for business modelling or to modularise a software monolith belonging to one of those top-level capabilities.

The goal is to capture and document the capabilities that represent what the business does now and what it desires for the future. In most companies, some sort of business model and business architecture already exists and should be brought to the workshop as input, be it value chain analysis, business processes, and business plans. Even existing org charts can be interesting for inspiration, as well as a list of core business entities. For some industries there even exist publicly available reference models that can be beneficial to take a look at.

To learn more about business capability modelling and how you can do this in practice, with tips and tricks in how to run a workshop and how to define and document the result, check out the free Visual Collaboration Tools book on Leanpub. Here you can also can learn more about a number of other great modelling and collaboration techniques like Event Storming, User Story Mapping, Domain Storytelling, Business Model Canvas, Example Mapping, Impact Mapping, Wardley Maps, and much more, all written by industry experts with a lot of experience using the tools. By paying a small fee you can also contribute to a good cause, a diversity program in tech.

If you want to learn more about what business capability models, I have a few talks on this, the most recent being this from the #DDDDD Conference: