The Various Types of Information Systems Analysis Projects

Personal Computer (PC) - also known as microcomputers or workstations, by the model name of the specific vendor (i.e. Apple [1], Macintosh [2], or PS/2 [3]) or by the brand name, model and speed of the processor (i.e. Pentium, Intel or 486/33 [4]) Any combination of processor, input device and output device designed for use by a single individual. Personal computers may also be called workstations.

Personal computers may have a character orientation, a graphical orientation, may be connected to other personal computers, or may operate in a stand alone mode, and may or may not have connectivity to a mainframe.

Personal computer software is normally characterized by an operating system which provides basic file access, management and display services and well as application scheduling and management.

Information systems analysis projects are initiated for a variety of reasons. These include:

The scope and magnitude of the functional and procedural changes may be fairly narrow or wide ranging. In some cases, aside from re-coding the system, there may be no changes in functionality at all.

Given the variety of reasons for a project being undertaken, the starting point may also be quite different from project to project. These starting points reflect the differences in current user processing environments and the current level of user automation. Because of these differences in current user processing environments and user automation, information systems projects can be categorized into three types.

From an analysis perspective, each of these types of projects involves different, and yet similar, work. The work is similar in that the development activities, which are involved in each, follow the same general phases and approach. They are different in that each of the starting or current environments that the analyst must examine have substantially different characteristics. Briefly, these six environmental types and subtypes are as follows.

From the analyst's viewpoint, this is the simplest environment in that all the components of the environment are overt. That is, they are clearly visible from observation and analysis. All work is performed by user personnel, who work directly with their files, forms, and documents. The processing of these forms and documents, the work flows, and the individual steps are easily followed.

At their core all systems analysis projects are concerned with the examination of what are, or once were, essentially manual operations. In fact, it is helpful, regardless of the type of project, to view all the activities of the user as if they were still being performed by hand. This allows the analyst to examine in detail each task being performed, each data operation, each data movement, and each data carrier (a data carrier is a piece of paper, a form, a report, a worksheet, a transaction, etc.).

The analyst's task in the manual environment is to simplify the work flows, streamline the processes, reduce redundant processing, rearrange the tasks so as to ensure more orderly processing, and ensure that the forms, documents, and reports contain all necessary data. Each task, and each task step, must be examined to determine (a) if its execution is appropriate and (b) if it is appropriately defined, positioned, and performed.

The results of the analysis of manual systems are usually new or revised standards and procedures which clearly define the processing sequence for the task to be performed and the rules which govern their performance. In addition the analyst may develop new input forms, control procedures, monitoring procedures, and reports. The output from the analysis may also include new or revised work and data flow diagrams.

Working in this type of environment differs from working in the strictly manual environment in that the analyst's task is to determine whether the manual environment, in whole or in part, can be augmented by automation, and if so, to what extent. The existing environment must be analyzed in the same manner as the purely manual, but as the analysis progresses, the analyst must also find ways of substituting automated processing for manual processing. To accomplish this, the analyst must break each process and task into its component steps and determine if the rules for performing the step lend themselves to machine automation.

The analyst's output for this type of project closely resembles that produced from the strictly manual project. However, here the analyst must also develop (a) new, input forms suitable to an automated environment, (b) file content requirements for ongoing master and transaction files, (c) report layouts, and (d) a processing flow which intermixes the original and unmodified manual processes, new manual processes, and new automated processes. The analyst must also make a determination as to the costs involved in the automation process, provide project schedules, and make hardware and software analyses and recommendations.

There have been many attempts to set down analytical and design methodologies for development projects in automated environments. What many of them ignore is that there are different types of automated business environments, which, while seemingly similar, must in fact be treated differently.

What distinguishes these environments is the extent and depth of automation. Early analysis methodologies were predicated on a manual environment. The aim of the analysis was to develop an automated solution to user business problems. In today's environment, most firms of any size have existing levels of automation. Many in fact have gone through two and three rounds of automation and reautomation.

Many of the existing processes and procedures are either totally automated or were developed as a result of a partial automation of the user area. Many of the forms and transaction flows within this type of environment are automated or semi-automated.

This prior automation poses a trap for the unwary analyst in that the currently used forms and documents of the business may in fact have been designed to support and accommodate an automated system. These automated systems may have been designed for the business using a level of technology which is now outdated or inefficient, or for a set of user requirements or a business environment which has since become wholly or partially obsolete. Additionally, these forms and documents are the result of some prior analyst's efforts and may not in fact reflect the natural information or data needs of the firm.

The processing flows themselves may be unnatural, to the extent that they reflect the intrusion of automated processing sequences. These flows may have been structured to accommodate the needs of the then prevalent technology rather than the needs of the business. Each of the documents, transactions and process flows must be reexamined in the light of the current business environment and the current business processing needs. They may merely need to be refurbished, or they may need to be scrapped entirely in favor of a new and more streamlined processing flow.

The analyst must look with care on batch flows, "processing windows," and transaction holding queues. These constraints may have been imposed on the processing environment by the requirements of prior automation efforts, most probably implemented under what is now an outdated, or, worse, obsolete technology. Reautomation is a major type of project which incorporates the following sub-categories.

