The future of the mainframe and Web services

Web services have had a long run of ''wrappering'' mainframe legacy systems. Will Web front ends overburden the venerable platform and end the party?

Have Web services and XML run their course as a useful means for “wrappering” mainframe legacy applications? Are

Web front ends beginning to overwhelm the noble platform? Experts weigh in here on SOA-enabling legacy applications, including strategies for migration and modernization, architectural approaches, and when enough may be enough.

According to Grace Lewis (shown here), senior member of the technical staff at the Software Engineering Institute (SEI) in Pittsburgh, the mainframe still has a place, but ideally organizations should be utilizing it for what it’s good at. 

Grace Lewis, Software Engineering Institute (SEI)

“A lot of firms have a lot of data in these mainframes, and they can keep using the mainframe for what it’s good at, data processing. Instead of using the mainframe like an interactive machine, finish the processing of data at night and expose it to more modern applications during the day. Some are seeing this as a way of extending its life; others are thinking that modernization, especially with support, is becoming expensive, and it’s getting harder to find people knowledgeable with mainframe languages.”

Lewis, who teaches the SEI’s Service-Oriented Architecture: Legacy System Migration course, said there are several modernization/migration strategies: “One is straight wrapping, not tinkering with code but wrapping a layer around the legacy to access some functionality; there are pros and cons to wrapping functionality as is.”

Another strategy is to do some incremental modernization, she said. “The advantage of service orientation as an architectural style is the separation between interface and implementation. In the beginning you can have the interface accessing some old legacy code, but over time, when you’re ready, it’s just a matter of switching the underlying implementation.”

And third, she said, is to “not necessarily use a Web service interface to the mainframe precisely, but rather create an intermediary. So data from the mainframe is extracted and placed in a more modern server with a Web service interface; you’re using data in the mainframe but you’re not exposing the mainframe directly.”

Part of any “wrapping” strategy has to be determining the right code to wrap, advised Sunil Talreja, senior vice president for the application development and integration practice at global consulting firm Sogeti.

 “We’re still advising clients to continue to wrap legacy code and legacy functionality,” he said. “It’s the proven method and pattern of getting the functionality and capability out of a legacy environment. The architectural relevance still stands.”

The obvious risk, he said, is “not making sound decisions in wrapping the code. Over the years I’ve observed clients that don’t take the time to wrap the right pieces of code, and they end up with spaghetti of wrapped code.”

Performance can also be a concern, Lewis said. “There are a lot of products that take screens and pass them through a tool, so in the end you’re adding a Web service interface to a screen, and there are a lot who have performance problems with this.”

While Lewis said this is a quick and dirty way to shield end users from having to deal with the mainframe, it may not be a viable approach if performance is an issue.

Talreja said wrapping needs to be approached holistically to be effective, however, he acknowledges that “you can’t keep doing it forever.” If the mainframe application is flawed, wrapping exposes those flaws.

The next step, he said, “is to really look at what does it take to improve the basic transaction and do an evaluation.” Organizations need to determine if it still makes sense to have a particular capability running on the mainframe, or if shifting it to a distributed environment would make more sense.

Talreja added, “That kind of investment is only for the portfolio of transactions that do need attention.”

Jim Johnson, chairman of The Standish Group, a research and consulting firm in Boston, said wrapping is not a strategy for the long term given the changing state of applications, and organizations need to start thinking about decomposing mainframe applications “to become more fleet of foot. The age of the enterprise application is slowly deteriorating, moving to a notion of the lightweight app that’s always changing.”

In the interim, Johnson said many organizations are “skinnying down. There’s a lot more refactoring going on than in the past; organizations are throwing out a lot of stuff, reducing the size of the application to cut maintenance, whether they’re using SOA or another approach.”

The crux of the issue is the age-old problem of aligning business and IT, according to William Ulrich, president of TSG Inc., a business and IT consulting firm in Soquel, Calif.

“At the core, the old legacy mainframe system is doing its job, but it’s not aligned to how business needs to work. We’ve got to find a way to decouple and retool the underlying architecture.”

Long-Term mainframe view

In the long term, Ulrich said, organizations are going to need to decouple all the middleware. “We have legacy Java, legacy C++, maybe some PowerBuider floating around. A lot of this was built on an architectural foundation that assumed back-end systems were black boxes.”

Ulrich acknowledged that decoupling is not simple, “which is why the message doesn’t resonate well. There are only so many band aids you can layer on; you can’t keep jury-rigging with interfaces, because at some point you’re jury-rigging the jury-rigging.”

Organizations, he said, need to utilize modernization analysis tools to get an understanding of their systems, and then “intelligently decouple them along a roadmap that is driven by a business architecture.”

He concluded, “Everything must be on the table when it comes to modernization – there are no sacred cows when it comes to systems. And there is no stated goal to make mainframes go away – this is a byproduct that may or may not happen based on business needs.”

This was first published in April 2011

Dig deeper on Service-oriented architecture (SOA) Design

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close