Application Rationalization During M&A

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).

Step 1. Confirm your M&A goals

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?

Build application rationalization into the broader M&A strategy

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.

Match your rationalization framework to your goals

Effective application rationalization requires consideration of multiple perspectives applied to a framework (scoring model, decision matrix, or decision tree) that derives the best possible recommendations for your applications. A significant part of the rationalization effort is in collecting and analyzing several data points, which represent each of these perspectives and act as the criteria for determining a disposition for each of your applications. The objectives of M&A will help determine which criterion, or “lens,” has greater importance and, therefore, requires more in-depth information.

For any mergers and acquisitions, some general guidelines apply with respect to the priority criteria and necessary depth of analysis.

1. Application alignment no doubt will be the top criterion and demands you apply a fairly extensive approach. Application alignment refers to the mapping of applications across the portfolio to business capabilities across the organization and is intended to identify redundancies, inefficiencies, and gaps. For any M&A you need to fully define:
   • What is the extent of overlapping functionality?
   • Which capabilities or areas of the business have been targeted for consolidation?
   • Are certain applications truly redundant or do they offer some unique features or critical business dependencies?
2. TCO will likely be the second biggest consideration. Often it is the deciding factor with redundant applications. Knowing the full extent of application costs is quite helpful in making good ROI decisions in your M&A.
3. Technical health and other backend considerations shouldn’t be left out of the equation and likely is the third most important factor. Here your technical health factors should skew towards:
   • Fit within the technical strategy, especially if the strategy has changed with M&A
   • Technical risk factors like security and maintainability
   • Understanding compatibility or interoperability of similar applications
   • Versioning
4. End-user perspective is likely the least important factor for an M&A rationalization. However, it is important if minimal business disruption and keeping end users satisfied are primary goals.
5. Business value is the wild card. In this context, business value refers to how well applications deliver on the core value drivers of the organization. Arguably this level of analysis is less of a priority at this time.

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.

Identifying redundancy part 1: Overlaps and where to prioritize

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.

Identifying redundancy part 2: Deeper analysis

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.

Identify your targets vs. consolidation candidates

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.

1. Completeness of process. The application that provides the best functional fit or best coverage across business capabilities and processes is the target. Often, the obvious answer is the simplest answer.
2. Decision matrix. Using a 2x2 matrix, and scoring your application on your priority rationalization factors, the application that placed closest to the top right would be the ideal target application. (Decision matrices can be built to incorporate a variety of factors more comprehensive than the three examples below.)

3. A new target. No existing application satisfies the business and technical needs, calling for:
   1. Building or buying a net-new application and retiring existing applications.
   2. Treating all applications in an area of redundancy as consolidation candidates.

Categorize Consolidation Candidates

Categorizing your consolidation candidates helps you determine a logical disposition:

• Fully Redundant. The application’s functionality is fully provided by the target application. These will be your quick wins.
• Partially Redundant. These applications offer some unique and valuable functionality not provided by the target application. These require further analysis to determine the value of some consolidation methods vs. maintaining the application as is.
• Justifiably Redundant. The application’s functionality is fully provided by the target application but still offers some value to the organization in maintaining its independence. This can often be due to allowing business unit portfolios to be self-governed or autonomous, diverse product lines, or along regional divides. Work within your M&A strategy team to build the business case for what is and is not justifiably redundant.

Assign dispositions to consolidation candidates

Decommission. Ideal for your fully redundant applications. These apps should be retired following proper decommissioning guidelines and can require additional efforts of:

• Migrating data from the current applications to the target applications or new database.
• Migrating users to the target applications.
• Configuring the target application to adapt to new business process.
• Process changes to meet the new target application.
• Various organizational change management functions.

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 current goals are to consolidate related business processes.
• Goals of data harmonization are high.
• Interoperability is or will become very low among applicable applications.

Build a consolidation roadmap

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.

---

Want to Know More?

• Discover Your Applications
• Build an Application Rationalization Framework