Okay, time to go back to business architecture school. Having our business architecture written down is at the heart of us being able to do cool stuff with it, so we better talk a little more about mapping it out.
In No. 12 here, we’re going to talk about the “core” business architecture domains. That means those four boxes in the middle of our favorite diagram below.
But first, reminders. Don’t forget, an organization’s business architecture should:
- Encompass the scope of their whole ecosystem
- Represent that ecosystem at a high level of detail
- Be reusable
If these are not ringing any bells, StraightTalk Post No. 1 can help.
Okay, tell me about these core business architecture domains.
In true StraightTalk style, here are the top 5 things you need to know about the core business architecture domains.
- The four core business architecture domains are: capabilities, value streams, organization and information.
- When documenting each domain, you capture names, attributes (i.e. information about the thing) and relationships to other things.
- Capabilities and information are intimately tied.
- Capabilities and value streams are your keys to the kingdom and priority number one to document.
- Organization mapping is typically done opportunistically.
Boom.
Break that down, please.
Let’s start with a few things on numbers 1 and 2.
Related to the point of documenting names, attributes and relationships, remember the concept of the business architecture knowledgebase, ideally in an automated tool? That is where you capture all of this information so that you can later generate all sorts of useful blueprints and reports.
For the capability and value stream domains, what we capture in the knowledgebase are called, well, capabilities and value streams. But FYI, for the organization domain, we capture business units, and for the information domain, we capture information concepts (e.g. Customer, Product, etc.).
Lastly, there’s a big fancy word called a “metamodel” that will tell you how to relate all of the business architecture pieces to each other. The official word on that is in Appendix B.4 of the BIZBOK® Guide.
What about number 3, that capabilities and information are intimately tied?
Yep, this is a key point. Together, the capability map and information map establish a business vocabulary that can truly be shared across 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. Customer / Product Matching) should match any relationships that are pictorially represented in the information map
What is the best order in which to create capability and information maps then?
Most business architecture teams either create the capability map first and then the information map, or they create them together simultaneously (with the capability being the primary driver).
What about number 4 then, the importance of capabilities and value streams?
Capabilities and value streams are at the heart of every business architecture. It’s not just about having one or the other, but about having both of them, cross-mapped to (a.k.a. related to) each other.
If you have capabilities, then you know all the things you do, like Customer Information Management and Payment Management. If you have value streams, then you know how you deliver value to external and internal stakeholders, like when customers Acquire Product or product managers Develop Product. But, if you have cross-mapped your capabilities to your value streams (and even specific stages within them), then you also know where your capabilities are used to deliver value. Now you’re unstoppable.
Sounds good, but I don’t fully get it yet.
Here’s what this means. With your enterprise-level capabilities and value streams defined and cross-mapped to each other, you can do a couple things that were not possible before.
1. Understand the comprehensive impact of anything across the enterprise. If you want to know the impact of a potential strategy, a new product, a regulatory change—anything—if you can identify the value streams impacted, the specific stages within them, and the specific capabilities within each stage, then you can follow those capabilities through to understand the full “butterfly effect” of the change on the rest of the organization. This includes things like any impacted business units, stakeholders, products, policies, objectives, initiatives, processes and system applications. (P.S. You’ll need to build out your knowledgebase though first.)
Here’s a quick illustration of that.
2. Improve the way you scope initiatives and design solutions. If you frame your initiatives and solutions in terms of which capabilities are involved, within a specific value stream(s) context, you can now ask better questions and create better designs. For example, if you identify that the Customer Information Management capability needs improvement within a sales context (i.e. the Acquire Product value stream), by analyzing the other value streams it is cross-mapped to, you might question whether a planned initiative / solution should also address how the capability is used within a servicing context (i.e. the Service Product value stream). Smart.
The elegance here is that capabilities and value streams give you a bird’s eye view of the enterprise from which to navigate and then choose where you want to dive into more details, versus getting lost in them in the first place.
Again, what is the best order in which to create capability maps and value streams then?
Some people create value streams first, some create capability maps first, and some create them simultaneously. Just don’t start the cross-mapping until both are stable.
And finally, what do you mean in number 5 that organization mapping is typically done opportunistically?
First, note that organization maps ≠ organizational charts. Org maps are a different type of diagram that provide a special, non-hierarchical view of the organization. See BIZBOK® Guide Section 2.3 for examples.
While you can absolutely create a reusable org map that represents your organization, many people just create org maps when they want to analyze or communicate something related to a specific purpose and subset of the organization. Both uses are okay.
One more thing. These terms map and cross-map. Help me out, please.
Right. Here’s a quick tutorial on those words that you may be wondering about.
- Map = A visual representation of one or more business architecture domains. It’s a noun. Note that the word “map” is intentionally used by the BIZBOK® Guide, not “model.” (Example: “Hey, that’s a brilliant capability map you have there.”)Oh, but to be confusing, we also use it as a verb to talk about when we create a business architecture map. (Example: “Wouldn’t it be fun to map all of the capabilities related to how we manage our products?”)
- Cross-Map = The act of relating two domains (business architecture or otherwise) to each other. So it’s a verb. (Example: “I can’t wait to see the insights once we cross-map our capabilities to our value streams.”) But it can be used as a noun! (Example: “Wow, the capability / value stream cross-mapping revealed some incredible new insights about our organization.”)
No, you’re not crazy. It is a little confusing. Just go with it on this one.
Not all organizations have their business architecture written down (okay, most don’t), but they do have one. Our job as business architects is to get it documented and visualized in order to help our organizations create a common vocabulary, simplify complexity, and translate strategy into action on an ongoing basis. Batten down the hatches and have fun.
More Good Stuff
What is Business Architecture? (S2E white paper): Just in case you missed it, this white paper is a really handy one that breaks down what business architecture really is—and isn’t.
20 Minute Capability Mapping and 20 Minute Value Stream Mapping (BA Guild webinars): Two of the most listened to webinars on capability and value stream mapping. These are Guild classics.
Nautical Language (See the Sea): Just for fun, since we business architects can be fond of lists and definitions. Here’s a glossary of nautical terms that have informed our everyday vocabulary. Who knew.
How I Use Sonar to Navigate the World (TED Talk): Just for fun + a big dose of inspiration. TED Talk by Daniel Kish (a.k.a. “Batman”), who has been blind since he was 13 months old, and uses his own form of echolocation to navigate his world. Humbled.