What is System Design?

Contact Martin Modell   Table of Contents


Any book on systems design is in reality about change - change in a business context. Change from what is today, to what we would like to have tomorrow. This book is about making changes which affect how businesses operate. It is about how to determine:

  1. why change is needed
  2. what to change
  3. where to change
  4. when to change, and
  5. the correctness of the changes.

Specifically we will be addressing the development of specifications for the changes to be made, and the planning of the changes. We will be discussing the mechanisms for describing those changes, the blueprints, schematics, diagrams, and specifications for those changes

A Definition

All things in nature are in a continuous state of change. These changes may be evolutionary in that they occur so gradually that the effects are almost imperceptible, or they may be revolutionary in that the transformations or alterations occur almost overnight.

In most cases change is uncontrolled, uncontrollable, and unplanned. Change happens. In many cases there is little we can do to prevent change from happening. In other words, change is haphazard and random.

All organizations, whether they are publicly or privately owned, profit making or not-for-profit, manufacturing or service oriented, large or small, centralized or decentralized, change over time.

These organizational changes can be structural, altering functional responsibilities or authorities, altering processing responsibilities or authorities or altering reporting lines.

The changes can be in the lines of business, in the products and/or services which the company offers to its customers or clients.

The changes can be in the manner in which those products are produced or assembled, in the manner in which they are sold, or in the manner in which they are distributed. The changes can be in the manner in which the services are performed, or when, where or how they are performed.

The changes can be in who the products are designed for, who they are sold to, what function they are sold for. The changes can be due to changes made by competitors, by legislators, or by other governmental, industry or administrative regulators. The changes can be expansive allowing more freedom of action or restrictive.

The changes can be fundamental to the company's existence, such as the decision to become publicly owned, the decision to buy up outstanding stock and become privately owned, or the firm can buy, be bought by, or merge with one or more other firms. The firm can suddenly become very much larger, or very much smaller.

In some cases change may result from a change in management, or a change in a single manager (due to promotion, resignation or termination). The change may be due to nothing more profound than the manager taking some courses in how to manage.

The problem of change and its effects on the firm becomes even more complicated when we consider that some changes are initiated not because the business changed, but because the management of the business determined that a new way of doing things would or could be more efficient.

In some cases, new technology becomes the agent of change. This new technology is acquired due to the availability of new tools which are deemed to be more cost effective that those currently being used, or to replace existing tools which are wearing out or becoming obsolete.

In all cases however, business change, regardless of how it was initiated, results in a change in behavior or action on the part of the firm. These changes may be formalized or not, but they always are reflected differences in "how things are done".

"How things are done" - the methods and procedures, the systems, by which these organizations conduct their business must change as well to remain synchronized with the changed environment.

The easiest procedures to change are those which are accomplished manually, are relatively simple in nature, or are relatively independent of other procedures. These methods and procedures can change rapidly in response to the changing environment. Many of these procedural alterations or repairs are accomplished by adding additional steps to existing procedures, or changing steps in existing ones. These changes keep the procedures operative and allow business to continue to function and remain relatively current in the aftermath of change.

Other procedures, especially the more inflexible, or complex procedures, which includes most automated procedures, do not, or cannot change easily enough or quickly enough to remain current.

Even when attempts are made to change these procedures, the time needed to think them through and then to affect those changes is such that by the time the change to the procedure is made, the company has changed again and the changed procedure needs to be changed.

Because of the relatively short periods of time within which the necessary procedural changes must be made, the firm usually ends up making repairs, patching the procedure, rather than making the complete overhauls which are called for. While these "patches" are usually designed to work on a temporary basis, they sometimes last for years. Over time, the patches get patched, until the resulting procedure is unrecognizable when compared to the original specifications.

The time constraints involved in making the changes also limit the amount of documentation which is produced describing these changes. Usually this documentation amounts to no more than a memo stating how things will be done in the future, a slip of paper placed in the procedures book, or a marginal note in the same book.

