Focus on Data Management with App Modernization Projects

Published: July 13, 2009

by Dan Burger

Companies getting into application modernization projects have their hands full. That's not necessarily because the modernization project is a nightmare for IBM i shops. Nearly 100 percent of IT departments are struggling to keep up with the work before the modernization project came on the radar screen. But modernization planning is a top priority. Trevor Perry--an application modernization evangelist and strategist, who also is a veteran AS/400 programmer--agrees. Not surprisingly, he has some unique ideas on the topic.

Perry is a self-acknowledged big-time yakker. Some say he can talk the ear off a statue without even stopping to take a breath. But his tongue-wagging is backed up with his in-the-trenches knowledge of application development and his passionate belief in improving app dev and app modernization.

"A lot of people who have heard about modernization think it's something they should do, but don't know where to stick their toe in the water," Perry says. "Much of this is basically a lack of confidence. One of my jobs is to describe the world they live in and the choices they have and raise the level of confidence that they can do it. Generally, they can do it. They just haven't had an outside person to help them guide it a little bit. I am facilitating the first step into modernization world. It's a mysterious step. It's not just building a Web site. It's serious modernizing that includes service enabling and exposing business logic in new ways and integrating it with new things."

In his role as IT strategist and modernization consultant, Perry is a G-man. That's G as in Governance, not Government. Perry strongly believes in governance, which is another way of saying control. In his case, it's control over the application development process. There are tools and procedures that provide the means for controlling app dev in an AS/400 environment. Some are sold by vendors such as ARCAD, MKS, Aldon, and SoftLanding Systems. Some are designed and implemented in-house.

In the interest of being brief, change management software can be described as a tool that manages the build and release process, including application requirements, versions, configurations, workflow, and deployments. A best guess on the use of change management software--either off the shelf or homegrown--is that it is at maybe one out of every three AS/400 shops.

Perry's modernization proverbs are angled toward service enabling applications, service oriented architecture (SOA), and dialing up the control levels. His degree of contentedness correlates with, as he puts it, "the ability to know where everything is, know the rules, and know how to use them." Lately, he's become focused on data--how it's controlled, how it's being used, where it's being used, and how important the information is to the organization and to each of the individual users who can access it.

"There are a lot companies feeling the pinch of regulation," Perry says, mentioning Sarbanes Oxley (SOX) as one of the primary sources of the pinch. "But even without the regulation, [a closer watch on IT environments] is something we should have been doing a long time ago."

Perhaps the people who are now being held more accountable would not be so shocked.

When change management, or more specifically data management, only exists in the head of one programmer, that falls short of accountability no matter if it's in the light of regulatory compliance or just good business practices. "We haven't had our house in order," Perry says. "Now that people are being held more accountable, awareness of change management is rising."

Along with that tide of rising awareness comes the matter of coordinating critical data within application development.

"If I want to take a file and move it from development through testing and into production, I can do that quite easily with software change management," Perry says. "But critical data management gives me a high level of control of the data. For instance, I can modify records and attach them, with a record of what was put into production and at what time it was done."

Bringing data management into the change management tent should make sense to any programmer who has had to modify something in the production system after the systems software, the applications, and the related objects have been promoted. It requires manual steps to make changes in a file such as a master record or master table. Extra programs have to be written to handle that.

As it becomes increasingly common to write configurable software applications, there will be more tables and control files containing data that should be managed and sorted as applications are built and promoted. For those writing configurable apps, moving data and/or adding records to production has been a manual process. Avoiding the time and potential errors that go with this manual process is reason for automating it along with other change management processes, Perry says.

Software applications are no longer judged solely on the amount of encapsulated business logic they contain. Ease of maintenance is also a priority, and the capability to alter software behavior, call it configurability, plays an important role in the maintenance cycle.

Does all this place a new burden on programmers? Perry says no.

"Programmers are already building things that are table-driven and control file-driven. The more of that they do, the more an application needs control over that data. That's why I talk in terms of critical data management. Companies are building more configurable systems. For instance, a system that is built for three users who all use the same application in a different way has to control who uses what," Perry says.

"If you look at the future of applications, people talk about role-based apps, meaning that a clerk and a manager use the same application in different ways. A lot of that will be configured and it's critical data that needs to be managed and controlled. People are writing that code today. There has been a change in the way we write code. Instead of just writing a program to do a single app, then writing second program to do the same thing for somebody else, and it's all hard coded, there is more stuff being managed in the application. People are getting smarter and writing modular code and more modern code. As they do that, there is more critical data," Perry says.

As application modernization projects gather momentum, the pro-SOA Perry sees modular code becoming more common there as well.

"You can leverage legacy applications by service enabling them," he says. "By this I mean re-encapsulating the business logic and business rules and exposing them in a different way so that you can integrate new things. As people do this they become more modular."

It's not necessary to immediately install an SOA when developing an app modernization program, but perhaps the greatest benefit of an SOA is that individual platforms no longer matter in terms of where services are consumed. What does matter is maintaining control of the data. If there is data on a Unix or Windows platform, and it needs to be collected, then data management becomes an issue, as does the decision on which platform the data management functions reside.

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot