Many large organisations invest heavily in custom software applications to deal with some of their core activities. Examples of this are hotel reservation systems, ticket booking systems for airlines, many banking based transactions and even the space shuttle control systems at NASA. These software based systems are normally developed to meet specific client needs, and in some cases may need to undergo stringent certification and security verification processes. Many such systems deal with the processing of huge amounts of data, possibly in several different locations in a predictable manner, according to client specified parameters and criteria.
In many cases these systems form the very core of the organisation’s operations and become such an integral and essential element that they fall under the umbrella of corporate intellectual property management policies and risk mitigation to ensure that these systems can be maintained and supported for many years, if not decades in some cases.
The initial investment in such systems due to their highly specialised nature, especially if used on a national or international basis, is usually very substantial. As technology advances rapidly, and faster and easier to use systems become available, many of these older systems continue to be run and operated even with less than perfect architecture and known problems, simply because in some cases the cost of replacing them or the inconvenience of downtime for the organisation far outweighs the benefits that any new system would provide.
Return on investment or simply the challenges of change management may well lead to such systems continuing to be used long past their popular commercial lifespan. Even when such systems are recognised as being based on old, outdated technology or application architecture, they may still continue to run, sometimes in parallel with newer systems, or in the background, because they still contain important, historic or even critical information. This can lead to various challenges for system maintenance and support, especially in cases where the original software developer or vendor is no longer able or willing to provide such services.
One obvious solution is that the client takes over the responsibility for maintenance and support of the system in question. Another emerging solution is to modernise and update these legacy programs to bring them in line with 21st century technology and allow the organisation to evolve without the need to go back to square one and redesign core system applications from scratch. Legacy modernisation can allow a business to balance the investment already made in their systems and applications with the technology opportunities offered now. The retention and expansion of such programs can prove more beneficial than starting over again. It can also allow the extraction of important business rules embedded in the legacy source code, enhance these to optimise system efficiency and build in modernised solutions, insulated from future technological changes.
In either case the end user, or the client, will need access to the original source code for the application in question. This is the code from which the executable files are derived and subsequently installed on operating devices, computers or data terminals. The original application source code is often placed in software escrow by the developer for intellectual property management of their software asset and as insurance for the client against possible adverse conditions which may affect the vendor from complying with their contractual obligations.
Software escrow provides control and custody of such software assets by a third party, usually a data management specialist company, capable of verifying that the source code meets with the specifications and provides the core functions paid for by the client.
While software escrow agreements may originally have principally dealt with intellectual property management for software developers, and giving assurance to clients purchasing it, it may be the case now that these custodial agreements will have to accommodate the possible release of source code in the event of a client pursuing a legacy modernisation solution also.
Nathan Morgan has been a IT professional for 14 years.