Because most business changes are unplanned, the resulting procedural changes are also unplanned. Because the changes occur in a haphazard and random manner, many procedural changes occur in the same manner.

Over the course of time, as change is made upon change, or just as important, as the procedural changes lag behind the business changes, the procedures become more out of phase with reality. There comes a point where the haphazard nature of those changes already made, plus the difficulty of determining where and how to make complex pending changes, requires that the firm replace the entire set of procedures to effect a more planned and orderly environment. Figure 1-1 illustrates the effect on system capability and business needs when future requirements are and are not considered.

We have used the term procedure in the preceding discussion, and we not system. But this book is about system design. Are procedures different from systems? Are they related? We will begin with a standard dictionary style of definitions of both terms from which we will begin to formulate our answers.

A Definition

A Definition

Before we can determine whether they are the same or not we need more information. We have used other terms in these definitions which themselves need definition.

A Definition

A Definition

A Definition

What results from these definitions is a hierarchy of concepts:

Thus to change a business system requires the changing of the business procedures which comprise it, such that all the procedures (and thus the tasks, activities and processes which they govern) operate as an orderly, harmonious whole.

We don't change systems, we change procedures such that they all work together. In other words, we must change each procedure, within a master framework which includes all of the related procedures. That leads us to our next question - do we change systems from the top down, or from the bottom up? That is do we change the framework first and then the individual procedures, or do we change the individual procedures and then construct the framework?

That question would appear to be similar to the one which asks which came first the chicken or the egg? We will come back to this question later, for in a way it is central to the theme of this book.

What is system design?

All of the above discussion is a way of leading into the primary questions. What is system design? How does system design relate to system analysis? Is systems design different from systems analysis, and if so how do they differ? If they are different what are the boundaries between the two?

To answer these questions we must again resort to definitions of terms. What is a system? What is analysis? What is design? What is a system design?

A definition

A Definition

A Definition

A Definition

A Definition

The process of system design is the process of creating a state or condition of harmonious, orderly interaction of interrelated interdependent procedures each of which determines how an individual process, activity or task is performed."

We have one other term which bears definition as well - framework.

A Definition

Putting all of the above concepts together we have the answer to the what and why of system design. A business system is intended to be an orderly, harmonious group of interacting, interrelated and interdependent procedural components. Over time, internal and external business changes cause gradual, individual procedural changes such that the component parts of the system either no longer interact harmoniously or those individual components can no longer be changed except with great difficulty. When that point is reached the system itself, and all its component parts must be taken apart, modified such that all the parts work harmoniously and put back together.

During the process of modification, the disorderly, disharmonious, independently acting procedures are changed. At this time new procedures for new processes, activities and tasks are developed and can be added into the revised system.

Systems Analysis versus Systems Design

If systems analysis is the process of separating a system into its component parts (individual procedures) for study, examination, and repair or replacement, then system design is the process of taking those component parts after examining, studying and making changes to them, and putting them back together into a harmoniously interacting complex whole. This life cycle of analysis, examination and study and design is illustrated in figure 1-2.

One can see from the above that there are in fact substantially differences between systems analysis and system design. In fact it could be argued that we are not talking about two processes, but in fact three processes - analysis, examination and study, and design.

Systems analysis works with tangible things and activities and how they act and interact today. Those things and activities can be observed, examined and described, and that description can be compared to the original for verification and validation. The description either conforms to reality or it does not. The analysis is correct to the extent that it is complete and to the extent that it compares accurately to the original. Systems analysis works in the present, and to an extent in the past. It works with, and attempts to understand and describe what is.

Examination and study works with the results of analysis, looking for ways to improve. It attempts to identify the problems with what is, and the opportunities for change. It also attempts to document the needs and requirements for what should be changed or added.

Systems design on the other hand, works in the future. It is a plan for what activities should be performed in the future, how they should be performed (the procedures) and what resources are needed for the performance of those activities. Most importantly, it is the development of a framework within which those activities must be performed. That framework is what provides order and harmony to the whole. The design may be taken to any level of detail necessary, or possible to fully describe what must changes be made and how, when and where they must be made.

