The impact of services-oriented architecture (SOA) is just beginning to be felt in the batch world-and the challenges are clearly present. Batch legacy applications have been around for years, capably running the business. Now, initiatives like SOA are forcing new integration and interoperability requirements on batch processes that had comfortably been categorized as "untouchable." These processes have to interoperate with online and Web batch applications.

"The problem with integrating legacy batch processes is that they didn't need standard interfaces to other applications back in the days when they were written," said Sal Del Conte, an independent consultant for data center business process improvement. "Data centers today are challenged with being able to move data along by communicating between applications, and at the same time they're faced with SOA, which has been endorsed by IBM and other vendors....There has to be a way for applications regardless of platform to communicate with each other in an easy manner so you can make changes to a given batch application or system and not negatively impact other applications."

By having standard interfaces between batch applications and systems, sites have the flexibility to revise their batch processes. The goal for most data centers is to position themselves to take a "big picture" look at both their batch legacy applications and their non-mainframe batch distributed applications.

"Sites want the ability to reengineer their batch applications and systems, while eliminating all of the redundancies at the same time," said Del Conte. "You can find good examples of this in large financial services and insurance companies, where many of the applications in their legacy-based systems are performing exactly the same function.... With SOA, the goal is to have common, callable modules performing common functions."

Moving batch processes to a flexible SOA environment is daunting. It is a process best pursued in progressively small steps. "You can take one step at a time with your batch environment by starting with applying a methodology to reengineer and optimize your JCL," said Del Conte. "A second step might be to look at the batch code within a given silo application, like a General Ledger. You can ask yourself, "What is the batch code doing? How can I change the code to make it run more effectively?'"

A third step is to purchase a package that monitors the processes, and that furnishes analytics that allow you to make buffering and caching changes. Once all of these areas are addressed, sites are then in a position to look at the end to end heterogeneous environment of their batch processing, and what it is going to take to efficiently move data from one platform to another.

Tools like WebSphere give sites the capability to look at system interfaces and to cross-reference data between disparate hardware and software platforms. The analysis provides visibility of where and how data is used across processes. Sites can then go back into systems to standardize data and data flows.

"Once your data is standardized, you can test and parallel run the revised applications," said Del Conte. "You are then in a position to optimize the operations and the resources of the data center with the flexibility of SOA-enabled batch applications. The flexibility allows for application recombinations and ease of provisioning. Enterprise deployment for new batch business applications becomes less risky."

Risk management is a central concern when it comes to reengineering batch processes to fit the SOA environment. By standardizing applications first, and by using data analysis tools such as WebSphere to document the data inputs and outputs to each batch process, potential risk is greatly reduced because the potential for error and the level of confusion are lower, and the level of control is greater.

"When you move batch processing to SOA, you have new capabilities of workload management and for the alteration of workflows to respond to changing business conditions," said Del Conte. "The system can determine where to run a new application, what resources might not be available, and what resources to commit in order to maximize workloads. SOA and standard interfaces between batch processes allow this to happen." This flexibility makes positive contributions to failover, since non-functioning components in the network can be readily detected and reallocated elsewhere.

Although there are clear pathways to SOA for batch processing, there are also substantial fear factors for IT at both the executive and staff levels.

Hesitance at the executive IT level starts with how to explain the value proposition of committing internal and potentially external resources to modernizing batch processes that have worked well for years. Upper business management isn't going to understand the technicalities of SOA, and "plain English" ways have to be found to communicate the value to the business of revamping batch processes.

"The mere promise of reduced risk won't do it, because corporate executives will tend to view it like an insurance policy and just say that they'll accept the risk," said Sal Del Conte. "Instead, an IT executive has to be able to explain the benefits of SOA-enabled batch as a way to improve customer service, the efficiencies of business operation, on-demand computing and order fulfillment."

Another way to demonstrate the benefit of SOA-enabled batch is to demonstrate results. This can be done by isolating a subset of batch processes, standardizing interfaces and reengineering them for optimum efficiency, and demonstrating the results in tangible business results for upper management. Once the results are seen, management is more likely to sign on for additional batch revision work that will further help the business.

"Selling a new technology approach can be very challenging, especially when the value is very apparent to an IT executive from an IT standpoint but difficult to convey from the point of view of the end business," said Del Conte. "Nevertheless, this is what has to be done to build support for the project in the business."

IT managers must also cope with the trepidation of their own staffs-who already have large workloads, and would not like to deal with processes that are "already working."

There are additional fear factors at the IT staff level, because many of these batch processes were written over 30 years ago. There literally is no one left on the staff who knows precisely how these batch processes work, or how they were put together-and nobody wants to be the one to introduce error.

"My number one recommendation in this situation is for IT staff to begin with a batch system that it is familiar with," said Del Conte. "This allows IT to get comfortable and to build confidence with revising batch. When they implement the finished product, they will see the business value. They may not understand everything that happens within a given batch system, but modern toolsets allow them to see the inputs and the outputs to these systems, and to at least standardize the interfaces between batch systems and processes. By adding standardized interfaces to batch, IT places itself and the end business in a position to Webinize or replace these modules of batch code in an SOA process when and where it is needed."