We conclude our exciting homily to modernization, the Black Stone Cherry of the IT world, with a thrilling chapter on the final component of the modernization triangle.

First a quick review. We opened this discussion two months ago by talking about how closely the word modernization is linked with the idea of replacing green-screens with GUI and making more extensive use of SQL. But I think it's questionable whether merely changing your tools or your presentation can, by itself, really be considered modernization. Isn't real modernization about making the application stronger and smarter rather than just building it with different tools?

We then dived into a conversation about just going GUI was not enough. If you re-engineer the screens to be more efficient and to reduce pages, clicks, keyboard switching, and other such nuisances, that would result in better screens.

That discussion was followed last month by a review of the role that modularization plays in this process.

Now, we turn to the final segment: intelligence. That is, we need to find ways to make our applications smarter and more useful.

Chances are, your application hasn't changed much since it was written a number of years ago. But probably certain things in your business, even businesses that are quite mature, have changed.

Making the Application Smarter

How do you make an application smarter? Well, one way is to make it do additional things for you. And to make it more connected to the rest of the system. And the starting point for this is a thorough review of what that application is supposed to do.

Application Review

When I say "what the application is supposed to do," I don't mean what the person who uses it thinks it's supposed to do (although that is important) but rather what a cross-section of people who are familiar with that segment of the business want it to be able to do. That is, you can't just assume that the original design was on target. It might just have missed the goal because of technical constraints (a lot of stuff we couldn't do 10 years ago is standard fare now). Or there might have been constraints on the development time frame that precluded it from being done more completely.

Or the original developer might just have screwed it up. And it might not have been that he was stupid. Design goes far beyond page layouts and is a special talent. And over the past 20 years, we have moved away from having developers and toward having programmers do it all. No disrespect to programmers (sometimes I am one), but I am a firm believer that everyone has one thing that they consider the core essence of their job, and that one thing overshadows everything else. For programmers, it's getting code into the hands of the users as quickly as possible and then hopefully moving on to something else. And many times, that's at odds with the design part of the job. A designer never believes what people tell him, always looks for potential problems that may crop up, and tries to think around the edges of what others see.

Anyway, the starting point is to do a good application review: What does it do now? What was the original vision for the app? How has that business area changed? What are the sore points about it with the current users? What additional things do users have to do once they're done using the app before they can consider the job done? What are the hopes of management for the function? What kinds of weirdo things can you think of that could be done here?

What Kinds of Things Are We Looking For?

The first things we should look for are useless data elements. (I'm assuming here that the app we're looking at is an online thing versus some sort of batch job run; the steps are pretty much the same for both except one you can see and one you can't.) Business changes over a period of time, and sometimes fields and codes that were critically important in 2003 have faded to a mere shadow of their former grandeur.

At the same time, we want to look for things that are not there that should be. As parts of the business have expanded over the years, we may need information that's in the database; maybe it's a new addition but hasn't been incorporated into the app.

Or it may be a case in which the data is actually a whole other level rather than being just a field here and there. Drill-down information is a good example. You start with a GL account number to see the summary for this month, but then you want to go deeper and see the detail that makes up this total. You can do this in green-screen, but the ability for the user to drill down easily is a big strength of GUI presentation.

Or it may be just as simple as the ability to view the same information—either summary or detail—from more than one perspective (that is, sort order) with appropriate subtotals. It shouldn't be necessary (although most users love it) to download data in an Excel worksheet and screw around with it. That should only be for blue-skying. If it's something they do regularly, it should be in the app.

Accessing Other Apps

But sometimes you can't do everything within one app. Let's face it; you don't want to build every app to access every possible bit of data that can be had on your system. Often, it's much better to be able to chain from one app (page) to another. For example, if we stick with our GL analogy, when we get down to the detail level, we may want to be able to see details about a given purchase or production order.

Naturally, you have to exercise some control here. If you gave everyone access to everything they wanted, you would be connecting each app to every other app. So you have to use some good judgment and work with management to see what they feel is realistic and what is just gluttony.

Accessing Stuff from the Great Beyond

Back in the good ol' days, when men wore handlebar mustaches and a women would wait a discreet amount of time before taking a seat offered to her by a man, there was nothing beyond the app. It was the sum total of the users' world. But those days are gone. Now there are many times when accessing some external application would be a good idea. For example, how many applications would be improved by being able to send an email directly to someone? For example, suppose a user is looking at the Material Requirements Planning (MRP) information and sees something that may not make it in time. What if the app had the ability to pick up some of the information from the page and generate an automatic (or even semi-automatic) email to someone at the vendor to see what was happening.

And once you're creating an email, you could embed links to salient information. For example, a link to a vendor-oriented page could show all the information that vendor might need to understand the situation. If you were in a more retail-oriented situation, you might include a link to a customer-service satisfaction survey or even a tweet option. In retail, self promotion has no physical limits.

Summary

The bottom line is that too often we think of things in strictly technical terms: am I using the coolest tools as espoused by the technical literary pundits? While those tools may be required to do what is best for the application and the organization, everything still goes back to expanding the breadth and depth of each application in the system. Wasted time? That occurs every time I do a key stroke, change formats from keyboard to mouse, switch to a different screen, or watch a commercial when I could just as easily switch to another show that is not in commercial. Strengthen your apps the same way you strengthen yourself: by expanding their reach.

David Shirey is president of Shirey Consulting Services, providing technical and business consulting services for the IBM i world. Among the services provided are IBM i technical support, including application design and programming services, ERP installation and support, and EDI setup and maintenance. With experience in a wide range of industries (food and beverage to electronics to hard manufacturing to drugs--the legal kind--to medical devices to fulfillment houses) and a wide range of business sizes served (from very large, like Fresh Express, to much smaller, like Labconco), SCS has the knowledge and experience to assist with your technical or business issues. You may contact Dave by email at This email address is being protected from spambots. You need JavaScript enabled to view it. or by phone at (616) 304-2466.

---

MC Press books written by David Shirey available now on the MC Press Bookstore.

		21st Century RPG: /Free, ILE, and MVC Boost your productivity, modernize your applications, and upgrade your skills with these powerful coding methods. List Price $69.95 Now On Sale

Also Read

The Power of Writing Code in a Low-Code Solution

TechTip: Let’s Have a Date, Part 2

Going off the Rails