Has Over-Standardization Overpriced the Mainframe?

Tillinger Consulting Corp. Making Computers Work for You

Has Over-Standardization Overpriced The Mainframe?
by Martin H. Tillinger

For the past several years, a theory has become prevalent that applications on PCs, networks and even minis are much easier and faster to develop and much more cost-efficient than applications on mainframe platforms. This may be due to IS packaging of the mainframe environment, which provides much more to the information system user in the following areas:

	Hardware reliability
	Comprehensive design
	System software reliability
	Corporate-wide standardization
	Data backup
	Disaster recovery
	Ease of maintenance

Use of the same procedures on systems of varying sizes produces either poor, large systems or overpriced, small systems.

If IS desires to stop or slow down erosion of the mainframe’s share of enterprise-wide computing, it must re-examine its methods of doing business. A principal tenet of the procedures and methodologies adopted by IS is the idea that there is one, and only one, acceptable way to do tasks such as:

	Perform a systems feasibility study
	Test computer programs
	Document the results of such a study
	Name computer programs, files, etc.
	Design an information system
	Back up programs and data
	Document that design
	Operate the systems
	Code computer programs
	Handle problems
	Document computer programs
	Provide for reliability.

When considering many of the alternative platforms, it is evident there are no standards being observed. From the IS viewpoint, many corners are cut for which the end user and the enterprise will eventually pay. This may be the case. More likely though, many of the applications developed outside IS either do not need the full scope of IS standards (because they are not mission-critical) or they eventually and incrementally are brought up to these standards as their users and local IS staffs learn what IS learned years ago.

Proposed Changes

Perhaps it is time for IS to develop a tiered set of procedures, methodologies and standards that distinguish between various types of applications within the enterprise and require different levels of reliability, documentation and standardization.

The key to developing this tiered set of standards is to review the objectives that the standards are used to achieve. Too often, IS standards are implemented by copying them from some other organization without an analysis of the needs of the current organization. The proper way to create or review standards is to start with the objectives the set of standards is designed to accomplish. Some of these objectives may be:

No system or user should he able to affect the proper operation of any other system unfavorably. This objective yields standards for naming global entities such as jobs, files and programs. Often, those standards require much more than guaranteeing uniqueness.

The development of a system should not waste resources or be inefficient. This objective is often used to justify elaborate feasibility studies, design methodologies and review procedures. However, systems vary widely depending on how crucial they are to the organization. The procedures should be varied depending on the size and criticality of the system. This prevents the production of poor, large systems or overpriced, small systems. The hassle and cost of performing systems development through IS often prompts users to find a way around it.

Every system is critical to the well-being of the enterprise. This objective is used to justify elaborate disaster recovery plans and facilities. Some enterprises, indeed, would fail if their systems were not available at certain times. However, not every system is critical to the same degree and harm might come only to specific business units.

IS staff must be able to easily perform problem determination and some classes of problem resolution on every system. This objective generates standards on naming, documentation, computer language, etc. Again, because every system is not super-critical, not all of these may be needed for every system.

Standards

One indication that an organization’s IS standards are too rigid is the presence of systems or jobs being run for production under the test environment. By staying in such an environment, the system does not need to comply with various formal reviews and documentation and does not receive full problem handling, backup and disaster recovery services.

Creating New Standards

Standards are often created based on examples that members of a standards committee may have encountered in previous jobs. While most standards committees have representatives from many IS areas (application programming, operations, technical services, quality assurance, etc.), these committee members often let one group make all decisions as long as their group does not have to do more work.

Sometimes meetings become power disputes between opposing groups. A problem arises when members of the standards committee have no idea how to create standards. This is not unusual since they do not often perform that task. The equivalent in systems design is to have a committee code a program without writing specifications.

IS should revise its standards and procedures to solve these problems. Since this is what the user desires, tiers of production support should be defined. Depending on the size and complexity of the installation, production could be split into a few classes or be defined with various types of selections.

Implementation

The proper approach is for the standards committee to start with the objectives the standards should satisfy and obtain agreement on these objectives. Once agreement is obtained, the committee can evaluate proposed standards to determine if they meet these objectives.

At this point, the committee should consider the objectives carefully. For example, an objective might be that one user’s work should not interfere with another user’s work. This would imply some minimal naming standards. A further objective might be ease of problem determination by IS staff. This objective might then be tiered so that if the IS staff is not responsible for problem determination (or is compensated at hourly rates), then this part of the standard is optional.

Ideally, every proposed standard and procedure should be reviewed to determine if compliance increases cost or makes the environment user-unfriendly. In performing this review, users should be involved, especially those who have expressed the most dissatisfaction with IS practices.

As IS departments face the challenges of enterprise network computing in the ‘90s with mainframes, LANs, workstations and PCs, they will need to consider these issues. By having a fresh business perspective on the issue of standards, they will be able to better serve their organizations’ needs.

Copyright © 1998-2002 Tillinger Consulting Corp. Any use of this Web site is subject to the policies, disclaimers, and conditions set by Tillinger Consulting Corp. Read our legal statement and our privacy statement. Send mail to with questions or comments about this web site.