Why is Job Scheduling "EXEMPT" from Change Management and Audit processes?

Job Scheduling software has been around since the late 1970's and surprisingly many data centers are still using the tools that were initially introduced around that time. What is more surprising is that many of the changes that occur in the job definitions are done outside the confines of the standard change management and audit procedures.

Many companies have justified "audit exceptions" for job scheduling software because of the manual tracking that had to be done to document the changes that were made in the job definitions. It was an accepted "exemption" because of the lack of a suitable process for automatically making changes to the definitions in a "trackable" method. These initial products either used proprietary databases or other custom file structures that could not be changed, other than thru a manual update.

You would think after 30 years, there would be a more auditable way of tracking changes in job scheduling software products, but that is simply not the case. Many of these products have not changed the underlying definition structure to accommodate the necessary tracking capabilities. It seems quite risky that critical business data is processed and output is created for the business using a tool that relies on the "honor system" for documenting and tracking changes.

Now, some vendors will insist that their enterprise job scheduling products are compliant with the recent industry mandates. You really need to look closely at HOW this can be done? What effort is required and what actions must be taken to achieve this? Some of the products can tell you that someone made a change to 'something' in the definition. But few can tell you exactly WHAT changed, leaving that to manual effort to document and track the exact change that was made and who requested it.

Shouldn't job scheduling software, in the 21st century, be advanced enough to detail not only the WHO and WHEN something changed, but also show you exactly WHAT is different when comparing one version of a definition to another? Do the enterprise job scheduling products still in use today even support the concept of versioning?

If you look at the advances in technology in the last 25 years, you would think that tracking WHAT was changed isn't too much to ask of an enterprise job scheduling product. Then you realize that many of the widely-deployed job scheduling engines have not changed their underlying architectural structure, specifically the definition repositories, leading to the situation we find ourselves in today.

Companies should not be allowed to skate through audit violations claiming exemptions to the normal rules anymore. Business impacts can be too high to simply look the other way and depend on human effort to manually document each and every change that takes place. Anytime I hear of a "computer glitch" causing sensitive customer data to be compromised I always ask myself if it could be related to a change made in the sequence of the job processing.

Enterprise Job Scheduling must be modernized to detect and report on even the smallest change. It should be used as a part of the lifecycle management process as well, so that any changes between operating environments are automatically adjusted and all the components are versioned, bundled, and promoted together.

Architectural changes to old job scheduling software can be risky and costly, as it can complicate the upgrade process so that it requires lengthy professional services engagements to simply upgrade the existing product. That is why we are seeing more "bolted-on" products to enable additional functionality where the development costs can be recovered by the new license fees.

Maybe your situation is similar to what has been described. If so, you might want to look at modernizing and updating your enterprise job scheduling software to a more advanced workload automation solution that can deliver the secure capabilities needed in todays business world.

Entry Permalink

Tweet