From Mainframes to I-Frames

I got a dose of reality last week when I took a briefing from TmaxSoft, a Korean company that specializes in mainframe conversions. I hadn’t thought about a mainframe in a long time and assumed they were no longer an issue, but it turns out that they continue to live on.

There are still 6,600 mainframes in operation in the U.S., according to TmaxSoft. That’s a lot of old iron supporting some conventional businesses in industries like banking, insurance and utilities, just to name a few. It was fun and a little disconcerting in an age of SaaS and PaaS to become aware that the era of green screens, VSAM and IMDB is not technically over. It also raised questions in my mind about what it will take to cause those conversions. As usual, a lot rests on the costs, and there are many ways to look at them, but there are also issues of labor and utility or usability.

TmaxSoft has an interesting partial solution that they use to rehost mainframe applications. Did I mention that mainframes are expensive to operate? I had forgotten about that, and the company has a good business in helping its customers save a bundle by getting them off of big iron and onto gear with a smaller appetite for cash.

Shallow Talent Pool

If things were that easy, this wouldn’t be much of a story. The major costs of mainframe applications can be divided into the gear and the labor. You can solve the gear problem, but then you really need to look hard at labor. Mainframes run COBOL applications and an alphabet soup of software like JCL (job control language) and the aforementioned storage architectures — and that’s just the beginning. It’s hard to find people with these skills today.

Kids just out of school look at mainframes as a career dead end, and older, experienced people have retirement in mind. So the idea of not only porting the applications but rebuilding them in modern technology is an important issue for virtually all of the 6,600 mainframe owners, which draws us up to today’s main point. There are a lot of applications that need to be rewritten — what will the technology be that hosts them?

In this day and age, an organization that builds and maintains its own software rather than buying it off the shelf does so because there is a lot of secret sauce embedded in those apps. For example, in financial services, trading systems are practically all secret sauce — they contain a great deal of competitive ideas that support distinct business processes within each firm.

You might ask yourself what the leading contenders are for the replacement technologies, and almost any answer you come up with involves code, and coding eventually lands you back in the same position as we are in with mainframes today. The alternative is SaaS and PaaS, which will certainly provide a cost cushion as well as a developer’s playground.

Crash Course in COBOL, Anyone?

There is also infrastructure as a service (IaaS which I will not try to pronounce). For companies looking to save on the costs associated with big iron, IaaS represents an important alternative. But IaaS also can eventually land you back in a mainframe-like straightjacket. There are many vendors today who will provide infrastructure over the Internet. The issue I see with that approach is the same we saw when it was called “ASP” (application service provider) about 10 years ago.

ASP or IaaS enables you to operate much as you have always done, and while it can lower your costs, it also lets you get into some bad habits by not mandating that you keep your applications up to date with the latest technology. A mainframe application transferred to an IaaS configuration (an I-frame?) could conceivably run for a long time in green-screen mode. About the only thing that might force a company to rewrite such applications might be the declining number of available COBOL programmers.

I would never advocate forcing anyone to do anything with the applications that support their core businesses. How would that work, anyhow? But I think it’s prudent to point out how an organization could paint itself into a corner by re-hosting without making an effort to update its core applications.

Can SaaS and PaaS can provide an environment that is powerful and functionally rich enough to handle the demands of the mission critical applications left on mainframes? It’s a good question, and I don’t have an answer. Certainly with every product release and iteration the industry gets closer to that reality. But will the owners of mainframe solutions ever trust their computing to off-site shared systems? Can they afford to stay in emulation mode? Anybody want to learn COBOL?