Leveraging the Mainframe in Your SOA Strategy

It’s a phrase that we hear all too frequently: “We’re moving off our mainframe.” Yet virtually anyone who has ever had a mainframe continues to utilize it in some fashion. These robust and highly functional legacy systems contain years and years of data, and when you’re talking about abandoning them altogether, you’re also talking about a huge chunk of change.

The truth is the mainframe is not disappearing. Whether you’re in the financial services, insurance or airline industry — or, well, any industry for that matter — mainframe applications and data help drive the way the world does business.

Many IT executives who have not come up from the mainframe have led many organizations to choose not to involve the mainframe in their early service-oriented architecture (SOA) initiatives. This is a mistake. Large enterprises with mission-critical applications running on the mainframe cannot continue to ignore the platform while formulating an 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, albeit under many different names.

SOA is an approach that has come into its own in the last few years as a pragmatic means of modernizing legacy applications. However, when it comes to integrating the mainframe into today’s SOA applications, many organizations have proceeded with very low expectations and, as a result, have achieved minimal results. Architects and CIOs around the globe generally assume there are no tools to effectively bridge the gap between mainframe applications, data and knowledge and the service-oriented demands of today’s customer-centric enterprises, and they have been satisfied with a rudimentary Web services-only approach.

Facilitating Reuse

Most organizations simply do not have a real understanding of the thousands of applications and diverse databases spanning multiple mainframe subsystems and DBMSs (database management systems). It is critical for IT business executives to truly understand their legacy application base, as the fundamental building blocks to engendering a SOA can be found there. The existing transactions and databases have a wealth of business logic that can be exploited in a new SOA.

Defining and building the proper business services from existing transactions in your application portfolio can be more complex than simply creating new Web services from scratch. In addition to being readily recognizable and understandable by the business user, a business “unit of work” typical spans multiple transactions, applications and databases.

Typically, this consists of wrapping discrete chunks of mainframe functionality as Web services, and publishing them for non-mainframe service developers to do with what they can. This provides a fast implementation; however, this approach involves far more back and forth processes, which can lead to more complications, including breakdowns that require more extensive repair and downtime.

This would be unacceptable in many other areas of the corporate information infrastructure; however, intimidated by its seeming intractability, SOA architects have settled for less when it comes to integrating the mainframe.

What is truly needed is the generation of a business service from the existing application logic that provides orchestrated multi-step, multi-operation functionality, with transparent communications and data transformation. Critical to successful SOA is the ability to understand and deliver such business services at the optimal level of granularity to facilitate reuse and to insulate the user from downstream maintenance.

Two Basic Design Approaches

To remediate this limited vision, one must look no further than the concept of automated Web service orchestration, the cornerstone of success for mainframe-based service development. This concept goes hand-in-hand with top-down design, where the goal is determined and agreed upon before the effort begins. Otherwise, everything that is developed in support of the SOA simply becomes an elementary building block that will have to be assembled into a usable structure elsewhere, with all the attendant development, testing and maintenance ramifications that implies.

There are two basic design approaches to creating services for your enterprise SOA — top-down and bottom-up. Top-down service design, where business processes drive the development of the Web service, has been shown to be a best practice for mainframe SOA. Even so, bottom-up design seemingly allows faster delivery of some basic services. Each can have its place in an enterprise that is implementing or converting to applications based on SOA.

With the top-down approach, the mainframe developer works in advance with the user who needs the service, identifying the consumer’s functional and data requirements, then mapping the mainframe components to the service requirements.

The Right Level of Granularity

So how do you identify and scope a business service that will be the right kind of building block to take advantage of your SOA?

Start your service definition at the end point — the employment of the completed service by the user: for example, the customer service representative (CSR) performing the job function “Get Account Information.” This is just one step in the process of looking up information for a customer, whether to provide service or to cross-sell a new service or product. It is a discrete job function within the process that the CSR will recognize and know how to use.

While the user sees a recognizable business task, under the hood, “Get Account Information” is a multifunction, multi-operation service, which is a further indication that you are approaching the right level of granularity. It comprises information such as financial transactions, address information, credit rating, purchase history, etc. Retrieving this information may invoke multiple applications or systems with different interfaces, and even external Web services such as an outside credit bureau. It might even perform specific operations on the data returned in order to fulfill the requirements of the service interface.

At the same time, all of this must be transparent to the user of the service; the alternative is a bunch of standalone services, each of which must be invoked in turn by the user.

Gather Feedback

Further, at the right level of granularity, the use of the service itself must be insulated from downstream changes to its underlying components. For example, if the company switches credit bureaus, the necessary changes can be made within the service without affecting the way it is invoked by the CSR’s customer upgrade application. This combination of granularity and transparency ensures the highest level of service understanding, acceptance and reuse — the ultimate goal of the SOA. If designed with the top-down approach, such a business process change will be much easier — if not intuitive — and at least more straightforward to accomplish.

As described above, with the top-down approach, the mainframe developer works in advance with the user who needs the service, identifying the consumer’s functional and data requirements, and then mapping the mainframe components to the service requirements. From this design map, the developer builds an integrated business service that automates all the steps and operations required to fulfill those requirements, which ensures that the components of the architecture are optimally designed and sized to promote maximum reuse and efficiency.

It is this service optimization that leads to the fastest returns on your SOA investments, in terms of cost savings, operational efficiencies, reduced overhead and strategic advantage. It is service orchestration that enables mainframe developers to achieve this level of optimization without coding.

As you embark on an enterprise SOA strategy, do not neglect involving your mainframe. Gather feedback from industry analysts such as Gartner and Forrester. Talk to other companies who have been down the same path. The benefits gained from service-enabling your mainframe far outweigh any cost or risks involved. If your mission-critical business applications reside on the mainframe today, then you absolutely must leverage the mainframe as a key component in your SOA strategy.