X
Finance

Ensure business continuity: Protect investments in mission-critical software

A major issue that CIOs wrestle with is the possibility that key processes could experience significant downtime should their software fail in some way. CIOs usually know where the deficiencies are, but they often have a difficult time deciding where to spend the money to tighten up those loose ends.
Written by Frank A. Bruno, Contributor

A major issue that CIOs wrestle with is the possibility that key processes could experience significant downtime should their software fail in some way. CIOs usually know where the deficiencies are, but they often have a difficult time deciding where to spend the money to tighten up those loose ends. After all, insuring investments in mission-critical software through the use of source code escrow could be hit or miss.

That's why it's important for CIOs to know how to set up such an escrow effectively. During the licensing negotiations process, most organizations simply ask, “Got escrow?” and move on without scrutinizing the terms and conditions of an escrow agreement or specifying exactly what they will need to continue to support the application in the event their vendor ceases to exist. The importance of doing it right depends on the ability to easily access source code and then use it successfully. Simply getting a “yes” response from a vendor and then letting them handle the details without close supervision is a common mistake that a lot of user organizations make. Let's review some strategies that will ensure the continuity of your key business processes through the use of escrow and verification.

Initial steps
First, it's imperative that you assess the risk of mission critical applications that support key business processes before you sign a licensing agreement. If we're talking about an “off the shelf” or “shrink wrapped” software application residing on ten desktops, you can safely assume that you don’t need escrow. On the other hand, if a financially unstable developer—whose unique application impacts millions in revenue, productivity, public safety, etc.—created the software, you would certainly consider escrow and perhaps, some sort of verification testing.

Next, you need to control the negotiations process by insisting on a few things. Get the escrow agreement executed at the same time as the licensing agreement. Most licensing agreements include escrow as a provision. Don’t allow this to be placed on the backburner, because it will run the risk of becoming a distant (and abandoned) afterthought.

Also, make sure you have read and understood all provisions written into the escrow agreement. Obviously, you need to ensure that the language enables you to access the deposit materials when you need them. Scrutinize release conditions and the release process to make sure that there are no loopholes preventing the escrow agent from completing his task.

These days, many best practice user organizations are setting up their own escrow agreements in advance and adding vendors (depositors) via a one-page addendum. By doing this, they have standardized the language that represents their needs, and they can avoid the costly contract review each time they acquire new technology.

Now the hard part
Ok, that was the easy part. Now let's focus on the single most overlooked aspect of an escrow agreement—the deposit materials. This is critical to rebuilding applications in a time frame acceptable to your business. A common misconception relative to the deposit materials is the assumption that everything is there and it works. I've found that, although the vendor will (in good faith) download all of the key components it feels will be necessary to recompile an executable, more than a quarter of all verifications performed have uncovered major deficiencies. As such, users should always verify initial deposits and subsequent (major) version releases for things such as compilers, build instructions, and contact information for key programmers.

It's critical that the process of creating a useable deposit be supervised and verified on an independent machine before continuing with the implementation process. Many times this process is ignored, resulting in quite a bit of frustration and significant time overruns relative to recreating the application development environment. The best course of action, if your vendor will allow it, is to have a technically qualified representative present to witness the download of the deposit materials and re-creation of the executable prior to the deposit going into an overnight package to the escrow agent. Verification testing is a common service provided by most good escrow agents.

Following these instructions will help ensure that your mission-critical applications are backed up by an effective escrow arrangement. In addition, your CFO will be happy to hear that even though the technology vendor may no longer be around to support your application, you can still meet your ROI projections because you have the ability to make modifications and enhancements necessary to support the business.

TechRepublic originally published this article on 29 October 2003.

Editorial standards