The first steps in a modernization project are the most frightening but often the simplest.

The world of application development is an ever-changing place. Languages and frameworks come and go. Many of them can be seen as fads, but they all leave a mark on the landscape of application development. The landscape is changing more rapidly now than ever before.

Should you jump on every bandwagon that comes along? Of course not! You should, however, stay abreast of trends in the industry. If you do this, one thing will become undeniably apparent. If you're not modernizing your applications, you're quickly driving your applications toward irrelevance. If you haven't updated your applications and your skillset, don't be surprised when management decides to replace your custom-written applications with an off-the-shelf package.

In my previous article "Modernization on the IBM i: Getting Started," I discussed the three major areas of application modernization as well as general technologies and techniques that you should become familiar with in a broad sense. This general knowledge is instrumental in preparing yourself to begin your modernization endeavors. If you have not read this article, I recommend doing so.

The hardest part of a modernization initiative is getting started. You'll find that, as you progress, the difficulty in starting the project is not insurmountable. You're reading this article, so you're interested in modernization. Here's a little secret. Your users want you to modernize your applications. So get started already!

Step 1: Buy-In

It's time to get some work done. We want to move our applications forward. Unfortunately, nothing is free. There will be costs involved, such as education, tools, and time. While in some special circumstances it can be beneficial to ask for forgiveness instead of permission, in most cases you should spend some time getting management and end users on board.

At this point, it's too early to talk about ROI. You don't even know what tools and technologies you'll use yet! The concentration at this point is to convince your stakeholders that you need to invest time and relatively small funding in the project. I find it best to break down several real examples in your organization that could have benefitted from a modernized application and toolset. These should not be difficult to identify and will resonate with the powers that be. Here are some common examples that you can consider.

Business Changes

This situation is "the big one." All too often, IBM i development staffs can become the limiting factor when the business is ready to evolve. Maybe the sales department wants to completely overhaul the company's pricing structure. Perhaps the company is expanding overseas and the application must now support multiple languages and currencies. It could even be as simple a situation as exceeding the maximum number of digits for invoices.

These situations can be huge undertakings in legacy-style applications. Often, business rules are hard-coded in programs and duplicated to other programs. The programs themselves are giant monoliths that require extensive testing for the most minor of changes. Find one of these situations in recent history at your company and explain that had the time and funds been invested beforehand, those incidents could have been dealt with quickly and with a minimal amount of risk.

New-Hire Training

You likely have users who have been using your application for decades. They are superefficient with the application as they have years of muscle memory and working knowledge of the application at their disposal. However, you also have new-hires joining your user base. These are often younger users who may not have even heard of an F-key, much less used one. For these users, a 5250 interface is foreign, frustrating, and outdated. Having a point-and-click interface for your application will be instantly familiar to new users. This way, new users need to learn only the function of your application. The interface is self-explanatory.

GUI Advantages

Some things are just easier to understand when represented graphically. This is usually an easy sell to users, especially management. Sure, upper management can flip through the summary reports each morning to get a high-level feel for the state of the business, but I bet they would prefer to log in to your application and see graphs and gauges to quickly get the pulse of things without having to examine the numbers directly. Now not only is management gaining efficiencies in disseminating the information, you are also saving the cost of paper and toner used for those daily reports.

Integration

No matter how reliable IBM i and Power Systems are, they're not the only platform in your enterprise. Other applications in your company, and customers/partners outside of your company, will eventually need to interface with your application. Modernized, modular applications lend themselves to be easily accessed via web services and stored procedures. Investment now in modularization can make these requirements a breeze when they arise, if they haven't already.

Step 2: Prioritize

It's far too early in the process to start planning your modernization project, although that will be what you will instinctively want to do. The problem with planning at this stage is that you don't yet have the knowledge needed to make the necessary decisions. Once there's a plan, there's a natural human tendency to "stick to the plan." You don't want to paint yourself into a corner early on. If you simply must have a plan for whatever reason, your plan should be to modernize your application and your skillset. That is as specific as you need to be at this point.

While you shouldn't over plan at this stage, you should most definitely begin to prioritize your goals. Modernizing an application is a broad goal. In the previous article, we discussed what I consider the three major categories of modernization. You should spend some time prioritizing these areas of modernization. Which areas will be the most beneficial to your organization? Which will be most compelling to users and management? Which area will benefit you as a developer? These are all valid and important questions. Once you have answered them, you should use the answers to prioritize your modernization goals. The priorities of your company will most certainly be different than mine or any other company's. There are no wrong answers here. Properly modernizing an application will require work in all of these areas, but the order in which you do the work is a personal choice.

