Effects of prior automation

Contact Martin Modell   Table of Contents


Although referred to as the system design process, a more appropriate name is system redesign. Normal business change cause procedures and resource usage to change over time. All procedures and resources operate within an existing system which while appearing to be stable and unchanging is in reality undergoing constant gradual change. Moreover, although business systems may appear to be inflexible, they are in fact very informal, flexible, tenuous and limited in nature.

When the number of changes to an individual procedure reach critical mass (that is, new changes can no longer be applied, or the user can no longer function effectively) the individual procedure must be changed. When the number of individual procedures which must be changed reaches a critical mass all the procedures and the framework within which they operate must be changed. When the change encompasses all of the procedures, the resources used by them, and the framework within which they operate, we are changing the system.

One of the reasons which make procedural changes difficult or impossible, is that the system within which they operate is not flexible enough or cannot provide the resources which are needed for their operation. In most cases unless the procedural changes are mostly cosmetic, they must be accompanied by some system modification. That is the system must be redesigned to a certain extent.

Although the effects of gradual procedural change and the need for more extensive procedural change can be tolerated by the firm for relatively long periods of time before critical mass is reached, there is much less tolerance for gradual data change. When data requirements change those changes by and large must be implemented as soon as possible. However, whereas procedural change can be developed and implemented rather quickly and with low impact on the firm, the data change takes time and has a substantial impact on the firm. This is true whether the changes required are for new data or for changes to existing data.

Data change is similar to changes in language, and in fact as we shall describe in later chapters, there is a strong parallel between language and data. Changes in meaning of words can make existing texts obsolete, or meaningless. The lack of the appropriate words to describe something or some event renders communication ineffective. Use of the wrong word can have extremely negative effects in any communication situation.

In very similar ways, and for very similar reasons changes in the meaning, or use of data can render information, or business communication ineffective. As with words, the meaning of data changes over time, often subtly, gradually and unintentionally. While this happens with all data in whatever form it is stored, its effects are most strongly felt when it is computer stored data that changes.

Different redesign environments

There are substantial similarities between all redesign efforts, but there are also substantial differences. These differences are apart from the obvious applications or functional area differences which make payroll different from order entry, and inventory, different from accounts receivable. These differences are those which are due to the effects of prior automation (or the lack of it), and the level and extent to which automation will be used in the redesigned system.

These differences occur most strikingly where data is concerned. Conversion from manual to automated data record keeping, from card media to tape and disk media, and from files stored using basic operating system file storage and access methods to files store and managed by data management software known as data base management systems, or simply as data management systems. There are even differences which occur when data is transferred from one data base management system to another, or when data is allocated between several different data base management systems.

Additional considerations occur when data and processing is moved from the centralized or mainframe environment to the decentralized or distributed environments, and still others are introduced when data and processing are migrated still further to microcomputers (also called personal computers or workstations). Each of these entails different design decisions and requires a different set of criteria to be analyzed when determining where and how data should be collected, maintained and stored.

However these differences not only occur when data storage and processing mechanisms are changed, but also when data philosophy changes (usually based on some new business or competitive need).

Reasons for Initiating a System Design Project

Aside from the need to apply the accumulated backlog of business changes, design projects may be initiated for a variety of other reasons. These reasons may be attributed to:

These reasons reflect the procedural needs. In addition, and in many cases more importantly, there are strong data reasons for initiating such projects. Almost all of any given firm's business procedures have been developed to acquire, maintain or disseminate data, or its derivative - information. The techniques used to analyze and design procedures have been developed and refined over time. These techniques may be data directed or process directed, but all focus on the end product of procedural development. Many of these techniques however, treat data as a by-product, or an afterthought. This is true even of the newer "engineering" based techniques and CASE based techniques.

These approaches to design generate data models because data models are called for and they link, or associate the components of the data model with the process components. In many cases however the data model itself is ignored after that, and there is no methodological or support techniques for developing the data model itself or analyzing it for validity, accuracy or completeness. In fact, many of these approaches begin with a top-down generated data model, and then proceed to compete it from the bottom up by populating it with know data items, or data items suggested or requested by the user participants in the design process.

Regardless of whether the scope and magnitude of the functional, process, activity and procedural changes is fairly narrow or wide reaching in almost all cases the data changes is substantial, or has the potential for being substantial. In some cases, aside from streamlining and updating the procedures of the system, there may be only minor changes to either the data architecture or in additional business processing capability aimed at providing more meaningful or usable data to the firm. Very few of these projects look at data opportunities, or evaluate existing data to determine whether it was correct in the first place. In other words, data in existing files very rarely gets discarded or dropped from the files of the firm.

