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/