• Login
• Become a member
• RSS
• Part of the TechTarget network

When considering mainframe modernization, performance is one important aspect to think about. Modernization issues are much different for systems that run a large number of million instructions per second (MIPS)

For mainframe applications, has Web services wrappering run its course?

Phil Murphy: I’ll give you two answers. One, has it run its course? No. For folks who are not at the small end of the MIPS scale and therefore moving off doesn’t make financial sense, but that want to take a well-structured application and expose what used to be screens that accommodate a business function and make them services that accommodate a business function, and expose them to a .NET or Web interface, why wouldn’t you? It’s a “don’t throw the baby out with the bathwater” approach that makes sense.

Now the second answer. The software that does this was all the rage while e-business boomed. There was huge demand, then huge consolidation. Since then my inquiries on it have almost disappeared, which would seem to be in conflict with the first answer, but it’s a reflection that the software has saturated the market. If you’re doing this, odds are you have the software in-house.

Is there an inherent mismatch between the mainframe back end and the interactive Web front end?

Murphy: Green screen applications were written to be pseudo-conversational—you see something, something happens; it’s a conversation back and forth. That’s what you still do with browser applications; they’re not a completely different and fundamentally incompatible paradigm. Now you take some badly written spaghetti Cobol code, and will it work well? No. Is it all bad spaghetti code? No. My time [in the industry] goes back to ’82; at that time you were taught to write structured Cobol, with loose coupling, logical cohesion, which is many of the things services strive for today. They aren’t new with services; it’s what folks were being taught in the mid-’80s that Cobol should be.

You’ve written that traditional application modernization techniques address one-off decisions; they don't solve the overall problems with application portfolios. Can you explain?

Murphy: We have been applying new technology [to old] for years. Since we’ve owned these applications for 30 to 40 years we’ve had to retrofit each wave; that’s what modernization has been. We’ve reached a point where the portfolio is a behemoth. We’ve patched, added, retrofitted. Simply applying the next wave of technology isn’t going to get us where we need to be. If all we ever do is apply the next wave of technology, [the behemoth] is getting bigger. The approach most of the services vendors use is to modernize one or two applications. You really need to look across the whole portfolio, identify stuff you can get rid of and consolidate, and when you do, you free resources and get credibility with business.

It’s a multistep process—what do we own, what condition is it in, where are we wasting money, and let’s fix that. Once that’s done, now we have intelligence, and we map the applications to the key business functions they support. The business knows how important those functions are to the business. Show them the resource consumption, where the spending is high, where we’re in good shape, where we’re not spending money and we’re in bad shape; that should be reconciled. If you can surface up that transparency you can step away from [IT saying], “Give me $10 million for a database,” to “I’m your coach for technology spending.” If it’s a potential revenue opportunity, they will make a business decision to fix that. If they decide to leave it as is, it’s still a good thing, because the business is making what they believe to be the right decision.

You talk about crafting a modernization framework. What would that consist of?

Murphy: I put these things on a continuum. Rationalization becomes the engine that drives the modernization project. At the lowest end [of the continuum] you’ve got modernization, which is what we’ve been doing for a long time. The simple definition is anything you can do to an existing application—you can monitor and maintain it, so leave it as it is but don’t enhance it; you can enhance it in some way; you can replace or rewrite; or you can retire it.

The next phase is application portfolio management. You need smarts to drive technology decisions. You develop an application inventory and metrics about their health and business implications. The third phase is rationalization. Now that you have intelligence about applications let’s execute—think of this as an engine spawning projects to get rid of dupes, modernize those applications that are critical to business, and starve everything else. The fourth phase is strategic application planning. You surface up the transparency to business so they can make business-based decisions.

Are developers writing new applications for the mainframe?

Murphy: They are -  right now. [Some would] have you believe all mainframers look like Jerry Garcia, which is a ridiculous, inflated FUD-based thing. But size really matters. If you’re [talking about] a couple of hundred MIPS, you can move really easily [off the mainframe]. We’re seeing folks move to save money, but this gets twisted when [it is] so large that the moving costs hundreds of millions of dollars. Plus, putting together a hundred speed boats doesn’t make a battleship. Many folks are writing brand new applications on the mainframe, and it’s not all Cobol; it’s Java running under zLinux.
I talked to a firm yesterday in the financial services transaction processing industry, and they’re leaving distributed servers and database and coming to the mainframe because their growth is crazy. They modeled their growth pattern and they claim the mainframe will save 30% over a distributed environment; that’s taking into consideration floor space, electricity, etc. -- the total cost.

IBM’s latest release of zEnterprise will fundamentally change the migration decision. They’ve taken the biggest, baddest mainframe, put it in a box with a blade center, tied it in with a private network and exposed it to central management. So whether you want to run blades, mainframe, Windows, Linux, whatever, it will run on this box and you can centrally manage it. So it begs the question, why move?

Join the conversationComment

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.