It's time to rethink how we develop applications.

"Application modernization" is a pseudo marketing term that is often used when we talk about the future of legacy systems. It pops up a lot these days, and that's fine because many of our business applications were developed 10, 20, even 30 years ago, and it's not hard to believe that they need to be modernized.

Now before we begin (too late), I want to make it very clear that this will not be your average application modernization article. If you're looking for some tips on whether to go with PHP or .NET; to buy a package, go with SAAS, or redo what you have; to do it in house or through a third party, then this article is not what you are looking for. I can give you those tips, I'm just not in the mood to do that today. You see, today I want to talk about a flavor of application modernization that means more than just a little eyeliner to bring out my cheekbones and some "Just for Men" to hide that little speckle of grey.

Screen Lipstick

Generally, when people talk today about application modernization (or "app modz" as we in the business call it), they're talking about updating the user interface that lies between the application and the users—that is, the screens we use every day.

Generally, this means going from a green-screen to a GUI format and, more specifically over the last few years, to a Web 2.0, browser-oriented format. I have never seen any studies that show this format to be superior in terms of ease of use, readability, or anything else over the old-style computer UIs, but the reality is that most of the kids at school consider the browser-oriented format to be more "modern" and "advanced."  And how can you argue with that?

The prevailing wisdom (another marketing-oriented term that basically means "what we believe today, which will soon be proved incorrect") is that by upgrading the UI you are making your system easier to use and showing your company (and the world) that you are using technology effectively.

So, Is That All There Is?

Now I know that the previous section may sound a bit sarcastic, but there really is value to going the GUI route with your application screens. Just remember that you can GUI-ize to your heart's content and it's just like putting on a new suit. You may look sharp, but it certainly doesn't make you any smarter.

I know that some people will argue that a browser-oriented screen is easier to understand (not sure about that) and to teach people to use (maybe, but that's a one-time bump, not something that happens every day), and it looks more familiar to most people (I'll give them that one).  But for me, that's just not enough.

I believe that we're at a point in our business systems evolution where we should be expecting more from our apps than merely broad shoulders and a nice butt. Properly done, application modernization should not only change the look of our apps but also take them to the next level in terms of how they can help us better manage our enterprise and really impact the bottom line.

And that's what this article is about.

Modularization

So what are the things that we would have to do to make app modz really cook?

The first thing is modularization, something that real hard-core application modernization gurus already recommend you do. "Modularization" is the term we use to describe the process of breaking your applications up into modules: small, easy-to-chew pieces that make it easier to understand the guts of an application.

This is purely a technical project. The programmers will go in, take the programs that exist, and break them up into smaller, more manageable pieces called modules. They may just break the old programs apart, or they may completely rewrite them; it all depends on their personal philosophy and how much money and time they have.

In addition to reducing the size, they also try to reduce the complexity. You see, most programs have three types of things going on in them: business rule logic that defines how your business functions, statements designed to accept or display data on your screen device, and logic to control where the program goes next both internally and externally. Even though all three types are required in most applications, having all three together in the same module really bulks things up and makes it even harder to follow the flow. So when the modules are created, the programmers will set them up so that all of the logic that makes business decisions, all of the statements for data display, and all of the logic that controls program flow are in different modules. This is generally referred to as the Model-View-Controller (MVC) model and is the best way to not only make programs smaller but also make them more single-minded and therefore simple.

And what's reason we want to do this, other than the fact that programmers just love to tear things apart and then rebuild them? Simple: large programs (and that includes 99 percent of all old programs) are massive and convoluted; they're real bears to deal with. As a result, they're hard to change, test, and fix. And that adds a lot of time and money to every project that involves a change to the existing system (which is most of them). The simple fact is, doing a solid and thorough modularization of your current system can lead to some real savings and make it much easier and safer to modify your system as business conditions change (which they do on a continual basis).

And that is really what it's all about: being able to easily and safely change your system as your business conditions dictate. Modularization is the single most important step in that process.

Unfortunately, very few systems will go through an overhaul like this. The problem is that it's a very time-intensive effort (which translates to more money).  Plus, it's hard to make a non-technical person really feel, in their gut, how much sense this makes and how it could make it so much easier in the future to change the way the application works. And the non-technical people are generally the ones who have to sign off on the money for this kind of project.

It's sort of like life. Learning to be flexible in your thinking and making good decisions is not something that is visible when you walk down the street. But it really does have a major impact on how successful you can be in life.

Mobile App Compatibility

