For AS/400 Modernization, Start With the User Experience
As VP of Rocket’s solution sales team, I talk to people using the IBM i nearly every day. We talk about modernization topics ranging from terminal emulation to multiplatform DevOps to building IBM i APIs. All too often, I find that the conversation turns to this question at some point: My executives want to know why we should hold onto the IBM i at all when there are newer, more “modern” solutions out there?
There’s actually a whole host of reasons to keep your IBM i – including the platform’s impressive TCO, its support for the latest technologies and its unparalleled security among enterprise computing platforms – but today I want to focus on the fundamental flaw in this question. Starting with replacement is looking at the modernization problem backwards. To quote Stephen Covey, you want to “start with the end in mind.” What is the user experience you want to end up with? In this context, user experience means both the experience of the end users of the application as well as the experience of enhancing and maintaining the application.
That means determining first the problem you are trying to solve. Are you looking for a better user experience (no more green screens)? Are you concerned about how you will maintain your applications when your current system experts retire? Do you want to update application workflows to match mobile or web use? Are you looking to take advantage of open source? These are the actual problems that generally underlie the desire to move to a different system. The good news is that this is the right approach regardless of whether you will end up replacing the platform.
The principle “start with the user experience” really gets at the core of what modernization is about. Application modernization is all about focusing on the best place to invest your limited development funds in order to help the business take advantage of emerging opportunities and overcome business challenges. It’s about minimizing risk and ensuring business continuity while allowing for innovation. So with that in mind, I’d like to offer an in-depth look at why I think understanding what the user needs out of the application is the critical and first task in any modernization project.
“Start with the UX” is more than just savvy decision-making. It’s good programming.
First off, separating the user experience from other elements of the application is actually a well-established principle in software engineering. I’m referring, of course, to the model-view-controller (MVC) architectural pattern, in which the part of the application that manages the data according to the rules you’ve defined is designed separately from the “view” (what the user sees) and the “controller” (the part of the application that translates what the user enters).
The benefits of MVC are well-documented, but perhaps the biggest is the ease with which you can modify any one part without causing problems in the other. That’s because each aspect of the application doesn’t know or rely on anything going on within the other units – all it needs to know is what kinds of data it should accept from the other components and what kinds of data it should generate so as to be understood by the other components. This also means that once you create the user experience, you can update the underlying code and database while keeping your new user experience.
What I hope to have shown with this little digression about software architecture is that if you’re not used to thinking about user experience as something totally divorced from the business logic and transaction processing aspects of the application, you really should be. It is perfectly consistent that you should find a modern, attractive, intuitive UX that screams “2018” powered by a codebase originally written for AS/400 in the 1990s. By building an independent UX that interacts with your IBM i, you too can achieve this.
Figure out how people want to use things first.
The truth is, when it comes to computer applications, most people don’t really care what is going on the background. All they care about is “Does it work?”, “Is it intuitive and easy to use?” and in some cases, “Does it look pretty?” Generally, the answer on the IBM i to the first question is absolutely yes. It’s the second and third questions that are the source of the problems. So, why start by looking at the core code? Instead, we should start by looking at the best way to improve the user experience.
There are a variety of approaches you can take to improve your IBM i applications for users without making a single modification to the underlying code, much less replacing the whole system. Giving the user interface a new sheen or “skin” is the easiest modification, and I find that in many cases this alone can address whatever issues companies are having. But it needn’t stop there. If the problem is with the workflow, such as having to move between multiple IBM i applications or between disparate systems to complete a task that should be simple, then an approach such as building APIs can allow you to combine data from a variety of sources to create whatever kind of user experience you like. Service-enabling the application can also make it possible to update workflows and to integrate your applications with applications from your customers and partners. The point I’m making here is that none of these needs entail, as is sometimes believed, that you need to replace your system from top to bottom to address them.
Only once you have the UX should you ask yourself, “Do I still need to rewrite it?”
To be sure, over time, you will want to update your core application code. However, with all the popular, new technology IBM is supporting on the IBM i, even that does not mean you must replace the platform. You can use the latest languages, open source tools and technologies on the IBM i. But regardless of the ultimate direction you choose, once you have the user experience you want, you can begin to replace the core code incrementally. You can take your time and do it in an effective, low risk manner. And you can run that code on the platform that is most sensible for your business.
By starting with the user experience, you can get the users what they want much more quickly and more cost-effectively. Then you can rewrite the underlying core code in a low-risk manner that does not disrupt your business. Once you have done that, you can choose which platform makes the most sense as the ultimate host of your applications.