System Design Backwards

"If an information requirement is stated improperly to begin with, then everything else that follows will be incorrect."
- Bryce's Law

One of the biggest challenges in any system design effort is to produce a viable design that is well thought-out with all of the pieces and parts working harmoniously together. If something is forgotten, regardless of its seeming insignificance, it will undoubtedly cause costly problems later on. The task, therefore, is to produce a design that is demonstratively correct.

Fortunately, the answer is actually quite simple and something we have long advocated in our "PRIDE"-Information Systems Engineering Methodology (ISEM); namely, work backwards during system design.

The primary objective of Systems Design is to define the system in terms of:

• WHAT business processes (sub-systems) make up the system.
  

   



• WHEN these processes need to occur (timing).
  

   



• WHAT data will be required for processing.
  

   



• WHAT inputs and outputs will be used during processing.

The emphasis in Phase 2 (System Design) of "PRIDE"-ISEM is to design a system that correctly satisfies information requirements. To do so, it works backwards, to wit:

• From Information Requirements back to all of the data elements needed to produce it.
  

   



• From the receiver of the Information back to the originators of the data.
  

   



• From outputs back to inputs.

Later, during Phases 3 and 4, the process is reversed and design moves forward as opposed to backwards. Here, the design expresses how the data will be physically processed in order to produce information.

• From the source of the data to the destination of the information.
  

   



• From Inputs to Outputs.
  

   



• From the start of the business process to the end.

This backwards approach to design in Phase 2 is based upon the "PRIDE" concept of Information Driven Design whereby information requirements are precisely designed in terms of the business actions/decisions to be supported, when they have to be made (timing), and the data elements needed to produce the information. Timing is an essential part of this approach because information is a perishable commodity. It only has value during a particular point in time. Users require information to support actions and decisions on a routine and timely basis, either instantaneously, daily, weekly, monthly, etc. All information systems operate routinely based on timing. Since this is true, why not make use of this timing consideration during system design as opposed to discovering it after the fact?

Timing will ultimately dictate how data will be collected and stored (availability requirements) and how data will be accessed to produce information. This approach implies that there are substantial differences between information and data, one of which is that data is the raw material used to produce information.

The supporting data must be defined in such a way that we can easily understand what primary data must be supplied by a User and what generated data must be calculated internal to the system. Data relationships can be extensive. For example, take NET-PAY which may be based on a complicated calculation:

NET-PAY = GROSS-PAY - FICA - CITY-TAX - UNION-DUES - (etc.)

The data elements used in the formula may also be calculated, such as:

GROSS-PAY = HOURS-WORKED X PAY-RATE

What this means is that in order to arrive at the correct value for NET-PAY, we must be able to reach all of the primary values, such as HOURS-WORKED and PAY-RATE, in a TIMELY manner. If we cannot do this, NET-PAY will be incorrect.

Defining these data dependencies has typically defaulted to the programmer who redefines the relationships with each application and buries it in the source code making maintenance and change difficult.

The timing and data specifications resulting from the information requirements will ultimately dictate the type of system to be created. For example, if information is required upon request and within a matter of seconds, this will probably result in an "interactive" type of process. However, if the information is required upon request but within a few hours, this will probably result in "batch" type processing (it may even be processable manually). These specifications are the basic building blocks for all systems and software design.

Information Driven Design organizes all of the data required to support the application, into logical files (objects). As such, it synchronizes the data base with the application.

Perhaps the biggest benefits derived from Information Driven Design is that it forces the Systems Analyst to consider all of the required data and simplifies processing. It also emphasizes the need for shring data. As a design develops, consideration is given to using data from other applications. After all, why create new files and processes if they already exist?

With the logical system design defined, consideration is then given to the most appropriate way to physically process the data, either manually or computer assisted. Here is where Functional Decomposition and Data Driven design techniques excel. For software engineering, the characteristics of the data, its structures and what functions the computer must perform (e.g., create, update and reference) dictates the required programs. These specifications are the result of Information Driven Design. The physical characteristics of the data defines its validity. The data structures denote input, file and output relationships. The functional requirements determine how the data will be read and written in a program, whether sequentially, iteratively or selectively. In other words, Functional Decomposition and Data Driven Design will dictate physically "WHO" and "HOW" the data will be processed.

It is very important to understand that Phase 2 "System Design" represents the logical design phase. The design produced can be physically implemented many different ways. The ensuing phases therefore, Phases 3 and 4, represent the physical design phases which details the best way to implement the business process (sub-system).

This approach to system design, although effective, is predicated on well defined Information Requirements. If they are poorly or superficially defined, than everything that follows will be wrong. Garbage in - garbage out. But if the information requirements are well thought-out, the chances of producing a good system design are not just likely, it is highly probable.

For more information on "PRIDE"-ISEM's Phase 2 "System Design" see:
http://www.phmainstreet.com/mba/pride/is20.htm

If you would like to discuss this with me in more depth, please do not hesitate to send me an e-mail.