The Alchemy of Application Modernization and Developing a Strategy for Legacy Solutions

In our previous blog post, we talked about the importance of application modernization and how it creates value by enabling a business to increase revenue and reduce risks. In this blog post we will look at how to categorize legacy systems into modernization strategies that will lead to these benefits. By evaluating both business and technical needs we can group application modernization approaches into five key strategies we call the Five R’s: retire, replace, rationalize, re-architect, and re-platform.

Each of these has specific drivers and attributes that help us understand which approach is right for each scenario. Sometimes there is significant value in rebuilding the core technology underlying your organization and other times there is an off-the-shelf solution that adequately meets the needs. Knowing how to do what and when is a key component to any IT transformation roadmap.

Complete application modernization is a long-term journey, and while it may seem complex, we simplify this journey with a three-step approach:

• First, inventory all systems to understand the current state of usage and processes.

• Next, categorize and develop a strategy for each system with understanding of the current state and business needs.

• Lastly, develop a systematic plan of execution that will allow for incremental changes with appropriate checkpoints along the way.

The purpose of this blog post is to address step two: how to perform the categorization of legacy systems into one of the five key application modernization strategies.

Five Application Modernization Strategies

1. Retire

Removing a system that provides little to no value to the business.

Retiring a solution simply notes that it is no longer necessary to the organization and the requirements of the business. Search for duplicate systems that perform the same or similar business functions. Systems that fall into the retirement category can often be related to discontinued products, services, or lines of business that have changed. Other indicators for retirement include systems that could have a change in ownership and requirements altogether.

There is a high value in retiring systems because it immediately provides relief in terms of costs, resources, and system overhead while having little impact on the business revenue.

2. Replace

Swapping the current system with another off-the-shelf system.

Technology and software solutions change incredibly fast. While this often means more due diligence in selecting systems, it also means there may be systems and components already developed that will suit the needs of your business when replacing legacy systems. In evaluating systems, it often makes the most sense to replace custom developed software with third-party components as opposed to spending the time and money on custom solutions, assuming the needs of the business are met.

The replacement approach can help reduce the level of customization and specialization that IT maintains while offering lower overhead with outsourced support and maintenance. Many times, software as a service (SaaS) offerings are evaluated in this strategy because they provide a lower initial cost and faster overall timeline for implementation and adoption.

3. Rationalize

Retain the system in-place with minimal revisions as needed in the near term.

Another strategy for legacy systems is one of rationalization, which means the system is currently meeting the primary business expectations but the solutions might not be ideal long term. Often, we rationalize these systems because lack of resources, both financial and personnel, lack of time to change the system, and/or the as-is state of the system has negligible risk to IT transformation. Using the expression, “you cannot boil the ocean,” we understand that there is a very practical approach to the strategy of IT transformation where you can’t change all systems at once.

A prioritization exercise will help you select the right systems for application modernization at the right time. Candidate systems in the rationalize category typically have some ability to scale, are adaptable with business processes, and are not immediate compliance risks, thus we choose to let the status quo continue for the near term.

A caution in rationalizing systems is that as they need modification, technical debt is absorbed. At some point this additional increased cost should be factored into the re-evaluation of the application and shift in modernization strategy toward re-architect or re-platform.

4. Re-architect

Modification using existing technologies and an incremental approach.

When a system is failing to meet business expectations of scalability, compliance, or user experience, then we should consider the strategy of re-architecting the system. In these cases, the existing core system(s) can be adapted to meet the drivers of innovation and scale while maintaining compliance and minimizing risk. This strategy often leverages in-house or a common skilled workforce, incremental changes can be made over time to support and build new features and functionality. There are many architectural patterns and practices in place when attempting this type of approach including Martin Fowler’s strangler pattern where, over time, a system is replaced piecemeal, ultimately leaving behind an entirely new system. Product companies who have regular releases or companies who need to demonstrate incremental improvement to clients and customers often find this approach best suits the business needs.

5. Re-platform

A complete transformation of the system with new technology.

The final modernization approach focuses on a very technology-centered solution. Re-platforming is a method of modernization where a large shift in technology is necessary to meet the needs of the business. These systems are often core components of the organization tied to revenue and growth and must succeed in transformation for the organization to move forward. Re-platform projects tend to occupy a large portion of the transformation budget but are worth the time and effort to get right. These types of solutions can often have large data migration efforts tied to them and arduous launch and rollback plans. Due to the risks often involved with this approach, it is not uncommon to see outside assistance and resources aide the development, launch, and support of these core systems. A few examples of these types of projects might be an ecommerce retailer changing the underlying platform or an industry seeking to move all internal applications to a cloud-based environment.

How to Choose

There are many factors to consider when choosing the appropriate modernization strategy for a system, including business requirements, operational needs and abilities, compliance and scalability of systems, timeline, and budget. To help simplify the process, consider the following strategic drivers to help provide a foundation on which modernization strategy to choose for legacy systems.

Hopefully, we have provided some clarification and structure regarding how to determine what application modernization strategies are right for your systems. But if you need help or have questions, please feel free to contact us at findoutmore@credera.com. Credera can help with knowledge and experience performing this type of assessment and can assist you with an application modernization roadmap for your organization.

• Application Modernization