Technologies do have a shelf life, and do eventually die. Vendors merge, are acquired, markets and environments change.
Sixty percent of the world's businesses still run legacy environments, according to Gartner, and IDC says there are still around 200 billion lines of operational legacy code, and the figure is growing by 5 billion lines every year as companies try to integrate their legacy environments.
Mainframe legacy environments represent a major headache:
* They have costly maintenance and licence fees;
* Experienced programmers and operators are few and far between as many have retired;
* The number of people who understand the organisation's knowledge - locked in legacy systems - has dwindled;
* The systems are undocumented; and
* The financial cost to switch to a newer system is high, there is a need to extract and redo the requirements that have taken decades to implement, the process is fraught with possible downtime, potential bugs, and extensive user training that is enormously time-consuming and expensive in large user environments.
It all adds up to unprecedented levels of risk. But most organisations that still rely on trustworthy big iron simply have little choice. Although they need the reliability of proven systems written for serious business applications, they also need the rapid flexibility those same systems deny them. Very often they also need to reduce the cost associated with them.
Legacy data stores, the big data bases attached to mainframes and other old environments, present the same problems. They are antique systems that are unsupported in the modern era and that makes them expensive, and they represent an unhealthy risk to the corporations that own them.
Although trustworthy technology, they make use of programming languages that graduates simply aren't learning or want to learn, and that means the available resource pool to support and maintain them is rapidly dwindling and becoming increasingly more expensive.
They also represent a conversion risk. As they have grown over the decades, they have been in place to become bulky, unwieldy and often-undocumented behemoths.
The Visual Basic risk
But big iron, green screens and ageing data stores are not the only legacy problem that organisations face.
Released closer to the dawn of the new millennium was Microsoft's Visual Basic 6.0 (VB6). VB6 was released in 1998, a mere 10 years ago, and Microsoft has, as of March this year, stopped support for the widely adopted environment. The Redmond software business has confirmed that specific updates will be available only for a three-year period, but at a fee.
The environment experienced massive support in building graphical user interfaces (GUIs) for corporate databases, and is not compatible with more modern technologies such as Visual Basic .NET, released alongside C# and ASP.NET, and which incorporates a host of advances, such as more comprehensive support for object-oriented programming.
Although it shares some nomenclature, VB.NET is essentially a completely new language, killing one language to replace it with a fundamentally different one. VB6 programmers migrating to VB.NET compare it to learning a new language.
One of the major problems when it comes to updating VB6 applications is that they typically started small, but have grown to become enormous systems. The problem with that is they were seldom documented or properly architected at the start, but they provide a lot of business value to organisations today; however, they are high-risk applications now that Microsoft has stopped supporting them.
The solution is not always to rewrite all of these applications if it can at all be avoided. The task represents a good deal of risk in lost or incorrect functionality and data, downtime, unavailability, cost and time.
Today there are companies that have special tools to directly convert legacy applications and systems to modern languages and environments.
The tools can automatically analyse the old systems to ascertain their architecture - particularly useful where no documentation exists - and automatically convert old languages to modern. Other tools can convert the system into Visual Studio, Eclipse or Rational Software Architect to still help many organisations, even if they cannot do a straightforward, one-to-one conversion. They can partially automate the conversion process and allow the architects to remodel the system into a proper object oriented system and generate the re-factored system into the required environment.
Share