Legacy Systems

What is a legacy system anyway? Wikipedia offers "a legacy system is an old method, technology, computer system, or application program, 'of, relating to, or being a previous or outdated computer system.' [Merriam Webster]", and notes it is often a perjorative term. For most enterprise IT vendors, a legacy system is one that is older than the one they would quite like you to buy. When UNIX servers were 'the thing', mainframe and AS/400 systems were legacy; when lower cost PC networks became available, UNIX servers & workstations were pictured as legacy; when Internet systems first became available and "three tier' architectures were in vogue, those same PC networks became the latest 'legacy'. For a while, on-premises systems were legacy and the cloud was where things are - until people started to look at what happens when connectivity fails, other considerations such as latency and contention: at the time of writing, hybrid systems look very attractive, but who knows what next year will bring?

However, there is another definition of legacy system - one that is far closer to home at times: a system that today's engineers have inherited, with little or no documentation, using components or subsystems that are no longer available, and at times with system suppliers that no longer exist. If that system is doing the job required, then it is probably still in use on the grounds that "if it ain't broke, don't fix it". When this is an embedded system on a train, this should be a cause for concern: when it's the train management and control system, it should be enough to trigger a reverse engineering initiative. While the existing system may work - and possibly work very well - limited supplier pools and inability to replace components on demand both constitute risks; integrating such systems into a larger data collection and processing environment could verge on the impossible, and in extreme cases diagnostic tools aren't even available. Even when software tools are available for diagnostics, they frequently require out-of-support operating systems that cause issues for a corporate IT team. If none of those concerns is enough to justify at least a small-scale "is this even possible" exercise, there is yet another: such a project can provide stepping stones for piece by piece replacement of the older (genuinely legacy!) system, and potentially a life extension for the rolling stock.

To take a hypothetical example: onboard control and management systems for rolling stock that is running towards "end of life", yet is mechanically sound and in an organisation facing financial pressures that make life extension a very real possibility. In an ideal world, one would consult all of the design documentation provided, examine the protocols in use, and build a simulation or an emulation to study and test how the on-train systems work, before considering approaches for replacing the "legacy" environment. These approaches could include wholesale replacement (all at once), subsystem-level replacement, or component-by-component swap out: without undertaking a full study of how the existing systems work, the only realistic approach is to replace the entire existing environment. While in many ways this is an efficient way to do things (ease of development, timescales, and so on), in others it is the highest risk approach - if the new system doesn't work, or leads to unexpected changes, or delays, or cost over-runs, then that could be apparent to regulators and government. In that case, questions will probably arise as to why alternative approaches were not considered, or if they are available (which, in most cases, they probably are).

The piecemeal approach may sound less attractive in many ways (especially to managers without recent engineering experience, or to politicians seeking "big bang" results) but if done properly it can provide a lower risk approach, at the cost of taking longer. It does, however, allow flexibility in planning and prioritisation: those subsystems that are the most complex can be studied separately; any potential "quick wins" can be taken; any parts that actually work well can be left alone.

When the documentation for the existing system is incomplete, or unclear, or has not been kept up to date, problems will arise with either overall approach: when the documentation is simply missing (either in part or, somehow, in it's entirety), then the exercise becomes closer to reverse engineering. This can, on the surface, strengthen the case for wholesale replacement - but of course, no such replacement can be done overnight, and the complexities of running a split fleet (part old, part new) have costs all of their own. If the alternative approach of studying the existing systems and replacing them part-by-part can be followed, those complexities can be reduced: where some (or all) of those parts contain older devices with lower capabilities, new functionality can be introduced gradually - or can be introduced but left quiescent, then made available once hardware replacement has been done fleet-wide, so passengers do not see any variation until the operator is ready to "switch on" the upgraded systems. As this gives the appearance of a "big bang" upgrade with no disruption in passenger service, perhaps that could be a "win win"?