Modernization. Everyone is talking about it. Everyone wants it. But we cannot always agree on exactly what it is. It can mean a few different things, depending on your needs and environment. This of course leads to confusion for those who need it most.

In addition to being a Modernization Specialist for a software vendor, I am a member of the team of authors who created the IBM Redbook Modernize IBM i Applications from the Database up to the User Interface and Everything in Between. This is an issue that even we experts were forced to overcome. We came together to write a book about modernization. After hours of deliberation on the table of contents of the book, it was apparent that it would be difficult to fit the needed content in one book. Even the title of the book is difficult to fit on a page!

The enormity of the topic and the plethora of options available can often discourage IBM i shops from even beginning their quest for application modernization. Fortunately, a few simple tips and clarifications will smooth out the start of your journey.

Modernization essentially falls into three major categories, each of which has its own unique challenges.

Database

The database is the foundation of your application. Your company's data is its lifeblood. This is arguably the most important part of your application to modernize, but it is often the hardest to sell to management. The reality is, if you have done it correctly, the vast majority of your users will never know it was done. The application may run faster and have fewer errors. Your development staff will spend less time "fixing" data and will be able to implement some changes in a timelier manner. These added efficiencies are just harder to quantify.

Before embarking on your database modernization project, here are a few things to add to your to-do list.

Study General Database Concepts

As IBM i developers, most of us have developed our own style of database design over the years. Remember, our system has had a relational database for a long time. That long and rich history has given us some habits that were well-founded at one time but now are no longer the best design choices. I recommend finding a good book on database design and doing some reading.

Learn about database normalization and form. Chances are you are not normalizing your database as much as you could or should. This is important for making your applications as agile as possible. Normalization will eliminate data duplication and help you maintain data integrity.

Also learn the proper SQL terms for database elements. This will help you when looking for resources online or when talking to database experts from other platforms. Below is a short table to help you associate common IBM i terms with SQL terms.

There are more books available on the topic of SQL and database design than anyone could ever read. Chapter 8 of the modernization Redbook is a good place to start.

Learn DDL

Take the time to learn how to create your database files using SQL instead of DDS. You have used DDS for years. You are comfortable with it and know everything about it. You can create files faster because of your familiarity with it. So why change now?

Whether you realize it or not, DDS is limiting you. Think about it. When is the last time you remember IBM adding an enhancement to DDS? If you watch IBM's announcements, you will see enhancements added to DDL, the subset of SQL used to define tables, constantly. New data types and functionality are added at least twice a year in Technology Refreshes. This is where IBM is spending its development dollars with regard to database enhancements. SQL is the industry standard, and you should be embracing it.

Luckily, there are tools to assist you, and resources on the topic abound. Chances are you have i Navigator on your computer. The database section contains tools to help you take an existing file and generate the DDL needed to create an identical file as well as a wizard to let you define a table in DDL using a point-and-click interface.

Understand Triggers, Constraints, Indexes, and Referential Integrity

You need to understand these database features in order to make your application more data-centric. There are entire articles and books on these topics, so there is no need to rehash them here. Through doing your research mentioned above, you should have learned the basics of these concepts. Moving business rules and validations down into your database will simplify your application code and enforce these rules even when data is introduced from outside sources. This is key to having a solid foundation.

Pace Yourself

Do not try to do it all at once! Start small by only creating new tables using SQL DDL. Then move forward slowly. Chances are you will not be designing a new database from the ground up very often, so you need to integrate what you have learned in a methodical way. Again, the modernization Redbook is a great place to start.

Code

When it comes to code modernization, your options are virtually endless. Should you stay with the programming language you are currently using? Should you move to PHP, Java, .Net, Ruby, Node.js, or whatever the language du jour is? The truth is I can't make that decision for you. Every programming language has advantages and disadvantages. I believe that modern RPG is still the best language for business applications, but it's certainly not the only choice. No matter which language you use, the following tips can be applied.

Write Modular Code

Modular coding is essential. In the RPG world, this means embracing ILE and service programs. In other languages, this will mean object-oriented programming. Coding in a modular fashion can be a big step for IBM i developers. RPG applications are historically monolithic and use a top-down methodology. Learning to design your applications and break them into logical units will make you a better coder in any language. Start by reading articles about ILE, service programs, and subprocedures. This information will be invaluable.

Learn and Use the Latest Features

