This is the 9th excerpt from the second book in the Defen series: BIT: Business Information Technology: Foundations, Infrastructure, and Culture
Note that the section this is taken from, on the evolution of the data processing culture, includes numerous illustrations and note tables omitted here.
--- As discussed in Chapter Two, the System 360 wasn't the only computer product available in the sixties or seventies and many users were influenced by ideas generated outside the COBOL/360 world's digital continuation of 1920s card processing methods. That, of course, led to increasing user unhappiness as the gulf between what they read about computers and what their own systems people delivered widened.
The resulting stand-off between Finance, through which Systems normally reported and not traditionally a bastion of user empathy, and the user community led to the evolution of a number of governance best practices. Those, in turn, rapidly co-evolved a system of formal controls - a set of minimum standards which, if adhered to by both users and systems, will nominally mark a secure and successful operation.
These controls achieved their clearest formulation to date in the CoBiT Framework for Governance, Control, and Audit for Information and Related Technology developed by the Information Systems Audit and Control foundation (ISACF) and available through isaca.org.
CoBiT sets the gold standard for audit and control work in mainframe data centers.
The CoBiT Framework establishes four governance domains:
These four domains relate to a total of 34 high level processes giving rise to 302 specific control objectives like:
3.6 Workload forecasting
Controls are to be in place to ensure that workload forecasts are prepared to identify trends and to provide information needed for the capacity plan
The key control documents are:
The importance of the service level agreement is hard to over state. The SLA is the "peace treaty" between users and the data center against which subsequent actions or demands from either side can be judged. All other documents are sub-servient to it - the disaster recover plan is, for example, simply evidence that the SLA can be honored during the aftermath of a systems failure. Furthermore, annual data center budgets and new project authorizations are often set by committees with user input specifically required under the SLA. Similarly, service appeals processes are generally spelled out along with the rights and obligations of both sides.
Nevertheless it is common in organizations to find that the SLA has fallen into disrepute or is simply no longer maintained or enforced. In those situations users will often be found, on investigation, to have bypassed the data center for services they consider critical and to have adopted an attitude of resigned contempt for the data center in areas where use of its services is unavoidable.
Notice that getting the facts right is particularly important for BIT - and that the length of the thing plus the complexity of the terminology and ideas introduced suggest that any explanatory anecdotes anyone may want to contribute could be valuable.