IT Management

Many IT executives of the world’s largest corporations are at a crossroads; the path they take will set the course of IT over the next several decades. At the center of this crossroads stands the mainframe, a machine whose demise numerous experts predicted as occurring in the mid-90s. Today, the mainframe remains an essential computing platform, and organizations that have mainframes can feel confident about investing in them for the future.

In every measurable way, running business logic on the mainframe is vastly superior to doing so on distributed machines, not only because the mainframe has a lower TCO, but because the mainframe is much more stable and reliable. The best way to illustrate this fact is to examine your IT logs and count the number of production outages caused by mainframes vs. those caused by your distributed systems. Mainframes also offer stronger performance; the mainframe is optimized for business processing.

Two related aspects of the mainframe do, however, belong solidly in the past: its primitive interface and closed architecture. These problems have kept the mainframe from participating in the Internet revolution and becoming a part of a Service-Oriented Architecture (SOA). In addition, they’ve given some people the idea that mainframes are no longer useful because they’ve been eclipsed by distributed machines. Fortunately, that line of thinking is in the past and the need for integrating mainframes is widely accepted, due in no small part to the failure of distributed machines to offer anywhere near the same quality of service. As a consequence, numerous solutions have been created to address the mainframe integration issue.

Chances are, if you’re reading this article, you already know all this, and you’re looking for the best way to solve this problem in your own shop. If you don’t fully understand the problem and the potential pitfalls that plague many existing solutions, you could wind up doing more harm than good. To help you avoid making a decision that will steer your firm in the wrong direction, this article outlines the top-10 pitfalls that can render a mainframe integration solution nearly useless, or even worse, detrimental. As you read this list, you’ll realize that most items on it are related; that is, one leads to the other. Without a true understanding of mainframe integration, failures are inevitable.

Here are the top-10 pitfalls of mainframe integration:

1. Processing off the mainframe. Beware of solutions that do any processing off the mainframe. The reason you want to preserve the mainframe is because it’s faster, more robust, and more reliable. If a solution requires any sort of processing on a distributed machine, it will introduce points of failure and performance bottlenecks and invalidate the reason you’re implementing the solution in the first place.

2. Edge interfaces. Stay far away from solutions that communicate with a mainframe via edge interfaces. An edge interface is a way of accessing an application by using the interfaces provided by the host environment (in CICS these are ECI and EPI). These interfaces are generally inflexible (the ECI interface supports only character data, while the EPI interface implies screen-scraping). In addition, they tend to be poor performers. An ECI call, for example, can add as much as 400 milliseconds to a transaction. What’s needed is communication with the application’s internal interfaces. If a solution can speak only to the edge interface, then the integration options are limited, inflexible, and slow. Even worse, they may require reworking the mainframe applications.

3. Middle-tier servers. Pitfalls 1 and 2 are usually, but not always, caused by the use of middle-tier servers. Using middle-tier servers between the mainframe and its distributed clients or servers can introduce points of failure and performance bottlenecks, and can compromise end-to-end transaction visibility.

4. Off-mainframe security or proprietary security. Traditionally, the mainframe has relied on its closedoff nature for much of its security. A hacker would practically have to sneak into your data center to do any real damage. When you implement an integration solution, you’ll be opening your mainframe to potential threats from the outside world. While a mainframe will never be as vulnerable to threats as a distributed machine, you’ll still require robust security that’s adapted to securing a mainframe SOA. If a solution offers off-mainframe security, you’re effectively entrusting your mainframe data center to a distributed operating system. Almost every day a new distributed vulnerability is exposed and dealt with; generally speaking, vulnerabilities are exposed when someone gets hacked. In addition, if a hacker can gain access to your network ”between” your distributed security servers and your mainframe endpoints, then your mainframe applications will be vulnerable. If you don’t want this to happen to you, stay away from solutions with offmainframe security and look for ones that enforce security behind the mainframe end-points.

Proprietary security isn’t flexible or adaptable. Standards are created for a reason, and standards-based security is the way to go—unless your environment is exactly the same as that of the solution provider and will never change or grow. That being said, solutions that offer the ability to extend the standards by incorporating your own business logic may offer additional benefits.

2 Pages