The Unix business architecture
The other mainstream in computing development doesn't directly reflect any of this. In fact the men who invented it all, people like Atanasoff, Newman, and Zuse, never thought of IBM in relation to their vision of computing. Fundamentally they wanted to extend the power of the individual, not replace him.
To them, the dumb terminal was both a way of sharing an expensive resource and a way of building a community of users. As part of that, their terminals differed from IBM's in one key way -the absence of the masking controller and block mode card assembly functions. Thus, by the time Unix came along, the principle of user control was well established and even the earliest shells allowed a great deal of personal environmental customisation.
The result was a system and a vision of computing that empowered, rather than replaced, its users.
That's why, if you were able to do what I suggested yesterday: find people who had used either mainframe terminal systems like those based on the 327X line or mini-computer users on early terminals like DEC's VT100; you will have found that the IBM users thought the things sucked and those science application users whose machines weren't run by IBM people generally thought them insanely great.
In the Unix world the 24 x 80 character terminal gave way first to the diskless client and then, by about 1988, to the X-terminal - or, as Network Computing Devices (NCD) called them: network computers. These were the first smart displays, and when combined with hardware and software advances at companies like Apple, Sun, Appolo, and DEC, produced some of the most productive systems we've seen yet.
The classic case for this is Boeing. Using X-terminals on Unix and VMS allowed them to develop the 757/767 line in half the time, and with one third the manufacturing change orders, needed for the previous generation, while their subsequent religious transformation to Windows client-server cost them almost a decade and very nearly took the company down.
What's critical here isn't the technology; that's only an enabler, but the management approach. Put a data processing professional in charge of a Unix/X-terminal system and what you'll get is a poorly functioning imitation of a mainframe system.
People do what they know how to do -exactly the problem you see when Windows people get control of a Linux installation and destroy it by doing what they know how to do.
Thus the key thing about the modern Unix Business Architecture is that you centralize processing, but decentralize control to give user communities near total control over their systems and individual users near total control over their working environment.
Remember, it's not the horse that's at fault, it's the refusal to use the telephone.
Go back and look at "Jimbo's" description of an IT service request process and what you'll see is that the problems really have nothing to do with technology, and everything to do with management methods. Look a bit deeper, however, and you'll see that Microsoft's client-server architecture virtually mandates those methods - but the Unix business architecture does not.
What's going on is that the technology has combined with cost pressure and management's pre-existing knowledge base to create and enforce the management methods - these things all co-evolve. That's why Smith's study of PC architecture implementation costs comes to the obvious conclusion: if you want to use Microsoft client-server, then the cheapest and most effective deployment strategy is to recreate the mainframe management architecture with the desktop totally locked down and all control in the hands of a centralized systems management group.
Hence the big lie at the root of today's Windows systems: the user gets this wonderfully user friendly, flexible, desktop -which Systems then locks down to function as an expensive, unreliable, and quite dumb, terminal.
With Unix and smart displays you don't need to do that - processing is obviously centralized, but the cost picture favors decentralised control and thus lets you deliver, on Unix smart displays, the individual freedom of action promised by Windows.
Doing it requires change - total organizational defenestration including a literal about face on the part of Systems - transforming it from an inward facing resource custodian to a much smaller customer facing service organization.
For example in the school cost scenario I'm presenting tomorrow, I've specified a wholly redundant system, including two sysadmins, where one would do. Couple that resource richness with the complete absence of Windows frustrations like hardware change, lost files, malware, multiple passwords, missing XML file components, and the application re-familiarization that goes with each upgrade or service pack and what you get is an environment in which there not only is no incremental cost or risk to having users do pretty much whatever they want to with their applications and environments, but there are benefits to having IT help them do it.
Freeing users and refocusing IT from a custodial role to one of pushing services at anybody who might remotely want them produces an enormous productivity benefit: the user starts to treat the computer as an assumed part of the environment that's safe to experiment with - and that's ultimately where the real value is.
Tomorrow I'll talk about implementing the architecture - costs and benefits using Sun Rays. On Friday I'll finish Carl's answer by trying to sort out what is, or is not, a smart display -winterms, for example, are not.
For today, however, please think a bit about this: the logic of business smart display use extends to formal organizational support for home use of Linux, BSD, or Solaris - so widespread adoption of the Unix Business Architecture may be our best route to getting Linux far more widely used too.