Three Basic Directions of System Integration

Introduction

Any design, for any system, for any type of application, must take into consideration the level of the organization the system is intended to service, the technical maturity of the organization, and the the category of application (not type) being designed. Although there are many ways in which to explain these concepts, the three most popular are the Managerial Pyramid model (Robert Anthony), The EDP Growth Stage model (developed by Gibson and Nolan), and the Operational-Informational-Administrative systems model (which as far as I can tell has no single person or group to which it can be attributed).

Because these three concepts have such an impact on the design process we will discuss them in some detail, and their implications for the design process. By reviewing them here they will help to explain the goals and process of system design, the directions of system movement and most importantly the various framework setting perspectives which help to guide and control the system design process.

The Anthony model - A Managerial Pyramid

Any organization can be viewed as a multilevel entity. Each level represents a different level of control. In addition, each successively lower level has a differing level of data requirement, and a different, and less extensive, view of the organization. Obviously the higher the level, the more interrelated the business functions become until, at the very top, it is viewed as one one homogeneous organization with one continuous data flow.

The levels of the organization have been discussed in other contexts, but briefly for our purposes we will use the definitions of Robert Anthony in his 1965 Harvard Business Review article entitle "Planning and Control Systems: A Framework for Analysis". In his article he discusses the organizational management as if it were arranged in a Pyramid (figure 5-1).

The pyramid is divided into three three sections, horizontally. From top to bottom these sections are labeled, respectively:

1. Strategic
2. Managerial
3. Operational

Strategic

At the strategic level, the requirements are informational, derived from past data events and outside activities. The strategic level is the highest level of the firm and is usually populated by the most senior management.

Their's is the broadest view of the corporation. All reporting lines originate from this point. The strategic level is responsible for overall corporate policy and direction. The strategic level is primarily oriented towards functions rather than toward processes and tasks.

Strategic data is highly concentrated, and usually contains little detail. In many cases data at this level may be limited to critical success factors (key numbers which indicate the operating health of the firm), or graphics which represent trends or comparison data. Much of the data at this level is financial in nature and relates directly to the critical balance sheets, and profit and loss figures of the firm. Strategic data is a mix of internally generated and externally obtained information. This information is used to compare the firm with its competitors, and with the economy as a whole.

Managerial

The managerial or administrative level controls, and organizes, not only the company actions based upon the organizational input, but also performs the supervisory activities aimed at ensuring its correct processing. It also monitors processing rates and quality. The managerial level is responsible for the tactical implementation of the policies and directions received from the strategic level. The managerial level is oriented towards functions and processes.

Managerial data is more fluid and limited, than that of the operational level. The people at that level being more dependent upon information than data. Managerial and administrative data is almost solely derived from internal sources, and reflects the operating health of the firm.

It monitors day to day operations and may be used at either the summary or detail level. In most cases, data at this level is extracted from operational reports. Managerial data needs are not as immediate as those of the operational level.

Operational

The operational level is data and processing oriented. Its inputs are specific, and derived from current data events. While management flows downward in the organization, data flows largely upward. At the operational levels all work occurs as a result of:

1. a transaction orientation

2. a response to the largely external entry of data from a data event, and/or the passage of a predetermined unit of time, or,
3. to the completion of some other internal activity which resulted in a change in the status of some activity or data entity.

It is the operational level which is the predominant recipient of data into the organization. The operational units and their related managerial overseers are fixed in focus. Their horizons are limited to their own specific activities. Applications and systems aimed at these groups are, of necessity, also limited. The operational level is primarily oriented toward processing and task, rather than toward functions.

Each vertically oriented operational area, at the lowest level may include many special processing applications. The area may be automated to any degree and may be integrated within itself to any degree. These special processing application areas rarely extend beyond the "walls" of the user operational area, and thus reflect the biases and parochial views of the particular user area, and the user area management

These operational areas were the first to be systematized and usually the first to be automated. Their activities were particularly suited to proceduralization and systemization, and were already subject to high degrees of standardization and rules.

