All Posts in Technology

|In: Industry Commentary|Last Updated:

Neuroscientists 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 if we PET scanned some religious fanatics, serious football fans, and the authors of the flames I received in response to my follow-up article on Network Computers a few weeks ago, 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 argued against in recent columns. The Citrix Winframe may be fabulous. The HDS @workStation may be just the ticket. Last I looked they aren’t built to the Oracle reference spec.

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: since Microsoft’s new license terms only let you run MS applications on MS operating systems, are you sure what you’re doing is legal? It’s debatable whether an NC running an MS application remotely is kosher or not, and Microsoft has better lawyers than God.

Speaking of definitions, I’ll bet lots of readers got excited over my exit line last week: that the opposite of “client/server” is “bad programming”. Got your attention, didn’t I?

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 operating system and database management utilities to involve at least presentation logic, and maybe business rules and processes as well.

We’ve been breaking these into independently compiled subroutines for years, so why would it suddenly start costing more when we called it “client/server” and making them portable? Answer: we’re confusing several separate issues:

Building to a Platform: COBOL/CICS/3278 programmers build to an existing, stable environment. They’re just writing applications. Lots of client/server projects sink because the team has to build their ship while they’re trying to sail it. Of course it’s going to leak.

Scaling: The IBM mainframe hardware/software architecture has been optimized and refined over the years to handle high-volume batch processing. Lots of client/server projects include a goal of unplugging the mainframe in favor 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 workarounds and kludges, and these will inflate project costs unreasonably.

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 center agents hundreds of transaction codes?

Employees learn how good an interface can be at their local PC software retailer. They rightfully hold IS to a higher standard now. Surprise! Building GUIs, with lots of interface objects, windowing, and extensive business intelligence, takes more time than building 3278 screens.

Programmer Training: We hire trained COBOL programmers. They learn in trade school or we just say, “3 years of COBOL/CICS experience” in the ad. 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 behavior many years ago, I presented some serious statistics to my research advisor. 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, from yours truly.

Comments

|In: Industry Commentary|Last Updated:

Back in the early 1980s, when the world was young, I had more hair, and Lotus 1-2-3 ran just about as fast on a 286 processor in character mode as Excel does now on a Pentium under Windows/NT, the toughest auditing problem in a big spreadsheet was tracking down circular references. (Okay, I admit it … I caught myself saying to a friend the other day, about rap music, “It all sounds the same to me.” I’m starting to geeze.)

Anyway, you’ll recall that with a circular reference, a cell’s formula refers to its own value, which means the spreadsheet never yields the same result twice. The simplest example: the formula =A1+1 in cell A1.

In some situations, for example simulations and formulas that require recursion, circular references can be useful. Most of the time, though, they give you meaningless results.

Here’s another example of a circular reference: “Client/server systems cost more than mainframe systems.”

You’ve heard this repeatedly from authoritative sources in the industry that charge so much for advice they must be right. Except they’re demonstrably wrong, because this calculation involves a circular reference. Don’t believe me?

How many times have you heard this semi-true statement: “The mainframe won’t go away, but it’s role will change. It will become the biggest server on your network.”

Okay, let’s see. Client/server systems cost more than mainframe systems, and mainframes will be servers in client/server systems. Put these two facts together and you’ve proved that client/server systems that use mainframes as servers cost more than themselves!

Ain’t logic a wonderful thing?

Want more proof? I’m glad you asked. Imagine a small system … it has ten tables, five concurrent users, no more than a thousand records in its biggest master table, and handles about one transaction a minute. Which will be more expensive to develop and maintain: a mainframe, COBOL/CICS/3278 system, or something you build in Access, Paradox, Visual Basic or Delphi on a small PC network? Hint: the word “COBOL” shouldn’t appear in your answer.

Now imagine an airline reservation system: millions of records in its main tables, thousands of transactions per second, and oodles of concurrent users. (An oodle is somewhere between a whole lot and a bazillion.) This time, yer basic COBOL/CICS/3278 system wins.

If you’re so inclined, imagine a graph. The y-axis is cost, the x-axis is a composite size/compexity index. When x is small, non-traditional architectures cost much less than their mainframe/terminal-host equivalents. The line representing mainframe/terminal-host costs increases with size more slowly than the line for non-mainframe systems.

Somewhere, the lines cross: “client/server” systems – actually, systems built with a multitier application partitioning model, non-mainframe servers, and GUIs – sometimes cost more, sometimes cost less than “mainframe” systems (those built with a single-tier application partitioning model, mainframes as the host, and a character-mode user interface).

This isn’t a one-size-fits-all situation: the optimal architecture depends on circumstances. Big batch jobs require big mainframes. Kludge together a solution based on too-small servers and your costs go up. Talk about blinding revelations.

And the circumstances are far more complicated than most pundits (but not yours truly) would have you believe: it’s a mix ‘n match situation. “Client/server” vs “mainframe” tangles a bunch of separate threads. Next week we’ll explore this subject in detail, untangling these threads and using them to cross-stitch a portrait stunning in its beauty and complexity (help! The metaphor police are after me!)

Strictly speaking, the term “client/server” refers to an application partitioning model. In client/server applications, developers separate applications into multiple, independent, communicating processes. They can all run on a mainframe. They can all run on a single personal computer. They can run on a server, or some can run on each.

Of course, we’ve been doing this, in limited fashion, since the invention of operating systems and subroutine libraries. Which means the opposite of “client/server” isn’t “mainframe”.

It’s “bad programming”.

Comments