This snapshot, taken on
04/09/2014
, shows web content acquired for preservation by The National Archives. External links, forms and search may not work in archived websites and contact details are likely to be out of date.
 
 
The UK Government Web Archive does not use cookies but some may be left in your browser from archived websites.

Question

How should the Government best deal with the issue of change relating to legacy systems or incompatible updates to existing open standards?

Go to question form

Responses

2052.

Malcolm Nebwury February 13, 2012, 3:30 pm

the convergence of products to comply with the latest version of a mandated standard is really a matter for the users and vendors to be managed through the standards testing organisations. IHE uses the connectathon to provide vendors with a regular opportunity to update their software to the latest version of the profiles. Government's best strategy is to delegate this issue to users and vendors.

2092.

Linda Kateley February 14, 2012, 8:00 pm

I think it is best viewed as a critical change which needs to take place. If there are systems in place that won't be accessable without the endurance of the vendor, well that can't be seen as acceptable. If the last few decades of technology have showed us, anyone can be at risk, and you can't depend on any single vendor.

20103.

Melvin REYNOLDS February 15, 2012, 9:28 am

Set aggressive, but realistic, time-scales for compliance of systems to standards at the procurement stage for all enhancements and new systems. Then profile payment on the basis of achievement.

20130.

Prashant Trivedi February 15, 2012, 11:41 am

The change of systems in NHS is very complex. Where ever possible we should continue to use the newer version of the standards with in NHS systems. All changes should be incremental rather than big bang change. We have to take into account any system change is not a software change but cultural change as well.

20168.

David Durant February 25, 2012, 6:44 pm

Legacy systems are best left in-place and an interface layer or 'shim' provided to allow connectivity via the open standard.

20189.

Glyn Moody February 28, 2012, 3:09 pm

First of all, it is important to bear in mind that all such legacy systems have significant exit costs. These must be paid at some time, and so the issue then becomes when and how. If there are equivalent solutions based around open standards, then moving sooner rather than later makes sense, for all the reasons noted above. If there are no truly open standards yet, there is less compelling reason to move off legacy systems.

20223.

Kai Hendry March 9, 2012, 3:45 am

Again, assuming we are using the Web, the Web has a good track record of "degrading gracefully". Nonetheless, there is churn and the trick is to spend time and money to re-factor and maintain old documents and applications. This is always very difficult to justify, but it's a key element.

20288.

David Alexander March 13, 2012, 10:06 pm

For legacy systems the question is all about providing API’s (application program interfaces) based on open standards supported by detailed meta data about the services and data contained within the legacy application. Exposing such API’s and meta data will enable legacy systems to participate in an open standards environment more quickly than replacement. The challenge will be the analysis required to identify the 20% of functionality and data that delivers 80% of the benefits by being exposed as an Open Standard API. Incompatible updates to open standards is all about ensuring suppliers are including maintenance of open standards compliance as part of their roadmap and not a one off commitment to a specific revision level. All changes to systems need to be planned and implemented in a structured way. Backwards compatibility is an inherent thing in software design and so it should be with standards. Managing this complexity is an essential part of open interoperable systems.

20300.

Dominic Tristram March 14, 2012, 4:13 pm

Legacy systems should not be replaced as a matter of course, assuming they are still fit for purpose. The adaptation of these systems to use open standards should be done as and when a change is required for some other reason (such as new required functionality, or legislation). All new systems should be written around the open standards, and where integration with legacy systems is required, an interface layer should be built around the legacy system so that it appears to support the standard. This would be a much cheaper and more efficient way of allowing the continued use of the legacy system until it reaches end of life. Any updates to the open standards should be in control of the government (assuming that the accepted standard is defined by the government, as discussed in our answer to section 1). Updates to the standard should only occur when there is a business case to do so since these updates would be functionally, rather than commercially, driven. Should such an update be unavoidable then scale makes change cost-efficient – since all government systems would use the same open standard it would be straightforward to release a converter to convert between them. However, we would expect that a well-defined standard would not have incompatible updates for several years. There is little point using a ‘standard’ which only lasts for a short time.

20355.

Iyke March 24, 2012, 5:05 am

The first thing is to audit the IT infrastructure in place now and pinpoint areas that have legacy systems or incompatible updates in place. Then educate the owners of data objects and data sets on the need for change Then using agile development methods based on iterative and incremental development, bring about the mandated Open Standard.