Batch Architecture, Part Zero

(Originally posted 2011-03-29.)

I’m not an architect. I don’t even play one on TV. 🙂 In fact real architects would probably say I’m in the babble phase, architecturewise.

But I’ve been involved in a few situations over the past year or so (and I’m involved in a couple starting round about now) which have led me to the following simple conclusion: Many installations would  benefit from drawing up a Batch Architecture. I don’t think this is specific to z/OS-based batch, though we do tend to have more complex batch environments than other platforms. (And modern environments seem to have z/OS-based and other batch mixed together, often in the same application.)

As I say, I’m not an architect so some of what follows will seem to real architects a lot like Officer Crabtree. 🙂 But it’s my thinking – and hopefully some of it resonates with you.

So what do I mean by a Batch Architecture? To me it contains the following elements:

• A description of the operating environment. This contains things like the LPARs Production Batch will run on, the database systems, message queuing systems and the like. You’d also rope in things like transmission networks, tape subsystems, job schedulers and printers supporting the batch. You might include commentary such as "we use PRDBATHI WLM class for critical production batch, PRDBATMD for most of it, and PRDBATLO for stuff that can run slowly but is still classified as Production".
• An inventory of applications. Though I’ll talk about this element more in a subsequent post I’ll note the minimum would be a list of names of applications and a description for each application. Also the job names (or rule for classifying jobs into a particular application).
  
• An understanding of the interfaces between applications. For example "PABC990D in ABC and PXYZ010D mark the boundary between the ABC application and the XYZ application, the former needing to update the General Ledger before the latter can begin to produce reports". Again, something I hope to write about some more.
  
• A view of when the window is – if there still is such a thing as a window. And what has to get done by when – with business justification such as "we have to post status with the Bank of England by this time in the morning".

The above, far from exhaustive, list enables you to think about your batch in a structured fashion. Done right, and it doesn’t really matter which tooling you use, it begins to enable you to:

• Talk about your batch at a level above the individual job.
• Think about the impact of growing business volumes.
• Plan for merging batch workloads (particularly topical at the moment).
• Plan for splitting off workloads.
• Think about how you can move work around.
• Consider what happens if there is a problem – whether an application failure or a disaster.
• Put some structure on modernisation efforts.
• Tune batch in a structured way.
• Collate the understanding of your batch that so often is in the heads of very good application experts.
  

Now, I appreciate most customers have huge batch inventories – often in the tens of thousands of jobs a night – and I think many customers are doing elements of this already. So what’s left to do that’s actually doable? I think quite a lot – and of course it varies from installation to installation.

But I do think some architectural thinking about batch would be really useful for most customers – and I’m certainly going to be thinking more about this myself (including seeking the wise counsel of some real architects).:-) At a practical level I’m going to post on how to do some of the building of a batch architecture.