Information Driven Design

BRYCE ON SYSTEMS

- a return to basics in system design.

PREFACE: A few months ago I made a promise to some of my techie friends I would describe the concept of "Information Driven Design" as used in our "PRIDE" Methodology for system design. This concept originated in the original version of our product in 1971 and was successfully used by our customers to build enterprise-wide systems. The reason I bring this up is that it appears to me people still have trouble defining information requirements and, as such, they are at a loss as to how to build total systems. Thereby, they are content building either a single business process or a program. Therefore, here is the conceptual foundation for all system design...

Information Driven Design begins with a simple concept:

INFORMATION = DATA + PROCESSING

Information is the intelligence gained from the processing and/or analysis of data. This means information is a product based on two variables, data and processing. We do not store information, we produce it based on these variables. Whereas data represents "what" is to be processed, processing (or systems) represents "how" it is to be processed, using formulas, algorithms or calculations. An invalid calculation is just as misleading as invalid data; both will produce erroneous information. From this perspective, both data and processing must be carefully designed and controlled as resources for producing information, and as resources, they can be shared and reused to produce information for other uses. In this way they should be identified and controlled like any other resource, hence the need for "Information Resource Management," a concept very much akin to "Materials Resource Planning" as found in manufacturing.

Since the intent of an information system is to produce information, the more we understand about information requirements, the better we can accommodate its implementation. This is why we refer to this concept as "Information Driven Design," a system design derived from the inherent properties of information.

Information requirements should be defined in such a way as to explain the Business Functions they serve, their Business Purpose, the Actions and/or Business Decisions they support, and the benefits derived from the use of the information. In this way, it a textual justification for the information. Now let's take it further...

There are three types of information:

Policy Information - To implement executive decisions.

Control Information - To monitor policy and manage operations.

Operational Information - To implement the routine day-to-day activities of the business.

Information is a dynamic and perishable commodity. It only has value at the time it is required. Whereas the definition of data is constant, information requirements can change for a variety of reasons, such as politics, government, competition, economics, people, etc. Ultimately, corporate survival depends on providing users with accurate and timely information.

In order to properly specify information requirements, it is not sufficient to merely determine what data is required to support it; it is also necessary to define the timing of the information (to support the actions and/or decisions). This timing will ultimately dictate how data will be collected, stored, and retrieved to produce information.

Failure to recognize timing as an important element of design will result in the data base being out of synchronization with the system. For example, consider a situation where data is collected on a routine weekly basis (just once a week). Daily analysis of the data will be inappropriate since the data will remain constant until the next weekly update. To resolve the conflict, data collection should be changed to at least a daily basis.

All information systems operate in time frames, such as instantaneous, daily, weekly, monthly, quarterly, annually, etc. If this is true, why not make use of this timing consideration during system design as opposed to discovering it afterwards while trying to correct the data base design?

There are three aspects to timing: frequency, offset and response time.

FREQUENCY defines "how often" the information is required, e.g., upon request, hourly, four times daily, once a week, twice monthly, quarterly, semi-annually, etc.

OFFSET defines when processing should begin, such as the beginning of the week, end of the month, etc. However, if the frequency is 'upon request,' then there is no scheduled offset; this is because the information can be requested at any point in time.

RESPONSE TIME defines how fast the information must be delivered to the user. For example, five seconds, two hours, one day, etc. This should not be confused with computer 'response time' or 'throughput' which is concerned with machine speed. Rather, response time is concerned with the maximum amount of time that will transpire between the request and delivery of the information, so the user can make the necessary decisions and/or take action. This implies that if the response time is exceeded, it is no longer information, only historical data.

Timing ultimately defines data availability and accessibility issues. Availability specifies, "Is the data there when I need it?" (a function of Input/Data Collection). And Accessibility specifies, "Can I get to the data when I need it?" (a function of Output/Information Retrieval). Understand this, you cannot access data (retrieve information) if it has not been made available (collected) in a timely manner.

Data comes in two forms, Primary and Generated. Primary data is what is collected and inputted into the system. Generated data represents calculations derived from primary values. To illustrate, suppose we need the generated data element, "Net Pay," as used in payroll. It would be necessary to define all of the other data dependencies, e.g.;

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

Other data elements used in the formula may also be generated, 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 program source code, making maintenance and change considerably difficult. Consequently, It is not unusual to find "Net Pay" defined differently in multiple applications throughout a company.

The timing nuances of the Information Requirements ultimately dictate the various sub-systems of the system (the business processes). Some will be used to exclusively input data (aka "maintenance"), some to produce information (aka "queries"), and some for both maintenance and query purposes.

The basic operations that can be performed on data include "create," "update" and "reference" ("delete" is the opposite of "create"). In programming terminology, a "create" represents a "write," an "update" represents a "read/write," and a "reference" represents a "read" only.

The timing and data specifications resulting from the information requirements will ultimately dictate the type of sub-systems to be created. For example, if information is needed 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.

Producing an information system design that correctly satisfies requirements is a vital part of Information Driven Design. If the information requirements are correct, the resulting system design will be correct. However, if the information requirements are wrong or incomplete, the resulting system design will be incorrect. With this approach, the emphasis is on business analysis as opposed to technical detail.

This approach to system design ultimately recognizes, "No amount of elegant programming or technology will solve a problem if it is not defined or understood correctly."

Keep the Faith!

MB - "Est superbia"

Note: All trademarks both marked and unmarked belong to their respective companies.

Author: Tim Brice, Managing Director, M&JB Investment Company

Tim Bryce is a writer and the Managing Director of M&JB Investment Company (M&JB) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at [email protected]

Copyright © 2016 by Tim Bryce. All rights reserved.