MANAGEMENT SPEAK: That's very interestingTRANSLATION: I disagreeNeuroscientists use a nifty technique called "positron emission tomography" to map which parts of the human brain process different kinds of thoughts and sensations. I'd bet that if we scanned some religious fanatics, serious football fans, and some of the people who hold extreme views about NCs, they'd all be using the same cerebral structures.
Larry Ellison of Oracle coined the term "Network Computer", and Oracle has an NC reference specification. This is the gadget I've argued against. The Citrix WinFrame may be fabulous. The HDS @workStation may be just the ticket.
But the last time I looked, they weren't built to the Oracle reference specification.
You can call anything you want an NC - it's a free country (expensive, but free). The companies that took advantage of free publicity by calling their various stuff "NCs" have to take the good with the bad. One question: given that Microsoft's new licence terms let you run Microsoft applications only on Microsoft operating systems, are you sure what you're doing is legal? It's debatable whether an NC running a Microsoft application remotely is kosher or not, and Microsoft has better lawyers than God.
People take definitions pretty seriously, and I'll bet that lots of you will get excited when I say: the opposite of "client/server" is "bad programming".
Applications are client/server when the developer breaks out different pieces of program logic into independent, portable executables. It isn't fundamentally different from what we've been doing all along with CICS, VTAM, and so on, but you may want to draw a distinction. That's cool: let's call it client/server only when application partitioning goes beyond OS and database management utilities to involve at least presentation logic, and maybe business rules and processes.
We've been breaking these into independently compiled subroutines for years, so why would they suddenly start costing more when we call them "client/server" and make them portable? Answer: we're confusing several separate issues: platforms, scalability, the user interface, and programmer training. Let's take them one by one.
Building to a platform. Cobol/CICS/3278 programmers build to a stable environment. They're just writing applications. Lots of client/server projects sink because the team has to build its ship while trying to sail it. That boat's going to leak.
Scaling. The IBM mainframe hardware/ software architecture has been optimised and refined over the years to handle high-volume batch processing. Lots of client/server projects include a goal of unplugging the mainframe in favour of cheaper MIPS. This is a great goal, and you should go for it if your system won't include big batch runs. If it will, you'll have to build in all sorts of nasty work-arounds and kludges, and these will inflate project costs unreasonably. Think of it this way: you won't win the Indy 500 with a freight train, but you also won't economically haul grain with a fleet of Porsches.
User interface. We used to build character-based monochrome interfaces that required users to learn both business and technology. Remember training call-centre agents in hundreds of transaction codes? Today, employees learn how good an interface can be at their local PC software retailer. They hold IS to a higher standard now. Surprise! It takes more time to build GUI applications with lots of interface objects, windowing, and extensive business intelligence than it takes to build 3278 screens.
Programmer training. We hire trained Cobol programmers. They learn in trade school, or we just specify in our ad, "Three years of Cobol/CICS experience". We ask client/server development teams to learn their tools as they build applications. C'mon folks, what do you expect - perfection on the first try?
So . . .
When I was a studying fish behaviour many years ago, I presented some serious statistics to my research adviser. He said, "This is fine, but what does it mean?"
Ask this question whenever you hear silly average-cost statistics from self-styled industry pundits . . . except, of course, yours truly.