Obviously, the lines between systems analysis and systems design are blurry at best. Most authors have treated the two topics as one, and to the extent that design is a continuation of the analysis process, it is correct to do so. However it must be stressed that there are in fact, three processes.

These processes are not separable. Analysis, examination and study are performed so that we can make modifications and come up with a new design. The reason for a new design is because we need to make modifications, and the scope and extent of those modifications were based upon analysis, examination and study. We cannot do any one without the other two, and in fact have little if any reason to do any one without the other two.

Most of those authors have presented systems analysis and system design in the form of a methodology - a fixed set of processes, activities and tasks which when accomplished will produce a design. To the extent that analysis and design are two ends of the same process they were also correct in developing a common methodology.

Design and analysis differ in distinct ways. First, their goals. The goal of analysis is to break down into component parts for examination. The goal of design is to construct from component parts.

System Design Components

Given the above what are the components of a system design? A system design consists of:

  1. A framework which specifies the processes activities and tasks which need to be performed, and how those processes activities and tasks are related and interdependent. It also specifies the interprocess, interactivity and intertask rules to which all processes, activities and tasks must conform in order to operate in an orderly and harmonious manner
  2. The individual procedures which specify in detail how each process, activity and task is to be performed and how each is to interact with all other related and interdependent processes, activities and tasks.
  3. The physical, personnel, monetary and data (forms, reports and reference materials) resources which are used by each procedure. The limitations or constraints in terms of time, personnel, budgets, data and standards upon each procedure.

Having described the reasons for embarking upon the process of system design and the three components of a system design, we can return to the series of statements and questions posed a few pages back.


We don't change systems, we change procedures such that they all work together. In other words, we must change each procedure, within a master framework which includes all of the related procedures.


Do we change systems from the top down, or from the bottom up? Do we change the framework first and then the individual procedures, or do we change the individual procedures and then construct the framework?

First let us begin by stating what should be obvious - that the process of designing a system is iterative in nature. That means that it is not accomplished as a result of one activity - one series of steps with a defined beginning and end - but as the concurrent, repetitive performance of a number of separate, but interrelated and interdependent activities.

We also believe that even within the framework of a given user application, there are different kinds of systems, and different kinds of design environments. Each type of system and each type of systems environment has a different set of considerations and thus no one design approach will suffice for all.

Systems versus Applications

There are two terms which are used somewhat interchangeably within the data processing community: system and application.

An application is the way in which a specific technology, such as data processing, has been used to solve a specific user business problem. Some examples of applications are: order entry processing, inventory record processing, payroll processing, personnel record keeping, customer statement generation, and accounts receivable or accounts payable processing.

In these examples, data processing technology has been used to support and accomplish a set of use area processing activities. These activities have not been wholly automated, only some of the highly structured, repetitive, well proceduralized, well defined, specific tasks of the data collection, filing, record keeping, calculation, printing and reporting have been taken over by the computer. Many of the other tasks within the same processes remain manual.

A system is the complete framework within which mutually supportive processes, activities and tasks operate. A good system is one in which these processes, activities and tasks operate in a cooperative, harmonious, efficient, orderly, timely and controlled manner. The processes, activities and tasks encompassed by a system may or may not be automated, and if automated may not be completely automated. Using the above definitions as a frame of reference, we will be discussing the design of systems not the design of applications.

At a minimum, a new system design is undertaken for one or more of the following reasons. To enable:

  1. new activities to be performed
  2. existing activities to be performed in a more efficient, cost effective, rapid or timely manner
  3. more iterations of a given activity sequence to occur in a specified period of time
  4. greater management control
  5. more efficient use of company resources
  6. greater cooperation between the various activities which have to be performed.
  7. a greater level of integration between system components
  8. the use of new technology or the replacement of obsolete technology.
  9. a faster response to future changes
Contact Martin Modell   Table of Contents

Data Directed System Design - A Professional's Guide
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.