% fortune -ae paul murphy

From Chapter one: Data Processing and the IBM Mainframe

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.

Roots (Part Three: The System 360)

--- 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:

1. Planning and Organization;
2. Acquisition and Implementation;
3. Delivery and support; and,
4. Monitoring

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:

1. The service level agreement (SLA). This document sets out the user's service expectations, when the system will be available, what processes are in place to react to problems, and who is responsible for what delivery step. All other controls are, from the user perspective, either subservient to, or triggers for, the SLA.

2. Systems documentation is seen as key to ensuring continuation of systems services. Are procedures documented? are the SDLC stepwise documents available for every significant system?

3. Role documentation and the separation of functions. Is production wholly independent of testing? and so on.

4. Proper process documentation and the separation of responsibilities are seen as integral to the security of information processing. Do the people who fill key roles have the experience and certifications needed for those roles? Are change steps demarcated by organizational walls that require management knowledge and approval to cross?

5. The disaster plan describes how the data center will react in the event of a predictable disaster such as equipment failure, fire, or flood.

6. The capacity plan, which may have human resource and succession attributes, sets out the data center's short and long term plans to meet growth in user processing needs.

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.

---

Some notes:

1. These excerpts don't include footnotes and most illustrations have been dropped as simply too hard to insert correctly. (The wordpress html "editor" as used here enables a limited html subset and is implemented to force frustrations like the CPM line delimiters from MS-DOS).

2. The feedback I'm looking for is what you guys do best: call me on mistakes, add thoughts/corrections on stuff I've missed or gotten wrong, and generally help make the thing better.

   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.

3. When I make changes suggested in the comments, I make those changes only in the original, not in the excerpts reproduced here.