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

by Doc Mills
March 1, 2006

While this may be attractive from a data integration perspective, it isn’t so appealing if the application exists within the CICS transaction monitor address space. There may be performance considerations when comparing this data integration model against a true application integration model designed to coexist and capitalize on a subsystem’s characteristics in support of mainframe transaction processing monitors such as CICS. Maximum performance can be achieved by placing the “service boundary,” where the MP resides, closest to the target application. (For more on this, see the previously cited August/September 2005 z/Journal article.) 

4. Get acquainted with the vendor’s support and professional services groups:  

Regardless of the architecture chosen, there’ll likely be a learning curve. Choose a vendor you can trust to give guidance and help coordinate your efforts. Test a potential vendor’s support channels. If you’re considering using professional services, understand and be comfortable with the integration product you’re considering. At some point, your company will need to maintain the integration project. That shouldn’t be the time when you determine the project’s complexity and required product mix are greater than your current staff can sustain. 

Start with proof of concept discussions, and then move to mini projects, instead of full-blown wholesale changes. These should be joint efforts between your software vendor and your project team, so stay involved. Make sure results can be measured, by discussing project milestones, recourses, and penalties if schedules aren’t met. Discuss and get vendor buy-in over acceptance criteria, including documentation, internal training, performance guidelines, and error recovery/failure scenarios. 

5. Be comfortable with the Integrated Development Environment (IDE):  

Beware of a collapsing market where software vendors are buying other software vendors, then encompassing several disparate IDEs. Find out how many different IDEs are supported and required. Acquisitions certainly cause software vendors to at least temporarily support multiple IDEs. Can you be guaranteed the IDE you used will be supported in the future? Changing an IDE isn’t so bad, but the result of the IDE is to generate a “service” and each vendor has a specific integration infrastructure to the services their IDE generates. Changing which IDE you use can also force a change to the supporting infrastructure of your SOA—and that could be costly. 

You should fully understand the IDE you’re considering. What happens when a customer deviates from the logic dictated by the software vendor’s product due to specific requirements of the integrated application? Many IDEs generate source code under the covers. When the application logic is too complex, the customer is left to manually write additional source code to complete the task the IDE started. This may work well if you’re a mainframe application developer who knows COBOL or Rexx, but this will no doubt waste time and cause problems if you’re a distributed developer specializing in Java or C. Since some IDEs may lose their appeal under simple application scenarios, it’s best to ensure the IDE can handle your most complex application.