Be sure that you are familiar with the enhancements added to your programming language in each release, and try to incorporate them into your applications. Those features were added because they were deemed useful. You should at least understand them well enough to know if they are useful to you. Even though you may be using the latest version of a language (RPG IV, for example), if you are not using its features, you are not getting the benefits of the language.

Experiment

Coding should be fun. You should experiment while you learn. All too often, readers will tell me they haven't tried to modernize their code because they have not determined what method is best. There is no best method! You will never know what method is best for you until you try a few. Just because you tried to code a certain way when you started modernizing does not mean you should be stuck with that decision if it is not working for you. Plan for time to redesign. If you try to get things perfect before you begin, you will never begin.

User Interface

Your user interface is the face of your application. This is what your user base and management interact with every day. You can have the most advanced database and coding methodologies available under the covers, but if you use them to drive a 5250 session, your users will instantly disregard it as outdated. Many great custom-built applications are replaced by inferior packaged software because the UI is better looking and easier to use.

The new users coming into your company were raised in an age of social media, smartphones, and instant access to any content they want. Can a green-screen deliver that? Simple things like checkboxes, dropdowns, and autocomplete are not only pretty "bells and whistles." They are essential ease-of-use features that users expect. Proper use of such elements can reduce costs by streamlining data entry and reducing training time.

Here are some considerations when modernizing your user interface.

Ease of Input

The key to a successful application is to make it as simple to use as possible. Reducing manual input should be priority one. With the influx of mobile touchscreen devices, many of your users will not have a real keyboard.

This is very different from the traditional IBM i application developer's mindset. We have always strived to speed data entry by keeping the user's fingers firmly planted on a keyboard. In the past, heads-down data entry was the norm and speed was essential. Users navigated screens repetitively and could hammer out data with super efficiency.

With the increase of data exchange via EDI, FTP, e-commerce, and web services, the need for massive heads-down data entry is on a steady decline. Usability should be our focus now instead of data entry speed. On a touchscreen device, you are actually slowing your user down every time you require something to be typed. That is where graphical elements excel. When your input method is a touchscreen, you expect to be able to interact with your application with a simple touch.

Do not forget about keyboards completely, though. Be sure to test to ensure that tabbing through elements flows as expected.

Variety of Access

Your application needs to be available on a plethora of devices and operating systems. Enterprises are becoming more diverse in their hardware every year. A Windows-based desktop is not the only device you must consider any more. Companies are issuing desktops and laptops running Linux. Apple devices are showing up outside of the art departments. More and more companies are deploying tablets on sales and manufacturing floors.

All of the devices should be able to access your company's data. You can develop and maintain applications for each of these possibilities separately, but that is very inefficient. This diversity has led to the vast popularity of web-based interfaces. All of these devices in the wild have web browsers installed. Having a web-based interface gives your application the flexibility to support them all. I do not recommend device-specific applications unless there is a technical need to do so.

Learning Curves

With the move to a graphical interface, the options available to you can be daunting. While I do recommend to everyone to learn basic HTML, JavaScript, and CSS, becoming an expert in all areas of web development takes time. For this reason, I recommend that IBM i developers evaluate tools to assist them in creating user interfaces. Many third-party packages are available for giving IBM i applications better user interfaces. New technologies like Rational Open Access RPG Edition can reduce learning curves even further for RPG developers.

I highly recommend that you try a few different options. Download a trial of a couple of commercial offerings. Try building a UI yourself from the ground up with raw HTML, JS, and CSS. Have a look at some of the frameworks available. All of these options have merits. Finding the right fit for you will require some hands-on time.

Wrapping Up

If I have not answered all of your questions about modernization, good! That was never my intent. But now you at least have a starting point. I do strongly suggest getting a copy of the modernization Redbook, and not just because I wrote a few chapters in it. It is a great source of knowledge on a very wide range of topics related to modernization.

The most important thing to remember is this. The only true mistake you can make with regard to application modernization is doing nothing. It is important to have information, but not at the expense of experience. You will learn as you go and change your mind on aspects of your plan. That is just the nature of modernization. You are not just modernizing your applications. You are also modernizing your skills. It is good to have a plan, but do not over-plan. Never limit yourself to only what you planned. How can you plan for what you didn't know you didn't know?

In the end, there are no magic bullets. Modernization is a process. It will take work, but the rewards are well worth the investment.