A Map of the World, Part 1

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.

Business Architecture In Action For Mergers & Acquisitions

How business architecture helps to assess and integrate organizations during M&A.

Here we go one more time looking at business architecture in action. This time we’re going to focus on how business architecture helps to assess and integrate organizations during mergers and acquisitions.

Remind me what that is again.

Simply stated, a merger is when two organizations come together and an acquisition is when one takes over another. (Hint: This is referred to as M&A for short.)

Performing a merger or acquisition is no small matter, so organizations do it for very good reasons like to gain more market share, expand their customer base, obtain access to new markets, create new distribution channels, obtain new technology / assets, and so on.

What’s the problem?

With lots of smart people working on M&As, it seems like we should probably have everything under control, but the reality is that the organizational fit and synergies between two organizations are not always known comprehensively up front during the “pre-deal” stage. Neither are the potential impacts to both organizations. (Think changes to business units, processes, systems, assets, locations, channels, etc.)

Then, if we do decide to do a merger or acquisition, when it comes time to integrate “post-deal,” people in both organizations do not exactly have a clear, comprehensive or actionable picture of:

What changes are needed to the business and IT environments
How those changes will be achieved (e.g. packaging, sequencing, etc.)
How to reprioritize all the in-flight and planned projects

Why? Because without business (and IT) architecture in place, it’s really hard to get a birds-eye view of what both organizations do and are planning to do, so that we can quickly compare and assess things. All we have are the details and different, fragmented mental models of how we understand the organizations.

How does business architecture help with all of that?

Business architects (from both organizations) bring a lot to the M&A party including enterprise-level business architecture blueprints, relationships and an approach for translating strategy into execution. This helps the M&A process by:

Aligning purpose, direction and structure between both organizations at a high level including goals, strategies and business models
Identifying all stakeholders that need to be involved up front
Ensuring that both business and IT perspectives are always considered
Greatly accelerating and ensuring completeness of impact analysis and integration activities
Creating comprehensive designs and roadmaps for integration activities, inclusive of all business and IT changes, providing a common vision and the most efficient path for implementation

Got it. So how do we actually do this?

First there’s the assessment and pre-deal. Here’s a quick overview of how business architecture helps with those steps.

Step 1: Create or Leverage the Minimum Business Architecture Baseline Content for Both Organizations – If it does not already exist, create the following baseline content in the business architecture knowledgebase at a minimum (yes, for both organizations):
- Capability map (one that encompasses the whole enterprise scope)
- Value streams (if you can’t get all of them, create a core set of value streams, typically customer-facing, described at an enterprise level without business unit or product specificity)
- Capabilities cross-mapped to value stream stages
Step 2: Capture Additional Content Needed for Analysis for Both Organizations – If you really want to do solid analysis, you’ll need to capture additional information and map it to the business architecture baseline. This includes things like business units, information, system applications, processes, strategies / objectives, initiatives, customer journeys and business model canvases. (This is not always possible, so get what you can and focus on the critical pieces at hand.)
Step 3: Assess Alignment of the Organizations’ Strategies / Objectives and Business Models – If you have the documented strategies / objectives and business model canvases in the same format for both organizations, now you can easily compare and analyze them to find areas of alignment and potential misalignment in terms of how they are structured and where they are headed.
Step 4: Assess Potential Impacts to the Organizations’ Customer Experiences and Business and IT Architectures – Again, if you have documented the business architecture in the same format for each organization—and mapped it to customer journeys, the IT architectures, and other aspects of the operating model (e.g. processes)—now you can easily compare and analyze the two organizations to find where changes would be needed if the merger or acquisition does go through. Capabilities and value streams provide a fantastic starting point for high level comparison, and then you can dig into any details as needed.
Step 5: Summarize / Visualize the Results and Share Insights – Summarize and visualize your insights and recommendations, and then share them with your leaders.

If the merger or acquisition goes through, then there’s probably a lot of integration work to be done post-deal. Here’s a quick overview of how business architecture helps with those steps.

Step 1: Capture Additional Content Needed for Analysis for Both Organizations – Capture any further detail that was not needed or available during pre-deal. Again, get as much as you can and focus on the critical pieces at hand.
Step 2: Analyze the Business and IT Environments for Both Organizations and Identify Changes Needed – Just like Step 4 during pre-deal, identify the impacts to the customer experience and the business and IT architectures, but now you need to actually act on them.
Step 3: Reflect Changes for Both Organizations in Target Customer Experience Designs and Target Business and IT Architectures – For the remainder of the steps, now we’re into the strategy execution life cycle, and you know business architecture’s role there. (If you want a refresher, check out post No. 3 on a new vision for strategy execution.) In this step we do the serious work of designing / redesigning the two organizations (depending on the M&A scenario), which could include combining, removing or creating new aspects of the business and IT environment. Then we visualize the new organization(s) in a target architecture picture(s) and communicate it to everyone so that they know where we’re going.
Step 4: Develop Strategic Roadmap to Implement Changes (per target architecture) – Here we scope and define all initiatives needed to achieve the target architecture(s) and organize them onto a strategic roadmap(s).
Step 5: Reprioritize Project Portfolios – Inevitably some of the work that is currently executing in both organizations will need to change as a result of the merger or acquisition. If initiatives are tied to capabilities and value streams, they can quickly be identified for assessment—to be stopped or adjusted as applicable.
Step 6: Execute and Oversee Changes – Business as usual. As each project is ready to kick off, the changes it will make are described within an architecture context and communicated to the execution teams. Business analysts translate the changes into requirements and tie them back to the architecture. Business architects provide direction and oversight to execution teams as needed, to ensure that the results meet the architectural direction and ultimately the original business direction.

