To ensure the success of your mainframe SOA initiatives, it's important to be able to support both bottom-up and contract-first design approaches. With the former, businesses may see an opportunity to jumpstart the SOA, quickly packaging bite-sized chunks of mainframe code as Web Services, and pushing them out to the rest of the organization to do with them what they will. But experience shows that the contract-first approach - basically, Web Service design informed by business processes - is a "best practice" that will yield optimal results.

The Myth and Pitfalls of "Instant SOA" Let's look at the difference between the two methodologies. With the bottom-up tactic, generally adopted for "instant SOA," the mainframe developer wraps pieces of mainframe functionality as isolated Web Services, and basically throws them over the wall to be accessed by various end-user applications and systems. This sort of point-to-point delivery of unassembled building blocks puts far too much of a burden on the rest of the organization to try to understand what a company's mainframe developers already know about the mainframe's proven applications and data. As a result, the service consumer has to interact with the mainframe developers to understand the underlying mainframe functionality. This eliminates the timeconserving benefit that probably drove the initial adoption of the bottom-up approach - and puts the lie to "instant SOA."

This method puts additional burden on the service consumer to orchestrate the interactions between the Web Service and the necessary data transformations, as well as the inputs and outputs in the business application. Further, when any of the underlying mainframe Web Service components change, the consumers have to be alerted as to how and what to change in relation to their specific uses of the service. With a back-to-the-drawing-board reaction every time there's a component change, the benefit - and therefore the likelihood - of reuse is lost, and along with it, much of the advantage of implementing SOA in the first place.

Further, companies that embrace this approach to get ahead of the game in delivering mainframe SOA frequently find that it has the opposite effect. They may end up with dozens or even hundreds of mainframe Web Services that have been developed in complete isolation from the SOA decisions that are typically made by centralized groups outside of the mainframe development organization. Services delivered in advance of such planning have no opportunity to take advantage of corporate direction. What's certain about a strategic undertaking like SOA is that all the elements must arise from and align with a centralized policy, so to avoid throw-away work, it's best to understand the big picture before you pull the trigger.

A "Top-down" Approach Is the Real Fast-Track
In the top-down approach, by contrast, business processes drive the development of the Web Service. Typically, the mainframe developer works in advance with the user who needs the service, identifying the consumer's functional and data requirements, and negotiating a contract to deliver what they need. Based on that contract then the mainframe developer maps the mainframe components to the service requirements, and proceeds to develop an integrated business service that automates all the steps and operations required to fulfill those requirements.

While it's true that this approach requires a time commitment in the form of upfront communication between the end user and the mainframe developer, it's a much more efficient, healthy, and beneficial interaction than the post-service delivery complaint-and-rescue interactions inherent in the bottom-up approach. In addition, it forges a social partnership between mainframe and non-mainframe constituents that serves as a solid foundation for building a successful SOA, ensuring that the components of the architecture are optimally designed and sized to promote maximum reuse and efficiency. It's this service optimization that leads to the fastest returns on SOA investments in terms of cost savings, operational efficiencies, reduced overhead, and strategic advantage.

If you embrace the contract-first approach as a best practice for successful SOA implementation, there are some foundational elements that must be addressed.

Don't Sweat the Small Stuff
As we've established, true service optimization can only come from a thorough understanding of the service definition in terms of the business process. Developing that level of understanding on the part of the mainframe developer requires social interaction with the end user. To free up the time for such interaction, mainframe developers will need service development tools that enable them to automate as much of the low-level development and delivery mechanics as possible. The payback on time spent understanding user requirements and negotiating effective service delivery contracts to maximize reuse will far exceed any return on time spent mastering unfamiliar Web Service integration mechanics such as SOAP, XML, WSDL, or HTTP protocols.

Maximize Your Assets
It's also important to leverage the mainframe developer's comprehensive knowledge of mainframe resources - what applications are available, where they are, and what they do. It may be helpful to augment or focus that knowledge by taking advantage of technologies specifically designed to assess the full range of complex mainframe applications, and isolate particular business functions for exposure as services. This kind of assessment, mapping, and realignment of existing applications to embrace Web Services and SOAs fully can greatly facilitate the service development process, and ensure that all available mainframe resources are utilized for maximum value.

Some Assembly Required
You'll find that the business services required by users will most often span multiple operational systems, incorporate a variety of transaction types and data formats, and even invoke external Web Services. Of course, the users won't be able to express their requirements in those terms, so an important factor in the contract-first approach will be the mainframe developer's ability to extrapolate from the users' requirements the cross-system orchestration that will be required to make the service work as advertised.

To minimize the learning curve and avoid manual processing, as well as to be certain that the orchestration of multi-step, multioperation business services is comprehensive and accurate, mainframe developers should take advantage of development and implementation tools specifically designed to facilitate and automate the deployment of mainframe-based services across systems and platforms. The ideal environment for a quick learning curve would enable developers to graphically model the inputs and outputs and multi-step processes required to implement the published service. Further, once the service is defined and published, the implementation environment should automate the business service flow, ensuring that SOAP processing and WSDL discovery can be fully leveraged without requiring mainframe developers to acquire an in-depth detailed understanding of these technologies.

Dance with the One Who Brought You
By definition, a robust business service that leverages mainframe assets in the SOA will likely combine a variety of mainframe technologies. For example, 3,270 applications may be combined with CICS and possibly IMS transactions and data in any number of formats, as well as incorporate external Web services. And the whole thing must also be able to integrate new functionality, such as data transformation and routing, easily. The most efficient leverage of resources will exploit native data access capabilities, processing information directly in its native environment, eliminating the need for middle-tier servers, and providing the flexibility to fully leverage mainframe processing power as appropriate in the SOA.

A Contract for SOA Success
An uninformed rush to wrap and ship isolated chunks of mainframe functionality as Web Services - in a vacuum of organizational strategy and user requirements - will ultimately slow and negatively impact the success of your SOA, both in terms of customer satisfaction and reduced ROI. An SOA best practice, on the other hand, is a business process-oriented approach that begins with social interaction between mainframe developers and service consumers. Such a dialog produces a real understanding of the ultimate use and function of the service in terms of business benefits, and produces a contract between service provider and consumer that enables mainframe developers to effectively produce the complex, sophisticated business services that will ensure maximum usability and reuse profiles.

In addition, the contract-first approach opens the way for organizations to fully and strategically utilize their proven mainframe resources, including the in-depth knowledge of legacy applications, technologies, and data that resides with the mainframe developer. To realize this goal, it's important to provide tools to help the developer map and integrate these mainframe assets, to really understand what they have to draw from, how it works, and where it resides.

Finally, to free up the time required for the social interactions that enable the best practice of business-process development be sure your mainframe developers have the best tools for the job. Although it may seem counterintuitive, the more sophisticated tools that enable mainframe developers to do it the "right way" need not be any more complex to master than the simplistic tools of the "wrap-and-throw" approach. Look for tools that they can learn to use quickly and easily, such as graphical modeling tools. Minimize the time they have to spend on low-level mechanics by looking for tools that automate the process flow as much as possible, and orchestrate the execution of complex services across operational platforms without developer intervention. With the right approach and the right tools to implement it not only will the final result be a more strategically beneficial SOA implementation, getting there will actually be more efficient and cost effective. And after all, isn't that the definition of a best practice?