Step 3: Education/Experimentation

You may have thought education and experimentation are separate steps. That's a common mistake. It's a classic chicken-and-egg scenario. How can you experiment without knowledge? How can you know what knowledge to seek without experience? It's a bit of a conundrum. The reality is that knowledge and experience are intertwined. You first have to accept that you have a limited amount of both and work to build on them.

So start by making a list of potential technologies to explore. The priorities you mapped out in the previous step should be used to guide you in creating the list. If database modernization is your highest priority, a class on a new programing language is probably not going to be on the top of your list. Keep in mind that this initial list will not be final, nor will it be complete. It's a starting point. Once you have the list, start educating yourself on the technologies.

There are a myriad of options when it comes to education. Internet sources are free but often less efficient than other means. Books can be bought for a relatively small investment. They are often a bit more efficient than Internet sources because they are organized and focused on a topic. Training courses are the most expensive option, but they can often be the most expedient way to learn about a topic. Dedicating the time to a training course and being able to focus free of distractions can often be well worth the investment of money and time. Find the option that works best for you within the investment your company is willing to make.

As you educate yourself, start experimenting. Find small problems you can apply your newly acquired knowledge to solve. These should not be major undertakings. These should be small issues that allow you to do some real-world application of newly learned technology, with the understanding that the work done may be abandoned or redone as you learn different skills.

Just because you're successful with the first technology you try doesn't mean it's the right one to settle on. Don't be tempted to make a decision until you have experimented with all of the options you planned to evaluate. Be sure to spend ample time on this step as it will avoid lost time later due to uninformed decisions.

Step 4: Proof of Concept

You have rallied the troops, prioritized your goals, and armed yourself with knowledge. Now it's time to put yourself to the test. It's time to build a pilot project. I know what you're thinking: didn't we just spend all that time experimenting? Yes, you did. Now that you have played with the technologies and formed your opinion on what's the best fit for you, it's time to find out if you're right.

Choose a pilot proof of concept that's large enough to build confidence in your decision. Make sure that it can stand alone within your application. This will allow for easy parallel testing of the solution. If the project changes the interface of the application, it must also be interesting to your users, because they need to be involved in this stage. Select a group of end users to test your pilot project and give you feedback along the way. If the project is database- or code-focused, select a group of your peers on the development staff to serve as evaluators.

Take the feedback of your testers seriously. Things that make perfect sense to you or make your job easier may not be as transparent or beneficial to others. Don't be afraid to admit that you're wrong. You may find that your selected technology is not the best fit or does not perform well. If this is the case, go back to the education and experimentation phase and find a better solution. Modernization is a process; you will not get it right the first time!

Step 5: Plan the Project

Once you have a successful proof of concept that both you and your testers are happy with, it's time to start planning your modernization effort. At this point, you'll have the necessary knowledge and some real experience to help you plan the project and estimate the effort required. If the solution chosen requires tooling and licensing, you'll need to budget for these in addition to the manpower required to implement the solution.

Look for specific gains in efficiency of end users and IT staff to build a solid ROI for your proposal. Spend time meeting with end users to find pain points and time-wasting tasks in their daily use of your legacy application. Do time studies to quantify the time lost on these inefficiencies. Look for redundant or unnecessary tasks and reports that can be streamlined or eliminated in the modernized application. You'll be amazed at the things you will uncover.

During this process, I have uncovered countless situations that were completely useless. I have seen instances where reports were being printed and then summarized in Microsoft Excel. When I followed the process, many times no one ever looked at the reports or the summaries. In many cases, a manager years ago asked for the data for some unknown reason and the process continued even after the manager left the company. It was just part of the routine.

Take every time efficiency you can find and quantify it in monetary terms. Use this data to build the quickest ROI possible. Once you have this data organized and graphically represented, present it to management along with your proposed modernization project plan and budget.

Wrapping Up

This is my recommended process. It's a lot to consider, but I hope the information I'm providing helps you to begin your modernization journey. Is my way the only way to approach a modernization project? Of course not! I don't claim to have all of the answers, but I have been down this road more than once. I hope my experiences can help you in your efforts. If nothing else, I hope it gives you ideas on how to begin modernizing your applications.

Brian May, an IBM Power Systems Champion and Solutions Architect for Profound Logic Software, devotes the majority of his time to assisting customers with their modernization efforts. He frequently writes and speaks on topics related to RPG, JavaScript, and IBM i Modernization. Brian recently contributed his time and expertise to the new IBM i Modernization Redbook.

 

Also Read

The Power of Writing Code in a Low-Code Solution

TechTip: Let’s Have a Date, Part 2

Going off the Rails