Service-Oriented Architecture

As Service Oriented Architecture (SOA) initiatives attain critical mass in the enterprise, there's more and more interest in boosting business results and competitiveness (not to mention leveraging significant long-term investments) by incorporating mainframe assets into the SOA. However, if this attention is myopically focused on data and functionality, companies may be overlooking the mainframe's highest potential for rapid time-to-market and ROI: the value of the expertise resident with mainframe developers.

While they may seem an unlikely resource to deliver SOA net-centric applications, equipping mainframe developers is actually a highly practical and cost-effective alternative to the near-impossible task of trying to infuse Web Services developers with decades of mainframe experience.

This article will look at the benefits of fully utilizing the portfolio of mainframe assets in an SOA, with a special focus on tapping into mainframe expertise as a primary resource. We'll examine an approach to SOA development that utilizes tools designed specifically for mainframe developers. We'll look at the impact and potential advantages in terms of learning curve, delivery time, and, most importantly, in terms of achieving optimal service granularity to promote maximum re-use of mainframe-based business services.

Why Mainframe Developers?
One of the leading motivations for companies embracing the mainframe in their SOA strategies is the opportunity to maximize the return on their long-term investments. At the same time, the proven performance, security, and scalability of mainframe functionality minimize the business risk associated with implementing new SOA initiatives. Equally important is the opportunity to lower operational costs through SOA re-use and maintenance benefits.

Although it's clear that the mainframe is an ideal candidate for participating in the SOA, many companies leave much of the mainframe's value on the sidelines, fearing that the skills required for service implementation, and the knowledge required to create business services from mainframe applications and technologies, are islands that can't be bridged within the organization. And it's unrealistic to expect service development experts to come up to speed quickly on decades of knowledge about mainframe applications and data. A reverse of the process, on the other hand, is actually quite practical. Instead of abandoning the mainframe, along with its proven functionality, for lack of service development skills within the community of mainframe expertise, companies should look for quick and effective ways to bring their mainframe developers up to speed on service development. According to Gartner analyst Dale Vecchio, speaking at a recent BPM conference, "The talents of your people do not solely reside in their technology skills. Evolve your development organization to a component/assembly mentality where re-use is rewarded - even on mainframe environments." And, in fact, mainframe developers are uniquely qualified to produce the right-sized "business services" that will maximize re-use.

Web Services versus Business Services
At this point it will be useful to understand the distinction between Web Services and business services. First, it should be noted that Web Services aren't necessarily required for, nor are they synonymous with SOA - although the two are frequently and erroneously used interchangeably. While Web Services are likely to be a part of an SOA, they're only one of several technology options for standardizing access to services across the enterprise. According to Integration Consortium vice-president Steve Craggs, this can also be achieved by utilizing such standards as J2EE Connector Architectures (JCAs) and Enterprise Service Buses (ESBs) together with a metadata repository. However, the business services that make up an SOA play a more complex role than simply invoking a function in a standard way. In the first place, they typically contain multi-step functionality, orchestrated in the service, with communications and data transformation that's transparent to the user. As Vecchio says, they must facilitate re-use above all.

Delivering mainframe SOA, therefore, is more than just delivering mainframe components dressed up as Web Services. It requires an in-depth understanding of how the components work together to comprise a recognizable business task - an understanding that's a built-in starting point for mainframe developers. It then requires automating the interaction of the underlying functionality and data sources necessary for the task. Again, mainframe expertise already carries an in-depth knowledge of that functionality and those data sources in terms of mainframe applications. Finally, the effective use and re-use of a mainframe-based service requires that the whole thing be packaged in an easily recognizable and accessible form.

It's typically only at this final step that there's a significant learning curve for mainframe developers. The fact is, with the right tools - service development tools designed specifically for their use - and with a solid understanding of how mainframe functionality will support SOA applications, mainframe developers can quickly assemble the right-sized multi-step/multi-operation business services described above. With such an approach, the development tools themselves can in fact become a teaching tool for demonstrating to mainframe developers everything they need to know about building SOA business services. This was the method used by one of the largest mutual company providers of property and liability insurance in the United States, which recently completed a mainframe SOA initiative that exceeded all expectations in development, testing, and implementation. This was in large part due to its use of mainframe developers - subject-matter experts in mainframe functionality and technologies - to create mainframe-based business services for the SOA.

Putting SOA Value on the Fast Track
With the need to develop and deploy composite applications based on components from across the IT infrastructure, the insurance company determined that SOA offered it significant strategic advantages. But according to its lead system architect, its developers had been spending half of their time on "plumbing" - that is, creating and parsing XML, dealing with HTTP or other transports, error handling, and so on. Not only did this slow their development efforts and create "brittle" code that was hard to maintain, it also cost them in terms of lost opportunities for code re-use. Furthermore, the company's Visual Basic and Java developers weren't familiar with the underlying mainframe COBOL applications. This meant that they couldn't quickly deliver the usable, maintainable business services required for the composite applications. As a result, the system architect was finding it difficult to get the company's SOA strategy off the ground.

