Taking Control of Third-Party Vendor Packages
by Mark Kasperowicz
Read the industry press and you’ll come away with the feeling that the Year 2000 is simply a mainframe problem, nothing more. Convert the code and you’re in control. But for many companies, it’s what you can’t touch, specifically code in third-party software packages, that may ultimately prove to be the millennial nightmare.
Because almost all vendor contracts prohibit a client organization from manipulating packaged code, you essentially have no control over when, how, and if the Year 2000 upgrades will be made. Just ask Harvey Reisberg of the Depository Trust Company. “At DTC, we did an inventory and came up with 650 vendors representing nearly 1000 software products. We wrote them all letters requesting their compliance status and over 50% did not respond. Of those that did respond, less than half said they were compliant. What happens six months down the road when they still haven’t responded? Do we continue to wait? Do we change packages? At best, it’s a high risk game with the vendor holding all the cards.”
DEFINING VENDOR COMPLIANCE
Because Year 2000 compliance is driven by the vendors, a company can easily be placed in a stand-by mode. To regain control, an organization needs to be proactive, not only in communicating with vendors but in assessing Year 2000 risks and contingencies. The first step is to understand a vendor’s compliance plan and schedule. This requires formalized communication, normally a Year 2000 Compliance Form, that is sent out as registered mail to each vendor. In addition to information regarding repair methods and release dates, the form should also include a deadline for their response as well as a definition of compliance.
“After about fifteen iterations, we put a definition of Year 2000 compliance into all of our vendor communications, contracts and documentation,” says Harvey Reisberg. “DTC’s definition states that, “By Year 2000 compliance we mean that each application, system, product, program, file, database and functionality correctly performs processing which is dependent upon usage of calendar dates including dates before, on and after January 1, 2000.”
To preserve your rights to pursue future financial reimbursement for any packages that vendors refuse to upgrade, a company’s legal department should ascertain each vendor’s contractual responsibility to make their software Year 2000 ready. All new vendor contracts should also be written to include clauses that require a state of Year 2000 readiness with both parties agreeing to a precise definition of compliance.
According to Joel Golub of New Jersey Transit, however, that’s often easier said than done. “We recently pushed very hard on one contract where we were replacing our entire rail scheduling system. And we’ve basically hit a stone wall. The vendor will not budge.”
TESTING VENDOR PROMISES
Contracts aside, many of the larger software companies have heeded the criticism and initiated Year 2000 communications programs to update the business community on their current state of compliance. In particular, Microsoft, Compaq, Novell, Bay Networks and others have created Year 2000 Web Pages that enable you to review the status of products and, in many cases, the company’s repair methods and philosophy.
But what about the smaller vendors? It’s important to note that just because a vendor says they will be compliant by a certain date does not necessarily mean this will occur. More important than words is how you match the vendor’s response with your direct experience. Have they missed release dates in the past? Have their releases been plagued by bugs?
“Ultimately, most vendors will respond that they will be complaint,” says DTC’s Reisberg. “The question is whether you’re ready to bet the enterprise on a promise. Even if they say they are compliant, you still need to test their products. And therein lies the magnitude of the problem. How do you test all of that software?”
TESTING VENDOR PACKAGES
Testing becomes especially critical in a technical environment dominated by third-party packages. Because each vendor will have a different upgrade date, complaint software that is placed back into production must interface with software that has not yet been upgraded.
To prevent complaint software from being compromised, a company will need to create temporary bridges that convert upgraded files to the processing formats needed by applications that have not yet been made complaint.
Most companies that are at the initial stages of their project fail to realize that third-party software is perhaps more vulnerable and less in their control that home-grown applications. Brining this threat under control demands a tremendous amount of work – work for which most organizations are not prepared. “The amount of people we need to do the mailings is substantial,” says Harvey Reisberg. “The record keeping is substantial. But we need due diligence. Because we want to have an audit trail if someone comes back and points a finger. With so much software and so little time, we’re under constant pressure. But with so much risk and so much liability attached to these vendor packages, we need to prove that we did the right thing.”
Mark Kasperowicz is western region manager with Computer Generated Solutions, Inc., a consulting and integration firm specializing workgroup computing, network integration, and document management systems. He can be reached at 213/625-2655.
