< Back to StraightTalk — The Blog

Putting the Pieces Together: Business Objects As The Glue For A Business Architecture

By Whynde Kuehn | 20 May 2019

Subscribe >

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.

Business Objects Ubiquitous Throughout Business Architecture

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.