From: John Conover <john@email.johncon.com>

Subject: Re: IT uses

Date: Tue, 14 Sep 1993 01:52:40 -0700 (PDT)

John Conover writes: > The previous applications involved coordinating project management > issues and execution that cross organizational boundaries. The > concepts outlined are equally applicable to service organizations, > where "customer satisfaction" (whoever the customer may be) is an > important objective. The previous applications offered a "how to" "cook book" approach to the integration of IT into the organizational decision making process. A good question should be addressed, at this time, as to why one would want to do so. To answer this question, I will offer a rather pompous analytical derivation, and then discuss the conclusions, relating the perspective to a typical organization, in (hopefully) a way that conceptual conclusions can be drawn as to the applicability of IT to a specific environment. The specific environment that will be addressed is the electronic systems design environment, since it is a straight forward procedure to evaluate the "complexity" (ie., the amount) of intellectual work that has to be accomplished to complete a design project. As a side bar for the un-initiated, a "register" is an electronic memory element that contains exactly 1 "bit" of information-like a RAM memory element in a personal computer, or a data flip flop in an IC. A "bit" is the basic unit measure of electronic information. In most contemporary digital electronic systems, each "bit" has two mutually exclusive "states," ie., it can be in "state" 1, or "state" 0, (representing "true" and "false," respectively) but never both at the same time, and nothing in between. So one "bit" of information can contain two "states." Two "bits" of information can contain four "states," since each of the first "bit's" two "states" can be associated with each of the second "bit's" two "states," and so on. Some Theory: Consider an electronic system. Let B = The number of registers (bits) in the system. Let S = The number of states in the system. Let I = The information in the system, (ie., Hartley Information.) Then from Information Theory: B = ln (S) / ln (2) = I. Or alternately (by solving for S): S = e^(B * ln (2)) = e^(I * ln (2)). Therefore, the number of states that the electronic system can assume is exponential on the number of registers (bits) in the system. Again, as a side bar for the un-initiated, you can understand the essence of the last equation by observing the following table that relates the number of bits in a system to the number of states that the system can have: BITS STATES 0 0 1 2 2 4 3 8 4 16 5 32 6 64 It is a key concept that the number of states doubles every time the number of bits is increased by one-that is all that the last equation says. Now the question can be formulated: Does the engineering resources required to design a system grow with the number of registers (bits) in the system, or the number of states in the system? Some Discussion: Obviously, a 4 bit counter is more difficult to design that a 4 bit data latch, because we have the 16 state transitions to consider in the counter. Consider 4 data latches. If the latches operate autonomously (as in latching data on a buss,) adding a 5'th latch would take about 25% more design resources, if the latches were designed individually, (ie., the design resources would be linear on "complexity.") But, if the latches were not operated autonomously (as in a counter, where the next state of the latches is determined by the current state of the latches,) and we are required to analyze all possible state transitions (in addition to designing the latches,) then adding a 5'th latch would take 100% more design resources since we have 32 state transitions to consider instead of 16 (ie., the design resources would be exponential on "complexity.") I chose the electronic systems design environment as an example, because it is well documented, and has been the subject of scrutiny of many studies. (The studies, in general, support the above theory.) The next obvious question is: does the same thing happen in other organizations? To answer the question, we re-phrase the above theoretical analysis. Some More Theory: Consider a memo based administrative system-each memo is assumed to contain subject matter on only one subject, and this subject matter can be about only one of the two issues that the organization is addressing. (I realize that this is an oversimplification of a how a real organization works. However, it should be enlightening to consider that, even in such a simple model, the resources required for the organization to operate can be exponential on the number of memos in the administrative system-as opposed to linear, which is the intuitive deduction.) Let B = The number of active memos in the administrative system. Let S = The number of states in the administrative system. (If you want to conceptualize this, assume that the administrative system is in one state, and we then add one memo to the system-then certainly the situation has changed, ie., the system is in a different state.) Let I = The information in the administrative system. Then from Information Theory: B = ln (S) / ln (2) = I. Or alternately (by solving for S): S = e^(B * ln (2)) = e^(I * ln (2)). Therefore, the number of states that the memo based administrative system can assume is exponential on the number of active memos in the system. So, we can see that, apparently, the same thing that happens in electronic systems design organizations, also, can happen in other organizations as well. The original question was: Does the engineering resources required to design a system grow with the number of registers (bits) in the system, or the number of states in the system? Or to re-phrase the question: Does the engineering resources required to design an electronic system grow exponentially on the "complexity" of the design? The answer is, no. Not necessarily. This is the fundamental premise of information theory. Information theory states that although the number of states in the electronic systems grows exponentially on the number of registers in the system, there exists a methodology that will handle the situation with resources that are linear on the number of registers in the system, and not the number of states. I will return to these "information theoretic concepts," but first I would like to explore the way that the electronic systems design organizations approached these issues. In reality, electronic systems design organizations do not achieve the theoretical lower limit of linear resources on the number of registers in the system. The best come close. The not so good are closer to exponential resources on the number of registers in the system. What the electronic systems design organizations do is to automate the design process using "Finite State Machine" (FSM) transition diagrams (perhaps, among other things.) Then using Boolean algebra, the design process can be made linear on the number of registers in the system-at least in principle. (If you are a designer, try to imagine the difficulty of designing a complex digital electronic system without these two "tools" or concepts.) It is an important key concept that the way that the issues of complexity are addressed is by automation, (that is why it is called Design Automation, or DA for short.) It is an equally important concept that the design automation did not automate the design, per say, but automated the design process. It is a key subtle difference. As an unrelated side bar, the key question to be asked when specifying or purchasing design automation software is "does it automate design or does it automate the design process?" If the design is complex, then the answer had, obviously, better be the latter. To this point, we have determined that information theory states that a project can be completed with linear resources on the project's complexity (if you know how to do it,) and the best organizations come close to this limit. The not so good are closer to exponential resources on the project's complexity (because they don't know how to do it.) The question is how to avoid the latter. It is obviously a question of "know how," which was termed "knowledge" and/or "capability" in the previous applications. The important key point is that this is an intellectual activity. This intellectual activity requires knowledge of the organization's dynamic or strategic "agenda," so that managers can influence changes, as appropriate. As previously described, the way that we do this is to establish a system that essentially automates the documentation of the "work flow" through the organization. (Or more correctly, in an idealized concept, it automates the "work flow" process.) There is a problem, though. It would probably be reasonable to assume that an organization that is requiring exponential resources on complexity to accomplish its agenda, would also generate information that is exponential on this complexity. That is the inherent advantage of the system described in the previous applications. It exhibits linear characteristics where information is increasing at an exponential rate. I will illustrate how, with the child's game of "20 questions." This will explain why "context framed searches" of the organization's "work flow" documentation (ie., email) are an effective alternative in this situation. In the classic "20 questions" game, (which has kept countless children occupied on long journeys,) the parent would say "I'm thinking of something, you have 20 questions that you can ask me to find out what it is." The child would then possibly reply, "is it in the car?" The parent would answer appropriately. Then the child would narrow down the search with another question, and so on. This kind of "search for an answer" schema is a very powerful "tool." The child's best strategy is to "frame" the questions such that half of the possibilities are eliminated with each question. Technically, this is what is known in computer jargon as a "binary search," (because you are always dividing the possible answers in half with each question-or alternatively, twice the number of possible answers can be handled by adding only one more question.) It is also a schema that can be readily automated by computing machinery. To be more precise about it, with each question that the child asks, more "context" is gained about what the parent is thinking about. In the above applications, this is what was called "context framework," or to quote from one of the applications outlined above: "The system differs slightly in that the original requests and responses concerning project status are archived in a manner that they can be retrieved, electronically, within a "context framework," in an expedient fashion (perhaps by upper management, or the managers of other related cross-functional departments who have a vested interest in the status of the project.)" It is an important key concept, that as the amount of information in the archive doubles, you have to increase the number of questions that are asked by only one, (ie., as the amount of information grows exponentially, the number of questions that need to be asked to arrive at a specific document/conclusion grows linearly.) Note that the key is being to be able to formulate a "context framework." Or to put it simply, the question is "what question do I ask?" Or again to quote: "Additionally, and this is another key point, if an issue comes up in the project schedules, (slippage, etc.) a manager can formulate another "context search" for an additional retrieval, that addresses the specific issues in question from the project status reports." The formal definition for this process is "relevance feedback," which is an iterated search technique (similar to the child's strategy, above.) There are several methodologies to do this, one is to query the archive for the count of certain words or phrases, and start with the most likely document, ie., the one with the most occurrences of the word or phrase. Another is what is called "proximity search," which will search for phrases and words that are "close" together in specific documents. Still another, is to print the text that surrounds specific words or phrases from specific documents-this is known as a "permuted index." With this information, new queries can be formulated (possibly using a "natural language" boolean query) to eliminate unlikely candidate documents from the electronic literature search, and narrow down the search until you finally arrive at a specific answer/document/concept. And that is the theoretical reason why the system works-and why it is applicable as a management tool in organizations that have to deal with "complexity" issues. -- John Conover, john@email.johncon.com, http://www.johncon.com/

Copyright © 1993 John Conover, john@email.johncon.com. All Rights Reserved. Last modified: Fri Mar 26 18:58:52 PST 1999 $Id: 930914085306.2173.html,v 1.0 2001/11/17 23:05:50 conover Exp $