Vendors hold the keys to the kingdom when it comes to business applications, and getting off a vendor maintenance program can be scary for any midmarket organization. But the risk of failure can be mitigated, especially for business applications that have run reliably, according to analysts.
"If it has been running for five years and hasn't broken yet and you freeze the environment and don't change it, then chances are it is just going to keep running," said Pat Phelan, an analyst at Stamford, Conn.-based Gartner Inc. and a former builder and manager of financial and human resources systems at Grant Thornton LLP.
By understanding the degree of access you have to the business application, knowing how it fits into your IT infrastructure, reviewing the incident history for the entire application stack and -- above all -- ensuring that change is kept to an absolute minimum, you can keep applications out of harm's way, she said.
Here, we outline Gartner's seven steps for the proper care and feeding of business applications that are being taken off a vendor support program. (A longer list is included in Phelan's "Six Risk factors to Consider Before Terminating Business Application Maintenance.")
Take an inventory of the tools, scripts and source code you possess (or don't).
In the early days of packaged applications, vendors did not sell maintenance, according to Phelan, so a customer contract included a copy of the source code and the compiler to maintain it, either as part of the deal or to be kept in escrow if the vendor went belly up. That rarely happens today, but "there are still active contracts out there that have copies of the source code," she said. PeopleSoft Inc. and Siebel Systems Inc., for example, give out the source code and compiler as part of the deal.
Vendors also provide -- for a fee...
To continue reading for free, register below or login
To read more you must become a member of SearchCIO-Midmarket.com
-- diagnostic tools that help tune and manage the application by identifying what has gone wrong. Finally, there are the tools that come as part of the license agreement and are intended to let users modify the presentation layer of the application.
Bottom line? You should know which layers of the application you have access to and what technical changes the license agreement allows you or someone on your behalf to make to the application before you cancel maintenance.
Review system dependencies, and identify all elements of infrastructure involved.
Changes made to databases, operating systems and various tools can cause the business application you've taken off vendor maintenance to fail. If the application is running on an old database release and the enterprise suddenly decides to upgrade or change from, say, Oracle to IBM's DB2, "you probably want to know about that," Phelan said. "You probably have to freeze that environment because you can't go to DB2 with the application that you have taken off maintenance."
The same holds true for software tools acquired in a friendly takeover. If SAP AG, for example, decides to take its new BI tool, BusinessObjects, in a different direction, you don't want to keep upgrading to the point where BusinessObjects no longer works on the application you've taken off vendor maintenance, advised Phelan.
Consider rolling back support services (OS, database, app server) to previously supported versions.
"Once in awhile I will get a customer who has frozen an older release of their operating system or database system to preserve the environment for that application that has gone off of maintenance," Phelan said.
But many organizations push the business application as far as it will go, by upgrading until the application breaks. Then they end up dialing back one version. "It's not a bad thing to do, but it just introduces risk every time you do it. Our advice is to stabilize and preserve the environment and minimize change," she said.
Implement layers of protection to reduce security problems.
"This means putting the fence around the environment so you minimize any change," Phelan said. The more completely you isolate an application, the less chance it has for absorbing new security protections.
"We also advise fronting the system with a series of trusted domain proxies," she said. The application is no longer getting the new security to accommodate the evolution of threats and needs layers of protection.
Limit system administration access for all parts of the application stack to only the few who manage master data.
This is tough, because today's packaged applications were designed with users "being able to make packaged-based changes to the configuration or the master data or whatever," Phelan said. All employees should be informed that changes must be approved by management, the CIO or someone in a leadership role.
"You don't want people going in there to introduce change in the configuration or to start monkeying around with how the application has been deployed, because that counts as change, too," she said.
Consider revising event management processes and monitoring rules so out-of-tolerance performance is identified early.
"Your environment has become rigid, so anything that could potentially be a problem, you want to catch early because your number of options for resolving the problem has potentially shrunk ," Phelan said.
An example of an event? A database starts to get overloaded and you have to go through database reorganization. Or you are going through a functional event, like year-end processing. You have to monitor performance. This is solid advice for older applications, even if they are under a vendor's maintenance plan, Phelan said. A vendor is unlikely to do much for you in these situations anyway.
"They are not going to certify a fix to that old release if you have some capacity or performance issue," said Phelan. In the end, you're just paying the vendor for its time and expertise to come in and analyze and resolve the issue -- similar to if you still had a vendor maintenance contract.
Inform users that the application is going into stasis, in order to manage their expectations.
"Quite frankly, the users are pretty satisfied with that -- 'Well, thank goodness! You're not going to be changing it on me every week,''" Phelan said.
The other side to this, however, is user groups who constantly ask for customizations and changes. CIOs need to periodically track the application to measure the gap between what is available in the frozen application and what the business wants. If the divergence is too great, Phelan said, it's time to move on.
Cutting vendor maintenance pays off at advertising firm
For Greg Folsom, CIO at advertising firm Arnold Worldwide Partners, dropping vendor maintenance contracts is part of a larger strategy to consolidate IT systems at remote offices and centralize them at the firm's Boston headquarters. The effort relies on a robust wide area network (WAN) built to provide disaster recovery. For example, the firm recently decided to leverage its WAN to get rid of an application and server that handled all the creative work in its New York office. "It's a costly investment, not only to purchase the equipment and the software but the maintenance for the software and the hardware," Folsom said. Using the WAN, the folks in New York can connect to a system in the Boston office.
Arnold's Adobe Systems Inc. products are another matter. "We definitely buy vendor maintenance on that," he said. The software is used to turn the firm's ideas into print, Web and TV campaigns for clients that include McDonald's and Carnival Cruise Lines. The software is business-critical and evolving. Adobe "takes a lot of input from users and turns it into features," Folsom said. "Our people need their latest and greatest."
User input is important when weighing whether to drop vendor support, he said, citing a recent gamble to buy "a bunch" of new Microsoft Office licenses without the costly Software Assurance. He said he doesn't know what new features and functionality he'll be missing out on, but users aren't clamoring for anything new. "No one is saying, 'Wouldn't it be great if …" he said. And in two years, it may be cheaper to buy it outright rather than pay insurance for the right to upgrade. -- L.T.
Let us know what you think about the story; email: Linda Tucci, Senior News Writer
