🚀 go-pugleaf

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
-------