The movement toward greater degrees of systemization and integration pushed these "local" systems beyond their traditional walls into other areas and more importantly upward into the managerial and strategic areas of the firm. This lateral and vertical movement dictated that new frameworks and new mechanisms of integration be developed, frameworks which allowed for and accommodated this vertical and lateral expansion and integration.

The Four Stages of EDP Growth

Another aid to understanding the various types of data processing projects, and thus the various types of environments in which systems design activities must be performed, is to understand the evolution of data processing support in the corporation. The most widely used model of this evolution is the Gibson-Nolan Model of EDP Growth Stages.

In 1974 Harvard Business Review article entitled "Managing the Four Stages of EDP Growth" by Cyrus F. Gibson and Richard L. Nolan, the authors outlined a cycle of corporate data processing evolution. These stages were labeled Initiation, Expansion, Formalization and Maturity (Figure 5-2). Today this staged view of the data processing evolution is used by the Nolan-Norton Company to analyze maturity of the data processing systems organization and to assess its development effectiveness.

Most, although by no means all, organizations evolve through the four stages during their existence. In some cases, as technology changes, the firm may evolve through the cycle multiple times, once for each generation of hardware and/or software technology. The following are descriptions of each stage, bearing in mind that these stages can be passed through multiple times.

Initiation

This first phase is typified by tentative starts at the new technology and by early pilot projects. Usually the first activities to be attempted are those which seem best suited to automation under the new technology.

Where the firm is undergoing initial automation, the projects addressed are usually activities which involve largely repetitive numeric calculations, such as payroll, general ledger, accounts receivable or accounts payable. As the organization gains experience and confidence with the new technological tools, or with automation in general, they progress, rather quickly to the second stage which is called Expansion.

Expansion

This stage, sometimes also called "Infestation", is characterized by rapid, and uncontrolled growth of applications. The data processing organization, in a rush to use the new technology, attempt to apply it to everything in sight, or attempt to place everything under a new technology base. The organization starts a large number of projects, brings in larger equipment, and hires more staff.

As these projects complete, and new ones start, management begins to realize that they have spawned a monster. The data processing expenses rise more quickly than most other corporate expenses, and management begins to realize that they have no control over the data processing area. In addition they begin to realize that there is little emphasis on the traditional project and expense controls. Management at this point begins to crack down and impose standards, policies and procedures on the data processing area.

Formalization

In the Formalization phase, controls, standards, and procedures are put into place which structure the expansion phase, and establish the foundation for the Maturity phase. As the levels of development control are established, management sees the need for data standardization and control. The management of data becomes as important as the management of the development process. It is in the late expansion and formalization phases the firm's need for data is replaced by its desire for information.

Unlike the earlier stages of initiation and expansion, where the impetus was for penetration of automation into user areas and the acquisition of data, with little regard to coordination and integration of systems, the migration to Maturity environment requires careful planning and coordination.

It is in planning this migration to a mature environment that management must resolve the organizational issues necessary for a successful effort. It is during the second and third stages of systems development that the distinction between operational and informational needs is identified and refined.

Maturity

The Maturity phase is characterized by a corporate recognition of the need for integrated systems and data and information availability. During this phase systems are usually redesigned and rewritten to use common software and common databases, new hardware or software technology, and other advanced information processing techniques.

It is the Maturity phase that traditionally gives rise to the use of database technology as a mechanism to integrate diverse applications into a planned architecture. It is only after the operational portfolio has been firmly established and controlled, that consideration, and appreciation, of the full benefits of the technology can be realized.

The effects of multiple curve residence

Because the firm or parts of the firm have differing levels of automation, and make use of differing types of technology, it is possible and probable for the firm to be at different stages in the model at the same time (figure 5-3).

