eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
If youre like most IT pros, your company is running applications that were created well before you arrived on the scene. How much longer will it be before you put those old apps out to pasture?
That question came up during a recent panel discussion I moderated in which five CIOs delved into their IT agendas for next year. Both Eugene Zimon, CIO of NStar, and Kevin Roden, CIO of Iron Mountain, figured that keeping the lights on and the data humming consumes about 60 percent of their budgets.
What do you get for those maintenance dollars? Usually another year of running some applications that were built for a reason no one quite remembers. They are reliable and hardly ever conk out, but there are probably only a couple of employees at your company who know how these apps operate. At some point, these applications are going to have to head to the software retirement community. This year, Id suggest, is as good a time as any to make those golden years a reality.
Why now? You have a much wider range of development options than you did a few years ago. You also can be fairly certain that the applications will need to operate within widely understood Internet standards. In addition, there have never been so many tools available to tie new apps to legacy apps.
You also have a range of development providers to choose from: your in-house programmers, who want to show you they have kept up with the times; U.S.-based companies eager to demonstrate they have learned to be on time and cost-efficient; and offshore outsourcers arrayed from Mumbai to Moscow.
But pulling the plug on old apps requires more dexterity than a swift snap of the wrist. I asked a couple of members of eWEEKs Corporate Partner Advisory Board how they go about deciding when an applications time has come.
Carol Knouse, senior vice president and CIO at Donna Karan International, wrote via e-mail that she begins by assessing productivity.
“The first thing that we ask ourselves is if the system is still providing value to the business and if the business is dependent upon the information or reports that are generated by the system,” Knouse said.
Then, she turns her attention to the escalating costs of keeping an aging app up and punching.
“We look at the cost of operating the system in terms of complexity—old architecture, limited expertise available—and risk,” Knouse said. “Is it flexible enough to support changing business, customer or statutory requirements? In other words, we basically perform a SWOT [strengths, weaknesses, opportunities and threats] analysis on the application to decide when and how to upgrade or replace it.”
Frank Calabrese, manager of PC strategy and services at Bose, had these e-mail remarks: “In the past—pre-MSBlaster—we allowed old versions of Microsoft OSes to support applications that could not be or had not yet been ported to a modern OS. Examples being things like CAD apps that ran under Win NT or test equipment running under Win 9x.”
This was necessary, Calabrese said, because proprietary file format support was needed for the documents. It would also save the cost of updating software and retraining users, of course.
However, his thinking has evolved to this: “One, we cannot have unsupportable applications in our environment. Two, I cant risk the exposure of an OS that I cant secure. Three, if a vendor has not invested in creating an update for a purchased legacy software package, then I can be assured they have no ongoing commitment to supporting that package. This is really bad if we rely on the software.”
This led Calabrese to conclude, “If we dont rely on the software, then we dont need to have it in our environment.”
Giving old applications a hard look is a great way to attain clarity of vision—and is without question the best place to start in building your IT infrastructure of tomorrow.
Discuss this in the eWEEK forum.
Editor in Chief Eric Lundquists e-mail address is [email protected].