Starting an enterprise modernization project can be overwhelming. There are a lot of options to consider, approaches to take, modernization solutions and services to purchase, and potential risks to avoid. After working on legacy modernization projects for IBM i (aka AS 400 or iSeries) for over a decade, I’ve learned a lot about what works and best practices – and I wanted to share that information with you!

This blog post, the first of a series, will cover the best way to start an enterprise modernization project and the importance of proper modernization planning. After reading it, you should have a good understanding of the steps that should be taken in order to answer the following questions:

• How do we decide where to start modernizing?
• How do we prioritize applications for modernization?
• How far do we take each application down the modernization path?
• How do we determine the minimum level of modernization required for each application?

Before we get into answering the questions above, it’s important to understand the size and structure of a modernization project. Modernization projects in the IBM i world usually include all the applications in an ERP system and therefore are considered large projects. It’s not just the number applications that make these projects large, it’s the various components of modernization that increase the size as well. Most people confuse modernization with UI modernization when in fact modernization includes so much more, including:

• UI modernization
• Database modernization
• Code modernization
• Application architecture modernization.

For example:

Getting an RPG III application off the green screen and running in the browser is a good step in the right direction for modernization but that only gets you part of the way there. Code modernization should take the application from RPG III to RPG ILE or a native web language like Node.js. Database modernization should take the application from record level access to embedded SQL and tables from DDS to SQL DDL. Application architecture modernization should make the application data-centric and utilize an API Library.

Planning the Project

Now that you have a good understanding of the size and structure of a modernization project, let’s talk about how to start planning for it. There is a common misconception that the best place to start modernizing is with applications that are used the most. In my experience, this is rarely the best place to start. It’s important to evaluate the current state of each application from a business perspective and a technical perspective then use the results of the evaluation to guide decisions on priority.

When evaluating applications from a business perspective you’ll want to look for things like process misalignments, places where users are working around the system, and the overall business strategy to help you determine the current state of the application and the business value of the application.

Analyzing the Risks

From a technical perspective you’ll want to look for risks. Below are some examples of risks your application could be facing:

• Losing application tribal knowledge to retirement
• Running an unsupported version of an ERP system
• Difficulty finding talent from a dwindling pool of RPG developers

The risk analysis should be used to determine the minimum level of modernization required for each application. Unfortunately, there is no one-size-fits all option so it’s up to each organization to determine their risk appetite and modernize accordingly. A good example of this is having an application that is written in RPG III. The risk here is that colleges aren’t teaching RPG III anymore, which means finding developers for the language is difficult. Some organizations may choose to modernize their code base to RPG ILE and stop there. Other organizations may choose to take on less risk and modernize further by moving to a more commonly used language like Node.js.

Application Scoring

At Profound Logic we use various factors to evaluate the state of an application and rank each application with two scores: a business value score and a modernization score. The business value score is a metric used to score the application in terms of its value to the business. Systems with a higher business value should be considered first for modernization as they typically provide the greatest ROI and are considered differentiators from the competition. The modernization score is a metric used to show where the application is on the modernization scale. Applications with a lower modernization score have a higher risk of having software, hardware, or process misalignments than applications with a higher score.

We use the combination of these two scores to help companies determine where to start their modernization and how to prioritize their efforts. The same thing applies for those of you looking to do the planning in-house. You’ll want to consider both the business and technical perspectives of the application when determining priority and building a roadmap. You may find an application that is in poor shape technically but has low business value. This application should have a lower priority than an application that is in better shape technically but has higher business value.

Conclusion

Enterprise and legacy modernization projects are large by nature and require an investment in planning to be successful. It’s important to evaluate each application that is in scope from both a business and technical perspective, and to uncover the best enterprise modernization approach. The results of your evaluation will help guide your organization in developing a roadmap that has the business in mind and in turn will deliver business value quickly throughout the modernization project. Hopefully, this blog post was able to answer some of your questions about planning an enterprise modernization project! Stay tuned for future blog posts to help your legacy modernization projects be successful.