Getting Started With SOA: 10 Tips for Better Results With Your Mainframe Integration Vendor

by Doc Mills
March 1, 2006

Are you beginning to plan your Service-Oriented Architecture (SOA) strategy but don’t know where to start? Or, are you already there and regret some of your prior decisions? Some early adopters might contend that the benefits of SOA don’t outweigh the cost. To eliminate setbacks and cost overruns, you should know what to look for when selecting a mainframe integration vendor. 

Follow these 10 tips for better results with your mainframe integration vendor: 

1. Research, question, and validate architectural options:  

This step is most important when researching integration vendors; it requires due diligence in determining your particular requirements. You must weigh several factors when researching what architecture is best suited for your particular purpose. 

There are three different schools of thought about integration architecture: distributed (anything that doesn’t reside on the mainframe); mainframe (no distributed run-time components); and hybrid (varying degrees of mainframe and distributed footprints): 

• Distributed followers may look to an architecture that doesn’t require the installation of any additional software on the mainframe. This is certainly advantageous where there’s no access to the mainframe such as when the mainframe is outsourced, or where there’s limited contact with mainframe personnel or resources. Installation and configuration processes are faster, requiring no mainframe coordination. While performance is good, greater throughputs, load balancing, and failover are achieved through distributed server proliferation; also known as “server farms.”  
• Mainframe proponents will look to architectures that are solely resident on the mainframe and possibly within various Object Transaction Monitors (OTMs) such as CICS. These products are unmatched in performance and scalability due in part to the intrinsic nature of the mainframe. Server farm and network complexity are replaced with a more complex internal architecture that requires mainframe knowledge and a coordinated project effort.  
• Hybrid deployments are relatively new and uniquely combine the best of distributed and mainframe architectures. In this configuration option, some of the CPU-intensive processing can be shifted from the mainframe to distributed platforms for better workload sharing. This may be vital to mainframe shops that are MIPs-conscious and leery of making mainframe upgrades, since many software products have a MIPs-based pricing and maintenance structure. In a hybrid deployment, XML processing can be distributed, which may be more efficient than having your mainframe parse thousands of XML messages a second. As an added benefit, there may be reduced network traffic due to the added layer of abstraction that a hybrid deployment offers. Since the hybrid distributed server handles the XML parsing, this leaves only the “XML-stripped” raw application data that’s passed over the network to the mainframe server component.  

No single architecture is ideal for every application; there are advantages and disadvantages to each. (For more on this topic, see the August/September 2005 z/Journal article, “Exploring Options for Mainframe Integration.”) Unfortunately many of the battles surrounding the selection of one of these architectures is one of comfort level, since neither of these groups is comfortable in the other’s back yard. Don’t be too quick to jump simply due to a bias ideology. Can your vendor support all three architectures? If so, you’ll enjoy great flexibility in deploying future projects.