For decades, most large-scale companies have used mainframes to host and run the software applications that make up their legacy systems. Most enterprise-level systems in operation today reside within mainframe machines, while COBOL applications (the primary language used with mainframes) continue to handle the vast majority of modern enterprise-level computer transactions. In some verticals, 50 to 60 per cent of core processes still run on mainframe systems.
But these systems might be sorely in need of some modernisation – whether that’s so an organisation can stay competitive, or so it can respond quickly to market threats and opportunities, or both.
Some organisations retain the platform because they are challenged from a cost and integration point of view. Others may have legacy systems and applications inherited from mergers and acquisitions, or from deferred IT investments.
Often, it’s easy for IT to see that the legacy infrastructure isn’t working and a change is needed – but it can be tough to get the C-suite on board with something new, because they might not understand exactly what the risks are or what options they have.
They might have their own ideas about whether or not to modernise mainframes or how to go about it – and if you’re aiming to get them to see things your way, you should be prepared to address each of their possible rebuffs.
“Let’s keep things the way they are”
Inaction is usually the easiest choice in any given situation, and legacy system modernisation is no different. Your C-suite might take the approach of “why fix what isn’t broken?” – and that might well be the right choice, if systems do not require any new functionality at the moment.
However, it’s important to remind executives that one risk of not modernising an older system is that it becomes more of a liability over time, especially as competitors modernise theirs to take advantage of newer technologies.
Additionally, if there is important data locked in the mainframe that isn’t easily available, any of the flashy new big data analytics tools the company implements might provide incorrect or misleading results – rendering the investment on that tool somewhat useless.
Another risk is that many users today require mobile support. Older systems are typically not that friendly to new user interfaces or the need for more flexible formatting.
Lastly, tell the C-suite to look at other industry players. Most enterprises are moving to cloud-based architectures. Less expensive x86 and virtualisation technologies have dramatically affected the design and cost of enterprise data centres. Why isolate the applications and data on your mainframe? Why continue to pay for expensive and unnecessary proprietary hardware instead of using commodity x86 systems? And why support file-oriented, non-industry-standard data stores when SQL alternatives exist?
To convince executives that maintaining the status quo should be a no-go, be ready to address these critical points:
· The capital tied up in maintaining older mainframes instead of being used on innovation and differentiation
· Many mainframe applications were written decades ago, so it’s good to ask or know whether any of the software was authored by a company that is no longer in business
· The TCO of maintaining the existing mainframe, taking into account purchase, installation, cooling, power and support
· Whether the current infrastructure is able to meet new, dynamic platform needs like mobile
· Whether the data on the mainframe is available to new, modern data analytics applications
· How much documentation exists on the systems themselves
· The number of IT staff who have the legacy knowledge to support the current infrastructure in case of a failure
“What if we just upsize or upgrade our current mainframe?”
For legacy systems that only need more capacity, one possible approach is to simply add more system hardware, or switch to a higher-capacity mainframe machine.
This has its pros as well as its cons: It will increase capacity and boost system performance, but also increase maintenance and licensing costs.
Ultimately, it won’t get the company any closer to addressing the core shortfalls of mainframe systems: the platform’s inflexibility, rising maintenance costs, diminishing skilled labour, etc.
The biggest risk of simply increasing capacity is that legacy systems is that it just kicks the can down the road; this prevents the company from reaping the benefits and lower costs of new available technologies, inhibiting innovation.
It also keeps the mainframe applications stuck with an “outsider” status, not in line with modern, private cloud-based architectures.
In addition to the points addressed in the prior section, be prepared to talk about or quantify:
· What kinds of patches, modifications and updates the legacy system might need to maintain the higher-capacity update
· The affects these patches might have on the system (growing complexity; lack of visibility)
· The additional costs the company will incur because of patching and continued maintenance on the legacy system
“Can you just rewrite source code instead?”
The short answer is, of course, yes. This is the most aggressive legacy modernisation option – a full-scale rewrite of the application source code while re-architecting for database and application tiers – and it’s certainly accomplishable.
But the longer answer is that a major rewrite brings some major risks. Developed business logic needs to be completely redeveloped, increasing the chances of getting it wrong and requiring extensive user testing.
Further, some sort of translation table may be developed to bring the data stores to a SQL environment and to isolate the data functionally to its own tier.
Be prepared to discuss:
· What you feel is the true cost inhibitor in the mainframe system – is it just the source code language or is it just the underlying architecture? What provides the greatest and quickest ROI?
· The risks of changing the business logic
· The other applications and data stores that could be affected by a rewrite
· The amount of time the project will take, including functional testing, user testing and parallel operation
· The resources (including demand on the staff) required to handle such a major re-write project
These three scenarios offer a way to rebuff less-than-ideal suggestions about mainframe modernisation. But what should you offer instead?
For IT professionals who are ready to upgrade their company’s architecture but want to carefully manage the risks, time and cost of a complete rewrite, there is another option: rehosting.
The advantages of rehosting
Rehosting is an option whereby existing mainframe applications move unchanged to a modern open environment, such as multi-tiered, SQL-based x86 environment, or the cloud. Applications may be written in COBOL, PL1, or other languages, and mainframes may be from IBM, Fujitsu and other vendors.
For many businesses, rehosting can be a thoroughly cost-effective way to overhaul mainframe architectures. When performed properly, rehosting provides many of the benefits of a rewrite, with significantly fewer risks and costs.
It can also act as a beneficial first step to a less complicated – and therefore less risky – source code rewrite. Where mainframes lock a customer into a limited and tightly coupled architecture, the loosely coupled architecture of an open system offers dynamic scalability, workload management and agility.
Safety is also improved, since existing mainframe security is maintained, and additional safeguards provided by modern SQL databases can now be employed quickly and easily.
Moving forward gracefully
The right rehosting solution can reduce risk through the use of an industry standard OS, standard x86 systems, standard SQL databases and standard cloud infrastructure. Simultaneously, it can provide improved integration and security, and lowered costs.
But to ensure executives are on board with the rehosting plan, it’s not enough to simply talk about its benefits – IT must be able to articulate why other options are not viable. Be prepared to talk to the C-suite in terms that matter to them – including competitiveness, budget and business risk – and you’ll have a better rate of success in getting them to see it your way.
John Yun, Global Chief Technology Officer, TmaxSoft
Image source: Shutterstock/everything possible