Related Links

Web Seminars

While service-oriented architecture (SOA) is enjoying a continued increase in both real-world implementations and marketing buzz, one area that raises more questions than answers is how the mainframe fits in SOA initiatives. The mainframe continues to be the mission-critical platform of choice for virtually every member of the Global 2000, local, state and federal governments. Most mainframes at large enterprises contain thousands and thousands of valuable line-of-business applications and serve as the central repository of record – where the so called “one version of the truth” is maintained. Mainframe applications and data drive the way the world does business – from ATM transactions to airline tickets and virtually every financial transaction on the planet. So why is it that the most significant computing platform in existence is subject to so much controversy over how, and even if, it should be included in SOA initiatives?

It’s really quite simple. While the mainframe is a ubiquitous computing platform driving business around the world, it is viewed as a “black box” by many architects and CIOs. On one hand, executives know it as a trusted partner of the business. Many mainframe programmers and business analysts enjoy long tenures at the same employer, many having 20-year plus careers with at the same employer. Contrast this with the newer Java and Web-centric technologies of the last decade where the average life span of an employee could be as little as 18 months. As a trusted confidant, the mainframe has helped bridge the unease that exists between business and IT. Yet, an air of mystery persists. Most organizations simply do not have a real understanding of the thousands of applications and diverse databases spanning multiple mainframe subsystems and database management systems (DBMS).

Beyond a lack of understanding of what applications reside on their mainframes, many in IT view the mainframe as old and Web-based technologies as new. Old stereotypes die hard. The mainframe is seen as a proprietary platform, with stove-pipe applications and nonrelational databases. Integration with the mainframe has historically been the realm of frail screen-scraping technologies or required risky changes to the code-base. This was true in the past, but there are now high-performance software solutions designed to leverage the performance, security and reliability of the mainframe in the world of Web interfaces and SOA.

This cloud of fear and confusion that permeates many IT executives who have not come up from the mainframe has led many organizations to choose not to involve this mission-critical platform in their early SOA initiatives. This is a mistake. If you’re a large enterprise with mission-critical applications running on the mainframe, you cannot ignore the platform as you formulate your SOA strategy. The heart of SOA is about reuse – both existing applications and data. The whole concept of application reuse isn’t such a novel idea. It’s been around a long time, and mainframe developers have been building reusable services from the beginning.

The mainframe should be an active participant in any SOA project, from tactical to strategic. In larger mainframe-centric organizations, whether they are CICS or IMS based, not only should the mainframe be an active participant, it should serve as the lynchpin in an enterprise SOA strategy.

Let’s examine some common concerns regarding SOA and the mainframe:

1. Security. Opening up the mainframe outside of the firewall is a security risk.

    

   Applications have been extended beyond the mainframe for well over a decade. Security is always a key concern, and should be addressed as part of your SOA strategy. Many mainframe SOA tools exist that allow you to continue to leverage the Enterprise Security Manager (RACF, Top Secret, ACF2) and provide additional security for the transaction using WS-Security.

    

2. Skill-set. My existing mainframe staff doesn’t have the right skill-set for SOA.

    

   This is a common fallacy. Organizations look to their mainframe developers who have deep knowledge of both the mainframe functionality and data and how the applications are used by the business. While it has been said that mainframe COBOL programmers lack the expertise to build services, this is not the case. There are tools that exist today that allow companies to leverage their mainframe staff to engender valuable Web services. There is no one more qualified to service-enable mainframe applications with the right granularity than the COBOL programmers who understand the mainframe code and the business. This allows services to be exposed in the right manner, possibly spanning subsystems and databases.