In-Depth

Q&A: Application Modernization Strategies

From mainframe brain drain to the maturity of Web services standards, we speak with an IBM engineer and enterprise modernization architect to learn what companies need to do to bring their enterprise up to date

• By Stephen Swoyer
• 12/16/2003

We spoke recently with Jim Rhyne, a distinguished engineer and eServer tools and enterprise modernization architect with IBM. Our discussion ranged from the scope of enterprise modernization (hint, companies often fail to adequately anticipate skills modernization), the phenomenon of mainframe brain drain (Rhyne isn’t convinced that there’s anything to it), application modernization strategies and, of course, the maturity of the Web services standards themselves.

Let’s start with the basics. What do you mean when you talk about enterprise modernization?

I tend to use enterprise modernization a little bit differently than some of my colleagues. I use enterprise modernization to talk about the overall picture of what customers have to do to modernize their enterprise. For example, what do they need to do with the infrastructure? I find an amazing number of customers that are not at the latest versions of the hardware end software for their mission critical operations.

The second part has to do with skills, and that comprises knowledge of other program technologies beyond what these people might have as a primary skill area, it comprises adopting modern day development methodologies. The third area has to do with application modernization, that’s the issue that you here most often addressed with SOAP and Web services and On Demand [computing].

You mentioned skills modernization, and that’s something that you don’t hear a lot about. What does that typically entail?

With skills modernization issues, it’s really primarily about changing the way the organization works. So it’s also about educating the developers and the development managers. But the key thing there is how do we do this without essentially pulling these people away from their responsibilities, or how [do you manage training and education] while people still have to work at their jobs?

To what extent does the issue of skills modernization go both ways, [as], for example, when an IT organization wants to train staff accustomed to working with modern platforms or development methodologies in mainframe methods?

I talk to customers and I find that they really don’t have a problem hiring people and teaching them necessary skills, even on mainframe systems. I personally have not found it difficult at all to get people to come in and run the COBOL and PL/1 compilers, for example. One of my best guys is a new Ph.D. out of Stanford that we hired two years ago. He didn’t know a thing about the mainframe when we hired him, and he’s quickly emerged as one of the key guys in that area. So that’s definitely an opportunity for organizations.

Is this one solution to the so-called problem of mainframe “brain drain?”

I find [customers] all over the map with regard to this putative brain drain problem. First of all, why wouldn’t the mainframe be an attractive platform for someone just out of college? There’s job stability and good pay, and it’s not as if it’s unexciting to work on. It’s something that you can train someone on just like you’d train them on any other [platform].

Are organizations increasingly turning to professional services to address skills gaps or staffing shortcomings?

Customers are spread over a spectrum in terms of their readiness [for skills modernization] so you’ll find some customers that aren’t where they need to be in terms of their infrastructure, in their skills, and the architecture of their applications, so that it would take a fairly substantial leap of resources to leap over that hurdle. So the interesting question for these customers is: Do I try to staff up by hiring to meet this requirement, or do I get an outside services organization to come in and jumpstart me?

Another issue is that starting four or five years ago, what’s been happening is that businesses are looking at software development the way they would any other capital investment, so rather than funding their IT infrastructure to have the capacity for any new development, they’re actually funding it when they see a need for a type of new investment. It’s very difficult for people to maintain the kind of capacity that they need to follow when technology takes one of these lurches, so that’s another reason or the increasing importance of services in this area.

Are there significant differences in the application development life cycle in the mainframe and Open Systems space, or could it be said that basic development methodologies are similar between the two?

Yeah, there are definitely differences. One of the things that we find is that in an enterprise organization that maybe has 300 or 400 COBOL programmers and 50 to 60 J2EE programmers, these guys use completely different programming methodologies, the whole life cycle is different -- different repositories, different perspectives -- so for someone who’s trying to weave all of this together for a single application to put into deployment, it’s a real headache.

What are some of the effective strategies that enterprises are employing to modernize their applications, then, with all of this in mind?

There’s an approach where a customer says, there’s a part of my application that I need to be able to access using Web services, or even using a Web browser, but it’s not a critical, maybe not a customer-facing, part of my infrastructure. So I need to do this, I need to do it cheaply, I need to do it quickly. But cheaply and quickly aren’t usually consistent with making modifications to the application, so what you have is this whole sort of wrapping approach, exemplified by the [Host Access Transformation Server] and Host Publisher products [both are IBM legacy modernization tools], which says you don’t need to change the application.

For another part, for a whole variety of reasons, this is not going to be satisfactory, and the reasons range from performance to what the business is trying to do is ... make an application that wasn’t formerly a customer-facing application into a customer-facing application, or that the original [green screen application] exposed information that they didn’t want the customer to see -- it was okay for the telemarketer to see, but they don’t want to make this available over the Web. In this case, there’s some reconstruction of the interface of the application, and this is something that can often be done pretty cheaply. It can be as simple as adding some new data style transaction that was formerly driving only in [a] 3270 [data stream], but you expose the business logic, you expose it in a different way that is much more Web-friendly.

What about the maturity of these Web services standards? Is the Web services stack complete enough to support companies as they attempt to modernize or expose all of their host applications?

There’s a certain set of customers that are looking at moving their internal wiring that connects their IT software together over to Web services from a variety of homegrown and proprietary solutions that exist today. In those cases, the customers pretty much have what they need today.

The second venue is where the customers are looking at using one of the things like [the Business Process Execution Language (BPEL)] standard for Web services choreography in order to do business process automation, and I think that the standards there are not quite at the level where customers can feel that they’re going to get good interoperability using this within the organization and within the enterprise. I think that will change rapidly as people come forward with more BPEL implementations, and as the interoperability folks begin putting together compliance suites to address interoperability.

Then there’s the third venue, which is that you would basically be able to use this as a way of doing cross enterprise connections, so customers, business partners, [and] suppliers can all be bound together in a big network of guaranteed interoperability, and the answer is, no, not all of the relevant standards are there yet. There’s some good foundational work that’s been done in the area of security, there are some emerging standards in the area of trust, authentication and provisioning and access, together with software management, and those are in the working stages and they’ll be tried out in some very interesting prototypes that will evolve them into things that become generally useful.