Business Architecture In Action For Mergers & Acquisitions: How Business Architecture Helps Assess and Integrate Organizations During Mergers and Acquisitions

Published

04 September 2017

Updated

07 May 2020

Published In

USAGE
Summary
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.

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.

Diagram/table showing business architecture actions for M&A activities

Business Architecture In Action For Mergers & Acquisitions

Downloadable Media

 

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 (see Business Architecture Guild®Public Resources page): 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.