The "system rewrite" is one of the simplest forms of reautomation. A system rewrite usually involves very little analysis of the current business environment and thus entails very little change to that environment from the aspect of functionality or procedure. It is closely allied with system maintenance in that the goal is not to change the processing flows or to add to system functionality but simply to "clean up" the processing, streamline the existing flows, or rewrite the programs in a more up-to-date language or with more up-to-date file handling technology.

As part of the rewrite process, file layouts, report layouts, screens, and transactions may change, but usually the file and report content do not, and neither does the user processing environment. A rewrite may remove processing anomalies ("bugs"), remove unused, obsolete, or outdated code and may add minor new functionality to the system. The emphasis here is on minor.

System rewrites are usually done for the benefit of, and are initiated by, the data processing community, either the data processing system developers and system maintenance personnel who need a "cleaner" system to maintain, or the data processing operations personnel who have requested operational changes to streamline the processing or to make it more efficient.

Although the two sub-categories are usually separated, they are sufficiently similar, from an analysis viewpoint, to be examined together. Applications maintenance and enhancement projects differ from development projects in one substantial way: The analysis and design personnel assigned to these projects must also assess the impact of the proposed change on an existing system.

These maintenance or enhancement projects usually leave large parts of the base system intact. The remaining parts are either modified or "hooks" are added to the additional code which support the added functionality. The requests for maintenance or enhancement changes normally originate with the user, although they may originate with the development team itself.

There are numerous reasons for these system modification requests; among them are changes to the business environment, user-requested additional functionality, correction of erroneous processing, and user-requested refinements, or cosmetic changes to the existing system.

Those changes which originate from alterations to the business environment are the most difficult to implement, followed closely by those which add new functionality. The implementation difficulties arise because these types of changes not only require new analysis of the user area but also re-analysis of the original system design to determine where and how the changes can and should be made. Maintenance or enhancement which is necessitated by correction of erroneous processing, user-desired refinements, or other cosmetic changes usually requires little in the way of new analysis.

The analysis and redesign efforts required by business environment changes and additions of new functionality can be almost as extensive as those which were required in the original systems development. The most difficult aspects of changing an application system are those which are directed either toward changes in underlying system design and the resulting processing logic, or toward changing the structure and contents of the system files or database.

When the maintenance or enhancement project is directed at a system in a database environment and the database must be changed, the analysis must not only cover the application in question, but also any other applications which use the same database and in particular the same data records or data elements.

In some cases, the immediate enhancement or maintenance project will require data which should logically be captured by a different, unrelated application. The "chain reaction" or "cascade" of changes can increase the scope and impact of the initial request by orders of magnitude. Use of database technology encourages integrated and interdependent systems designs. The greater the integration or interdependence, the greater the potential impact of any change.

The most difficult of these data-directed changes occurs when the structural logic of the database must be modified. Even minor changes here can have major impact. The more extensive the use of the database, the more thorough and painstaking the analysis that is required. Reporting, retrieval, or other file access facilities may be severely impacted by these data structure, content, or processing logic changes.

The system redesign and redevelopment project is the most comprehensive and difficult type of reautomation. It involves not only the traditional activities of the "new" development project but also the additional activities of file conversion.

The system redesign and redevelopment requires a start-from-scratch analysis, which must at the same time acknowledge the presence of the existing system. This type of project is usually undertaken when an organization "migrates" from one hardware or software technology to another.

In some cases, this "migration" is from a batch to an on-line environment, in others to an integrated environment, and in still others to a micro- or minicomputer environment. This "migration" usually involves new file organizations, new data and data structures, and sometimes new hardware and implementation software.

The newness of the technology requires that the existing hardware and/or software base be replaced. In some cases the business environment has changed so substantially, either for competitive or internal restructuring reasons, that the old systems can no longer service the business. The internal restructuring may have resulted from a shift from a centralized to a decentralized environment, the addition of major new lines of business, or a change in orientation of the firm, such as from an account to a customer orientation, or from a sales force-based organization to a direct-mail-marketing organization. In some more recent cases, this restructuring results from the firm's acquisition of other businesses or from the acquisition of the firm by another business. In all cases, the internal automated systems need to be redesigned and redeveloped to support the new environment.

Any organization can be viewed as a multilevel entity with each level representing a different level of control. In addition, each successively lower level has different data requirements 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, they are viewed as 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 [5]. He discusses the organizational management as if it were arranged in a pyramid (see Figure 2.1). The pyramid is divided into three horizontal sections. From top to bottom these sections are labeled, respectively,

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. Theirs 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, and is primarily oriented toward functions rather than toward processes and tasks.

Strategic data are highly concentrated and usually contain 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 are financial in nature and relate directly to the critical balance sheets, and profit and loss figures of the firm. Strategic data are 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.

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 toward functions and processes.

Managerial data are more fluid and limited than those of the operational level since the people at that level are more dependent on information than they are on data. Managerial and administrative data are almost solely derived from internal sources and reflect the operating health of the firm.

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

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 one of the following.

It is the operational level which is the predominant recipient of data introduced 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 tasks, rather than toward functions.

