Krueger Thinks Through the Application Renewal Dilemma
by Dan Burger
Is your company dead meat unless it undertakes an application renewal project to Web-enable your legacy code? You've heard the promises about remaining competitive and getting products to market quicker. What's the truth? Application renewal prevents the need for rewriting applications or tossing away major investments. The process covers everything from "screen scraping" to integrating new technologies and disparate systems. But just knowing about these options doesn't tell you which one is right for your company, and plenty of companies are stymied by the choices they need to make to modernize their applications.
I asked Janet Krueger, a specialist in the areas of e-business, building Internet-based organizations, and integrating distributed workforces, to provide some concrete advice to our readers. Krueger's approach is to find a balance between a company's technical skills, business needs, and strategic goals. No Web-enablement project can, as Krueger explains, succeed without taking into account a company's computer systems and the people who manage and use them.
Krueger was one of the speakers at the recent iSeries and AS/400 Conference in Naples, Florida, where she presented seminars on topics such as Investment Maps for iSeries Applications, Sifting Through eCommerce Alternatives, Justifying a Java Conversion or Defending Your Current Skills, and Friendly Interface Design. During a break between sessions, Krueger and I discussed her views on application renewal projects.
What are the main focus points for companies contemplating an application renewal project?
The first thing is to identify the real business needs. How much investment does a company actually need in its applications and why. If you can't identify something that has a potential return on investment, you are not going to get very far with justifying anything. I encourage people to stop focusing on how to enhance applications and to start focusing on what business needs do these applications have. To say applications aren't sexy enough, aren't beautiful enough, or aren't graphical isn't articulating a business need.
I also suggest companies take a complete inventory of applications and staff, then figure out how much expertise is in-house and how much of the application set is "ownerless." If applications are running with little or no understanding by the staff, that application is ownerless. It is often the things that are not understood that will likely create problems when changes get made. If you reach the critical point where almost all of the applications are not understood, that's the point where you are better off buying or building a different package, rather than attempting an application renewal project.
Throughout the process, keep things simple. Don't chase after the latest buzzwords. There's no need to change if 90 percent of what you have works. Deal with the 10 percent that doesn't, rather than trying to rebuild the entire system. Figure out which parts have adequate functions and which need new functions. Prioritize what needs replacing. One of the keys to building new interfaces is to do it without breaking what you have. Many business transactions don't need to be changed; they need to be linked with other things.
I tell companies to look at their current skills. If they fit with the job that needs to be done, use them. One of the things IBM tries to talk people into is the RPG versus Java--old languages versus new languages--discussion. I think there are a lot of business jobs where languages like RPG make perfect sense. To say that it is not modern or current and we should retrain people in object-oriented programming, persistent objects, and all that wondrous stuff leads to a level of complexity and replacement that's uncalled for in a lot of application sets.
What is the overall picture you come away with when surveying the iSeries and AS/400 shops that are considering or undertaking application renewal projects?
Part of what I see is a lack of defining strategies--what needed to be done with the applications. A lot of companies no longer have an ongoing investment stream in their applications. Many do not have a good staff in place that allows them to build as they go. They get stuck behind the justification curve of having an IT staff that is actually capable of enhancing the applications.
Once a company loses its expertise--a staff that initially helped write and maintain applications, and understands them--there's a big initial expense in getting your arms around what everything does and what's there, so that you can move forward. You can't justify that expense unless you have a specific business reason for needing to move forward.
What are some examples of business needs that a company needs to be focused on meeting?
Finding ways to allow remote access is one of the business needs that many need to address. There's been a growing need for businesses to support functional remote access over straight Internet connections. So a lot of business applications need Web-enabling that isn't based on retail sales or different-application access. There is a clear business need for remote access. It's about a different entry point into the application set, which often can be done with straight Web-based 5250 emulators. Setting them up and tying them in then becomes the task.
It is difficult to justify tweaking applications because people want remote access. What companies have discovered, however, is that the biggest cost to setting up remote access, if you weren't doing it on well-identified targeted lines, is that you have to step up the security. A lot of the time, stepping up security means changing the applications, because once you have Internet access you need to be locked and in control.
There is a different level of business need that you see IBM pushing a lot. IBM says businesses need to change how they do electronic data interchange [EDI] and different levels of e-commerce. It involves orders and accounting and the availability of applications through other computers systems. It's a new level of functionality. There is a raft of products for getting into e-commerce. But, again, you have to identify what the business need is and who it is that needs to communicate with your applications. What are their constraints to doing that? Different businesses will have different levels of constraints.
Where does 5250 emulation fit into application renewal, and is it fair to categorize it as only a short-term solution?
It is the fast way to [satisfy] a business need. A plan that takes a year or more to implement isn't going to sell. A plan that provides some level of basic access in two weeks can make you a hero.
Often there's a plan for solving the immediate need, even though the resources for a long-term solution may not be available at the time. When companies build the quick one, which is also going to be inexpensive compared to the long-term solution, without a plan for the long-term, it becomes problematic to get the justification for the long-term plan. That's why short-term solutions sometimes end up lasting forever.
My rule is, when implementing a short-term fix because it's the fastest way to get people off your back and the fastest way to make people somewhat productive, you need to realize when it is not the right long-term solution. In those cases, make sure there is an obvious end-of-life to your short-term fix. It's like a spare tire that cannot be driven for more than 100 miles. It forces you to fix the problem.
You are saying the "if it ain't broke, don't fix it" approach is actually best in some cases. In other words, application renewal isn't necessarily required, even after determining there are good business reasons for maintaining 20-year-old applications.
You have to differentiate between not liking a solution because it is architecturally inelegant and not liking it because there are problems. In my view there is nothing wrong with architectural inelegance that functions and works.
A good example is an installed application that is not quite automated and requires some manipulation of files. If it is tailored to a specific business application, having manual steps isn't a bad thing, if it is well documented and people are trained to do the job properly without taking short cuts.
In your opinion, do most companies have the resources to Web-enable their applications?
Most companies can do some Web-enabling training for part of their staff, but most of the available training is not iSeries-based.
A lot of the iSeries-based companies that have gotten into Web services are somewhat disconnected. They are not going into live transaction data. There are manual keying processes to get from one system to another. They have set up a Web-based commerce system that requires keying in an order and then someone else keying those orders into another system. Or there might be a batch process where orders are collected on one system and harvested into a file, and then that file gets loaded into another system.
You can cobble together systems that will work. These are independent, disparate systems that are not linked. It is cheaper to hire a programmer to provide a new function than to do true integration with more efficient information flow.
Another problem that companies face is the 24/7 availability issue. On the Web, people expect access at all times. That means within the IT infrastructure, some level of 24/7 help-desk support and IT support is required. Either that, or you had better expect a lot of tolerance from users when they can't find something or the system is down.
A lot of AS/400 shops are set up with a batch processing window and a save/restore window. They take the system down, they save all the stuff, then they bring the system back up. And as long as it's running by 4 a.m., it's ready for employees coming in the door in the morning. But with remote access through the Web, and the iSeries as the Web server, you can't take it down.
If you set up a separate Web server, you have to figure out how it functions when the iSeries is down. There are complex high-availability systems that are OK for large customers, but small customers can't afford them. There's an impact on infrastructure that has a high cost, and many have trouble understanding it and planning for it.
What is the biggest mistake someone can make after thoughtfully determining a business need for application renewal?
Making a step-by-step plan prevents mistakes in the long run. You have to consider supporting existing customers along the way and avoid breaking things as you go along.
It's hard to get a customer set or a user community to [go through] a long process with you without getting anything. You have to look at how soon you need get something up and functioning. How long can you stretch that? How long can you continue to provide support while you buy yourself time to move forward?
There's a basic principle that applies to application support, just as much as to anything else: It always costs you more to get new customers than to keep the ones you have. If you can help the users move forward with you, and help them train new users, you are a lot better off than if you torque them off and make them go away.
Janet Krueger has more than 25 years of experience in the IT industry and currently works as an educator and consultant. She can be reached at email@example.com.
Contact the Editors
Last Updated: 7/15/02
Copyright © 1996-2008 Guild Companies, Inc. All Rights Reserved.