Here's an interesting question: What happens when you service-enable batch processing?

This isn't exactly a new topic. Back in 2007 Gartner Research Vice President Dale Vecchio wrote about the topic for Insurance Networks. But articles about the topic are scarce -- which is too bad, considering the business implications of marrying batch and SOA.

If you're curious about just what the business benefits would be, then check out this recent article by Ronald Schmelzer, an analyst with ZapThink, a consultancy and analyst firm specializing in SOA and SOA training.

Of course, you're probably more familiar with the benefits of service-enabling data processes, application functions or even business processes -- but Schmelzer notes that services "are also well-suited for exposing the very processes that drive batch-oriented workloads."

The benefit to that is pretty straight-forward. Service-enabled batch processes could move from being pre-defined to being consumed in a flexible process, he explains. And instead of scheduling batch processing as a daily activity, it could be executed on demand, in part becuase you could couple the business rules and IT process requirements with the batch process service:

"From a Service-oriented perspective, the Service contract and policy would have to specify how many times a batch can be executed in a single day, how long the batch takes to operate, and any other Service or data dependencies."

Schmelzer's piece is focused primarily on how service-enabling batch process could help real-time organizations. It focuses on the benefits, but I wish he'd spent some time looking at the possible cons. For instance, while he talks about ensuring the batch processes services are tied to business and IT rules, he doesn't talk about how that might work in real life. The Insurance Networking News article, on the other hand, points out that the marrying SOA to batch applications can negatively impact performance in tricky ways:

"Batch jobs have historically processed large volumes of data in defined batch time windows overnight. If service calls introduce a level of delay or dramatic performance hits, then batch processing won't finish in time. Transaction volumes occur over the course of the work day and, while there are peak processing times in any organization, the volumes of processing in batch and the limited time windows leaves no room for error."

Of course, that piece was from 2007, so perhaps there are better options now. Perhaps Schmelzer will explore this topic in a follow-up piece. (Hint, hint.)

If you'd like to learn more, you should also check out this older, but still pertinent, article published by Enterprise Systems nearly a year ago. In the article, Sridhar Sudarsan, an executive IT architect with IBM's Software Lab Services, shared the lessons he's learned about managing batch processes in a SOA environment.