Many were predicted to die on January 1, 2000 – but mainframe legacy applications are still around. In some ways, they are the zombies of the IT world. Now they are running on the cloud as well. What are they and why are they still alive?
Mainframe application development was in its heyday during the 1960s, 1970s and into the 1980s. During this time, hundreds of programmers labored in the salt mines of large IT shops, coding custom programs for corporations. These were one-off systems, each designed specifically for the unique needs of the enterprise. The user interface might employ unconventional hotkeys to iterate through screens or have custom code for specialized business logic or priority clients.
Every night, hundreds of batch jobs cranked through thousands of programs. These applications did their job well, processing millions of transactions flawlessly over the decades. In some ways, corporations are the victims of this success. Systems worked so well (even after the year 2000) that there was simply no compelling reason to retire them.
Why They Need to be Killed
Fast forward to today and we can find plenty of reasons why legacy applications need to go. The programmers who coded and supported them have moved on – either to new technologies or Florida retirement communities. Making a simple coding change can be daunting, even when written in an accessible language like COBOL, if it is to a program with extensive patches or one that uses arcane inputs or business logic.
The platforms these programs were written in or run on are no longer supported. If there is a problem, there is no vendor support to help solve it. The systems are no longer saving money. In fact, there is a significant investment in systems programming and hardware resources just to support them. And users who are now proficient with cell phones and the internet have come to expect more than a green screen application. They want an intuitive user interface and they also want the option to work from home or on the road, to access their information via mobile devices, to query their data on the fly and see it visualized in new ways.
In the meantime, the cloud has dramatically reduced the cost and time to deployment of IT infrastructures. Enterprises, especially in conservative fields like banking, may not want to jump onto the cloud right away, but when it becomes time to replace old infrastructure, it is getting harder to justify staying out of the cloud.
Finally, independent software vendors continue to create innovative cloud-based software that can add value to the enterprise – if the enterprise could only get to the cloud to use it. Fortunately, there are several options for moving legacy apps to the cloud.
Application virtualization software can allow the system to run in a virtual operating system on a modern server.
Pros: this is the fastest method. Running the legacy within a cloud-based OS is a great way to move off of a legacy mainframe. Cons: you have your application running in the cloud, but you can’t update any of the code. If there is a problem, you are not going to get help from a service provider, who will not cover these kind of applications in a service level agreement. In fact, you don’t realize any benefits from being in the cloud (such as multitenancy) except getting the application out of your data center.
A complete rebuild of the application on a modern software platform is a time-consuming solution, but one that is a good match if the business model has changed significantly, or if there is a strong need for the strengths that come from the cloud, like agile development or scalability. Pros: this is the best way to deliver an application that fits business needs. End users have a good understanding of what they need, and will likely be happy with a finished product. Cons: like you are ever going to get to finish this project. It will take forever. At the end of it, unless you add some great new features (did we mention Izenda’s killer ad-hoc reports and visualizations?) you are basically reinventing the wheel.
Incremental application replacement involves updating one tier or set of processes, project by project. Pros: This is a less risky approach. IT can choose the most appropriate application to move; then use that experience to incrementally move other applications. Cons: this can be a time-consuming solution. It requires not only identifying the best candidates for the move (see below) but also understanding and rewriting the code. Applications that move may still need to communicate with other systems using middleware or APIs.
Replacement with a SaaS solution is yet another option. If the application is outside the business core competency, it may be possible to purchase an existing solution from a software vendor. Pros: this is more cost-effective than rebuilding in the cloud. The software vendor can do the heavy lifting for the migration process. Cons: a SaaS application is often a one-size-fits-all solution. End users, who may have spent years using a home grown application, can have a hard time adjusting to the new processes, look and feel, even the terminology of another application, making adoption difficult.
The best candidates for a move are low risk applications: ones that don’t have complex requirements for compliance or lots of data requiring high levels of security. Consider moving applications that have high processing volumes, especially where volumes fluctuate frequently. These leverage the cost efficiencies of the cloud. Similarly, consider standalone, front-facing applications that directly benefit in-house users. The ability to provide access in the cloud from any device is an immediate benefit for the enterprise and can help with buy in for other migrations. For testing, run the cloud version simultaneously with the legacy application. Finally, virtualize your application’s reporting. At Izenda, we provide ad-hoc reporting and dashboards that can be integrated within applications to give end users new ways to see their data.
According to Gartner, by 2017 large enterprises will be investing the bulk of their IT resources in the cloud. So the issue is no longer whether, but when. Fortunately, the cloud offers not only growth, but real savings to business – although for now, much of that savings may end up paying for developers to hunt down and replace the living dead of applications.