Text File

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 <jgoerzen@complete.org> 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.