“The whole is greater than the sum of the parts” - Aristotle
Technology integration is often the tip of the spear when it comes to mergers and acquisition activities. However, IT departments are typically among the last to learn about them. M&A never features on roadmaps and, as a result, they instantly conflict with forecast activities when they happen. Rarely are those existing activities reprioritised and M&A becomes the preverbal having your cake and eating it too situation. The company needs both M&A and planned roadmaps delivered on time and within budget. Complexity, attack surface, and exposure increase almost overnight.
Not only does M&A happen with little warning, but integration needs to happen quickly. CEOs are under immense pressure to show immediate value to pacify shareholders about the sometimes eye-watering sums changing hands.
In my experience, two M&A models tend to dominate. The first is full integration, which results in a brittle, deeply coupled single organisation. The second is a standalone model that results in a more flexible and loosely coupled federated entity. Regardless of the model, one inescapable requirement binds them together: the need to share applications, data, and identity. For an IT department, this means connecting networks together.
Connecting two separate, independently trusted environments via a private network link must be safe, surely? The answer is that you don’t know, and it takes time to find out. Buying a breach is sadly all too common when combining two networks that weren't designed to be combined.
Imagine trying to cross a busy street tied to the leg of someone you just met. M&A is much like that, except in the real world the street is the internet, malware are the vehicles hurtling towards you at great speed, and instead of walking you need to run. As individuals, we can cross the road with the confidence that comes from experience. But with someone else, we need to learn how to adapt quickly or face the consequences.
Not crossing the proverbial road isn’t an option. So, how do we navigate it quickly and safely? The answer is by aligning not binding – never restrict critical movement by binding networks together. As the head of infrastructure in my past life, I searched long and hard for the answer to this problem. Over the years I tried it all, from VDI to bringing applications to the edge. Much like invisible rope, the rules of an IP-based network bind those solutions together. Balancing agility and security during M&A became an art form.
So, how do we closely align but loosely couple business while still sharing those things that are important? The answer is to adopt a closely aligned architecture on multiple fronts, loosely connecting the things that matter and leaving separate those that can and should sit independently.
Federate your identity in the cloud
This, for me, was one of the critical decisions as an IT function. It represented a leap of faith for our security and identity teams – authenticating in the cloud. Creating the means to anchor your application authentication to a trusted source was a significant advancement for many organisations adopting SaaS.
But this capability alone doesn’t go far enough in M&A. So it becomes necessary to adopt applications that can accept multiple identity providers or a single identity provider that can support multiple federated identities. Either of these capabilities in the cloud, but ideally both, allow organisations to provide flexible authentication capabilities without the need to re-issue identities at point of integration or to perpetuate multiple identities per person.
More significantly, this type of cloud architecture removes the requirement to join networks together to connect or migrate identities together on premise. We all know the complexity that comes with multi-forest multi-domains. They are simply too tightly coupled, creating a large surface area. North/south trust relationships into each respective organisation allows them to continue to operate independently and undisrupted with the federated layer in the cloud creating the illusion of a single entity. Highly aligned, yet loosely coupled.
Proxy-based architecture and blast radius thinking
Never let the truth get in the way of a good integration. Network teams know all too well that M&A can be like death by a thousand cuts. Requests to join systems together come in thick and fast and typically from disparate business groups working without regard for requirements outside of their own, not to mention the security implications. The result is a lie network teams tell themselves to justify all-encompassing, any-to-any connectivity and deferring the security responsibility in favour of a lock-it-down-later strategy (where “later” often never arrives).
I will never forget the look of panic on my project manager’s face when I told him we would no longer join networks together. The truth is, very few users need the ability to reach every application, and even fewer application-to-application connections are required. To address connectivity count mismatches, organisations need to adopt proxy-based, zero trust architecture to broker user-to-application and application-to-application communications in a controlled way, facilitating object-to-object connectivity (1:1) instead of network-to-network (*:*) thinking.
The introduction of a proxy-based approach breaks the link between direct connectivity challenges, with no more worrying about conflicting IP address schemas, routing loops or gateway bottlenecks. More importantly, we reduce blast radius by limiting lateral movement, which is an unintended consequence of any-to-any network relationships. Organisations are becoming increasingly adept at using separate accounts or subscriptions to protect applications when migrating to the cloud. After all, why connect unrelated applications with one another within a single organisation? The same thinking should apply to M&A and applications across organisations.
Adopt as-a-service wherever you can
One of the hardest lessons to impart on my teams and business leaders throughout a transformation was that adopting as-a-service solutions did not mean losing control or relevance. In fact, the result of any good transformation is a burst of acceleration leading to happier customers, greater productivity, and business growth. The consequence of this growth using SaaS is reduced complexity that results in greater control at scale.
One of the last anchors on my journey to the cloud was the branch office. Printers, telephony, and a whole host of smart building systems were huge drags along the last miles of transformation. It’s pointless to have a robust cloud hosting strategy only to conveniently ignore services sitting in the branch office. My team and I were committed to transitioning to zero trust architecture and adopting the internet as the new connectivity standard, and this meant un-networking the branch office. To do this, we moved commodity-based IT services to as-a-service solutions, removing the need for on-premise hardware. Any remaining pieces of hardware such as routers and switches were managed over 4G or using cloud-managed services.
Pay-for-play models
Dollar for dollar, cloud capability is cheaper than I ever achieved hosting on-premise. So why would my CIO regularly ask me why we were spending more? The reality is that the price didn’t change, we were simply using more of it. When companies are successful, the desired consequence is organic growth. However, M&A isn’t like that.
Growth via acquisition results in a sudden cost increase followed by a protracted step decrease. Like from the bridge of a large sailing vessel, it takes time to change course. Vendor and service contracts are often the defining factor in the turning radius of M&A activities. This is why an OPEX pay-for-play model is better suited to acquisitions. The ability to ramp up or slow down is an advantage for business agility. Some organisations experience this during their transition to cloud, however for the full impact it is important to adopt everywhere.
Earlier, I outlined the importance of implementing closely aligned but loosely coupled architectures as part of a M&A technology strategy. The same principle applies to procurement and finance. It is overly idealistic to think we make the best technical decisions based on technical capability alone. Financial and complexity constraints play a huge part in the decision-making process. It simply isn’t practical to tear up multi-year contracts because of M&A. Instead, we must dampen the impact of such a change. Much like introducing proxy-based architecture to insulate one organisation from another, moving to a pay-for-play vendor strategy can insulate against integration cost instability.
Mergers and acquisitions are periods of intense change. Creating closely aligned but loosely coupled technology and financial ecosystems can dramatically lower time to value during an integration through adaptability and scalability.
“It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change.” - Charles Darwin
What to read next
Merger & acquisition integration: How a zero trust exchange accelerates time to value