Mission Critical Legacy Systems

From Blindside

1 What is it
2 Impact & Maturity assessment
3 Information Assurance issues
4 Timescale
5 Examples
6 Comments (attributed)
7 Organisations
8 Documents & research papers
9 Experts (academic, practitioner)

[edit] What is it

A legacy software system may be defined informally as an old system that remains in operation within an organization. Legacy systems typically have been developed several years ago sometimes without anticipating that they would be still running much later.Inevitably the software requirements for legacy systemsmight change and legacy systems must be evolvedaccordingly. Maintaining legacy systems, however, is in general hard because legacy systems very often run on obsolete, slow hardware that is hard to maintain, thedocumentation of the legacy system is lacking orincomplete, the interfaces of the legacy system components are limited for integration and/or adaptation,etc. (Towards an Aspectual Analysis of Legacy Systems, Bedir Tekinerdo, Yasemin Satıro, Department of Computer Science, University of Twente, The Netherlands)

The problems posed by mission-critical legacy systems - brittleness, inflexibility, isolation, non-extensibility, lack of openness etc. - are well known, but practical solutions have been slow to emerge. Most approaches are "ad hoc" and tailored to peculiarities of individual systems. (Legacy Systems Migration A Method and its Tool-kit Framework, Bing Wu, Deirdre Lawless, et al.)

To take it to the next level, when large percentages of communications traffic has migrated to xOIP, will it be in the interests of current providers to continue satellite broadcasts of television, terrestrial broadcasts of both radio and TV, for telecommunications providers to maintain twisted wire connections to houses? If small scale power generation becomes the norm, will large scale power networks become disused and unusable?

At that point, are we over-reliant on the Internet?

[edit] Impact & Maturity assessment

[See definition of levels]

We assign this an Impact Level of 3, our highest level. Any organisation that does not have a 'sunset' policy that includes the monitoring of support systems for critical IT infrastructure is at risk of having an 'orphan system' on its hands due to bankruptcy or mission change of a vendor. The information assurance implications are grave. Data can be lost, corrupted or simply inaccessible. Critical operations may become impossible. It is easy to visualize a scenario where a public sector organisation decides to use Sun's Star Open Office system to save money and show independence from Microsoft. Sun was in fairly serious trouble in recent years, and had it gone bankrupt, there would have been considerable impact on performance in this hypothetical situation. It is highly unlikely that a Microsoft will cease operations and support. It is not difficult to imagine the failure of second-tier providers, such as anti-virus vendors, media players, etc. However, until this happens with a large size vendor, we will assign this a Maturity Level of 1. The adoption of Service-oriented architecture, discussed elsewhere on this wiki, is designed to mitigate the effects and prolong the usability of legacy systems. However it comes with its own set of issues and has not yet been adopted as a widescale information architecture.

The question when procuring enterprise systems is, does the vendor have a sunset solution in place? Do SLAs include an end-of-lifecycle plan?