Understanding Information

"Companies run on information, not data."
- Bryce's Law

INTRODUCTION

I have been doing a lot of reading lately regarding the latest fads in the industry, particularly in the area of "Agile Methodologies," "Business Rules," "Information Architecture," and "Enterprise Architecture." There is a considerable amount of material to wade through. Of interest, I have noticed all stress the importance of requirements and warn of the consequences if they are not defined properly. This sounds nice, but I found them all to be very evasive in terms of describing the
inherent properties of information and how to document them. I guess this shouldn't come as a surprise as the industry for years has been wallowing in how to define information requirements. Many think it is nothing more than a set of data or output specifications; others see it as nothing more than a programming spec. Rarely, does anyone want to take the time to truly understand information requirements and prefer, instead, to get down to the business of programming where they feel more comfortable. It should, therefore, not come as a surprise that requirements definition is left to the interpretation of the individual. Inevitably, this leads to inconsistencies and errors. For something that is supposed to be so critical for success, information requirements definition is too often taken for granted.

Let's see if we can clear this up by describing the characteristics of information and end with a definition. This may all seem very elementary, but the problem of requirements definition is very real. Perhaps a simple description of the properties of information may provide the insight needed to adequately perform this vital task.

CHARACTERISTICS

First, information is not synonymous with data. Data represents the facts and events of a business consisting of primary values (such as "Customer Number," "Unit Price," "Name," etc.) and generated values ("Percent Complete," "Net Profit," "Total Ordered," etc.). By itself, data is meaningless. It is only
when it is put into a specific context, at a specific point of time, and delivered to a specific human-being, does data transform into information. From this perspective, let's consider the fundamental characteristics of information:

A. Information supports actions and/or business decisions.

This is a critical characteristic that is vital to define. If an action and/or business decision cannot be made from the data presented, it is not information, it is just raw data. In this world of application development there is a tendency to produce too much data and not enough information.

During my "PRIDE" classes I usually illustrate this point by describing a "bookmaker" or "bookie" (slang for someone who accepts wagers on sporting events). Among the bookie's actions/decisions include paying off bets, and collecting on
bets. Using a blackboard, I would write down the following scores:

6
5

4
3

I would then ask the students to play the role of a bookie and asked them if what I wrote on the blackboard could support their actions and decisions. Of course they said, No, that they needed more data; to which I wrote down:

New York - 6
Chicago - 5

Cincinnati - 4
Los Angeles - 3

Still not satisfied, they wanted to know what sport I was describing; to which I added:

Sport: Baseball

New York - 6
Chicago - 5

Cincinnati - 4
Los Angeles - 3

Since a city can have more than one team, they also wanted the
team names.

Sport: Baseball

New York Yankees - 6
Chicago White Sox - 5

Cincinnati Reds - 4
Los Angeles Dodgers - 3

They also needed to know who the bettor was, so I added:

Sport: Baseball

New York Yankees - 6
Chicago White Sox - 5

Cincinnati Reds - 4
Los Angeles Dodgers - 3

Bettor:
John Doe - $30 - New York Yankees - Odds: 3:1
123 Main Street, Tel: 123/456-7890

They then said they had the information needed to fulfill their actions or decisions (e.g., they would pay $90 to John Doe for betting on the Yankees).

This example demonstrates two things; first, information is data that is arranged in a specific context, and; second, it is based on the actions and decisions to be supported. This means we must first have a clear understanding of the actions and/or decisions to be supported before we can determine the required data elements (primary or generated). This is an area commonly
overlooked in application development. If we cannot act on it, than it is not information, it is just raw data.

B. Information is a perishable commodity.

Information has value at a specific point in time. This is because we must make certain actions/decisions on a timely basis; e.g., daily, weekly, monthly, quarterly, annually, or upon request. Using our example above, the bookie requires his information daily; having it delivered weekly, monthly, or annually will not
satisfactorily support his actions/decisions. It thereby becomes important to define "when" actions/decisions have to be made.

There are three attributes to timing:

Frequency - specifies how often the actions/decisions have to be made; e.g.,
4D - four times daily
1W - once a week
2Y - semiannually
R - Upon Request (anytime the user wants it)

Offset - specifies when the cycle should begin; e.g.,
8H - on the 8th hour (8:00am)
7D - on the seventh day (end of the week)
Note: There is no scheduled offset when the Frequency is "Upon Request").

Response Time - specifies the maximum amount of time to deliver the information; e.g.,
5S - Five Seconds
1D - One Day
Note: This should not be confused as a measure of machine throughput.

These timing attributes will ultimately influence the design of the system and software. For example, if information is needed "Upon Request" with a five second response time, than in
all likelihood it will be an "interactive" type of application. Conversely, a weekly process with a one hour response time will likely result in a "batch" process (maybe even a manual process).