What’s the fine print?

A few things.

In some organizations, it may take some time and change management for architects to earn a seat at the table during M&A activities. Be patient and persistent.

There’s also this concept again of needing a minimum set of business architecture baseline content in order to do this great M&A analysis and integration. That minimum baseline includes capabilities and value streams at the enterprise level for both organizations. The good news is that we can contribute a lot of value with just this bird’s-eye view and it can be created pretty quickly, even for new practices. And if you have business architecture for either of the organizations, it can accelerate creation for the other. However, having that additional content like business units and system applications mapped to the baseline will really make business architecture’s contribution valuable, and can be created on a just in time basis.

BTW, a similar approach may be used for internal changes such as merging business units, so that’s another opportunity for business architecture to add value.

Helping with M&A activities is a great way for business architects to get involved strategically and demonstrate value, even for relatively new practices. It may take some time to earn a seat at the M&A table, but it will be worth it for both the organization and the business architecture practice.

And a handy summary of all that is right here for you.

Common Challenges

Assessment and Pre-Deal

Organizational fit and synergies are not always comprehensively known up front

Potential impact to both organizations is not always comprehensively known up front

Deal and Integration (Post-Deal)

People throughout both organizations do not have a clear, comprehensive or actionable picture of:

What changes are needed to the business and IT environments
How they will be achieved (e.g. packaging, sequencing, etc.)
How to reprioritize the in-flight and planned projects

Business / enterprise architecture is typically not at the table to assist with M&A, leading to the challenges above

Opportunties

Assessment and Pre-Deal

Assess alignment of purpose, direction and structure between both organizations at a high level including goals, strategies and business models

Identify all stakeholders to involve
Ensure both business and IT perspectives are always considered
Greatly accelerate and ensure completeness of impact analysis

Deal and Integration (Post-Deal)

Create comprehensive target architectures and strategic roadmaps for integration activities, inclusive of all business and IT changes, providing a common vision and the most efficient path for implementation

Leverage business / enterprise architecture throughout the M&A life cycle and integrate practices across both organizations (if they exist)

How We Do It

Assessment and Pre-Deal

Create or Leverage the Minimum Business Architecture Baseline Content for Both Organizations
Capture Additional Content Needed for Analysis for Both Organizations (e.g. business units, information, system applications, processes, strategies / objectives, initiatives, customer journeys and business model canvases all mapped to the business architecture baseline)
Assess Alignment of the Organizations’ Strategies / Objectives and Business Models
Assess Potential Impacts to the Organizations’ Customer Experiences and Business and IT Architectures
Summarize / Visualize the Results and Share Insights
Considerations

Deal and Integration (Post-Deal)

Capture Additional Content Needed for Analysis for Both Organizations (i.e. further detail that was not needed or available during pre-deal)
Analyze the Business and IT Environments for Both Organizations and Identify Changes Needed
Reflect Changes for Both Organizations in Target Customer Experience Designs and Target Business and IT Architectures
Develop Strategic Roadmap to Implement Changes (per target architecture)
Reprioritize Project Portfolios
Execute and Oversee Changes

Considerations

A minimum set of business architecture baseline content for both organizations is needed for both pre-deal and post-deal analyses, but can be created within a relatively reasonable time frame, even for new practices. This includes capabilities and value streams created at the enterprise level.
- Note: Existing business architecture content for either organization can be used to accelerate completion for the other
While capturing a full set of additional content is ideal (e.g. business units, information, system applications, etc.), it can be created on a just in time basis if needed. Significant value can be contributed even if only the business architecture baseline exists.
Architecture may accelerate and improve the M&A process, but it is dependent on business engagement and decision-making
It may take some time and change management for architects to earn a seat at the table during M&A activities
A similar approach may be used for internal changes such as merging business units

Download Summary >

More good stuff

Business Architecture for Acquisitions (S2E Presentation): A little more detail that you can use to understand and explain business architecture’s benefits, role and focus during acquisitions.

Business Architecture for an Acquisition Case Study: Always learn from your friends. Here’s a great story on how Maersk used business architecture for an acquisition, shared during a recent Business Architecture Guild^® Summit. (Spoiler Alert: If you scroll almost to the end of the document you’ll find the key takeaway: By using business architecture, “149 general process-driven requirements surfaced by the project team were able to be filtered down to only 19 of the most critical ones based on actual capability differences between the two companies.” Go business architecture.)

Mergers & Acquisitions: Definition (Investopedia): Here’s some official 101 on Mergers and Acquisitions if the concept is new to you.

Mergers, Acquisitions & Failures (Raj Ramesh): And here’s a video which underscores the importance of using models (business architecture+) for Mergers and Acquisitions.

Top 10 Best (and Worst) Mergers of All Time (CNBC): Just for fun, here’s a look at perhaps the top 10 best and worst mergers of all time. The good, the bad, and the ugly.