In this installment of StraightTalk, we return to the idea of business objects, and the important role they play throughout an organization’s business architecture – and why it matters. We will do some serious condensing here of the BIZBOK^® Guide to help you put the pieces together and understand how it all works. Why? Well, not for the sake of theory. That’s not what StraightTalk is about. We’re about helping to build a common understanding so that we can all move forward in unison. And architect great things for our organizations and societies, which is the point.

Let’s go.

What’s a business object again?

From a business architecture perspective, business objects are the core nouns that form the vocabulary of your organization like Customer, Product and Agreement. The idea of business objects is used throughout the BIZBOK^® Guide.

Why does this matter?

Perhaps business objects are the things of the universe. As Donella H. Meadows tells us in Thinking in Systems: A Primer, “a system must consist of three kinds of things: elements, interconnections, and a function or purpose…a system is an interconnected set of elements that is coherently organized in a way that achieves something.” So, any system – whether that is a person, a family, an organization, a nation, or a solar system – is made up of elements.

In business architecture, our elements are the business objects and it all starts there.

Business objects are ubiquitous throughout an organization’s business architecture.

Really? Where?

For example, within the business architecture…

• Business objects (formalized as information concepts) are further described and related to each other on the information map.

• Business objects are the basis for capabilities. Capabilities are actions performed on objects (e.g., a Customer is a business object and Customer Management is a level 1 capability). P.S. Check out Post No. 51 for more on this topic.

• The states of business objects dictate the flow of value streams.

• Business objects (e.g., Customer, Partner and Human Resource) can be a category of stakeholder. And, stakeholders participate in value streams as triggering or participating stakeholders.

What are the benefits of structuring our business architectures based on business objects?

Business objects help to…

• Establish a shared business vocabulary for the entire organization, first and foremost. (For real, so that people across business units can mean the same thing, like when we use words such as Customer.)

• Contain the scope of level 1 capabilities to just one object, which helps to ensure a non-redundant capability map structure, allowing it to be used for analysis and decision-making that illuminates similarities, not differences, across the organization (e.g., think about trying to find where investments are targeting the same capability).

• Create rationalized data (e.g., based on a harmonized definition of Customer) so that we interpret information consistently and fully leverage technologies, including the exciting emerging ones.

Further, within the IT architecture, business objects help to…

• Align data architecture with the true business view of business objects and relationships.

• Provide a quicker way to identify the databases and applications that are supporting a capability (until an official cross-mapping is made and maintained) because they can be searched using just one business object (or alias) versus a function or grouping which includes many objects, making it harder to find the match.

• Ensure that capabilities are contained to just one object with specific outcomes so they can become the basis for reusable software services.

And, business objects help other disciplines, such as to…

• Accelerate requirements creation because the words are already available (along with the relevant capabilities in value stream context and stakeholders).

• Accelerate and create alignment within other disciplines like business process management or techniques like event modeling.

Pictures, please.

Check out the handy diagram below to see an example of all that.

So, where do we go from here?

• If your organization already has a business architecture and it’s based upon well-defined and agreed-to business objects: You’re good to go.

• If your organization is just creating your business architecture now: Study up on the BIZBOK^® Guide so that you can get your business objects defined appropriately and your business architecture structured correctly now, so that you have a strong foundation to build upon and use going forward.

• If your organization already has a business architecture and maybe it’s not exactly based upon well-defined business objects or the methods we’ve discussed here: It’s okay to evolve. You can go cold turkey and reshape your business architecture, or you can work into changes over time. Start by defining your business objects from an enterprise perspective and use those concrete definitions to at least serve as a glossary to underpin the rest of your existing business architecture (e.g, your capability map). Then, you can take additional steps over time to reshape your business architecture when you’re ready.

In Closing…

If your head hurts a little bit after all of that, here’s the good news. The more you just do it, the more it makes sense – and the elegance of it all unfolds. And, if you can understand this, then you pretty much understand the heart of business architecture. Everything just builds on from here.

More Good Stuff…

What Is Business Architecture? (S2E white paper): Just in case you haven’t read it yet, this foundational white paper will help you understand the basics of what business architecture is and is not.

The BIZBOK^® Guide (Business Architecture Guild^®): Get the full story on it all from the source: the BIZBOK^® Guide. Part 2 contains the details on all business architecture domains (e.g., 2.2 for Capability Mapping, 2.4 for Value Mapping, 2.5 for Information Mapping and 2.8 for Stakeholder Mapping). Check out Section 3.8 for more on alignment with requirements, and Part 6 for more on business architecture and IT architecture alignment. (Business Architecture Guild^® membership required.)

Business Architecture Webinars (Business Architecture Guild^®): There are loads of recorded webinars available on these topics. For example, Core Business Architecture Domain Recap, Extended Business Architecture Domain Recap, 20-Minute Capability Mapping, 20-Minute Value Stream Mapping, Mapping Update: Building and Using Information Maps, Stakeholder Mapping, Business-Driven Business/IT Transformation and more. (Business Architecture Guild^® membership required.)

The Business Architecture Quick Guide (Business Architecture Guild^®): Available on Amazon and Barnes and Noble.

Thinking in Systems: A Primer (book by Donella H. Meadows): Brilliant work. Brilliant human.

Objects of Desire (TED Talk): An interesting TED Talk by Denis Dutton (and illustrated by Andrew Park) that explores the artifacts and images that have intrigued humans for centuries – and why we find them so alluring.

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:

BTW, don’t worry, there are ways to accelerate the creation of a capability map. Check out Post No. 22 and Post No. 23 on speedy business architecture. 

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 (BIZBOK^® Guide): 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 Business Architecture Quick Guide (Business Architecture Guild^®): Available on Amazon and Barnes and Noble.

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.