Application modernization is fast becoming one of the most important items on CIOs’ agendas. According to a recent survey performed by Rackspace, 71% of respondents say that 1 in 4 of their applications are currently undergoing modernization. There are several reasons for why these initiatives have gained in importance:
- The desire for most organizations to move their applications to the cloud. Improved customer experience and process optimization are two big factors for this shift.
- The skills needed to maintain legacy applications are leaving the workforce as they get older.
- Reductions in cost for out-of-date infrastructure.
- The need to ensure that current environmental conditions are accounted for and compliance requirements are met in systems. 56% of organizations that responded to the above survey claimed that they had experienced these kinds of failures due to delays in modernization projects.
At the same time, there are still many fears and hesitations that come into play when attempting to update or transform applications. Costly blunders in modernization projects typically occur because of a lack of understanding either in what is contained in the source applications or in how to determine the best approach for the applications based on project requirements. In our experience, the best way to take advantage of the benefits listed above while avoiding negative outcomes is to follow a step-by-step, phase-based approach to devising an application modernization strategy.
The key steps are as follows:
- Define your current state and your desired end state (Assess and analyze)
- Research and outline your options for getting to your desired end state (Select the path to modernization)
- Determine if you need additional tool(s) to get you to your desired end state and undergo a proof of concept (Start transforming your applications)
Assess and Analyze
Know where you are to plan where you want to go. It’s important to take time upfront in any modernization project to get a baseline understanding of where you are and define requirements for the future. This includes:
- Defining your portfolio appropriately for the set of applications that are in a related area that need to be modernized.
- Generating a comprehensive set of documentation artifacts for this portfolio including reports related to logistics, inventory, complexity, dead and redundant code, drill down diagrams, and database model details. This documentation should be easily digestible by both technical and non-technical personas to enable collaboration.
- Defining must have and negotiable end user and technical requirements for the future application.
Select the Path to Modernization
Once you’ve framed up the project and have a better sense for what would need to be done to get to your target application, you’re ready to determine which modernization path makes the most sense for you. The two main courses of action here would be either to extract business rules or to optimize the code and migrate it to a modern language. The way we think about making that decision is as follows:
One of the key decisions will be whether it makes sense and if there’s an appropriate commercial off the shelf (COTS) product available for you to implement your application in. This will involve your own research and due diligence on available third-party offerings to see if there is something available that will fit your needs. The other key decision will be whether your legacy application needs substantial enhancements or not, which is information you can derive from the assessment and analysis work done prior along with input on current environmental and business conditions. Once you’ve made these decisions on a per application and portfolio basis, you’ll be well equipped to determine whether it makes sense to replace or rebuild, which require rules extraction or refactor which hinges on optimization and migration.
Start Transforming your Applications
Now that you know how you can get to where you’re trying to go, it’s time to determine if you need additional tools or companies to facilitate that process and research the options if so. Factors that come into play might include:
- What capabilities the tool offers. Does the tool provide you with the flexibility to choose different paths to modernization?
- What programming languages the tool supports. Is the entire portfolio that you want to modernize covered from a documentation perspective? If you’re looking to migrate code, is the target language supported?
- What levels of automation are supported by the tool. What kind of timeframes are you looking at for the project and is the level of automation sufficient enough to meet those goals?
- Enabling collaboration between business analysts and technical personas. Does the tool provide outputs that facilitate decision making across the business?
Once you have selected a tool, it is always wise to carry out a proof of concept to test the outcomes that you are trying to achieve. A good vendor will work with you on this process and help set expectations accordingly for you to plan budget and resources necessary. Application modernization can feel daunting without the right information and the right approach. By arming yourself with knowledge and a step-by-step decision making process, you’re able to make an immensely complex undertaking more manageable while also setting yourself up as best as you can for success.