Integration platform to support your Merger and Acquisition

Recent research shows that companies drive growth through 3 primary sources: Portfolio momentum, Market share, and Mergers and Acquisitions (M&A) which are responsible for 3-4% of all growth sources. If we are looking at the global scale according to “Refinitiv” data, the total value of pending and completed deals announced in 2021 has landed on $5.9 trillion (over 68 000 mergers), surpassing the full-year tally of 2020 by 64%. Each M&A comes with a bigger or smaller price tag attached for IT-related tasks: common data model, removing redundant systems, common IT strategy, and sometimes consolidating or removing many IT departments. After the deal is done and a full, detailed system audit can be done, plans for full transformation are born.

Since business usually requires IT operations to continue working, even during transformation, this limits the possibility to operate within IT. To reduce risks, transformation usually is gradual:

1. All systems evaluated
   1. Evaluation should be objective
      1. Because one system is “louder”, it doesn’t mean it’s better
      2. Systems from the acquiring company are not always the best
      3. More developers working on the concurrent systems may only reflect its inactivity
   2. Each system should be evaluated by the same points considering migration costs, future IT stack, and licensing
2. All systems are marked in minimum 3 groups:
   1. Remain – system remains as is, and investments can be aligned
   2. Tolerate – the system should continue working, alternatives need to be investigated and no new investments (usually all “Tolerate” systems have a timer which reduces the tolerance level to “Sunset” after some period)
   3. Sunset – system to be actively sunsetted, only investments to reach this goal
3. After the evaluation is done:
   1. A virtual transformation team is created with weekly (even daily) meetings and project reporting
   2. end-to-end architects should draw the new landscape for the transition period and after 
   3. Data architects should draw up their schemas and data transformations for transition and after
   4. Business analysts should map these with business processes (during the transition and after)
   5. API/Integration experts should map business processes with required APIs so they perfectly reflect the process
4. Only after each of the previous points is done, should you start your next Gate with implementation. Having to fix bad production data will cost you more than waiting one extra week for data to be analyzed and fixed.

This logic is repeated for all areas of the enterprise until the target landscape is reached. Often there are problems with legacy systems – they are supporting some clients with complicated agreements or other complexity thus removing the system would result in extensive costs or any development is more expensive than annual license costs. There are also cases where the same vendor is providing the same functionality for all involved parties in M&A, but merging to one master system is too far away. Last, but not least – trying to restart SAP ECC to S4/HANA migration as the acquired enterprise has not even started its migration can be a huge motivation and resource killer. 

What are the options here?

Every case calls for a different solution, but all of them are either temporary or permanent solutions. Also, you need to understand how you are going to merge all systems – point-to-point, single access point, or central API platform.

Point-to-point or system to system

This is a straightforward approach that is best suited if you have to merge 2 or 3 systems. System to system approach is having the same evaluation, but all of the merges are being done on a functional level – if 2 (or more) systems do the same, only 1 master needs to remain and all others should be merged and sunsetted. This approach in a long run is quite expensive and resource-demanding – the second you have to look outside your 1:1 merge and start managing integrations with both systems, you will require increasingly more and more resources.

Central access point

Deploy a central API Integration platform between both stacks and design mapping inside your stack. This is a good solution when you want to have only one entry point into your new IT stack, but then deploy a gateway solution to internally map APIs and integrations between systems. This allows configured, simply adjustable mapping and master/slave data relations. This approach allows flexible endpoint and data management inside your stack (while reducing the redundant systems).

Central API Gateway

The central system allows you to keep your original endpoints for every client-facing system while slowly migrating the data with simple mapping, eventually leaving the master system to handle all of the requests and sunsetting any other system. This approach allows you to fully utilize the API infrastructure and build your IT stack in a controlled way. The option allows you to execute IT merger while continuously providing service “as is” until the very last moment you need to switch. 

Putting an API platform in the middle of a merger allows you to concentrate on your destination architecture. API platform will do most of the heavy lifting supporting both IT stacks and slowly transforming to the desired state. As you will have to rethink all your processes and how they map to your IT stack, placing an API platform in the middle of your architecture gives you a chance to build your architecture following one simple rule: API design is a 1:1 match for any business process. 

Unfortunately, many businesses choose to go the easy route – not investing too much thought into the IT merger process, limiting funds for merger projects and in the end, they need to live with this newly born monster that does not reflect business needs, business domains are not separated causing huge testing, process implementation, and development efforts. While on paper the merger is completed, the underlying work to deal with IT, if not done properly will cause huge cost increases and delays. You will have to invest in IT. Why not get the most out of it? Think about this investment in the API platform as an investment in your future. Companies are relying on IT more and more. If you spend huge amounts of cash acquiring other companies, why would you limit yourself and your future business by investing in bad infrastructure? If a new product on a well-executed system takes months to be delivered, imagine the cost and time overhead if you need to do lots of custom development, do extensive bug fixing (just to get the systems back to normal), try to find someone who has a clue how everything works now and continue spending cash on unneeded licenses. 

Let us know if we can help you with making the right decision for your API platform needs. Give us a call right now!