In other notes we have tackled what application rationalization is, its true purpose of supporting business decisions for your applications, and why it’s challenging or often leads to subpar results. And long story short, those publications emphasize the importance of applying the right framework and toolset based on the specifics of the goals you are trying to achieve. In most cases, a generic approach will not produce the specific outcomes you need.
This note outlines the steps of how application rationalization should be applied specifically for a merger or acquisition (M&A).
M&A has many flavors and ranges in terms of the nature and degree of integrating multiple entities. For instance, the acquisition of an up- or down-stream organization is more in expanding the capabilities of the organization or increasing the efficiency of the value chain (e.g. a distributor acquires a retail organization). Many mergers, particularly in the public sector, are designed to join related entities under one roof to create a shared direction or create efficiency via the centralization of certain business functions (e.g. police and fire services merger). Other common scenarios feature an acquisition or merger of two alike organizations where the primary goal maybe to eliminate competition, capture greater market share, or expand product types (e.g. retail company acquires another retail company).
For many of these M&A scenarios, the primary implication for IT is more concerned with expanding capabilities and ensuring efforts are focused on integrating the applications and databases of the newly formed environment. In other scenarios, IT is focused on realizing the ROI of M&A by consolidating all of the newly formed redundancy.
Most M&A scenarios feature some balance of these two objectives. You need to determine how goals of limiting cost and complexity compare against minimizing disruption or even enhancement of certain capabilities; or more specifically, how this balance of objectives applies to different areas of the business and their suite of applications.
Consolidation during an M&A is a balancing act of eliminating redundancy and maintaining the other benefits the business is pursuing. You need to know: are you in a position to strip redundancy wherever it exists or do you require a more nuanced approach?
Too often applications are an afterthought to the other aspects of M&A. If not central to the M&A strategy, you will add portfolio complexity stunting business operations and growth or add costs and limit the ROI of the M&A all together. It should go without saying, applications must not be an afterthought in the M&A strategy.
While many acknowledge its importance, they still often make the mistake of treating rationalization as an initiative conducted solely within IT isolated from other M&A efforts. IT may have more in-depth knowledge of the technology, but lacks the business perspective to make the best possible decisions in line with the purpose of M&A. Ultimately these are business decisions and IT should play the role of support and consultation in a holistic decision-making process.
Furthermore, most likely, some of aspects steps listed below may already be designed or underway by other groups responsible for executing the M&A strategy. Do not redo the work. Align and consolidate your efforts to achieve multiple outcomes with less effort.
Ensure the application rationalization effort is a key element of your M&A strategy and the necessary personnel collaborate where appropriate.
For any mergers and acquisitions, some general guidelines apply with respect to the priority criteria and necessary depth of analysis.
For completely redundant apps, affordability and health would be main criteria for which app would be best to keep. For partially redundant apps, whichever app offers the strongest functional coverage revealed through application alignment should primarily guide your decisions.
However, when dealing with competitive advantage creating business capabilities or the capabilities that M&A was designed to expand or improve, rationalization and consolidation will need to be more sensitive to the specifics of what the organization defines as value.
Moreover, if your goals include removing apps that aren’t necessary redundant but low value, then gauging business value should be a priority, especially if business priorities have changed with M&A.
Start by defining the organization’s core business capabilities. These are high-level expressions of what the organization does, for example, risk management, workflow management, or market research. Leverage Info-Tech’s reference architectures for examples of high-level business capabilities and a good place to start in producing your own. This must at least be validated by the appropriate business stakeholders. Ideally your business function heads across functional divides are primarily involved in defining business capabilities.
The business capability once assigned to your applications will act as a “grouping attribute,” which will then allow you to categorize your applications based on similar, overlapping, or complementary functionality. Be sure to apply consistent naming conventions when defining capabilities across the organization.
Map your applications to these high-level capabilities to produce an understanding of where you have overlapping or similar functionality between your applications. Many tools do this, including LeanIX, Orbus iServer, or Sparx EA. ServiceNow APM, which doesn’t specialize in enterprise architecture, even allows some ability to align applications to grouping attributes in the form of business capabilities. At this point, you will not produce a granular understanding of application redundancy, but you will have a better sense of the problem areas and where you should prioritize your efforts for deeper analysis.
In this scenario there are quite a few areas where a recently merged organization has overlapping applications. We have a better idea of the problem areas but lack the detailed understanding of redundancies.
Here is where you should also validate which capabilities are the priority for consolidation.
Start by decomposing your capabilities into their core business processes. Processes are more granular and get into the specifics of day-to-day operations and specific use cases of your applications. Think of it as capability = what gets done, process = how it gets done. Again, this must at least be validated by the appropriate business stakeholders. Ideally your business function heads and/or business process owners are primarily involved in defining business processes and their core steps.
The process will act as more granular “grouping attribute” for categorizing your applications based on redundant functionality. Be sure to apply consistent naming conventions when defining business processes and steps across the organization.
Selecting one or a group of similar capabilities at a time, align your applications to your processes to pinpoint where you have redundant functionality between your applications. A spreadsheet can suffice to showcase the overlap.
We now have a better understanding of the functions the applications provide. In this scenario, applications 2 and 3 don’t offer any unique functionality compared to what is offered by application 1, making them fairly redundant. However, we revealed that application 4 is actually the only app that offers customer surveying, making it a unique system. You should gain a good sense of where your consolidation opportunities exist.
Most likely, you will run into scenarios where you may need to apply an even more granular analysis and align your applications to the even more granular steps in your processes. This will further allow you to define specific functionality and expose things like business dependencies, integrations, data elements, and other key considerations necessary prior to executing consolidation.
Based off of the previous analysis, gather your consolidation candidates. These are the groups of applications still considered redundant after the previous analysis.
First determine which are the target applications. These are the preferred applications that will be kept but will require additional effort to facilitate migration of new users and data and other process and organizational changes.
Here you can entertain a variety of approaches.
Categorizing your consolidation candidates helps you determine a logical disposition:
Decommission. Ideal for your fully redundant applications. These apps should be retired following proper decommissioning guidelines and can require additional efforts of:
Sustain. Ideal for justifiably redundant apps and some partially redundant apps. These apps would not be removed but would likely require new integrations into the new environment.
Merge. Ideal for some partially redundant applications if the consolidation candidates are compatible with each other or the target application. In this sense, merge refers to building a new central system comprising the functionality of individual applications onto a common platform. This would require a substantial undertaking from a development perspective and would really only a preferable option when:
The dispositions assigned to your applications imply a specific call to action or new projects that will require development or configuration needs. Work with your delivery teams to validate the feasibility of these items and start estimating the effort for specific consolidations. Be sure to consider a wide range of business factors when determining the scope and effort for these changes, including user training, new documentation, and other organizational changes.
Capture all of this in a roadmap that organizes all the consolidation proposals into a comprehensive plan. Present this to the appropriate stakeholders to showcase the future direction of the application portfolio to kick-start the investment required to get there.
Plainview Enterprise One is one toolset that covers this journey from start to finish. It provides the features that allow for capability mapping, alignment to applications, rationalization, and roadmapping. Its focus on the relationship between capability and technology allows for a view of redundancy across multiple entities or a newly unified organization.
Lean IX and Apptio have partnered to produce an integrated solution that better informs the strategic decision-making process with improved visibility into an application’s total cost of ownership and alignment to business capabilities.
From the business architecture perspective, agility is the ability to quickly change structurally and operationally to react to external changes or to create new business value. Enterprise architecture comprises business and service/application architecture – therefore, it needs to provide an environment for harmonized agility at each level.
This note outlines some of the fundamental KPIs that you should measure to show the success of the enterprise architecture team. It also discusses how you measure them and visualize the result.
The application portfolio management (APM) tool space can be a confusing one, as many software vendors offer their own take of what APM is. Enterprise architecture, application management and project portfolio management tools offer an APM use case, but these are often quite skewed the primary function of the tool.
Often people misidentify the purpose of application rationalization, leading to misuse and unsatisfactory results. We try to break application rationalization down to its simplest form to understand how to make the most of this critical IT function. tr
Measuring technical debt is important, but more important is communicating the implications of this problem in terms of risk to business capabilities. Cast Highlight tools are used for application portfolio management (APM), specializing in applying code analytics to business decisions regarding your organization’s applications.
Many application rationalization tools and frameworks miss the true benefits of this practice, as they only assess the individual application without consideration for its redundancies. Infusing an enterprise architecture perspective, as seen with LeanIX, will generate the bigger savings you are looking for.
MEGA International announced the launch of its HOPEX Information Architecture solution, enabling various stakeholders to share the same level of information to make collaborative, informed decisions about the governance of data.
Enterprise architects want to collaborate with businesses in real-time to design and create models, but due to geographical constraints, this is not often possible. Many enterprise architecture (EA) tools simply don’t allow the parties/teams to view changes in real-time.