The way everybody talks, in another couple of months no one will be using desktop or laptop computers. We'll all be surfing the Web and doing our application work on smart phones. Ya can't beat that 2.7-inch screen for clarity!

Naturally, I think that's a bit of an exaggeration, and if you're over 40 then I think you know where I am coming from on this (is that a 1 or an l . . . or an f?). But at the same time, there is no doubt that mobile devices are going to become increasingly important and certain roles (sales folks) and certain applications (inventory movement entry) may indeed use mobile as their primary environment.

As a result, it will be important in the future if your applications (or at least some of them) are compatible with mobile technologies. In theory, this sounds like it should be a snap. You just make sure that the Web pages that normally display on your desktop browser will also display via your smartphone operating system, right? Unfortunately, it's a lot more complex than that.

Obviously, the screen on your mobile device, be it a smartphone or a tablet, is going to be a lot smaller than what you are used to on your 21-inch desktop or 17-inch laptop screen. The really important issue with a mobile device is to make sure that you can see the data you're looking for without having to do a lot of navigation or scrolling. And that may mean design changes for existing application screens.

In some cases, you may want to use the new kid on the block, Responsive Web Design (RWD), so that the page resizes automatically based on what screen it's being viewed on.

In other cases, RWD may give you the right screen size, but the data you need may not easily appear in that reduced window, in which case you may need to design a brand new screen, just for mobile devices, that gives you a better view. The trick is to decide which pages will need this kind of dual life and then decide which venue (RWD or special screens) will work best for you.

Task-Centric Applications

If I asked you to make a list of the top 10 time-wasters in your organization, I'd be willing to bet that after "talking about last night's game," email is the number one entry.

Now I'm not going to go off on a tangent about email and how evil it is. Evil it might be, but necessary it also is. There are ways to curb the amount of email you get, and they work more or less, depending on how they're implemented, but in the final analysis, all of them hinge upon people agreeing to follow certain rules and procedures. What's needed is something to pull the underpinnings out from under the need for a lot of the emails.

One of the biggest email generators is the multi-department, multi-area project, something like setting up a new customer. This used to be a simple thing. It involved one or two people, customer service and sales, and could be set up in a few minutes. Today, it's much more complex, generally involving a half dozen or more departments and people from different locations and time zones. Face-to-face meetings to do this are out of the question, so we call upon our old friend, the "distribution list" email.

This email, sent to a group only slightly smaller than everyone in your company, details what specific people have to do and asks them to do it. It seems like a straightforward idea, but what it usually triggers is a virtual email monsoon as people ask questions, reply that they haven't done things, ignore doing things, complain about other people who have ignored doing their things, reply their part is partially done, etc. The real problem is that the person who has only one little thing he's responsible for must wade through all of the emails that this generates on the off chance that he's going to be asked to do something else. And that's where email begins to sap productivity.

How does this relate to application modernization? I thought I'd never ask.

Historically, most of the applications we have developed are data-centric. That is, they revolve around certain data files, not around a business processes. I know, we think they do (revolve around a business process), but they don't. Granted that sometimes the dividing line between data and process is thin, but in our era of multi-location organizations, there are more and more times when a process (like setting up a new customer) involves a number of data files but only a handful of fields in each file. Our applications, however, are oriented around setting up the entire file. The result is a disconnect between our tasks (what we're trying to do) and our application system (the tool we use to do these tasks).   

As a result, we need to begin to look at our applications not from a data point of view, but in terms of a business task. That is, what is really important is not the files and fields that are involved but what tasks need to be done, who is responsible for doing them, what the dependencies of doing them are, etc.

Doing this (switching to task-centric applications) will require that we do a really good design (an unnecessary waste of time in the minds of some IT people today) and that the design really focus on what people are trying to do and who is involved in it (rather than on what files we are hitting and what programs we will need). If you really switch over to a modular way of thinking, then a task-oriented design will automatically generate the program structure that is required.

An added plus is that by developing task-oriented design, you can more easily build in workflow and auditing functionality so that the business of who has done what and when and who is up next becomes something that is easily visible as part of the task and doesn't have to be laid out in a distribution list email.

More Than a Pretty Face

Are there more things that we could list as part of true application modernization? Yes, but I'm getting tired and I would guess you are too.

The bottom line is that we need to expect more from our business applications than we are currently getting, and we're not going to get that extra mile by just making them look prettier.

It's time we rethought how we develop applications, how they are organized, and what they do. It's time we turn application modernization into application evolution.

as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7, V6R1