The growth of computer capacity and speed, and the declining costs of hardware have given the firm the capability to process data rapidly and consistently. The development of newer, faster and cheaper machinery all provide an impetus for the organization to change its processing environment. Each major change in technology can cause the firm to revert back to the first or second stages of the growth cycle. These changes however are usually not firmwide, and thus various parts of the firm may be at different stages of the growth model for different technologies. In some cases the same part of the firm may be at different stages of the growth curves. Two of the latest changes, one hardware and one a combination of hardware and software have caused this type of multistage environment in many firms. These changes are the introduction and rapid development and deployment of personal computers (microcomputers) and the introduction of viable implementations of relational database technology either via hardware (database machines) or software.

With each new introduction of change, a new round of enthusiasm, experimentation and familiarization is embarked upon. In many cases, new projects are initiated for the sole purpose of using the new technology. When we examine the growth models however we soon realize that controls are usually introduced late in the cycle, along with methodologies and standards. The usual reason for this being that it takes a while to determine what standards and methodologies will be needed and which will work best in the new environment. In many cases, methodologies used for older technologies are not applicable to the newer ones.

The development of methodologies and procedures, and the maturity of the technical tools and facilities provide the capability to control, manage, and maintain both the individual applications and their data. The methodologies and techniques of design, the designs themselves, and the processing, may not have been changed or upgraded to fit the newer technology. This mismatch between technology and methodology causes greater disruption and lack of effectiveness in development than being in multiple growth stages. Many processing methodologies still only replicate the manual processes they have supplanted. In some cases where new technology has been the impetus for change, the new technology is employed to process systems designed or even redesigned under the older outdated technology.

As firms progress along these growth curves the individual applications, and their structuring systems become larger and more all encompassing. This movement along the curves and the multiplicity of curves creates two sets of pressures on the design process.

The first is to move each individual application further along its individual growth curve, adding more and more management monitoring and control mechanisms and capabilities, making it more subject to processing standards and more and more standardized in its use of the basic processing resources of personnel, budget, and data. This is especially true of the data resource, since this normally has a high level of modification and change anyway, and thus is the easiest to focus on.

The second set of pressures is stimulated by the drive to expand system scope and to integrate more and more systems around a single framework. These pressures are exerted to bring the various systems, each of which is moving forward on its individual curve, into synchronization with a master curve, such that as many systems as possible reside at the same place on their respective curves.

If the systems are in the same relative phase on their individual curves this process of synchronization becomes relatively easy, the further apart they are the more difficult the synchronization process becomes because movement on these curves can only be forward, and the imposition of controls and maturation (integration) technology on immature systems can be both premature and traumatic. The natural movement along the curves allows for experimentation and the gaining of understanding about the underlying processes, and the appropriate technology and framework needs. Moving too fast may cause more disruption in the user environment than living with systems which need to be changed.

Operational Versus Informational Systems

One of the primary issues facing the designer with respect to the understanding of the users and the system which must be developed to support them, is that within the organization, there are two distinctly different types of functional roles, and thus two distinctly different kinds of systems.

These functional roles can be identified as operational and informational. From the designer's perspective these two classes of systems must be viewed, and treated differently.

When we look at the levels of management on the classical pyramid (figure 5-4) we can more clearly see the distinction.

At the lower level, we have the operational units. Here the functions are vertical and the focus is limited to a specific organizational segment. Systems at this level are developed on a client specific basis and used to facilitate and control the day-to-day business of the firm.

It is at this level that the bulk of the corporate portfolio of systems are developed. These systems are customized to the needs of the user client and are usually under the control of that user.

In an organization where the systems portfolio are well developed, but in a second or third phase of growth, management's informational needs are usually satisfied by reports which are little more than summaries of reports originally developed for operational people. These reports are extracted from the operational files.

The primary emphasis in the expansion stage is in the operational environment. Management's need for cross-unit information during this phase is usually satisfied by multiples of these summary reports each slightly different, each representing the unit, timeframes and specific definitions of their originating organization units.

