CIOZone.com - Professional Network for CIOs and IT Professionals

In some circles, "mainframe modernization" is a code word for migrating applications onto other platforms. But for those organizations that continue to value the mainframe qualities of stability and reliability, the big question is how best to modernize mainframe applications that need to be better integrated with the rest of the organization's enterprise architecture.

One of the approaches IBM has held out is the ability to support applications written in Java on the mainframe, as part of the WebSphere middleware architecture.

Another alternative I hear a lot about is taking existing mainframe applications or specific CICS transactions that can be treated as software components and exposing a web services interface so they can be treated as part of an enterprise's Service Oriented Architecture.

The two approaches aren't mutually exclusive -- you would probably want mainframe Java apps to be SOA enabled as well -- but the SOA approach is more appealing to those enterprises that are leery of adding or changing code in the mainframe environment any more than is absolutely necessary.

I'm curious what the experience is of CIOZone members who have tried either of these approaches -- either put it into practice or even just tried to sell it internally as a technical strategy.

SOA has worked well for for target applications - making an individual appliation or service available to other apps. Experience has shown companies have run into trouble when they attempted the big picture approach - trying to implement so-called SOA libraries.

Interesting comment. It brings to mind a statement by Burton Group’s Anne Thomas Manes, who declared in a blog earlier this year that “SOA is Dead; Long Live Services.”

Manes point was that the promise of SOA had been so over-hyped that organizations developed expectations that simply couldn’t be met. As you say – vast libraries of mainframe or legacy applications that could be tapped with a simple interface. “SOA,” she wrote, “has become a bad word. Let’s remove it from the vocabulary.”

I don’t quite adhere to Manes’ conclusion – I’ve talked to a number of companies that have achieved excellent results with SOA implementations. But yes, expectations do need to be tempered.

Jack,

Do I understand you right that implementing a library of SOA functions on the mainframe itself is where things tend to bog down? In other words, adding a services interface to an existing mainframe function works as a tactical measure, but trying to implement an elaborate SOA framework on the mainframe tends to be a bridge too far?

Seems like there ought to be some middle way, where you make some strategic investment in making the mainframe part of your SOA, but without getting so ambitious that you tie yourself up in knots.

David, yes I was referring to the challenges that are incurred when you attempt to implement a so-called SOA infrastructure. In concept, programmers would be able to tap a wide range of SOA-enabled legacy applications to puzzle together apps. In practice it tends to be much more difficult, and programmers often prefer to build the functions they need from scratch. That isn’t always the case, but it has proved difficult to achieve the vision initially set out for SOA.

SOA still has its solid fan base. Came across an interesting blog by Roger Strukhoff, in which he, for one, plans to dedicate himself to promoting SOA because of the profound changes he believes it can bring to the business world. The blog is worth reading for more than just his views on SOA.