Application rationalization: why is it valuable?

Application rationalization is a little like clearing out your wardrobe so you have space to store your clothes. Chandra Knabel, enterprise architect at SAP, explains how you can "Marie Kondo" your IT landscape.

Application rationalization always reminds me of that moment when you realise you have 10 pairs of running shoes, 25 sweaters, and 18 pairs of black yoga pants. Maybe you have a vague sense that you don't need all of these items, and maybe you're starting to run out of room. How do you work out what you need and what you don't?

During the COVID-19 lockdown, I read Marie Kondo's The Life-Changing Magic of Tidying Up and tried some of her tips. I gathered up all my clothing and then evaluated what "sparked joy."

Clothes that made it past the cut were organized by color and I limited what I kept to what fit into my existing drawers and shelves without using auxiliary storage. As a result, I always know what I have and can easily find it.

"Sparking joy" with application rationalization

As an enterprise architect who manages an application portfolio, I notice when we have too many applications that aren't "sparking joy" – that is, adding enough value to the organization.

Organizations find themselves in this situation for various reasons:

Mergers and acquisitions
Decentralized IT decision-making
Speed-to-market considerations
...and so on

Application rationalization is enterprise architecture's answer to tidying up your IT landscape and offers significant benefits.

You need to start by creating an inventory of all your applications, tracking a few critical attributes for each. Once your list is complete, the rationalization process can begin.

Find out how LeanIX can support you in creating an application rationalization inventory

Naturally, your plan to simplify the application landscape will be based on the specific needs of your organization. Still, whatever you decide to keep or get rid of, simplification results in cost savings and increased agility. This makes it easier to respond to new and changing business demands, while freeing up investment for innovation.

What’s more, as long as changes in the application landscape are reflected in your inventory, you'll always know what you have and where it fits in the business.

Getting buy-in for application rationalization

Before starting out on your application rationalization initiative, securing support from key stakeholders is essential.

Typically, the owner of the initiative would be the chief information officer (CIO) or, in larger organizations, the senior leader who owns the enterprise architecture function. These sponsors should work with the enterprise architecture team to outline the scope and goals of the project.

Since one of the main benefits here is cost-saving, the chief financial officer (CFO) should be included as a stakeholder. Then, for each functional area, the project lead will partner with the senior leader in that group to jointly own the decisions being made. If they can't agree on specific choices, whoever owns the application budget should make the final decision.

It’s also important to keep in mind that application rationalization is an iterative process. You will always have the opportunity to revisit the decision to keep any particular application in the future.

In fact, the most crucial byproduct of this process should be a strengthening of the trusted advisor relationship between the enterprise architects and the operational leadership team. Winning the battle over a specific application in the IT landscape, but losing the war by souring the relationship with that leader, isn't worth it!

The right time for application rationalization

In the same way that it's always a good time to declutter your house, it's always a good time to focus on application rationalization. The specific inflection points that might make rationalization a higher priority fall into four categories:

1. People

When a new CIO or enterprise architecture leader joins the team, for example, they often want to know what the application landscape looks like and where there might be opportunities for application rationalization.

2. Financial

Since one of the top benefits of application rationalization is cost savings, financial considerations often drive rationalization efforts. The organization can use the cost savings generated through rationalization to fund additional capabilities, free up resources for innovation, or simply increase profitability by bringing down IT spend.

3. Organizational

Organizational changes like mergers and acquisitions often result in duplicate applications and, thus, often trigger an application rationalization effort focused on the future-state application landscape.

4. Contractual

Finally, contract expiration dates offer the chance to change the application landscape, though these changes must be co-ordinated and planned well in advance. The important thing to note is that application rationalization supports the long-range planning needed to make significant contractual changes.

3 steps to application rationalization

Depending on your starting point, the work needed to inventory your applications may vary. If at all possible, crowdsource the information-gathering from your internal technical and business experts to enable speed and accuracy.

Find out how the LeanIX platform can automate application information-gathering from everyone in your organization

The overall application rationalization process involves three steps:

Application rationalization step 1: inventory

Try to keep it simple. Agree upon what information you will capture about each application and create an application template.

Fight the tendency to add too many attributes during the initial phase of your application rationalization. Adding too much information will slow the process. After all, the team may never use some of the information collected and you can always capture more later.

To start with, I'd suggest capturing the following information for each application:

Application name
Provider
Life cycle stage
Business criticality/risk
Department/user group
Functional fit
Usage/Adoption
Technical fit
Business Capability

You can use readily available references if you have not yet documented your business capabilities.

For more information, see our Definitive Guide to Business Capabilities

