"Companies run on information, not data." 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 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 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 6 4 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 Cincinnati - 4 Still not satisfied, they wanted to know what sport I was describing; to which I added: Sport: Baseball New York - 6 Cincinnati - 4 Since a city can have more than one team, they also wanted the Sport: Baseball New York Yankees - 6 Cincinnati Reds - 4 They also needed to know who the bettor was, so I added: Sport: Baseball New York Yankees - 6 Cincinnati Reds - 4 Bettor: 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 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 There are three attributes to timing: Frequency - specifies how often the actions/decisions have to be made; e.g., Offset - specifies when the cycle should begin; e.g., Response Time - specifies the maximum amount of time to deliver the information; e.g., 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 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")
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 E. Information changes. The actions/decisions of the business are greatly influenced by such things as:
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 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 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 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 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 No. 29 - "Using Information Strategically" - June 20, 2005 |
Technology | ||||||||||||||||||||||||||||||||||||||||||
|
|