Mergers and acquisitions – API strategies

There are 2 departments that feel the impact of mergers and acquisitions instantly: IT and people who need to change the company name signs in and on all offices. Problem is that with the name changers the problems end quite fast, but IT departments feel the effect many years after the deal is done. 

As part of M&A you will get to feel the effects in areas like infrastructure (from networks and routers to databases, on-premise data centers and data clouds), contracts (licensing, support, contractors), teams (people, team organization, management and their philosophies), deployment approaches, ways of working (development lifecycles, analysis approaches) as well as more global issues and questions related to them (markets/locations, products/services and how to merge both technology stacks without impacting business) and merging operations.

No matter how complex your IT landscape looked like before, with the addition of the new IT stack the complexity has grown and you still need to come up with 2 plans (short-term to minimize impact of the shift and long-term to optimize provided services, save resources and follow financial targets that were set by someone during M&A process). As an added bonus – if you were able to build and tune your old enterprise IT landscape over years, now you have to “come up with the plan by Tuesday as on Wednesday we are having our board meeting and everything that will be said in this plan is going to be considered as written in stone.” and think what impact will it leave on the S/4HANA migration that is almost completed in one part, but not even started on another.

Extremely important point with such setup and speed requirements is to remain as flexible as possible at all times. An obvious choice for this would be to use APIs (application programming interfaces) as they provide easy way to standardize your solution and use enterprise systems less like standalone systems, but more like exchangeable functionality building blocks that have enough flexibility to be quickly replaced with any alternative (you don’t want to do years of development just to understand that the decision you made in the heat of M&A deal was a bad one). With the use of APIs you need to have enterprise grade tools to support your API economy and organize the transition. Here you have two options: go without API management platform and spend thousands of hours doing, re-doing, fixing and inventing the wheel 5 more times or go with API platform and never worry about the infrastructure or how to build any process or product.

Why API gateway?

Key point of any modern M&A strategy from an IT point of view should be APIs. Assuming that most of the enterprise grade businesses fully rely on complex IT systems – key point of any M&A strategy should be extensive usage of APIs. Once you have made this decision, you need a way to organize, manage and use your APIs in a smart, meaningful way. That is where the API gateway comes in.

With an API gateway you control who can enter you, who needs to do what and who should stay outside. The M&A process will be chaotic and many decisions will be made in a rush. Relying on API platform would allow to change noticeably less than if using direct integrations:

1. One API is used by many systems, no need to make hundreds of direct integrations
2. Systems behind the API can change many times, but as long as the request/response schema remains the same the only changes may be caused by data content not technical requirements
3. Pre-built analytics, user management, API management, scaling, and other tools and technologies allows to decrease time spent on infrastructure and fully concentrate on system and data migration
4. Merge behind the scenes: imagine you end up with 2 CRMs. Instead of having 2 databases and 2 technology stacks, you can slowly, using APIs migrate to the master system and move all of the functionality as well as transfer data in batches

Target is to create a system that is as flexible as possible with a stable base (the API platform which remains as static as possible) providing the same rules for everyone and enabling long-term planning possibilities. It is much easier to plan and implement that an integration is not changed for 100 systems because of 1 system. Instead the API stays the same while specific cases can be covered by developing additional APIs that are configured in the flow. With advanced mapping features to support any API transitions your process will flow easily.

Management options

By using API Gateway you are able not only to remain as flexible as possible during transition, but to provide built-in API management options for quick and easy setup. Once used and required APIs may need to be throttled, limited and their users monitored and evaluated. API Gateway delivers functionality that allows you not to spend hours and hours on already existing  feature development. Hours that can be spent on harmonizing the application stack and migrating the data.  Functionality for caching, throttling or request quotas can be introduced out-of-the-box. It’s not a secret that not all systems were made equal. More often than not, even if your IT stack is tuned and modeled to work in an optimal way, introducing another “tuned” solution may cause huge issues. 