The set of business capabilities you start with doesn't need to be a perfect fit for your organization, as you can always revisit it later. For an application rationalization exercise, what matters most is a high-level view of the business capabilities supported by the organization’s applications.

While the recommendation is to keep it simple for the first go around, gathering additional attributes may be necessary. For example, if readily available, capturing the annual cost of applications and contract expiration dates may be helpful for the rationalization analysis to come!

Application rationalization step 2: analysis

After you've completed your application rationalization inventory, the fun begins!

Create logical groupings of applications using the business capabilities or the department/user groups they support. Then, bring business and technology stakeholders to review the list based on those groupings.

Lean on each area's technical and functional sponsor to reinforce why this analysis is being done. Focusing on the goals established at the beginning should help minimize conflicts, but some disagreement can be expected.

The application rationalization sponsors should work together to gather feedback from all stakeholders. Then document the reasoning behind decisions made to mitigate revisiting the decisions in the future.

A tool that allows for data-driven views based on different attributes, such as functional and technical fit, will enable the process to proceed quickly (as I discussed in this post). The goal is to create a recommendation for each application and work with the application rationalization team to prioritize next steps.

There are several frameworks for deciding on next steps, such as Gartner's TIME method:

Tolerate
Invest
Migrate
Eliminate

...and the 6Rs Framework:

Re-host
Re-platform
Re-factor
Re-architect
Retire
Retain

Ideally, the team should document these recommendations directly in a tool, so the stakeholder groups can see the results in real-time.

Find out how the LeanIX platform can automate your application rationalization documentation

Application rationalization is an iterative process, as I said, and you should assume that only some of the actions you want to take to rationalize the application landscape will happen the first go around. Of course, this means there will be an opportunity to revisit the recommendations during the next phase.

Application rationalization step 3: planning your future

This step is where you plan to realize the first benefits of application rationalization.

Every organization I've worked in had multiple applications that did the same or close to the same thing. I'm sure your organization is the same.

Reducing this duplication will make everything run more efficiently. Based on the data you have gathered, it's time to tidy up your IT landscape.

Your organization's unique business demands and dynamics will likely drive how you approach this. It would be best if you targeted changes with business stakeholders that you already have a good, trusted working relationship with.

This approach is akin to Marie Kondo's method of starting with the most straightforward category of clothing. In my example, this was the 25 sweaters taking up too much space.

The enterprise architects will drive the plan by creating an application rationalization roadmap with different phases. Understanding the interdependencies between applications, the capabilities they support in the landscape, and what it takes to move them successfully is where enterprise architects shine.

With this roadmap, you should have a clear plan of which applications to target for retirement or replacement, and how to co-ordinate those changes. Execution of these plans will result in immediate and long-term cost savings in software licensing and support costs.

How long does application rationalization take?

You would get many different answers if you surveyed all of your friends and asked how long it would take to declutter their house. How long it takes depends on how much stuff they have, how quickly they can analyze what to keep and what to get rid of, and how much time they have to dedicate to the process.

Application rationalization is much the same.

Because of the broad group of stakeholders, it is assumed that all the work on this process will be done incrementally. How many applications you have and how spread out the information about those applications is will dictate how long the first inventorying step takes.

A reasonable estimate for creating the inventory is one to four months.
Analyzing the inventory to determine what should stay and what should go might take one to three months, depending on the complexity of the application landscape and the organization.
The final planning step should take the least time because all the decisions will have already been made, so let’s say one or two months. The enterprise architects can take those decisions and plan for phasing in the changes.

Using this high-level estimate, you could reasonably expect to complete an application rationalization process in three to nine months.

Maximize the value of application rationalization

Application rationalization provides a way to maximize the value your organization realizes from its technology investments. Still, it is critical that you also establish a corresponding governance process to ensure the value is retained.

If you declutter your closet, but then go out and buy more clothes, the closet becomes cluttered again quickly. In the same way, you must establish a governance process to analyze new business capability requirements against existing applications before introducing new applications.

Once you run an application rationalization process on your portfolio and have a governance process in place, keeping it up to date should be relatively easy.

At least annually, refresh the application ratings and revisit the analysis to see if there are any new opportunities to remove duplication. With an annual roadmap-refresh process in place, you should be able to co-ordinate your rationalization projects with other strategic initiatives.

In any growing business, the need for application rationalization will arise again and again. With the systematic approach I've described, you should be able to stay one step ahead of the clutter and keep your business running smoothly.

Chandra Knabel is an enterprise architect at SAP.

To find out more about how the LeanIX platform can support your application rationalization efforts, see our use case:

Use case: application portfolio management and application rationalization