This fictitious situation may sound familiar to Corporate Technology/Digital/IT teams: the firm has decided to close a proposed merger or acquisition: target dates for the transaction execution and follow-on work are set, tentative integration planning has kicked off in various parts of the firm. All of this leads to more and more objectives - and question marks - for each function and business unit of both parties.
All business objectives result in a mandate for the Technology and Digital functions of both sides of the deal: enable and drive the integration of technology assets and organizations, thereby helping both legacy organizations to become one.
This planning process starts with strategic decisions e.g., what integration approach to use (best-of-breed, full fold-in, greenfield, etc.). This in turn defines and influences operational decisions such as defining the “long poles” i.e. the integration projects with the longest duration that need to start early to avoid impact on the overall integration timeline.
The challenge with Technology in PMI…
Because M&A and post-merger integration (PMI) technology work can be both protracted and complex, it requires stamina and a multitude of technical experts for various challenges. It often combines high velocity and long duration (relative to the total integration plan), tied to tight cadence and timelines. Creative solutions across many different technology areas are needed every day to meet the challenges that present themselves to the technology teams. Full integration work often starts with an end-to-end assessment of both technology assets and capabilities and ends with a fully integrated set of exactly these assets and capabilities. At least that is the expectation. In reality however, integrations often fail, according to Harvard Business Review at the incredible rate of 70-90%. While Technology is not always the culprit, it is often a contributor to the sub-par outcomes. IT/Technology typically represents the largest individual expense, requires the longest implementation timeframe, and comes with the highest complexity across any post-merger integration effort because it is everywhere.
How to approach the task at hand?
Traditional integration approaches are illustrated below; all of them typically variations and combinations of three archetypes:
· Best of breed: choose the best technology solution for each capability between the superset of the buyer’s and the target’s technology assets
· Fold-in: decide on either all of the buyer’s or all of the target’s technology solutions
· Greenfield: build a completely new landscape, designed and built from-scratch
In practice, these archetypes are not followed religiously. Instead, priority is given to specific solutions and their ecosystems based on business fit, cost to value, etc. In every scenario, the mode of operations is to determine for any given capability if the combined entity will employ one of these options:
(1) use the buyer’s solution, or
(2) the target’s solution, or
(3) both solutions in parallel or in combination, or
(4) a brand-new option – a preferred way of handling this question whenever both firms use outdated or unfit solutions.
These options have been in use for decades and were sufficient in a more traditional, on-premise technology PMI world. The teams start with understanding business objectives and requirements, assess and select one of the existing solutions, implement the necessary solution changes, integrate it into the now grown ecosystem, migrate data, and deploy the solution throughout the enterprise. This example shows why IT often is the long pole in integrations – this approach takes time. The timeline is in the best case like rolling out a given solution to a new entity and in the worst case it takes as much time as deploying a completely new solution while catering to double the stakeholders.
Digital tooling offers a new opportunity for Technology PMI
Agile approaches to design, develop, deploy, enhance solutions not only provide a new way of thinking about software engineering but the architectures supporting them also present opportunities to rethink post-merger integration work.
Digital platforms are modular, scalable, support vast integration options. They are built with an MVP approach, allowing for fast time-to-market and regular feedback loops, all with the goal to provide business value faster. These platforms fundamentally embrace the idea of starting with a clear architecture vision that can be implemented and built over time. Every new feature can be used by customers and other stakeholders as soon as it is released. And exactly that makes it interesting for the world of M&A that requires good-enough solutions fast - and good solutions even faster.
So how can a Digital platform help with the integration of an acquired company? Let’s take a look at a model to show how this can be achieved. For the purpose of this discussion, we will refer to this platform as Integration Platform. This platform leverages SOA, APIs, microservices, or even file sharing for data integration and transaction processing between Centralized features on the integration level and Localized & legacy services in the Buyer-/Target-specific areas, as displayed below.
The Integration Platform acts as a decoupled layer, allowing to connect the buyer and target systems and data without requiring full integration of all applications. The setup and scope of this platform depends on the specific situation and objectives, requiring a set of decisions:
1) What functionality should be centralized vs. localized?
It is best to use an example: cyber security often provides better returns at scale and under centralized (read: standardized) control, covering the combined entity instead of defining and providing services in each entity individually. This makes cyber capabilities an ideal candidate for a Integration Platform. In contrast, during the post-merger integration of two manufacturing businesses that build separate products that can be marketed in combination (e.g. tractors and combine harvesters), the newly formed entity can see value in integrating cross-product CRM capabilities and salesforce activities in a Digital integration layer (e.g. combining CRM instances and data). However, product-specific capabilities can be kept separate (e.g. optimized manufacturing execution systems).
2) What are the basic capabilities of the platform and what capabilities will be added over time?
The basic capabilities must be valuable and required in both organizations, typically foundational in nature. Examples are cyber security (see above), mobile device management, identity and authentication services, cloud service platforms, Middleware services and integration engines, data analysis services incl. data marts and data management functionality. in short: anything that provides base level functionality that expands and scales across the future enterprise. But that is only the starting point. These platforms lend themselves well to adding new digital enterprise services that can potentially provide value across the enterprise. This makes them the ideal starting point and home for e.g. integrating Blockchain capabilities, adding AI and scaled automation services, or integrating with any outside provider of services. An example are product-/service-based partnerships requiring data sharing such as Plaid providing integration services for banks and Fintech payment providers such as Venmo.
3) What local functionality can or should be transformed to Integration Platform capabilities?
Generally speaking, most functionality can be transformed to the Integration Platform, provided that a couple of technical criteria are met. Specifically, it needs to be cloud-based or cloud-ready and it needs to provide simple integration capabilities to allow for data and service sharing, ideally API-based. This means in turn that on-premise, monolithic applications will not immediately qualify for use in an Integration Platform. The main reason may not be the technical hurdles but the financial ones that we want to propose as the leading decision criterion: leaving technical criteria aside, any functionality that can unlock additional value for the combined organization and not just one BU, coupled with a favorable value case, makes a formidable use case for an Integration Platform. This is especially true when you consider future acquisitions and how these services can help accelerate and simplify integration activities. Examples are back-office functions like Finance (e.g. for financial consolidation) and Procurement (e.g. contract management and negotiations). Client-facing services such as Sales or Customer Success/Service can benefit from transforming to the Integration Platform but will require often substantial organizational alignment and investment. In summary: where a value case can be made and technical requirements are met, transforming functionality to the Integration Platform can be a smart strategy to modernize functionality. This also helps with putting it to use more effectively in the combined entity – and in future acquisitions.
So...how to bring this concept into daily life ?
The Integration Platform brings together the core concepts of modern architectures with the technology needs of firms that go through inorganic growth. Firms typically strive for integration of functions to share capabilities across the legacy (buyer/seller) organizations for additional value capture. In addition, this concept presents a valuable option as you aim to purse legacy modernization while also providing foundational capabilities such as DevSecOps and Cyber for continued expansion.
For your next integration effort, be it eCommerce, CRM or ERP initiatives, you may want to bring the Integration Platform concept into the discussion. Check if your technology-enabled business objectives can benefit from this kind of platform before you decide on the traditional "2-into-1" consolidation of applications.
Please reach out to us at info@aberdeenadv.com if you would like to discuss more.