As IM's momentum shifted towards supporting PCs and then PC
LANs, the evolution of the information infrastructure began
to resemble the history of urban transport and seemed
destined to repeat the same mistakes. By the 1990s end-users
finally started to figure out the difference between
automation and effective automation, but IM still doesn't
have a clue. At this point it is sitting in the back seat,
but still trying to drive.
IM Chases its Tail
As IM's momentum shifted towards supporting PCs and then PC
LANs, the evolution of the information infrastructure began
to resemble the history of urban transport and seemed
destined to repeat the same mistakes.When cars were
expensive and rare, efficient streetcars and inter-city rail
systems were built to provide basic transportation. Soon
affordable and powerful cars allowed unrestricted travel and
the streetcar tracks were paved over. After a few years this
mode of transport became too congested and inefficient, so
streetcars--now called light rail systems--started to appear
as a "new" alternative. By then the old streetcar and
railroad rights-of-way had been sold, so light rail proved
to be far more difficult and expensive to build than the
original streetcar lines. In similar fashion, the highly
efficient and easily managed centrally controlled computing
systems of the 60s and 70s gave way to the chaos of
stand-alone PCs in the 80s. IM started scrapping its
mini-computers and mainframes in the late 80s to support
stand-alone PCs, only to find itself wiring LANs and WANs
and installing central file servers a few years later.
The whole point of linking computers in a LAN is to allow
its users to share information. While some equate sharing
information with sending thousands of E-Mail messages to the
far reaches of the globe, the "information" that really
needs to be shared is the type of data which appears on
spreadsheets and financial reports. The people who need to
share this data usually work just down the hall in the next
department. There are really two types of computer systems
needed today. The first needs to operate like a telephone /
fax and allow any user to communicate with any other via
E-Mail. The second should allow smaller groups of users to
efficiently share a centrally located data resource--like an
agency-wide purchase order system--with the simplicity of
creating and using a spreadsheet. With a shared database for
purchase orders, all the people involved in the process
would put information into a database, call orders onto
their computer screens, to add approval and status
information, and print copies only when necessary.
Information would be shared via the database instead of
passing multiple printed copies of a purchase order form
through the inter-office mail and filing is eliminated
entirely.
IM has the right idea, but WANG gets the implementation all wrong
Many agencies already had the ideal hardware and network
architecture to meet both of these needs in their
inter-connected WANG VS mini-computer networks. These
systems were quite effective for E-Mail and word processing,
but they lacked the second vital component, a user-friendly
data transfer mechanism. The VS computer is quite capable or
sharing data via a database; the problem is getting the
database applications developed. IM departments do not have
large staffs of application developers and cannot respond to
individual user needs. Users neither have the skills
necessary to use the complex VS database development tools
nor access to them. It is possible for users to solve many
of their own problems with spreadsheets, but the VS does not
have the processing power to handle such interactive
software.
Many years after the introduction of the IBM PC, IM
sought to correct the spreadsheet deficiency by replacing
the "dumb" VS terminals with WANG PCs. The addition of the
PC allowed the users to create spreadsheets and databases
for the first time, but it did nothing to help them share
this data with others.
A VS/PC system looked like a PC LAN
it wasn't; the PCs could neither communicate with each other
or the host VS system. While using the PC the user could not
communicate directly with the central VS system to retrieve
and store files. Even "sneaker net" wouldn't work. While in
the VS mode a PC diskette could not be read. For power-users
wanting to share data between VS and PC or between PCs,
adding a PC to a VS was like being given Christmas present
only to find the box contained a lump of coal.
The dysfunctional split personality of the VS/PC could
probably have been corrected by WANG with a rewrite of the
VS operating system and probably could have been avoided
entirely if WANG had not chosen the non-standard
bisynchronous method to interface its VS terminals to the
host computer to keep the system proprietary. If WANG had
used the standard asynchronous mode (the same that is used
for PCs and modems) for its terminals, any PCs or terminal
could have been connected relatively easily, via its serial
ports, and the VS system itself would have been simpler and
less expensive to wire.
Unfortunately WANG was sliding into
bankruptcy and as a result it became necessary to start the
phase-out of what could have been powerful central file
servers on a PC LAN. Equally unfortunate is the fact that
most WANG VS users never got upgraded to PCs and are still
using "dumb" VS terminals. These users are still shackled to
word processing and the limited number of shared
applications IM departments have implemented on the VS.
In 1994, 12 years after the introduction of Lotus 1-2-3,
they still cannot work with spreadsheets or any of the
thousands of other software packages that are available for
the PC. Massive amounts of money and human potential have
been wasted of because of poor equipment purchasing
decisions by government IM managers.
Offices probably would have been more productive if IM
saved the cost of the VS interface cards and just put the
PCs next to the VS terminals. PCs, which could have been
networked in parallel with mini-computers while shared
database applications were transferred from VS data bases to
PC LANs, were tied-up serving as VS terminals, creating a
chicken/egg dilemma for IM: they couldn't connect the PCs in
LANs because the PCs were needed as VS terminals and they
couldn't port the VS applications to PC LANs because they
didn't have any PCs that could be networked or the resources
to develop the PC applications. What a mess!
Reinventing the wheel--The PC LAN
About the same time computer users discovered the database
concept they realized the biggest shortcoming of their PCs.
Stand-alone PCs did nothing to improve the efficiency of
sharing information between users; people either reentered
data from a printed report into a spreadsheet, or used
"sneaker net" to send it via diskette so they could copy it
from spreadsheet to spreadsheet (and use the embedded
calculations and logic). It took no great leap of insight to
see the solution to the problem: link the PCs together in a
network so they could share information--just like a VS!
When Local Area Networks (LANs) started to appear nearly all
end-user applications were on spreadsheets.
Spreadsheets can be shared over a LAN on a "read-only"
basis, but cannot be modified by two users at the same time.
Most users did not realize the spreadsheet, while ideally
suited for the stand-alone PC, environment was totally
inappropriate for sharing information over a LAN.
Since IM's focus was on installing PCs and defining
standards to control hardware and software purchases, it
paid little attention, and gave even less support, to what
the end-users had been doing with spreadsheets to automate
their offices. As a result IM was out of touch with how
users needed to share information. The users had an equally
narrow, but entirely different perspective. Few understood
the technical and organizational ramifications of shared
computing: server management, access control and security
(i.e., log-ons and back-up of files) and the need for file
sharing protocols. For most it was a rude surprise when they
discovered a spreadsheet could not be modified by two users
on the LAN.
Out of ignorance, or bureaucratic self interest, most
LANs were planned around political subdivisions rather than
functional inter-department work groups. Separate LANs and
fileservers would be installed in the budget office and each
department it serviced, rather than putting everyone that
worked on the budget data on the same LAN regardless of what
department they were in. Many failed to grasp that the key
to truly effective automation is the electronic sharing of
information across traditional bureaucratic lines to
eliminate the reliance on reports as the vehicle for sharing
information.
The lynch pin of the LAN concept, shared PC
database applications, was largely missing from the planning
and implementation of PC LAN shared information systems.
Although only a few large-scale shared applications had been
developed over a 10 year period for VS or other
mini-computer platforms. These needed to be replaced with
PC applications before the PC LANs could replace the WANG VS
LANs.
Because IM departments had used turn-key solutions
such as OIS and WANG Office, it lacked application
development resources, and experience to implement PC LANs
effectively. The new applications were often developed on
outmoded (non-graphic oriented) PC databases which did not
take advantage of the user friendly interface of of Windows
or the ability of skilled users to tailor automation to
their individual needs.
LANs would be built around E-Mail and separate LANs be
would be connecting together to form Wide Area Networks
(WANs) to move it. Thus, the movement of information,
rather than its effective use, became the driving force for
IM led automation in the 1990s. Most IM departments totally
ignored Macintosh which had a far better networking strategy
as an integral part of its design.
LANs--A Better Alternative Ignored
MS-DOS / Windows PCs were never designed to be connected
together. In order to communicate with another PC over a LAN
it is necessary to take each PC apart and add a $200 circuit
card. A networking program must be installed also. This
program costs about $50 to $100 per user. Communications
between the PCs on the LAN requires a third computer to act
as a post office or "fileserver." The server needs the $200
circuit card and a $2,000 hard disk to store the files
everyone shares. Adding the disk to the server requires
taking apart the server to install a SCSI disk interface
card. An installation program is also needed to tell the
computer how to run the disk and often the priority
(interrupt) settings of other interface cards on the
computer must be changed.
The installation will take two
skilled people from IM at least two days. If you do try to
do it yourself and are not fluent in MS-DOS techno-speak and
the LAN networking package (Do you know the proper syntax
for the PATH statement in the CONFIG.SYS file or how to move
jumpers to solve an interrupt conflict on the network card?)
you will probably give up after two weeks and take a
vacation.
Or, you can buy Macs instead, take them out of the box
and plug them in. They cost the same as the PCs, but you
don't need the network card or software (you save about $300
per computer). Macs have built-in networking in their
operating system and the hardware has been designed to be
linked together in LANs since Mac were introduced. They have
built in connections for a SCSI disk and monitors too, so in
most cases you never need to open them.
There are no extras
to buy or install. You create a LAN by plugging a $30
"AppleTalk" connector into the back of each machine, and
stringing a plug-in cable between them. After turning on the
computers and entering passwords and access via "pull-down"
menus and icons you are finished. It has taken a couple of
hours to computerize the whole office and the total cost
thousands less than the PC system. You saved several
thousand dollars: the $300 per computer, plus the cost of
the fileserver.
Mac LANs don't need a dedicated fileserver. Each user can
share some or all the files on their computer with and other
users directly on a peer-to-peer basis. You can do it all
yourself, which is a good thing because IM usually doesn't
support Macs, and if they do you don't need them anyway. PCs
can be added too.
So now you have a LAN, what do you do with
it? E-Mail?
A better idea would be to install Claris FileMaker Pro
database software. It costs about $100 per user for a
10-user system. It works identically on Window PC and Macs.
It installs with a few mouse clicks; takes about 5 minutes.
Take the manual home and over the weekend and read it. On
Monday you can run the tutorial then create a purchasing
database. It will take a couple of days to polish the
layouts but by Friday all the users on the LAN will be able
to create purchase orders and track purchase status and
cost; all at the same time. You can get rid of electronic
forms and start on the next database, perhaps an inventory
that is linked to the purchasing system. The possibilities
are infinite.
These examples are based on actual personal experience
setting-up both PCs and Macintoshes. Many IM departments
will say, "But that's Macintosh. We don't support that." I
say, "But it works, so maybe you should. Come an see the 50+
databases in my office that are used by 30 people to solve
their own problems." If you had to install and support a LAN
in your office which system would you chose? If you were
spending your own money for your own a business which would
you buy?
What's the best computer system?
What's best depends on what users need and what they will be
most productive with. The best software for shared databases
is the one which allows the users to create applications
themselves--it might not be the most powerful, or the
cheapest.
The best LAN is not one with all Macs or all PC, but
one which can accommodate both, plus Sun Workstations and
what ever else is used. The best network system for an
office is the one easiest for the users to install and to
support--themselves--without a lot of IM support.
In short, it's best to be flexible. Technology changes too fast and
so does the user's needs. By being inflexible and flatly
refusing to support PCs when they arrived on the scene and
Macs when they became a viable alternative for LANs, IM
painted itself into a corner and perpetuated the need for an
expensive hardware support infrastructure.
IM did not look at the alternatives or ahead at the
support costs. By the 1990s end-users finally
started to figure out the difference between automation and
effective automation, but IM still doesn't have a clue. At
this point it is sitting in the back seat, but still trying
to drive while offices like the author's that have managed
to purchase Macs have flourished without IM support and had
LANs operational years ahead of others.
Why IM has failed to meet user needs
IM--the main roadblock to productive computing
Is it really any wonder that the IM bureaucracy has become
totally out of touch with the real value of
computing--empowering the user to solve his own problems?
All IM has done for the past 20 years is implement turn-key
solutions with little or no user input. Imagine how the
end-user feels when someone from IM shows up on the doorstep
one day and says, "Here's you new timekeeping system, adapt
all of your forms and procedures to it." That's exactly what
happened to the author just last year, and a "new" and
"better" property inventory system is on the way--to replace
a better one he created himself two years ago.
As the circular evolution from central mainframes back to
central file server LANs has shown, the information
professionals were correct back in the 1970s when they said
that centralized administered systems were the most
efficient and effective means of meeting enterprise-wide
computing needs.
There is a big difference between
having the right idea and being able to implement it
effectively. Now, when the technology is finally available
to meet the hardware needs the users with efficient
centralized systems, IM has neither the personnel nor the
perspective to supply the database applications which are
the key to doing anything productive with the technology. IM
will finally let you trade-in your tractor for a car (last
year's model of course) but they can't supply the
gas--applications-- to make it past the E-mailbox at the end
of the driveway.
The IM bureaucracy has become hamstrung with its obsolete
centralized systems, standards, and mind set. The task of
customized application development was left to contractors who
built large, one-size-fits-all enterprise wide applications.
Power-users filled the gap, and in many cases have been
far more effective in solving problems with technology.
However rarely did they participate in the planning process
for information technology.
IM should give users what they ask for and then get out of the way
Many IM departments are still run by ex-COBOL programmers
and mainframe operators who view application support from
the "hire a contractor" mainframe perspective. Even worse
are the ones run by bureaucrats with no "hands on" computer
application experience at all. Many IM departments just
don't seem to understand that the point of giving someone a
powerful PC is the expectation that they will create an
application to do something productive with it. The most
important contribution IM can make to that process is to
give the users what they ask for and get out of the way.
It is foolish to equip someone who only types letters
with a $600 word processing package that can format multiple
columns and add footnotes. It is equally foolhardy to force
someone whose job involve preparing documents with extensive
footnotes and two-column formatting to use a word processor
without those features to save $400. Yet, one can find
examples of this in nearly every organization at some point
in its technological evolution, and most often the cause is
a IM bureaucrat blocking the passing lane by refusing
power-users the tools they need to make their offices
productive--themselves.
Power-users invariably use the tools that are most
effective to get their job done--that's why they are
power-users in the first place. Often this requires software
and hardware that is not on IM's approved list. IM continues
to slam the door in their faces, limiting software choices
on the grounds of compatibility and training. "We can't
support that," is the standard refrain when a power-user
asks to purchase anything that is not on IM's list. Usually
the power-user has spent many hours of his personal time
developing the application and has implemented the system on
a model or pilot project basis to prove it would work. He's
already gotten approval from his office to implement it,
otherwise he wouldn't even be talking to IM. None of that
sways these obstinate IM bureaucrats who have probably never
actually used their "standard" package themselves to create
an application.
What Support?
What IM considers software support consists of handing the
end-user a shrink-wrapped package of software and holding
one week class that does little more than teach them how to
read the manual. IM has failed to notice that millions of
PCs and Macs are being used by people who never attended a
class. IM claims standardization is needed so offices can
share information. All PC word processing, spreadsheet, and
database packages allow the user to translate data between
brands and types of software transparently and people rarely
share information effectively now because they don't know
how to use databases, or create them to solve their own
problems.
People can, and will, solve their own
problems
if they are given the right
tools.
[- next section - ]
[- table of contents -]