This is a perfect example of the "people effect" at work. Without being able to use their mainframe development expertise, the company would be unable to leverage its other mainframe assets in the SOA - and might not get the SOA going at all. With the right tool, however - one designed specifically for mainframe developers to create complex business services from mainframe data and functionality - the system architect found that he could effectively bridge the company's SOA and mainframe knowledge bases in less than a half-day.

"Using a mainframe-specific development tool allowed us to focus our training on Web Services, business services, and SOA. We were able to quickly produce examples that helped the developers to experience and understand the benefits in terms of code re-use. With this approach, working from the developers' in-depth understanding of the COBOL applications we were service-enabling, it essentially took only four hours of training to turn them into service developers."

The Right Tools for the Job
Once mainframe developers understand how the services they are developing will fit and function in the SOA - assisted by tools that can readily demonstrate and model the process - they can use their existing mainframe expertise to quickly develop the complex business services that make an SOA successful. Given the potential upside, then, what are the considerations for selecting mainframe service development tools?

First are the unique features of the mainframe technology landscape. In his paper on "Best-of-Breed Mainframe SOA Tools," author Steve Craggs recommends that the best toolset, by design, will be right at home with the specialized mainframe applications, resources, and environments that are the purview of mainframe developers, such as:

• IBM transaction processing products, CICS and IMS
• IDMS, Natural, and Adabas
• COBOL
• DB2 database and MQSeries messaging middleware
• RACF and SAF

In addition, the toolset should provide a way to map mainframe programming structures to technologies such as XML and Web Services, the foundation for bridging mainframe expertise and SOA deployment technologies. You can eliminate any toolset that doesn't provide the basic functionality required to integrate mainframe functionality according to SOA principles. Virtually any development tool can manage mainframe applications that can be "driven" through a programmable interface. But many of the older mainframe applications are screen-driven, and the toolset must provide screen-based access for them. The toolset also has to be able to play by SOA rules, providing wrappers or adapters that "bridge" mainframe access mechanisms with SOA interface standards. And besides providing interface support for different types of applications, the toolset should access various mainframe data sources, such as DB2, VSAM, Adabas. and others under a single SQL-style interface that will be familiar to mainframe developers.

Unfortunately, even the most sophisticated functionality can be rendered ineffective if it's not easy to use. To make immediate use of mainframe expertise, the development tools provided should be intuitive and accessible, automating the creation of services on the mainframe as much as possible. It shouldn't mean extensive training or third-party consulting to produce results, as this will defeat the advantage of leveraging your existing mainframe development resources.

The toolset should make it easy to assemble and orchestrate the proper execution of multi-step/multi-operation business processes from mainframe applications. This is best achieved by a graphical modeling approach that will provide a familiar development environment for the mainframe expert, and reduce or eliminate manual coding, thereby shortening the learning curve and speeding development.

The modeling environment should also provide visual feedback that will serve to improve accuracy by highlighting problems early in the development process. To this end, the toolset should enable the developer to test components in isolation, simulating their performance in real operations, without requiring that all components be completed and assembled before they can be tested. The toolset should also provide development lifecycle support, allowing services and components to be marked as development, test, QA, or production-level, and should support versioning as well to ensure that untested components or changes don't enter the production environment.

Ultimately, all of these development and deployment considerations will demonstrate whether or not a toolset was created based on an extensive understanding of mainframes. If so, it will offer features that support the stringent integrity and recoverability requirements of the mainframe environment. And, in addition to supporting mainframe operating system functions, it will have the appropriate look-and-feel to gain rapid acceptance and utilization within the mainframe community. This will be key to putting the "people effect" in motion.

Transforming Mainframe Expertise into SOA Success
It's clear that mainframe applications, data, and performance have a major role to play in the Service Oriented Architectures of today. But it's equally important to tap your mainframe expertise to leverage those resources effectively. No one knows more about mainframe applications, functionality, and the underlying code than the mainframe developers already on your staff. Equipping them with development tools that enable them to readily visualize and understand the concept and benefits of a business service composed of mainframe components is the first step - and the fastest route - to bridging the knowledge gap between proven legacy assets and strategic service initiatives. Armed with that knowledge, the right tools will then equip mainframe developers to quickly and easily assemble and deploy multi-step/multi-operation mainframe-based business services that are right-sized to maximize re-use. This approach unlocks the full value of all of your mainframe assets - from data to developers - to fuel rapid and robust SOA implementations.