As the systems are being merged and evolved new restrictions can be introduced or removed. Starting from simple access management to traffic management and going to advanced features like process mining, machine learning for data security (learning data and user patterns and identifying outliers), general security improvements, etc. 

Centralized API Gateway allows you to govern your system landscape while leaving major flexibility for the end-systems. Just like in any normal country – there is a central government responsible for rules and limitations, but while individual companies operate within the boundaries of these rules they are free to innovate and be as flexible as they want. 

A microservice can be built that acts as an interface for more than 1 system. It can have mapping logic built-in to logicly route the requests while providing high flexibility. Combine that with load balancing options, possibility to dynamically deploy new instances and you have a system that virtually has 24/7 uptime and impact for end-users is limited as much as possible. For most of the clients M&A efforts on the IT side doesn’t mean anything – they don’t care what is being migrated, why it is so and what new features to expect. All that they want is to have a normal workflow without any disturbances and data loss. With a smart and flexible architecture you can be able to maintain your SLAs and client satisfaction goals. The more stable the systems, the faster you can return to normal mode of operation and innovation. 

API as a business process

API configuration should directly represent your business process. If your process is to greet the client, get his information, validate if it’s a good customer, provide the service and cash in then your APIs should be configured in a way that supports all of these steps. In a way that simply can modify any of the steps and simply add a small step in between. 

As now you are dealing with infrastructure from two companies (and imagine if they are having some complicated situation from previous relations (previous M&A)) it becomes crucial to have process-API mirroring. For example – if you are dealing with 2 CRMs instead of one, you will write a process that explains the new way of working. Your APIs should support this new process and as the migration is ongoing and more functionality concentrated in 1 of the CRMs, your APIs also keep transforming together with the process.

Leverage your new solution faster

When you do M&A your goal may be to leverage the technology (at least fraction of it) from the new, acquired enterprise. If company A produces a loss of 100 000 and you acquire company B that produces 100 000 loss then now you have company ab that produces 200 000 loss. Same goes for APIs – M&A happened for a reason and you should use existing and possible APIs for your benefit. Instead of continuing to spend resources on developing products in each part of the new enterprise, you should have a common API portal to produce high value products and phase out old ones in the background. It is much smarter to enable new revenue streams while “cleaning out the kitchen” in the background instead of trying to push the maximum out of existing products in product stacks and delaying technical IT stack mergers (remember about those contracts, agreements, blockers, etc.).

Get those APIs done externally

While in a “normal setting” your management would never go for hiring a team(s) of API implementation experts during M&A you can use this strategy to get very good results, very fast. Often internal teams lack knowledge, experience and most importantly: “they come from the other side so all they say is bad”. By applying this strategy you can get the groundwork done, put effective processes in place and teach your interna teams. After a period of time simply phasing out the external teams and leaving optimal internal teams to operate the API platform and manage integrations as well as govern the process. API management teams often play a central role in organization as they are the hub that connects both sides after M&A. They can be the ones to set the process, guidelines, naming conventions, etc. There have been many occasions when initially everyone tries to get their foot in the door, but when it comes to doing so, general enthusiasm is quite low. By using external API experts you can leverage this situation in your favor.

The conclusion

There is no single model that will fit every organization out there. You will have to come to compromises, agreements and losses. The process will be long and hard. The hardships will come from all sides – technological, people, management and contractual. What you can do is to build a solution that is as flexible as possible and has built-in options for scaling as well as “the next 5 years” in mind. If you have to integrate system X and it requires 10 000 hours or make a bunch of APIs for the same cost, it doesn’t seem to matter much. But when you will have to merge it with the new stack and phase it out over the next 4 years, having API infrastructure will pay off in the time and resources required in order to reach your goal. The same could result in a fat bonus check for you as the mastermind behind saving all that cash with the transformation.

Goal is to maximize the gains while minimizing transition time. API platforms can help you do that in short and long terms. Leave us a message to learn more about the API platform and possibility to earn a possible bonus.