When data processing was first introduced to business in the late 1950’s and early 1960’s it was not initially accepted, because of fear and lack of knowledge on how to utilize the computers and peripheral devices attached to computers. Then, after a short while, people lost their fear and began using data processing in ways that nobody had previously expected - resulting in rampant growth and an uncontrolled environment.

In order to gain control over data processing, management needed to develop disciplines that would provide personnel with standards and procedures, which would enhance efficiency and improve productivity. Eventually, these new disciplines were codified into the Systems Management and Controls (SMC) utilized by most data processing organizations today.

This document will provide the reader with a general overview of data processing and the SMC disciplines used to control and manage Information Technology environments.

The typical Data Processing environment

Figure 1: Quality Assurance and Project Life Cycle Checkpoints

Figure 1 depicts a normal application development and implementation cycle, from the request for a new business application (“Create Service Request”) through the Testing and Quality Assurance process, to submitting the application to Production Acceptance. The picture is used to should how complicated the process is and why there is a need for Systems Management and Control disciplines.

Checkpoints are used to reduce errors and insure that all personnel associated with application development and support are aware of new and changing application functions.

Systems Management and Controls overview

Figure 2: Systems Management and Controls overview

Figure 2 depicts the stages associated with implementing, supporting, and maintaining applications within the data processing environment. Systems Management and Control functions and disciplines are shown in the process where they occur. For example, Service Level Management procedures must be accomplished (both Service Level Agreements (SLA) and Service Level Reporting (SLR)) contracts must be in place before either Application Development or Maintenance work can be performed.

As shown in Figure 1, and again here in Figure 2, the sequence of events associated with propagating an application from inception to Production Operations consists of: Development, Testing, Quality Assurance, Production Acceptance, and then finally Production Operations. If the application is critical in nature, then Vital Records Management, Disaster Recovery, and Off-Site Vaulting must be accomplished. Both mainframe and office recovery procedures must be developed, tested, and implemented along with production acceptance for critical applications. This insures that critical applications and their associated data files are safeguarded and capable of recovery, should a disaster event occur.

Disaster Plans must be developed for both mainframe resources and End User business offices, when critical applications are moved into the Production environment. This insures that the business associated with the application can continue, should either the data center or the business office is lost due to a disaster event. Additionally, Vital Records Management, EDP Security (both Physical and Data Security), and Off-Site Vaulting must be accomplished for a critical application to be accepted into the Production environment. This implies that Disaster Recovery and Off-Site Vaulting contracts be expanded to include any new capacity or data files.

When a Change is made to an application, the current Production module(s) is moved to the Maintenance environment (Component and Release levels are upped by one to indicate that a Change is in process) and the Maintenance Project Life Cycle is initiated. Afterwards, applications Test, Quality Assurance, Production Acceptance, and Production Operations procedures are followed.

This closed-loop process ensures that applications adhere to the Standards and Procedures associated with an organization and that the highest level of Quality Assurance is maintained over the data processing environment.

As data processing procedures evolved a set of disciplines were developed to control this process. These disciplines were named Systems Management and Controls.

In order to insure that Systems Management and Controls were understood and followed by data processing personnel, most companies developed Standards and Procedures Manuals to define how work is requested, processed, and validated. Through the use of these Standards and Procedures, improvements in efficiency and productivity were achieved, thereby optimizing the data processing environment while safeguarding vital data processing resources.

Standards and Procedures Manual - Structure

Figure 3: Standards and Procedures Manual - Structure

Job Descriptions

Figure 4: Job Descriptions

SMC Disciplines and Organizational Structure

Systems Management and Controls (SMC) disciplines have been developed to aid Information Technology Management manage the data processing environment and improve productivity. SMC functional responsibilities can be applied to both the mainframe and distributed data processing environments. When implemented, SMC disciplines will improve productivity and the quality of work being processed through a data processing organization. SMC disciplines are identified in Figure 1.

Figure 5: SMC Disciplines and Organizational Structure

SMC disciplines should be implemented from left to right, with each column being completed before proceeding to the next. Each of these disciplines is described in the following pages.

Service Level Agreements (SLA) and Service Level Reporting (SLR)

Service Level Agreements (SLA’s) should be developed between the Information Technology organization and End Users first. These documents are used to define the amount of processing power needed by the End Users, the hours of operation associated with end user work, and what to do with end user output (output balancing and distribution). Once SLA’s have been developed, it will be possible to define the amount of data processing Capacity and the Performance objectives associated with End User work load demands.

Once SLA’s have been defined, Service Level Reporting (SLR) can be devised and implemented to insure that End Users are being provided with the level of processing they expected.

Figure 6: Service Level Management and Service Level Reporting

The SMC disciplines of Capacity Management, Performance Management, Facilities Management, and Data Center Operations are used to provide Service Level Reporting. The SLR is compared with the SLA to insure that End User computing adheres to the level agreed to by the End User and the Data Processing Organization.

Inventory Management and Configuration Management

Inventory Management is used to define all of the components associated with an End User’s office and applications, including fixed assets, office equipment, personnel, and data processing components. An Inventory Management data base is usually created to identify assets, their financial profile, and configuration. This makes it easier to track and manage assets within the organization.

Configuration Management is used to manage where resources are kept and how they are connected to the data processing environment. Many areas within the organization are concerned with Configuration Management, as is depicted in Figure 5. Both physical components and personnel are included within a configuration. This makes it easier to define recovery requirements and costs associates with the support of an End User’s configuration.

Figure 7: Configuration and Infrastructure Management

Capacity Management

Figure 8: Capacity Management - Process Flow

Capacity Management

Performance Management

Figure 9: Performance Management - Process Flow

Performance Management

Application Development and Project Life Cycle (PLC)

Figure 10: Application Development and Project Life Cycle (PLC)

Application Development and Project Life Cycle (PLC)

Application Maintenance

Figure 11: Application Maintenance - Project Life Cycle phases

Application Maintenance

Application Testing

Figure 12: Application Testing Procedures

Application Testing

Quality Assurance

Figure 13: Quality Assurance Principles

Quality Assurance

Quality Assurance Organizational Structure

Figure 14: Quality Assurance Structure

Application Management – Process Flow Diagram

Figure 15: Application Management - Process Flow Diagram

Production Acceptance

Figure 16: Production Application Management

Production Acceptance

Production Operations

Figure 17: Application Life Cycles and Production Operations

Production Operations

Recovery Management

Figure 18: Why you need a Disaster Recovery Plan

The best insurance against disasters

Figure 19: The best insurance against disasters....

How Disaster occur and procedures for avoiding them…

Figure 20: How disasters occur, and avoiding them...

Since Disaster are no more than problems affecting critical resources or services, it stands to reason that every effort should be made to avoid problems or at the very least react to them as rapidly as possible. Problem Management and Recovery Management are therefore married and should be treated in unison when critical resources are developed, maintained, or supported.