Feature

The next step for your mainframe

Despite what pundits might have led us to believe over the past 20 years, the mainframe is not going to disappear any time soon. What is going to change, however, is the mainframe product environment. Organisations need to have plans in place for either migrating or maintaining their current set-ups in the changing environment.

In 1991 experts predicted that mainframes would be obsolete by 1996. Yet in 2007, mainframe-based programs still process about 75% of the world's transactions, and IBM announced that more than 10 million mainframes were now in operation.

"Although firms are vocal in their dissatisfaction of the costs of maintaining them, legacy mainframes continue to run core business functions for medium, large, and Global 2000 companies," said Phil Murphy, principal analyst at Forrester Research.

However, in a 2006 survey conducted by Forrester, 49% of companies said it was a priority or critical priority to replace or upgrade mainframe applications. Murphy said there is demand among larger companies to modernise their legacy mainframe programs, so that they can run under potentially cheaper Linux operating environments.

The other benefit to modernising mainframes is that it enables the use of Java over Cobol. Java has a wider, more available skills base than Cobol, which is the traditional language used to code mainframe programs and faces a growing skills shortage.

Total cost of ownership is key in determining whether a modernisation plan should be undertaken. Fewer proprietary platforms and cheaper alternatives make moving off the mainframe compelling.

Supporting this need, a new segment of suppliers is providing runtime environments designed to emulate the mainframe online as well as in batch environments, either on Microsoft Windows or Unix/Linux platforms.

Among the mainframe emulation products are Neocics and Neobatch from Fujitsu, as well as the Enterprise Server with Mainframe Transaction Option from Micro Focus and Unikix from Critical Path.

However, even though the move to a new technology platform can reduce expenses and provide greater flexibility for larger mainframe users, some organisations are reluctant to change. For them, the process of modifying their systems can be expensive, as it involves rewriting the software used to manage core business processes.

Organisations have already wasted millions of pounds on purported one-size-fits-all solutions to their legacy application issues: dump the mainframe rip and replace move it all to Unix and, most recently, outsource it all.

"The main decision facing mainframe users today is between migrating to a new platform or staying with the system they have," said Dale Vecchio, research vice-president at analyst firm Gartner.

Vecchio said mainframe users with processing requirements in the 500-2,000mips (millions of instructions per second) range may want to move to what they see as a cheaper, more agile application environment. "But they have shown tremendous reluctance to risk the quality of service, performance, reliability and availability they have come to expect from their legacy environments," Vecchio said.

And yet the prevailing questions concerning moving from the mainframe remain about Cobol versus Java or Cisco versus IBM Websphere, rather than more fundamental issues.

"If a company decides to stick with its current system, then they have to make an investment in ensuring they will still have the required skill sets (eg Cobol) in place within the next 10 years," said Vecchio.

"They must also realise that IBM's modernisation strategy for mainframes lies essentially in Java, and must be able to put a cost on maintaining legacy systems."

Vecchio added that organisations leaving the mainframe behind in favour of alternative platforms should consider that they could be moving to a potentially lower quality of service, with a more complex infrastructure and a more lax design discipline to software applications, and that there would be no one supplier driving towards a consistent architecture.

"The quality of service of the mainframe represents the epitome of reliability, availability and serviceability. Platform migrations require significant effort to come close to this quality on different hardware platforms."

Vecchio said that one of the greatest risks for these systems is not with the applications themselves, but rather with the growing shortage of IT professionals with the skills to continue to develop, maintain and operate the applications.

Modernisation is not just an application issue. Modernisation also has implications on the underlying IT infrastructure that serves as the platform for delivering the applications.

Replicating the quality of service of established systems on new and dissimilar platforms requires strong focus and attention.

"Migration is saving IT organisations money, time and the effort of trying to locate and hire competently skilled resources in waning legacy technology. But do not throw the baby out with the bath water," said Murphy.

Firms, including large insurance companies, have tried and failed to migrate finely-tuned, high-performing applications. Clearly, these applications can only continue to deliver value under new environments if they maintain the quality of service provided by the mainframe.

"Do the homework and determine the true resource requirements of supporting applications on or off the mainframe - do not assume that because someone else saved money moving off the mainframe, that you will too," said Murphy.

IBM's Viper attacks mainframe market >>

EMC protects mainframe environments >>

Big iron's battle of the boxes >>

'Mainframe masters' highlight job opportunities >>

Comment on this article: computer.weekly@rbi.co.uk




 


Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in May 2007

 

COMMENTS powered by Disqus  //  Commenting policy