Operational systems are those systems which support those at the lowest level of the pyramid. They are characterized as being transaction based, cyclically processed, usually batch oriented, and usually operate in a current time frame. That is, the transactions are accumulated and processed on a periodic basis. The files created from those transactions represent the accumulation period and are designed for expediency of processing rather than, necessarily, for the production of information.

Operational systems are built on a function by function basis or functional collection by functional collection basis, and each system supported function is traditionally called an application.

Informational systems are broader based, more horizontal in nature, and usually arise from the operational files of the firm. While there are "applications" within the Informational systems, these are reportive in nature rather than processing in nature. Existing data is arranged and ordered to provide the control, coordination and planning functions with views of the business.

These systems are retrospective in that they are concerned with what was and projective in nature in that they project future trends from past events. The data in informational systems tends to be less precise and more statistically oriented. That is, they tend to look at the whole population, or samples, or segments of the population rather than individual members or occurrences of the population.

There is a third category of systems which are both horizontal (informational) and vertical (operational) in nature. These can be classified as administrative systems. In this category fall those systems which are usually overhead, and support the organizational as a functioning unit regardless of what the business does.

The most common examples of these administrative systems are Payroll, Human Resources (Personnel), and the myriad of Financial Systems (General Ledger and Budgeting) The systems Support the planning managerial and control needs of the firm rather than some specific aspect of the business of the firm.

As the operational and administrative functional needs have been fulfilled, automation has even penetrated the managerial and executive functions with decision support, marketing, planning, forecasting, monitoring, control, and management information system applications.

Generally speaking, these automated application systems are designed to accomplish one or more of the following:

1. replace well defined, repetitive, manual tasks
2. support existing work flows
3. provide information to support the monitoring of business operations, or
4. support the management decision making process.

There are exceptions to the above generalizations. These usually occur in organizations which:

1. produce products or provide services which are either in whole or in part creatures of data processing
2. provide data processing services for hire
3. develop data processing systems for sale, lease or franchise.

For the purposes of our discussion, it is immaterial as to whether the the system is being developed in an organization where data processing falls into the former or the latter role. The principles and guidelines laid down here apply to the general processes of applications systems analysis, design and development, and thus apply equally to both.

Regardless of the purpose of the system to be developed, the process of design is the same, what differs is the system or application to be designed.

System Design Goals

The development of effective informational systems is predicated on the development of frameworks which support more global, more horizontal, and thus more integrated views of the firm. Information systems are predicated upon the ability to assemble more and more data in a consistent and meaningful manner. This presupposes that the data framework for the various systems has a high degree of commonality in terms of accessibility, definition and content and that the procedural framework for the various systems is such that the currency and timeliness of the information is also synchronous.

Each of these three concepts all have in common that they are forces which are applied to the firm's systems over and above the forces which result from business change. These concepts illustrate the natural movement of systems development and the goals towards which systems development strives.

These goals which are common across most design projects. These are:

1. to increase the level of integration among the functions, systems, processes, activities, tasks and procedures of the firm
2. to increase the level visibility management has into the activities of the firm, and to increase the level of control that management has over those activities
3. to increase the responsiveness of the firms systems and to increase their flexibility such that systems and procedural changes can be accomplished when business changes warrant.
4. to concurrently decrease the conditions which cause changes to the firms systems and procedures when business changes occur. In other words, to make the firms systems and procedures more independent of change.
5. to increase the level of standardization and conformity between systems and procedures
6. to increase the level of systems and procedural documentation
7. to increase the quality, accuracy, consistency and timeliness of the information needed by the business.
8. to increase the level of accountability for, and the level of reliability of, the firms processing activities.
9. to decrease the degree of uncertainty of the firm's ability to respond to change.
10. to increase the logical foundations upon which company systems and thus company processing is based and thus make that processing more predictable.
11. to ensure that all the firms processing is in conformance to the business rules, business strategy and business tactics, and that all the firms processing makes a contribution to the corporate goals.