Far too many times we have had projects come across our desks in what can only be described as in a derelict state. Often we see situations where vendors of custom software solutions are no longer able to support the application they've built, and their clients, who are now our clients, are often left with precious little original code and documentation to be able to maintain their solution.
For many organizations, custom software represents a huge capital cost and, yet, from our observations, it is often an area suffering from an extreme case of deferred maintenance.
Your software system is likely to be made up of a number of different components. Some of these may be custom developed for you. Some may be third party libraries. Other components might include off-the-shelf applications and operating systems from vendors both large and small.
It is very important that you have a good understanding of the specific landscape of your system. What are all the components that make up your application? Where have they come from? Do you own the source code? Does your custom software developer own the licence to the source code? Who owns the licence to any other third party tools?
Here are some ideas for ensuring that you're not left holding a can of dated spaghetti code.
Look for a licence with source code wherever possible. Ideally, when you have software developed for your specific needs, it should come with a copy of the source code as well as the binary. In some situations, this may need to be handled with an escrow agreement. Don't forget that you need to keep your copy of the source code up-to-date. If the application is being maintained by a third party, then you should ensure that you receive regular updates of the source code. One approach that we like is to actually take a back-up copy of the version control system that is storing the code. If your vendor is not using a source control system, we recommend you find another vendor immediately.
Escrow source code for off-the-shelf products from small vendors. If you are using commercial off-the-shelf software (COTS) from a small vendor, you should ensure that they have placed the source code to their application with a reputable and reliable escrow provider. One provider that we have used in the past is Standby Computing, of Dunedin. Once again, ensuring that the escrowed source is kept up to date is very important.
Ensure that you hold a licence to and a copy of any third-party controls or libraries
If your vendor has chosen to use third-party libraries or controls, then it will obviously have licences of its own. In addition to this, you should mandate that, along with the source code, the vendor provides a licence and copy of each control or library used.
Maintain a virtual machine capable of building your application. This might be a new one for even the best and most cautious of readers. Much of the development that we do at Intergen is done in virtual machines. The luxury of a virtual machine is that it can easily be copied onto a portable hard drive and stored securely for access later on. By taking this approach, you ensure that you have always got the ability to simply re-compile your application reliably and deploy it. This is a godsend for those 'minor' changes that might come up four years after the system has been forgotten about. Without this VM you will often end up paying a vendor much more to set up a development and build environment than you actually pay them to make the change.
Clarify with your vendor who owns the IP. Different vendors will have different policies on this. It's the eternal balancing game for services companies to ensure that they meet the clients' needs while still protecting their own innovation. At a minimum you must insist on a non-exclusive, non-transferable licence to both the source code and binary code for anything that is custom developed for you. Ensure that your licence explicitly allows for the source code to be provided to another vendor so they can maintain your solution.
Documentation. Provided all of the above have been followed, then a lack of documentation will not be fatal. If we have the source code and any referenced libraries we can maintain any solution... for a price. Documentation will significantly reduce the costs of ongoing maintenance.
It is, of course, a balancing act a little like buying an insurance policy. Do I want to spend the money documenting now (pay some premiums) so that I can have a lower cost maintenance option later (receive payout on a claim). The following documentation is particularly useful: architecture diagrams (What are the various components and how do they bolt together?); deployment diagrams (Where are the various pieces of the application running?); and source code comments.
Please encourage your vendors, staff and anyone else with write permission to your source tree to adequately document their code. The concept of "self documenting code" just doesn't cut it.
Maintain, maintain, maintain. Even where clients have been diligent at the outset to follow most, or even all, of our rules, they often let themselves down in the time dimension. Specifically they do not keep all of the above up-to-date. We end up coming in four years later and, sure, they've got everything we listed above for version 1.0 of the application ... problem is, the business is running version 3.5.
As part of any managed services arrangement with your vendor, you should insist on regular updates of all of the above content. Where a version is released to production, the source assets should ideally be updated to either yourself or your escrow provider.
Auld and Johnson are from New Zealand design, development and integration firm Intergen, www.intergen.co.nz