For many years now “Legacy Transformation” and “Legacy Modernisation” have been buzzwords throughout the IT industry. Whilst, more recently, cloud computing, mobile, and social media are more to the fore, the Legacy issue has certainly not gone away.
Many companies tackled the problem with mixed results. Some chose replacement, whilst others chose re-engineering. Some even analysed the problem and decided that it was either too expensive or too difficult, or both, to undertake.
The Y2K problem was a perfect opportunity to tackle the Legacy issue, however this was almost completely ignored, with a large number of companies having little or no assets remaining from this huge, costly exercise. Documentation, regression test packs, standardised code and many other assets could have been produced as a result of Y2K, but inevitably they either never existed, or have been allowed to fall into disrepair.
So how do organisations tackle the Legacy issue? First of all it is important to understand just what comprises a Legacy system. Code that is being written today can quickly be regarded as Legacy, if there are no standards and best practices to support the software development lifecycle. Refactoring is an accepted practice with most modern languages, however, this is often seen as time consuming with no measurable business benefit, and so it is ignored. The resulting code can almost certainly be described as legacy.
More traditionally, legacy code can be described as that written in languages that are difficult to support. Although there are a number of organisations still promoting the use of COBOL, it is now in decline. However, the sheer extent of COBOL usage around the world, particular in large organisations, should not be underestimated, and for this reason it will almost certainly be around for the foreseeable future. Assembler is almost dead as an application development language, however the support of Assembler based applications is still a necessity, and as assembler resource becomes ever more scarce, this particular skillset could well see a short term spike in demand.
As well as code, databases can cause huge Legacy problems, and could continue to do so. Any database not from a major recognised vendor will inevitably become legacy, mainly due to the lack of technical support provided by the vendor as well as the absence of skills in the marketplace.
The same applies to infrastructure, though in theory this should be simpler to modernise. There may be compatibility issues, but essentially a modernised application should be platform independent, although the original legacy application will almost certainly not be.
In summary, the Legacy issue faced by many organisations can be narrowed down to code and database, however the modernisation approach will almost certainly be determined by other, very different, factors that I will expand upon in a later article.
