Enterprise Architecture describes the composition and interdependencies between corporate strategy, capabilities, and the IT landscape. The first framework for this type of structuring was developed by John Zachman in the late 1980s. Since then, many companies have used EA, and tools such as dashboards, business impact analyses, and implementation road maps have become standard.
Used properly, EA makes it possible to convert key business strategy decisions into IT specifications or architectural principles and, in return, even generate new options for action. This potential of EA is still underestimated.
Our projects have shown time and again: Architectural tools and products are very useful and helpful when companies need quick and effective access to comprehensive knowledge about their IT-business environment. This happens more often than people usually expect. The following shows examples of typical cases:
Merging different IT landscapes is a mammoth task
Let’s elaborate on one of the above-mentioned examples. We will focus on the last bullet point, a merger process.
Architectural products are especially important in transformation processes, such as post-merger integration, since they make it possible to outline all systems, processes, and their respective interrelationships across companies and divisions that are to be merged. Mergers and most transformations do not start from the greenfield.
Mergers and most transformations do not start from the greenfield."
Instead, companies face the mammoth task of merging long-established IT landscapes. This complex process involves several steps, starting with due diligence and the development of a PMI strategy, followed by gap analysis and the migration strategy, and, ultimately, plans for archiving and shutting down the old system.
Typically, the timeline is tight and specific goals regarding costs and benefits must be met. Another fact to consider is that staff from at least two different organizations and external service providers are congregating. None of them is familiar with the respective corporate environments. Architectural products can help organizations tackle these challenges. A look at the first two stages of a merger process exemplifies this.
During the due diligence phase, a post-merger integration strategy will also be set up. This in turn requires a high-level assessment of the business and technology ecosystem, including analysis of the technical debt and planning cost synergies. The high-level definition of the target architecture will also be completed. Useful EA products during this stage are:
- establishing an as-is architecture of solutions, for example, technologies used, production dates, or future-readiness
- allocating costs per system, broken down into licenses, human resources, and infrastructure
- mapping solutions to available competencies
The next stage usually focuses on modeling the target application landscape architecture along with a product catalog definition. At this point, matching business and processes to existing IT solutions or products and to supporting applications within the merging companies can help identify discrepancies in available business resources. Migration flows can be tracked with the help of system lists, data flow maps, and high-level interface definitions. Furthermore, operational risks are greatly reduced due to better control and decision-making material.
EA needs to be used correctly
There are numerous critical points in the entire merger process where EA provides valuable insights. It can significantly shorten the overall project duration and thus reduce the impact of lengthy transformations, restoring business-as-usual more quickly.
But it is important to keep in mind that EA always needs to be utilized correctly. BCG handles these types of transformations routinely. While most organizations have their own EA departments, we often witness that they have practically no useful architectural knowledge about their business IT environment.
Consequently, they are not able to deploy EA following well-established practices, potentially causing inefficiencies and waste of effort.
On the other hand, companies with well-functioning EA structures can significantly reduce the costs of transformation.
On top of that, it is easier to make the right decisions on a sound data basis. The results of the transformation are not a black box but can be precisely calculated.
Company values can be accurately modeled with a strong EA, and dependencies can be transparently presented. EA will always form a solid starting point for any transformation initiative. It is worthwhile to dare to look inside the ivory tower and actively use the potentials of Enterprise Architecture.