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
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.
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.
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.
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.
Legacy systems are best left in-place and an interface layer or 'shim' provided to allow connectivity via the open standard.
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.
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.
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.
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.
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.