In a recent online discussion about Mergers & Acquisitions (M&A), a fundamental question emerged: Can we simply consolidate the technologies and tools used by the two merging companies to meet most of the architectural needs of the new entity?
The answer, more often than not, is no.
A more structured approach is necessary to ensure that we don’t end up with a half-baked concoction served in an extravagant setting. We require a method to formalise a recipe that addresses most of the business and stakeholder concerns while incorporating essential elements of innovation and budget.
What if we could leverage the insights from The Open Group Architecture Framework (TOGAF) and its four core domain pillars (BDAT) as a starting point?
The first essential step is for management, stakeholders, and technology leaders to collaboratively define an Architecture vision. This vision should encompass the desired state of Architecture that spans across the BDAT (Business, Data, Application, and Technology) pillars. Moreover, the vision should serve as a means of communication with other leaders to articulate the new company’s direction over the next 3–5 years.
Think of this vision as a refined menu at a Michelin-starred restaurant—just enough to pique the diner’s interest. For small to medium enterprises undergoing a merger, allocating at least 2-3 months for this definition is advisable, as it will become the guiding star for subsequent architecture development efforts.
Once the vision is defined, it becomes crucial to assess the current state of architecture in comparison to the vision (similar to maturity models). This can be as straightforward as using a ranking system from 1 to 5, with the vision positioned at 5 and the current architecture at rank 1, especially if both companies’ systems are adopted as-is initially.
Over the coming months, each cycle of the TOGAF Architecture Development Method (ADM) should assist in progressing towards rank 5, with periodic reassessments, much like the journey from a Michelin Star 1 to 3.
The TOGAF ADM, when applied to each of the BDAT pillars, proves to be an ideal approach for our requirements.
The Business (comprising common processes such as procurement and operations), Data (including types, tools, and policies), Application (encompassing toolsets and policies), and Technology (encompassing elements like Service Registry, SOA, microservices, and neural networks) pillars necessitate the creation of various viewpoints as needed.
Additionally, cross-cutting viewpoints such as DevOps, Infrastructure, and HR must be assessed and detailed during the ADM.
Continuing with the BDAT framework, ADM provides the means to define the governance model (who, how and what) and determine when and by whom the governance model itself can be altered or refined.
This is the ideal moment to outline the roadmap for the next couple of years for the merged company, which also contributes to improving the targeted architectural rank.
As we can observe, ADM compels us to establish a formal mechanism for identifying the perfect recipe for our new architecture. It encourages us to explore opportunities, including those arising from innovation programs in merging companies, which could lead to the definition of new business processes, tools, use cases, and products.
Upon completing the first cycle of the ADM, we can provide partner businesses with reference enterprise architectures. All documentation, including reference models, process changes, viewpoints, governance models, recipes, and principles, can now be incorporated into the TOGAF enterprise continuum.
The soup is now served, and this time, it has been meticulously prepared and presented in a proper china soup bowl.
