Should You Leave the Batch World Behind?

Most customers start thinking about making many widespread changes to their IT landscape as part of a core system replacement project. Even though the goal may be business transformation, it makes sense to consider what technology benefits can also be realized.

One of the first areas to consider is the potential replacement of a long list of batch programs that run on the mainframe at the close of every day and month. By selecting a software vendor that is capable of integrating natively with newer technologies like web services, you can open up a world of possibilities.

But before you rush headlong into replacing all of these programs in one fell swoop, some considerations warrant a closer look. Here are a few to get you thinking:

• Batch programs typically use several concepts that provide an excellent audit trail, such as both individual transaction and batch identifiers. These form the foundation for reconciliation between two systems, including answers to the questions of how many records were successfully processed, what was the total dollar amount processed, and which records failed, among many others. To build an equivalent with web services requires some thought (maybe using log files or database tables to capture transmission details, for example) and careful execution, as none of these ideas are native to the web services domain.

• The interface for batch programs is really just the file format itself, usually just a fixed-length text file or CSV. When changes need to happen to the program implementation itself, any changes to the interface must be explicitly made to the output format. In contrast, adding fields to entities used within web services can trigger automatic updates to WSDL files, which form the interface contract. If the other system is not expecting these changes, it can be a big headache.

• Sometimes it makes implementation sense to leave a process alone. Core system projects are notoriously complex and risky. If there are existing, well-defined interfaces that wouldn’t clearly benefit from replacement, leave them alone. For example, a typical general ledger system just expects a single flat file posting daily. It’s just not set up to accept data on a real-time basis. It would be counterproductive to try to rewrite that integration with web services for little obvious benefit.

After considering all of these angles (and others), you’ll be in a better position to plan your journey.