Aside from the variety of reasons for a project being undertaken, we must also recognize that the technical base differs from project to project. This technical base reflects the differences in current user processing environment technology, the current level of user automation, and current residence on the maturity curve. Because of these differences in current user processing technology and user automation, and because the goals of any system design project normally include

These automation levels can be categorized into three types which reflect both their existing level of technology and the technology of the redesigned system. These categories are:

  1. basic systems - wholly manual
  2. intermediate systems - partially manual and partially automated
  3. mature systems - fully automated

From a design perspective, each of these three automation levels involve 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 system designer must use as a base have substantially different characteristics.

The following is an overview of the design activities in each category of system.

Effects of Prior Automation

The effects of this prior automation on the re-automation design efforts must be fully understood by the design team. This prior automation impacts all forms and documents currently used by the business area users, all automated and supporting manual procedures, and the structure and contents of all data files used by the automated system. The technology used to construct these automated systems, may now be outdated or inefficient, or worse obsolete. Business changes which occurred since these systems were originally developed, may have completed changed the user requirements or business environment which the system was originally designed and developed to support.

The difficulty of changing automated systems is such that it is usually easier to twist and contort the user processing to fit the system that it is to change the system to fit user business processing needs. As the business changes mount, the contortion or twisting in the user area is such that when the tension is released by the initiation of a new design effort, the emergent processing requirements bear little if any resemblance to the system being replaced. Procedural forms, documents, reports, and file contents which were the result of some prior designer's efforts and may no longer reflect the current information or data needs of the firm.

The natural user procedural processing flows themselves may have become unnatural, to the extent that they were modified to reflect the intrusion of less-than-effective automated processing sequences, minor attempts to repair systems which no longer function properly, and the normal contorting of business procedures which occurs when individual task procedures are consolidated to accommodate efficient and integrated automated processing. These automated processing flows may have been structured to accommodate the needs of the then prevalent technology, rather than the needs of the business and as a result the user processing was changed to accommodate the needs of automation.

Each of the individual task procedures both automated and manual, the process flows which have been established to govern and control the procedures, and the documents, transactions and data files all must be re-examined in the light of the current business environment, the current business processing needs and the currently available and usable technology. Because of the combined effects of the changes necessitated by business changes, those necessitated by technology changes, and those which result from the natural pressures to move forward along the maturity curve, increase the levels of integration among the firms processing systems, and the needs of management to have increased access to and availability of business management information (control information, monitoring information, etc.) the most common decision by the design team is to scrape the existing system entirely in favor of a new and more streamlined processing flow, new procedures, new data files, new documents, forms and reports, etc.

These re-automation projects are very difficult, complex and time-consuming, because the replacement systems are almost always larger, more complex, more global (more integrated), more technologically sophisticated, and have more capability than the system or in most cases systems which they replace.

Forms of Re-Automation

