Developing with Workload Automation
Fitting into your busy schedule
Gartner thinks that schedulers will be taken more seriously if they're called Workload Automation Brokers - but don't let that put you off.
Gartner has renamed its "Event-Driven Job Scheduling" category as the "IT Workload Automation Broker" category, in a report entitled "Gartner Hype Cycle for IT Operations Management, 2005 (ID #G00127768, July 20th, 2005)", something that Gartner may well be an expert on. You can purchase the report here.
Or you can, as we did, check out Cybermation, which seems to be the main company talking about Workload Automation, and which features prominently in Gartner's report.
I've had a soft spot for job schedulers since my early days on mainframes. And I am not alone: in his book In Search of Clusters, Greg Pfister points out that IBM's Job Entry Subsystem has distributed work across clusters of mainframes working in parallel since the 1970s. In fact, software scheduling independent jobs probably delivers more real parallel throughput in practice than anything else.
But, job schedulers have always been seen as Operations tools. Now, they're becoming Developer tools too, as developers are being asked to deliver complete business systems instead of individual programs. Gartner is now talking about the use of job schedulers to integrate new programs with legacy systems, to produce new automated business systems.
As Charles Crouchman, a Cybermation vice president, puts it: "It's no longer the case that applications folk throw an application over the wall and let the operations folk figure out how to run it, that's all part of the application architecture now. It used to be that the application architects would hand over all kinds of documentation and charts showing the flow of jobs, which Operations would then map into the scheduling tool; now, for the same effort that it used to take to document the process, the architects can define it in the tool itself, before handing it over to Operations."
It's really all about automating business processes and, although middleware is widely used to automate the integration of online transactional systems, a lot of work is still done in batch processes – which is where a job scheduler comes in. However, an event-driven scheduler can automate not just by the calendar or the clock but also respond to application and infrastructure events, such as an incoming online invoice or a B2B message. This helps you develop complete business systems without rewriting what you already have; and without the use of ad-hoc scripts or manual processes.
The survival of batch processing is surprising, although it appears to be surviving by the skin of its teeth. We were talking about moving to “near-real time” online processing 20 years ago, but admittedly there is a continuum from batch to real-time, and an overnight batch-run optimises computer utilisation throughout the 24 hours for many companies.
Nevertheless, internationalisation means that you can no longer just assume there's a period during the day or night when no online applications are needed anywhere on the system. And that's just one reason why you might need an advanced, event-driven scheduling package. Development architects can design a composite system in which independent systems are forced to collaborate and run in the right order; and can share and reuse scheduling logic effectively.
Cybermation claims to be at the forefront of all this (although Microsoft must be a competitor on the .NET platform) and has now adopted Eclipse, which brings multi-platform capability and a familiar development environment. Automation functionality plugs straight into a development IDE, either natively or through IBM's WebSphere. By providing an interface that is developer-friendly as well as operations-friendly, automation can be moved further back in the lifecycle and efficiently built into the fundamental system design.
For developers, however, the underlying message is that you must find a way to start delivering working business systems, ones that business users (who pay developers' wages) can relate to. If developers just deliver programs, which must then have security subsystems, legacy integration, and so on bolted-on after delivery by Operations, the blandishments of outsourcers and offshorers will look increasingly attractive to the beancounters.
Advanced event-driven job schedulers - call them IT Workload Automation Brokers if you like - are just one tool developers can use to fight back. However, remember to make sure you look for proven delivery capabilities (even with very big systems) with these tools, deep functionality and the ability to run on any platform you have now or might have in future – as well as ease of use and simplicity. Different platform-dependent schedulers that need external scripting for interoperability, or even manual orchestration, risk being unreliable and probably won't really deliver at the business systems level. ®
Sponsored: DevOps and continuous delivery