Using Enterprise Architecture for forecast and implementation of Merges and Acquisitions (M&A)

After explaining how to use enterprise architecture for IT long term planning and  IT cost reduction this post is dedicated to enterprise architecture for merge and acquisitions (M&A). In this post I'll try to share with you my experience with how to use EA to forecast  M&A efforts from IT point of view and after a decision has been taken, how to use EA to implement M&A (From IT point of view).

In a nutshell the idea here is simple (the implementation is not). Behind  M&A we can find business logic, which can be transfer to business capabilities.  And M&A strategy (Vertical, Horizontal, Concentric Diversification Merger and Conglomerate Merger), which can be translated to EA principles. 

Based on business capabilities and EA principles we create an EA blueprint (or to-be architecture) which takes in account the needed business capabilities as well as information, applications and technology.  If the combination of our and the acquired company "as-is" architecture meet the  blueprint (supplying all the business needs and benefit from M&A) then the M&A should be easy and fast.  We don't have such scenario in reality, but this blueprint serves as a model that we want to achieve.

Having this blueprint we can model each candidate (for acquisition) "as-is" situation. Then, based both on the blueprint and "As-Is" of both parties, we can Identify gaps and translate them to resources needed to fill those gaps. The outcome gives us indication how complex, aswell as resource and time consuming, a given M&A scenario will be. This outcome also sets the roadmap to M&A effort once decision will be taken.

Now let's see what are the tasks that we need to take in order to create the blue-print ("To-Be")  and "As-Is" architecture, identifying gaps , translating gaps to resources and creating a roadmap for M&A. I'm writing from an assumption that your business, Information, Application and Technology domains are already modeled. If they are not you can follow my blog (www.theeagroup.net) to learn how to do it.

Creating blueprint ("To-Be")

 First step is to understand which business capabilities are playing any role in the suggested M&A. We can find those business capabilities directly from our hierarchal capability model. or by going over business processes that should be effected from the M&A. note that we have to collect both business capabilities that will be effected and new business capabilities that we want to acquire through the M&A. the capabilities that we have to list down include also capabilities that will have any interaction with new capabilities that we want to acquire. To this pile we should also pour capabilities that we know that exist in both acquire and acquired, and we want to cancel one of those capabilities.

Having all the mentioned above capabilities (tagged as I mentioned), we can start to build end-to-end processes that depict the to-be architecture (post M&A situation). After understanding what are the impact from business point of view, we start to understand which Information (from your conceptual model) will be send and received (data flow) between capabilities in the to-be architecture. If it's an existing information we'll tag it as an existing, if it's an existing Information but we feel that a new entity should be added to this information, we'll tag it as well. If it's a new information, we'll tag it as well.

Next step is to understand which one of the existing application is playing in the game. For this purpose we're using a matrix. On the Y axis all the business capabilities and information that we manage to identify, on the X axis all the application (and products) that we have. We're using this matrix to map between an existing application to capability or information that is playing any role in the M&A. in a matter of fact most of this data already exist in our existing repository, we just have to do some adjustments following the identified new Business changes and new Information model. The outcome of this matrix is a list of applications that will be effected by the M&A, and which capability or information doesn't have any support using current application portfolio. If application support is missing we add new applications (tagged them as new)  and  relate them to  existing applications (if data needs to flow between them or they need to consume a service, etc')

Now it’s time to start collecting data on technology stuck. Collect all the technology elements that will be effected by the listed applications, Information and business capabilities. Then start to build a to-be technology stuck by going through the common following topics:

• Is there any new technology that can address new capability?
• Is there a need to maintain new volume of data?
• Is there a need for new security policies?
• If there is a need for application integration, is the current technology sufficient?
• Are there new applications required more CPU, Memory and storage? Do we have those resources?
• Do we need to support new communication medium or new sites?

Again, tagged new, changed and existing technology elements.

Before building the "to-be" architecture we need to understand what is the M&A strategy (Vertical, Horizontal, Concentric Diversification Merger and Conglomerate Merger), since it influence the "to-be" architecture in a form of enterprise architecture principles. 

Having all of this data in front of us, we can start to build (visually) the to-be architecture of the four domains.

Creating "As-Is" architecture:  

creating the "to-be" architecture is pre-requisite . Next step is to map the "as-is" architecture of candidate company. The steps are more or less the same as modeling your own enterprise. You have to model business capabilities, information, applications and technology and their relations.

Identifying gaps:

Now the fun begin. We take the to-be architecture (blueprint) and both the as-is architecture of our company and the acquired company. I guess that the business capabilities that doesn't have any support in our organization are supported by the acquired company (otherwise, what's the point in acquiring them). For all the others architecture building blocks (information, application and technology)  that was tagged as new, we identify if there are architecture building blocks in the acquired company that match them.  If any new building block doesn't have a match in acquired company, mark them as gap.

Find out if existing building blocks in acquired company follow your architecture principles, if not mark it as a gap.

Using the technology architecture we find out if application in acquired company can work with our application collaboration platform, can it be integrated into security model, is it introduce new data volume that we don't have any support, is it using applications or technology that doesn't follow our Technical Reference Model (TRM), can we host the acquired company applications on your technology stuck, can our databases hold acquired company data, etc'. We add a new gap for each inconsistency that we find between the as-is of the acquired company and the to-be model.

We should finish with a list of gaps between the combination of our and the acquired company as-is and the to-be model that we defined. The gaps will give us an idea of how much complex this M&A from technical point of view. If you're using any EA tool you can see most of those gaps visually (see image 1.0). the less opacity building blocks are the “as-is“ building blocks.

Translate gaps to resources:

Gaps are not enough for understanding how complex a M&A will be from our point of view. Now it’s the time to use your and your team experience and translate those gaps into human and financial resources need to fill those gaps. Resources along are not enough to get a decision we need to add the time perspective as well. Therefore, for each gap the we manage to identify we'll have

1. human resources needed to fill the gap.
2. Financial recourses (without human costs) needed to fill the gap.
3. time estimation for filling the gap.

Next step is to take the gaps and trying to find out if they can be filled in sequence or in parallel.  Then we can add the resources and time estimation and we'll have an idea not just how much it complex from technology point of view, but also is it feasible from practical point of view.

Creating roadmap for M&A:

If a decision to move forward with the suggested M&A has been taken, we need to translate the gaps into a road map. Actually most of the work already done, we know all the gaps, we know their dependencies and we have estimation of time and efforts needed. All we have to do is to break this data into a list of projects with clear outcome, described by high level analysis of the project, and a name of a person pulse his resources to do the project.