Why are mainframes still in the enterprise data center?

In the recent past, I’ve had the opportunity to speak with representatives of Cobol-IT, Compuware, Heirloom Computing, TmaxSoft and a few others who have targeted enterprises still using mainframes.

A few of them, such as Compuware, are focused on adding rapid application development and deployment (aka DevOps) to the mainframe, making the environment seem relevant today.

+ Also on Network World: Why banks love mainframes +

Most of the others, however, are focused on convincing enterprises that it is finally time for them to abandon the mainframe and move those workloads to industry-standard x86 systems running Windows or Linux or, perhaps, to midrange Unix systems.

Regardless of all of this industry attention, the mainframe still is a common resident of the enterprise data center. The key question is why?

Snapshot analysis: Mainframe workloads are complex

The problem facing enterprises wishing to move away from mainframes has always been the “all-or-nothing” challenge posed by their own workloads. These workloads are so interdependent and complex that everything has to be moved at once or the enterprise suffers.

The suffering typically centers on underperformance, increased complexity caused by bringing functions over piecemeal, or having to add new development or operational staff to support the target environment. In the end, the savings on hardware or software turns out to be less than the increased costs required of a hybrid computing solution.

Some have chosen to lift whole functions and substitute cloud-based solutions, or just replace the whole custom solution with a less custom, off-the-shelf piece of packaged software. The enterprise decision makers appear, in these cases, to have accepted having less customization in exchange for some benefit: better performance, made possible by using a cluster or grid of industry standard systems; increased ease in finding development and operational staff; or reduced costs for additional hardware, software and software components that can be found in the industry-standard world.

I’ve noticed that many of the competitors in this “mainframe migration” market target Cobol-based applications executing on mainframes. Some hope to persuade customers to move to other computing platforms or to the cloud by transforming the Cobol to Java, others suggest moving to a more portable version of Cobol, and a very few suggest different language processing environments. If my memory serves me well, some of those other platforms include Ruby and Python.

While all of these services appear to offer at least something to help enterprises wishing to retire their mainframes, none of them really addresses the entire environment.

The lurking complexity of migrating mainframe workloads

Mainframe workloads are often complex mixes of programing languages, a workload management tool, a transaction processing monitor and a mainframe database engine. Migration of an entire workload typically includes finding a way to replace a combination of all of the following tools at once:

• Job Control Lanuage (JCL) files
• The transaction processing environment monitor, tyically CICS or IMS TP
• The database engine, which could be any of the following all by itself or in combination with another: Adabas, CA Datacom, IDMS, Oracle, FOCUS, NOMAD, TOTAL/SUPRA/ULTRA, IBM IMS, Model 204, SQL/DS or a handfull of other products
• Applications written in one or more of almost 20 supported mainframe languages

It is easy to see that moving the complete workload environment from the mainframe somewhere else is a very difficult problem. That’s why most suppliers cherry-pick the “easy” bits out of the list as their focal point.

Can one of the suppliers help with mainframe migration?

Many suppliers are clamoring for the enterprise’s attention, but can they really help? It’s a simple question that unfolds into a difficult answer. It all depends upon how complex your mainframe computing environment is.

If it is largely constructed of some Cobol applications using a relational database managed by a simple job control environment, the answer could be yes they can help in a migration effort. If your environment is more complex, at best they can help you move the simple bits somewhere else leaving the rest of it behind.