Most organizations figured out a long time ago that instilling some level of governance and control over application source code (your business applications running on the mainframe) was a very good idea. This governance:
- Saves costs, drives revenue and mitigates risk.
- Provides traceability for changes.
- Moves artifacts through a lifecycle of structure and rigor.
- And most importantly – it protects production.
Yet as sound as this is, I’m amazed at how the other half of the mainframe is open and unprotected. By and large, most firms don’t have any change governance in place against the system software (the software that’s running your mainframe). This means that your system programmers can grab any object or member, make a change and throw it into production.
When I see this in a mainframe shop, I say: “Congratulations, you’ve got half of your world protected!” At first they are a bit confused because they are proud of their change management system, until they realize that it’s only protecting the application code and not the system software. This is the stuff that drives auditors crazy and, if it were known, would keep the CIO up at night.
For the most part, there are fewer system programmers than application programmers in organizations, but their work is complex and crucial to operations. And when questioned about change governance against system software objects, most firms will admit that this is an unprotected area currently being controlled by a bunch of good people being very careful. The reality is that allowing your mainframe system software to be vulnerable is a large business liability that can affect your continuity of operations. Think about it this way: it’s impossible to run your mainframe billing application if the mainframe is not working properly.
It only makes sense — protect your mainframe system software… all of it!
Is this your situation? Does your Auditor or CIO know this? Give me your thoughts in a comment below.