The various operational functions interact, passing data from one to the other; in the process files are built in support of the overall activity of the business and the informational needs of management. The data requirements of the operational level units, while extensive, rarely change since they are contingent upon fixed sources of input.

Another aid to understanding the various types of data processing projects, and thus the various types of environments in which systems analysis 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 Richard Nolan's model of EDP growth stages.

Cyrus F. Gibson and Richard L. Nolan [6] outlined a cycle of corporate data processing evolution. These stages were labeled initiation, expansion, formalization, and maturity. 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 developmental effectiveness (see Figure 2.2).

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; however, bear in mind that these stages can be passed through multiple times.

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, it progresses rather quickly to the second stage, which is called "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, attempts to apply it to everything in sight or 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 it has spawned a monster. The data processing expenses rise more quickly than most other corporate expenses, and management begins to realize that it has no control over the data processing area. In addition it begins 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.

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 that 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, migration to the 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.

The maturity phase is characterized by a corporate recognition of the need for integrated systems and for 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 database environment and the need 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.

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 that the firm will be at different stages in the model at the same time.

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 provides 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 firm-wide, 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 (see Figure 2.3). 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 the introduction of each new 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 is 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.

Thus, we must couple appropriate methodology with technology in order to properly process and store data. Unless this is accomplished, the processed, edited, organized data will still have marginal or narrow usefulness to large segments of the firm outside the specific area of origination.

Organizations need to record data for both short- and long-term use. The systematic, short-term, accurate recording of data is basic to the successful daily operation and long-term survival of the organization. By providing a permanent record of the corporations activities, the archiving of data sustains the auditing, statistical, forecasting, and control functions.

Usually, this data is stored in a decentralized manner which reflects the functional departmentalization of the organization. Payroll records, for instance, are normally stored in the payroll or accounting department and personnel records in the personnel department. Some records, however, are stored in more than one functional area. Copies of purchase orders, for example, might be kept in purchasing, inventory, receiving, quality control, accounting, and in the originating department itself. As each area performs its part of the processing, the base data are modified. Rarely, if ever, are all copies of the base data changed in unison; thus, to gain a complete picture of a particular transaction, one must look into the files of each area that had access to, or processed, the purchase order in some way. As a result (and to the detriment of the firm), the data in each processing area are incomplete or, worse, inaccurate. At best, it is suspect. In any case, only those areas that have copies can use the data or their part of it. Thus, the view management has of the data it receives is biased toward the area from which it was obtained. That is to say, only the data germane to a given area can be expected from that area.

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

These functional roles can be identified as operational and informational (see Figure 2.4). From the analyst'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 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 are used to facilitate and control the day-today business of the firm. It is at this level that the bulk of the corporate portfolio of systems is 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 is 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, time frames, and specific definitions of their originating organizational units.

Operational systems are those systems which support those at the lowest level of the pyramid. They are characterized as being transaction based and cyclically processed; they are usually batch oriented and operated 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 are 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 are projective in nature in that they project future trends from past events. The data in informational systems tend to be less precise and more statistically oriented. That is, these systems 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. They can be classified as administrative systems. In this category fall those systems which are usually overhead, and support the organization 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 managerial planning 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:

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

For the purposes of our discussion, it is immaterial whether 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 analysis is the same; what differs is the application to be analyzed.

The personal computer revolution added additional complexity to the firm computing environment by developing a three tiered computing architecture to replace the previous two tiered environment.

These tiers are the Corporate, the Departmental and the Personal. Although they appear to correspond to the tiers of the management pyramid, in reality there is little, if any, relationship. There is also no correlation between the type of system and the platform it resides on.

Platform is the term used to distinguish between the different classes or sizes of computing machinery –mainframe, minicomputer and microcomputer (or personal computer or workstation), between the various operating systems on each machine, and in some cases between stand-alone machines and networked machines.

In some cases the term platform is used to distinguish between one combination of machine and software and some other combination.

Throughout this book we will use the qualified term hardware platform to represent differences in computing machinery and the qualified term software platform to represent differences in operating systems on a given class of machinery.

This level consists those information and business systems which are designed for use by all areas of the corporation. These systems are normally characterized by:

This level consists of information and business systems which are designed for use by a specific area or areas of the corporation. These systems are normally characterized by:

This level consists of information and business systems which are designed for use by a single individual. These systems are normally characterized by:

[1] Trademark of the Apple Computer Corporation

[2]Trademark of the Apple Computer Corporation

[3]Trademark of the IBM Corporation

[4]Trademarks of the Intel Corporation

[5] Anthony, Robert "Planning and Control Systems: A Framework for Analysis." Harvard Business Review, 1965

[6] Gibson, Cyrus F. and Nolan, Richard L, "Managing the Four Stages of EDP Growth," Harvard Business Review ,1974

Contact Martin Modell Table of Contents

A Professional's Guide to Systems Analysis, Second Edition
Written by Martin E. Modell
Copyright © 2007 Martin E. Modell
All rights reserved. Printed in the United States of America. Except as permitted under United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a data base or retrieval system, without the prior written permission of the author.