FREE DM Review Site Registration!
Sign-up today and access DM Review on the Web!

Your FREE registration entitles you to:
FREE email newsletters

FREE access to all DM Review content

FREE access to web seminars, resource portals, our white paper library and more!

   

Batch Processing is the Missing Link

Simply SOA

The adoption of service-oriented architecture (SOA) as an approach to provide a more effective means to leverage mainframe data and other disparate legacy applications is growing. Perhaps ironically, enterprises are also challenged with another crucial element that would enable the realization of a comprehensive SOA strategy: Batch processing. Despite the intense focus on leveraging the mainframe, companies - especially those within the financial services and insurance realms - are encountering the dilemma of how to incorporate these massive transactions in bulk into their SOA.

Let's say you've decided on an SOA. You need multioperation business services to garner the advantages of the SOA, but you've also encountered the proverbial roadblock: your company performs batch processing every 24 hours, and there is only a small window of time to complete it. How is it possible for you to implement a comprehensive SOA strategy that will enable your batch systems to not only talk to external Web services, but to CICS and IMS applications as well?

When it comes to SOA strategies today, one of the most innovative approaches is the incorporation of batch mission-critical applications with Web services as well as the integration of all mainframe assets. Organizations heading down the path of an SOA strategy are making batch processing a key part of their planning for these initiatives, as batch processing remains such a major part of how these companies operate. Whether it is claims processing or credit card authorizations, batch is the only method these companies can use to process the massive volume of transactions required daily.

Whether or not companies really want to incorporate batch processing into their SOA isn't really an option, based on the simple fact that every day there's another Web service that those systems need to talk to.

Consider several real-life examples. In the insurance industry, if a company is processing auto insurance claims, one of the steps in that process is to validate a vehicle identification number (VIN) against data that is controlled via the state or federal government data sources. Before SOA, this was merely a daily download of data, but now, it has become a real-time Web services request.

There is a three-hour window to process 4 million claims daily, and now you must introduce a full "round trip" Web service call to complete the VIN validation. You must deal with a batch window that cannot be altered because there is only so much time to complete this batch feed; plus, there's the introduction of the overhead of Web service calls.

The reality is that organizations are introducing Web services themselves, and the batch systems need to talk to those systems. In fact, there's another Web service every single day that must be processed. Case in point: one of the leading health plan companies in the U.S. was challenged with the recently implemented national provider identification (NPI) system, a new methodology for identifying and uniquely enumerating health care providers at the national level. Essentially the NPI system assigns health care providers a number for identification purposes, and all health plan companies use this number when processing medical claims throughout the U.S.

Prior to the NPI, each health plan company had its own unique identification system. This company took an SOA approach and built a service to perform a translation between its own proprietary IDs and the NPI numbers. During the batch processing performed at night, the company must convert the IDs back and forth in order to fulfill their claims updates, and this must be accomplished in a way that doesn't compromise the batch window.

Batch, Technically Speaking

For this health plan company, its mainframe applications remained a key client and server within its SOA. As its architects created services, the need to leverage those across the online and batch environments was essential. Otherwise, the SOA roadmap could be compromised.

Financially, it was not feasible to eliminate or fully restructure the batch programs; therefore, the company was able to consume the services from those programs, meeting the extremely high service level agreements for performance and reliability. The company was able to achieve a complete round-trip Web service call and translation process in less than 12 milliseconds, meeting the time requirement for the batch window.

What are the Major Considerations for Batch Processing When it Comes to SOA?

Essentially, flexible deployment options should be at the top of the list. You should have the ability to deploy the access to the service in multiple locations, in line with batch or CICS or as a "start a task." Your SOA integration solution should provide comprehensive XML support and enable the incorporation of WSDL definitions created in a wide spectrum of tools, applications and environments. Your developers must be able to leverage centrally defined XML schemas to comply with both your corporate and industry standards such as ACORD, IFX and HR-XML.

All-in-all, batch processing is a critical part of standard business operations for companies globally. In order for these companies to realize the true business value of SOA, organizations must lay a solid technical foundation in a service-oriented environment that meets the rigorous performance requirements of batch applications. The result will be a comprehensive SOA that enables more agile and robust performance throughout the enterprise as well as significant financial gains.


Robert Morris, GT Software chief strategy officer, is responsible for the planning, integration and marketing of GT Software product solutions to the global market. Morris has an extensive background in application development and integration including experience with CASE methodologies, distributed systems as well as midrange and mainframe environments. He speaks frequently at customer and industry events including Gartner Symposium, Java One, IBM Common, IBM Transaction and Messaging, and IBM CICS and IMS. You can reach him at rmorris@gtsoftware.com.

For more information on related topics, visit the following channels:



Industry Vendors