Mainframe SOA Best Practice
By: Robert Morris
Sep. 24, 2006 06:30 PM
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
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
Maximize Your Assets
Some Assembly Required
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
A Contract for SOA Success
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?
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week