Before we get into some more fancy stuff, we need to have a solid foundation to build upon, so we return to our business architecture bedrock: capabilities. This StraightTalk installment shines a light on the realities of capability mapping and helps us to interpret some key concepts in the BIZBOK® Guide in an effort to move us forward in unison and architect great things for our organizations and societies.
P.S. Capabilities are really important and the connector to every other aspect of the business architecture (and other disciplines, too), but they aren’t the only domain in the business architecture. Don’t forget that they have a BFF called value streams, which are also critical, as well as the eight other domains, too. If you are new to business architecture, we recommend you read Post No. 12 on the business architecture core domains and Post No. 13 on the business architecture extended domains before moving on.
Capabilities have been around for a long time now and we all know what they are. What’s the big deal?
We like to think that is true, but we need to speak truth here so that we can recognize where we really are as a global community and move forward in greater alignment. Truth be told, we all use the word capability — and we frequently even cite the same definition — yet what we actually write down as capabilities can differ quite a bit depending upon our experiences and methodologies used. Various industry reference models do the same in that they provide capability models or maps, but the content listed as capabilities varies quite significantly.
Think of an aisle in your favorite grocery store labeled Produce, where some of us put fruits and vegetables in it, some of us put sandwiches in it, and some of us do a bit of both.
And yes, we are the very discipline whose purpose is to build common understanding within our organizations, but we do not always do the same for ourselves, even on one of the most fundamental concepts.
P.S. The term capability map (instead of capability model) is intentionally used here as that is the specific selected language of the BIZBOK® Guide. “Tōmato, tomahto”… you get the idea.
How should we define capabilities then?
The BIZBOK® Guide leads us to base capabilities on business objects, so capabilities then are actions performed on objects.
What is a business object and what does it have to do with a capability?
The term business object is the one used throughout the BIZBOK® Guide. Think about business objects as the core nouns that form the vocabulary of your organization.
Here is a highly important concept from the BIZBOK® Guide that helps to explain this. The capability map and the information map are intimately tied, and together they establish the shared business vocabulary for an organization.
Here are some ways in which they are tied:
- The level 1 capabilities on a capability map (e.g., Customer Management) are always based on information concepts (e.g., Customer)
- The definitions of information concepts in capability definitions should match how they are defined in the information map or glossary
- Any “matching” capabilities (e.g., Agreement/Product Matching) should match any relationships that are pictorially represented in the information map
Give me some more examples.
Good examples: Customer Management, Product Management and Agreement Management are all good level 1 capabilities because they are based on business objects.
Not so good examples: Sales Management and Procurement Management are not good level 1 capabilities because they based on functions or value streams that would leverage multiple business objects. For example, Sales would instead be reflected as a value stream for a customer to Acquire Product, which would bring together capabilities from many level 1s including Customer, Product, Agreement and Payment. Procurement would instead be reflected as a value stream for an internal stakeholder to Acquire Asset, which would bring together capabilities from many level 1s including Partner, Asset, Agreement and Payment. As a result, level 1s like Sales Management or Procurement Management would repeat some of the same child capabilities below (e.g. for agreements and payments), which creates redundancy — and goes against the purpose of a capability map, which is to be a non-redundant view of the organization.
What do people typically base capabilities on then?
In practice, there are of course many good business object-based capability maps in use, especially as the adoption of the BIZBOK® Guide continues to increase. However, a large majority of capability maps list other things as capabilities, including a mixture of functions (frequently used), value streams or processes, or various other custom groupings.
This inconsistency tends to happen when we:
- Haven’t yet learned how to do capability mapping, so we tend to default to something we’re used to like functions or processes
- Try to please others and make the capability map wording more familiar to them, because they are used to thinking in organizational structures or processes
- Follow a methodology or use reference models which define capabilities as functions, processes or other groupings
- Do not leverage other business architecture domains (e.g. organization mapping, product mapping, stakeholder mapping) and thus make the capability map do all the work to reflect all of those nuances, which we should instead be cross-mapping the capabilities to
Why does it matter? Isn’t this just theoretical when it’s most important for an organization just to agree on something?
Agreeing on something is a good start, and we all know it’s hard enough to do that. But, if we all start doing our capability mapping consistently and according to the same industry principles, then we can not only deliver the best benefits for our organizations, but also put the pieces together in new ways both within and across organizations.
- From an individual organization’s perspective — A business object-based capability map ensures that capabilities are unique and non-redundant. So, for example, we can actually know when two people are planning to invest in or change the same capability and have a conversation about it. And, as we will learn in our follow up Post No. 52, business objects are ubiquitous throughout the business architecture, playing an important role throughout both the business architecture (e.g. in value streams) and the IT architecture as well.
- From an industry perspective — Creating capability maps in a consistent way helps us to be a cohesive global discipline, making things like hiring and onboarding people to our teams much easier. And, we can spend our time architecting with capabilities instead of defining what they are. A common approach to capabilities also makes it possible to combine and leverage them across business units and even across organizations, such as in cases of mergers and acquisitions, joint ventures or extended ecosystem definitions. This will become increasingly important as our world expands with globalization and digital transformation.
So, what do we do if our capability map is not purely business object-based?
You can always adjust. If your capability map is primarily based on functions or some other grouping, you can shift to a business object-based capability map in different ways. For example:
- Redefine your capability map based on business objects — Go cold turkey. Recreate your capability map and move away from the old one. This is often the most expeditious and least painful way to do it.
- Evolve your capability map to be business object-based over time – Step into it. One option is to start by defining your business objects in a separate information map or glossary to at least provide a common way for people to interpret the words used in your capability map. You can also switch out level 1s over time, starting with some that are easier to adopt like Customer Management or Product Management, until you have converted the map to be purely business object-based.
Here’s a handy diagram that describes all of this:
I’m there, but this “business object” language just does not resonate with business people.
This is a valid concern. It can take time. It helps to remind people that the capability map is fit for purpose to achieve specific results, and it’s not the only view of the organization.
When it comes to broader socialization of the capability map, it is always best to introduce it within context when you can show how it was used to produce business insights and value versus socializing it on its own. It’s always a journey and using the capability map to provide real business results will be the best selling point in the end.
More Good Stuff…
What Is Business Architecture? (S2E white paper): Just in case you haven’t read it yet, check out this foundational white paper that cuts through the myriad of content available on the topic of business architecture to help you understand what it really is and is not.
Section 2.2 of the BIZBOK® Guide (Business Architecture Guild®): The full story on capabilities from the source: the BIZBOK® Guide. (Business Architecture Guild® membership required.)
20 Minute Capability Mapping (Business Architecture Guild webinar): One of the most listened to webinars on capability mapping. It’s a Guild classic. (Business Architecture Guild® membership required.)
Business Architecture Reference Models (Business Architecture Guild®): You can view business architecture reference model content in Part 8 of the BIZBOK® Guide (Business Architecture Guild® membership required). Downloadable content is also available in the by the Business Architecture Guild® store for both members and non-members (at a cost).
The Joy of Lexicography (TED Talk): Speaking of words, in her fun and exuberant talk Erin McKean, leading lexicographer, looks at the many ways that today’s print dictionary is poised for transformation.