For IT teams, merger impacts are felt immediately. A key element of your merger strategy will likely be APIs.
“We’re acquiring XYZ corporation.“ As an IT leader, you hear the words and you know what’s coming.
A barrage of thoughts hits your mind like a freight train: thoughts about people, markets, products, services, operations, and of course, infrastructure. Especially infrastructure: different networks, routers, management philosophies, support contracts, deployment topologies, application servers, and databases.
The words that will keep you up at night are on the tip of your boss’s lips. You know they’re coming, and that there’s no escape. “We need a plan ASAP for how to do this”.
They hit. And just like that, the hardest part of your company’s mergers and acquisitions (M&A) equation just became your job. However big and complex your infrastructure was before—it’s bigger and more complex now. However challenging business strategies were to execute, they may be even more challenging now, at least in the short term as your company and the one it’s acquiring begin to integrate.
So what should you do?
A Useful Pattern from Caesar
My colleague Joshua Norrid developed a magnificent analogy for businesses facing shifting IT landscapes, including M&A scenarios.
In 52 B.C. at the Battle of Alesia, Julius Caesar laid siege to a hilltop fort occupied by 80,000 Gauls. Caesar predicted that Gauls in surrounding areas would come to the aid of the fort and that his legions would need to defend against constantly shifting battlefield complexity both inside and outside the siege lines, all while being outnumbered by their opponents. To meet this challenge, he ordered dual fortifications to be built—a moat and ditches on the siege’s inner wall and blockades and primitive barbed wire along the outer wall. Caesar positioned his army between the fortifications, ensuring that no traffic could reach them without first being mediated via the fortifications and validated as helpful to Caesar’s cause—an example of a “true physical proxy,” as Joshua calls it.
See also: With APIs, dealing with bad bots is part of being successful
The IT challenge in M&A execution often mirrors Caesar’s challenges. When businesses merge, they have to deal with shifting IT complexity inside the company’s walls—such as numerous systems, networks, applications, and databases—and shifting complexity outside the company, where IT components are rationalized into a cohesive system of applications, services, and products that advance business goals. Just as Caesar used fortifications to manage and assess complexity, you can do the same, if you are tasked with rationalizing the IT systems
A key element of your strategy will likely be APIs (application programming interfaces). APIs are the mechanisms that allow software to communicate with other software—which means that APIs are central to how systems, data, and applications are integrated during a merger or acquisition. All traffic passes through APIs, just as combatants passed through Caesar’s fortifications; and with an API management platform, the traffic can be analyzed to inform strategy, just as Caesar assessed and controlled traffic to win the Battle of Alesia.
Specifically, an API management layer can facilitate a tremendous leap in visibility, allowing business to answer and address questions such as the following:
- Which resources are being accessed?
- How are those resources being accessed?
- How frequently are those resources being accessed?
- Which applications are using which resources?
- Which networks are being accessed?
- Are all the network boundaries needed?
By putting an API management layer in front of all HTTP traffic, an organization can create a single pane of glass across all infrastructure, allowing companies undergoing M&A to make more strategic, data-driven decisions. You know you’ll need to find ways to combine or consolidate your technology with that of the company you’re merging with or acquiring—but without visibility into how infrastructure is leveraged, knowing how to effectively and profitably do so may be nearly impossible.
Visibility is only a baseline benefit, however. Even more important, the API layer also becomes a lever for infrastructure optionality and business optionality.
Infrastructure Optionality
Once all traffic flows through an API layer, it can be mediated, a term frequently referred to as proxy decoration.
Caching and quotas can be introduced, for example, in order to alleviate stress on southbound infrastructure components and improve reliability and resiliency of systems and services. As risks to your business evolve, new and flexible security options can be introduced, from authentication mechanisms that control access to APIs to machine learning algorithms that learn to identify bad actors based on API traffic patterns.
And of course, data can be manipulated to address the fact you’re dealing with infrastructure from two companies instead of one. As an example, you may have had a /customers resource that pulled data from a CRM system or database. Now that you have purchased a company with its own CRM system, you can modify the behavior of the /customers resource to combine data from both companies systems.
Additionally, the API layer provides a single source in the network for requests. Southbound infrastructure—behind the API management platform—can be more easily manipulated because traffic can be routed elsewhere without disrupting services. Changes behind the API do not mean downtime for the end-user services and experiences that rely on the API. You can test new systems and networks through canary releases, test different deployments, and otherwise update APIs with zero downtime deployment. This means that your infrastructure can be evolved while maintaining SLA, SLI, and SLO targets, you can refactor at your own pace, and change management can occur on your own calendar. This flexibility may enable your business to more quickly achieve capital expenditure and operational expenditure goals, accommodate asset depreciation schedules, and initiate “move and improve” programs at the speed that makes sense for your business.
Business Optionality
An API layer enables a company to package digital assets as digital products—that is, the API does not merely connect systems, applications, and data but serves as a software product that makes it easier for developers to leverage those systems, applications, and data to meet new business goals.
API products can accelerate business partnerships and facilitate the adoption of common digital resources as teams from previously separate companies become part of what is now one company. You can make API products available via a self-service developer portal, for example, that encourages ecosystems of developers, whether internal talent or external partners, to form around your digital assets. You might explore new business opportunities by monetizing API products—an option that may alleviate the “billing integration” woes that plague many M&A projects during their early days.
The Silver Bullet
There is no silver bullet; achieving a successful IT strategy when your company is merging with another requires hard work, perseverance, and data that can be analyzed to extract the promised value from combining infrastructures. Critical path elements include gathering accurate data about systems, maintaining business continuity while migrating and modifying systems at a pace that makes sense for your business, and responding to market demands without affecting southbound infrastructure. Achieving all these goals is in many ways a juggling act—but if there is a critical infrastructure element that provides you maximum leverage during your M&A cycle, the API layer may be it.