Re-automation project activities may take the following forms:

  1. Basic changes - Simple procedural rewrite

    The procedural rewrite is one of the simplest aspects of re-automation. Procedural rewrite does not major framework or architectural changes in the design of the current business system and thus entails very little structural change to the user business processing capability. Procedural rewrite normally results in the exchange of the old version of procedural component with a new version - a component for component substitution.

    Procedural rewrite does not involve change to the inter-procedural processing flows nor does it add to system complexity. It is simply a clean up of the procedural processing within the existing flows usually in a more up-to-date language or with more streamlined logic within the automated procedures themselves. Because the opportunity exist, may of these efforts incorporate those business changes which can be accomplished within the context of the original system structure and with existing system resources.

    In the process of the procedural rewrite, minor changes may be made to existing file structure, data content consistency may be cleaned up, report layouts, screens, and transactions may change to a minor extent, but generally speaking the changes are predominantly cosmetic in nature and as such file and report content, the availability and accessibility of data to management, and system business support capability usually do not increase. There is usually little of any impact on the user area. A procedural rewrite may eliminate processing anomalies ("bugs"), remove unused, obsolete, or outdated code and may add minor new data presentation capability to the system. The emphasis here is on minor.

    Procedural rewrites are usually done for the benefit of, and at the initiation of, the information processing area, specifically for either the 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 perform more efficiently.

  2. More complex changes - procedural enhancement

    Procedural enhancement has may characteristics in common with procedural rewrite. One of the main one being that it usually requires minimal of any framework or architectural changes to the system. Procedural enhancement may result in increased user processing capability, increased user access to existing data files or the introduction of new procedures into the system framework.

    These types of changes require all of the activities which need to be performed at the procedural rewrite level, and additional activities to assess the impact of the proposed changes on an existing system and to make those architectural, framework or other procedural changes (automated and manual support) which are needed to enable the additional or enhanced procedures.

    These procedural enhancement projects, usually leave the majority of the system framework intact. They also leave intact, and usually unchanged, the bulk of the system resources. The framework may be modified slightly to reflect the new or expanded capability of the existing procedural components as well as to accommodate newly added procedural components. Other procedural components may have to be slightly modified to support the added capability and to provide the needed interface capability with the new and revised procedures.

    The requests for procedural enhancement normally originate with the user, although they may originate with the development team itself.

    There are numerous reasons for this level of system modification requests, among them are changes to the business environment, user requested additional capability, correction of erroneous processing, and user requested refinements, or cosmetic changes, to the existing system. In most cases these changes are relatively easy to make (that is easy in relation to a full-blown system redesign project) and incorporate a sufficient level of business changes and new capability. These types of changes are normally sufficient in stable user areas (areas which are not subject to a high degree of change), and can normally be accomplished within a short period of time.

    Of these, the procedural enhancements which which originate from alterations to the business environment are the most difficult to incorporate into an existing system design, followed closely by those which add new processing capability. These implementation difficulties arise because these types of changes not only require new procedural design but also selective modification of the original system design to enable the procedural changes to be made. Procedural enhancement which is necessitated by the need to correct erroneous processing, by the need to add user requested refinements, or other cosmetic changes, usually require little in the way of system design modification.

    The redesign efforts required by business environment changes and additions of new processing capability can be almost as extensive as those which were required in the original systems development even though many system components and large parts of the system framework remain untouched or are only changed in minor ways.

    The most difficult types of procedural enhancements are those which also require changes in underlying structure, format or contents of the system data and reference files or the system database

    Procedural changes which require additions or modifications to portions of the system files or database, may not only effect the the system being changed, but any other system or application which uses the same files or database, and in particular those which use the same data records or data elements.

    In some cases, the desired or needed procedural enhancement will require data which can only be procedurally captured by a different, unrelated, application. The "chain reaction" or "cascading" of changes can increase the scope and impact of the initial request by orders of magnitude. When database technology has been used a a means to achieve system integration, this integration by its nature causes a greater interdependence between what might otherwise be separate systems. The greater the level of integration or interdependence between systems, the greater the potential impact of any change to the integration mechanism.

    These data driven changes, when the files or database must be modified can have major impact. The more extensive the use of the database, the more thorough and painstaking the system modification efforts that are required. Minor changes in format or content definition may require changes in all procedures which use the modified data items. These include data acquisition, data editing and validation, reporting, retrieval or other data access or presentation facilities may be impacted by these data structure, content, or processing logic changes. Although the individual procedural changes may be minor in each case, the cumulative effort to make these changes may severely impact the time needed to effect the changes.

  3. Most complex - complete system redesign and redevelopment

    The complete system redesign and redevelopment project is the most comprehensive and difficult type of re-automation and thus is the most difficult and comprehensive of any of the variants of system design project. It involves:

    • the procedural modifications and redesign of a the "new" development project
    • the additional activities of data file, and database conversion, and
    • reintegration of the newly designed system into the global family of systems under which the firm operates.

    System redesign and redevelopment requires a start from scratch design, which must at the same time acknowledge

    • the presence, capabilities, and limitations of the existing system;
    • the needs and desires of user areas who have lived with an increasingly restrictive system, and who have a increasing backlog of business, cosmetic and ease-of-use changes to be included in the next version of the system;
    • the pressures and lure of newer and more attractive hardware and software technology;
    • and pressures from management to provide more useful and timely information, more service, more flexibility and more accessibility to information, to provide more integrated information, more more monitoring and control capabilities

    A project of this magnitude is usually undertaken when

    • the backlog of pending changes reaches critical mass;
    • when a single radical change has occurred, such as corporate takeover, or the introduction of a new product or product line by either the firm or its competitors;
    • the firm undergoes a radical reorganization, or restructuring, or radical change in senior management. This internal restructuring may have been as a result of a shift from a centralized to a decentralized environment, or as a result of the addition of major new lines of business, or of 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;
    • the capability of the existing system "runs out of steam" - that is, it can no longer process the growing volume of information;
    • the organization's information processing technical staff and management makes a determination to replace the existing hardware and/or software technology base with a newer, more sophisticated, and usually radically different technology base, which is expected to offer increased processing flexibility and capability and which is expected to be easier to change.

    Any single reason may be the trigger for such a redesign effort, but more often than not once started, the project takes on a life of its own. The growing integration of systems brings many users under the same systems "umbrella" and thus there are many interested areas of the firm seeking to incorporate as much of their backlog of business changes into the new system as possible. Given the complexity of the issues which affect such a project, it is not surprising that the size of these types of projects mushroom to tremendous proportions.

Contact Martin Modell   Table of Contents

Data Analysis, Data Modeling and Classification
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.