C. Information is a consumable commodity.

Information is received, acted on, and life moves on. But there is little point in having information if it is not acted upon at the time it is received. It means actions/decisions will not be performed as required.

This brings up a point, information is consumed by human beings, not by machines. True, machines process data but only humans require information. I get into a lot of arguments over this concept. Let me see if I can clarify it. Let's imagine a totally automated company (what I like to call a "company in a closet")
whereby customers interact with a computer through a network connection to place orders for a product or service that can be delivered electronically. The owner of the company is retired and spends most of his time playing golf and checks on his stocks and other investments. I contend the machine is just
processing data and will continue to do so until there is some sort of mechanical malfunction. However, under this scenario there is still a need for information by such people as:

• Customers who want to check prices, product/service availability, terms and conditions, order status, and to report problems.
  
  
• Vendors who offer upgrades or additional support.
  
  
• Government regulators who need to know about sales volumes and taxes.
  
  
• And the owner himself who needs to know about how his "company in a closet" is performing, thereby making decisions regarding modifications to the business.
  

Processing data is one thing, making business decisions and taking actions is something entirely different. Until such time as machines become true freethinking entities, they will only need data, not information.

D. Information is not stored, it is produced.

Information is produced and consumed as required. On the other hand, data can be stored and retrieved as required. We have long touted the concept that:

INFORMATION = DATA + PROCESSING

This simply means there are two basic variables in the production of information; data (the facts to be processed) and the process itself (the logic). Assuming this is correct, if the data remains the same, but we change the processing, then the
information will be changed. Conversely, if the processing remains the same, but we change the data, then the information will also be changed. This means it is important to manage the resources needed to produce information, which is the
premise of Information Resource Management (IRM). If we can control the resources, we can manipulate them accordingly to suit the information needs of the business. Therefore, "Information Management" is a fallacious concept; we are
not truly managing information as much as we are managing the resources needed to produce it.

E. Information changes.

The actions/decisions of the business are greatly influenced by such things as:

• Customers and Vendors
  
• Government/political changes
  
• Economics and competition
  
• Market expansion/contraction
  

As an example, suppose the government decides to impose a new regulation on a company's manufacturing process or institutes a trade embargo on a country the company does business in. Inevitably, this will cause a change in the
actions/decisions of the business, thereby affecting information requirements.

Let's also consider the affect new shipping methods might have on keeping the company competitive. Again, this will undoubtedly affect the company's information requirements.

In a static world, information requirements would not change. The reality is we live in a dynamic world. The more we know about our external influences, the better we can adjust and adapt our information requirements.

F. Information is conveyed through outputs.

Media such as screens, printed reports, and audio/video represents the human interface by which information is transmitted. Hence, the temptation by a lot of developers to
think of outputs as the starting point for specifying information requirements. The business rationale for the information is much more important than physically how it will be delivered. If we do not understand the rationale for the information, we
will inevitably make erroneous conclusions regarding the outputs. Also consider this, there is not necessarily a one-to-one relationship between information requirements and outputs. One information requirement may be implemented by multiple outputs, and one output may be used to satisfy multiple information requirements.

Knowing the relationship between information requirements and outputs, existing screens, reports, etc. provide a convenient road map for documenting requirements. Simply ask the user what the business purpose of the output is and what he/she will do with the information (better yet, ask him/her what would
happen if you took the output away),

A DEFINITION

Okay, now that we understand the characteristics of information, let's try to devise a definition:

Information - the understanding or insight gained from the processing and/or analysis of data. Information is created as a result of the collection, processing and analysis of data in a prescribed manner. Information supports specific business related actions and decisions. The accuracy of information depends on the validity and completeness of the data and the processing logic used.

CONCLUSION

It is true that defining requirements is the Achilles heel of any development project, but a lot of people are vague or have different interpretations of what this means. In the "PRIDE" world, it means supplying the end-users with the necessary intelligence to support the actions/decisions of their end of the business. The more we know about the business, the better we can service it; see:

No. 77 - "Enterprise Decomposition" - May 29, 2006
http://www.phmainstreet.com/mba/ss060529.pdf

Concentrating on output specifications is nice but it doesn't supersede the need for accurately defining information requirements. Frankly, users do not particularly care what physical form outputs come in; it is immaterial to them. All they are interested in is: Do they have the necessary information to support their actions/decisions; is it timely, and is it accurate?

It is fallacious to believe, "Users do not know what they want." They may not know how it physically should look or be delivered, but they most definitely know what they want. You're just not asking the right questions.

For more information on this subject, see:

No. 4 - "Defining Information Requirements" - Dec 27, 2004
http://www.phmainstreet.com/mba/ss041227.pdf

No. 29 - "Using Information Strategically" - June 20, 2005
http://www.phmainstreet.com/mba/ss050620.pdf