Aucbvax.1791
fa.apollo
utzoo!duke!decvax!ucbvax!Barns@OFFICE
Wed Jun 17 02:03:33 1981
Works: Re RIvanciw: OA Architecture
I think it is certainly wrong to say that "the problem in most organizations is
that they don't have an overall architecture (not even conceptual) for office
automation."  This implies that office automation is a valid objective, which
it is not.  Office automation is not an objective.  In some cases it is a good
means to some end.  In some cases it is a waste of effort.  Therefore, office
automation as an idea, and office automation systems architecture in
particular, should never have priority over accomplishment of the productive
task.

The problem in most organizations is, rather, that DP people and administrative
people are each of the opinion that their "system architecture" is the key to
saving the world.  Anyone who thinks that a system architecture does useful
work is wrong.  Only people do work.  All the management theory and systems
analysis in the world is worthless without someone to do the work.  It is that
person whom we should be trying to help, and OA is only an indirect aid to them
- someone who is supposed to help them uses OA to help them help.  It is not a
given that (even potentially) a computer based device or system can help do all
tasks.

The proper purpose of a systems architecture is to make the pieces of a system
fit together once it is known that a certain type of system is integral to the
best solution to some real problem.  Therefore, it should only come into play
after the real, productive tasks to be performed are defined.  For example, it
is silly to buy communications capability if you do not have information worth
communicating and someone who can benefit from having it communicated to them.

The Big Black Box theory has not departed from the scene.  You all recall this
as the theory that when the whole organization puts all their data into the one
Big Black Box, everything becomes wonderful.  An example of this occurred with
a relative of mine some 15 years back.  He had 45 people working for him on
engineering costing.  His DP department sent the IBM salesman down to explain
to him that 7 people could do the same work using the wonderful 360.  Well,
they got the 360 and found they could do the same work with only 61 people.
IBM eventually said "You needed a 370" and they got a 370 which allowed them to
do it with only 76 people.  When last heard from, they had a 3033 and could do
it with only 91 people.

Nowadays we have the Distributed Big Black Box theory, which holds that the
basic problem with the Central Big Black Box theory was the "Central" part and
not the "Big Black Box" part.  But, for years people have been announcing that
we now have the language, processor, comm protocol, etc., that is going to make
everything work right, but that's something that the claimant has to prove!
What makes this any different?  I contend, though, that if "systems
architecture" is just a code word for the "Big Black Box" then it is just as
bad to have a standard systems architecture as it was to throw everyone into
one machine/language.  Seems to me that the truth is that now as always,
systems are being evaluated in terms different from those the real, PRODUCTIVE
worker would apply, if s/he knew enough to evaluate it independently.

It is not always true that the benefits of a standard language, processor,
communication protocol, etc., outweigh the pains incurred by those users for
whose applications the standard item is ill suited.  A properly run OA support
group will evaluate this on a case by case basis and will not say "this is the
standard, you better learn to like it".  It is up to the standardizer to prove
that the benefits of the standard are sufficient to justify the pains incurred
by those whose applications don't fit the mold.

If some workstation performs a productive function better than any other, and
it is incompatible with the system architecture, the fault is with the system
architecture.  This is not to say that having a system architecture is bad.
The point is that the design is supposed to follow the needs and not vice
versa.  Therefore, the evaluation of new developments of all sorts should be
first with respect to its satisfaction of a productive work requirement and
only after that with respect to a previously conceived "system".  In respect to
DARCOM I will only say that it will be interesting to see what happens when
someone in DARCOM wants to use their system to do something that doesn't fit in
64K address space.  If someone on this list is involved with Wharton's
econometric work (for example), maybe we can hear more about how things like
that should fit in.

--Bill Barns
-------


-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <[email protected]>
of http://communication.ucsd.edu/A-News/


This Usenet Oldnews Archive
article may be copied and distributed freely, provided:

1. There is no money collected for the text(s) of the articles.

2. The following notice remains appended to each copy:

The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.