Replying to LO25651 --
Peggy Stuart writes:
> 1. Database infrastructure design. As we want to become a LO, I would then
> think we would ideally want a database that could be accessed centrally
> and easily manipulated to fit the changing needs of our organization. As
> well as helping to reduce any redundant work processes, I see that this
> infrastructure design would facilitate the sharing of information. For
> example, Mary accesses database to plan for upcoming conference. She sees
> a read-only table built by Jane for a well-run conference that she
> coordinated last year. From Jane's table, Mary learns how she can make her
> own planning process better as well as can copy/overwrite Jane's table,
> which could save Mary time.
The "infrastructure design" of a database is usually called a schema. A
DB schema is a language, which describes and thus restricts what can be
said, and what can be asked. As I've asserted in previous messages, the
(human) language(s) of a LO will constantly evolve. Evolving a database's
"language" is a task that requires constant care if the DB is central to
the operations of the organization.
Generally, the best database for a person or small group with changing
needs is one you create and maintain yourself. For small amounts of data
with simple use requirements, this can be implemented in a spreadsheet or
even a text file with lists of items (or a box of 3x5 cards...). Beyond
this, you need to learn more powerful tools, or to delegate the work to
someone (who becomes a mediator between you and your data -- an "umlomo",
as At would say). In this latter case, it's important then that the
language used between you and the mediator is effective in conveying your
needs and your understanding of the data, if the database is to be more
help than annoyance.
One problem with a central database is that it's developed and maintained
by a group whose identity is tied up with the DB. This can make it
difficult to have an effective dialogue between the group and those whose
data it must import, manage, and export. (It's not hard to find war
stories in this area.)
There's also a more subtle and difficult problem: the schema of the
central database, no matter how carefully constructed, must be a
compromise in an organization of considerable size. This can make it
problematic to determine what the data mean.
An example: when a major oil company hired some AI workers to develop
expert systems for various operations in the 1970s, the workers uncovered
some interesting (and disturbing to them) inconsistencies in terminology
within the company. For example, the term "(oil) well" meant something
different to different groups within the company. To some, it was a
particular drilling platform, to others the main hole, which could be
tapped by several platforms, etc. (I'm writing this from memory -- the
details could be wrong.) Most interesting was that this inconsistency
caused no problems in the running of the company. Human coordination at
the boundaries managed the translation between terms (what has been called
"articulation work" by some OIS researchers). Further, any attempt to
change the operations of the various groups to impose a consistent
terminology would have had harmful effects on the groups -- the cost of
the articulation work was less than the cost of consistency would have
been. If anyone's interested, I can dig up another example from an
insurance company.
In LO terms, this means that the parts of an organization must be free to
maintain a shifting local consistency, doing articulation work across the
boundaries to maintain the global consistency at a different level. (At,
does this call to mind examples in the biological, chemical, or physical
realms?)
The upshot of this, in my mind, is that it's better to live with the
problems of distributed, local DBs, owned by the people and groups who
need them. The core problem here of course is information transfer
between the databases. Again, this is primarily a linguistic problem, and
is one of the major forces that make XML so attractive: it's a
metalanguage framework that can be instantiated to allow for such a
transfer, _once the people involved on both sides have agreed on the
meaning of the XML fields_.
Peggy, I hope I haven't rained too much on your parade. To end on a
positive note, I believe that addressing these problems carefully, and
using the five disciplines as tools, will in itself help in the effort to
increase the "learning quotient" of the organization. (Disclaimer: the
quotes are to indicate that I don't believe in the literal existence of
such a quotient.)
> Thanks and have a great day!
And to you...
--Don Dwiggins "The truth will make you free, d.l.dwiggins@computer.org but first it will make you miserable" -- Tom DeMarco
Learning-org -- Hosted by Rick Karash <Richard@Karash.com> Public Dialog on Learning Organizations -- <http://www.learning-org.com>
"Learning-org" and the format of our message identifiers (LO1234, etc.) are trademarks of Richard Karash.