The Gartner Group calls it the “Zero Latency Enterprise.” Regis McKenna’s new book is titled Real Time.

McDonald’s asks “Want fries with that?”

Although McDonald’s doesn’t dominate the fast food business the way Microsoft dominates the desktop, it’s been stunningly and consistently successful over the years, even though its food is about as good as Microsoft’s software (but don’t push the metaphor, please – I’ve never found a bug in a Big Mac).

One reason for McDonald’s success is that a long time ago it realized that customers don’t care that much about flavor. Speed matters a lot – McDonald’s customers want their food in real time, with zero latency between ordering and eating. They want a clean restaurant to eat in. They don’t want to spend a lot. They want to keep the kids happy.

And oh, by the way … actually eating the food shouldn’t be unpleasant.

I have a lot of respect for Regis McKenna, and have even gained one or two useful insights from the Gartner Group. You can learn a lot from McDonald’s, though, which figured it out long before RM or GG, and you can learn it for a lot less money. Not only that, you can get a Happy Meal in the bargain. For example:

  • Training: McDonald’s doesn’t leave things to chance – Hamburger U may sound funny, but it’s one of the reasons eating at McDonald’s doesn’t lead to unpleasant surprises. Is the training you give your leaders as effective as Hamburger U? If not, why not? The products you deliver are a lot more complicated than a Breakfast Burrito.
  • Leverage: People get all gooey about how the plains Indians used the bison so efficiently, but McDonald’s puts them to shame. When McDonald’s buys a cow, the entire cow – skin, meat, bones and hooves – gets put to productive use. In IS, leverage comes from reuse. Do you create libraries of reusable subroutines or objects? Do you require developers to learn what’s in it?
  • Procedures: There are lots of ways an employee could assemble a Quarter Pounder, but there’s only one way a McDonald’s employee does assemble a Quarter Pounder. When it comes to your core processes – tasks employees do over and over again – do your employees do things by the numbers? Or do they waste time trying to figure out the solutions to problems that have long-since been solved?
  • Willingness to customize: My youngest, Erin, asks for a fish sandwich with “… only the bun, the fish, and the sauce, please. Nothing else.” And that’s what she gets. We spend a lot of time in IS worrying about enterprise-scale problems, but the single biggest difficulty we have is helping small constituencies with specialized needs. Do you know how to help a small group solve a small problem, or do you tell them, “That violates our standards,” or “We won’t solve it for you and we won’t let you buy the tools you need to solve it yourselves, either”?
  • Hiring old people: Think there’s a labor shortage in IS? Compared to the food industry, you have it easy. McDonald’s hires old people. It hires young people. It hires recent immigrants with poor language skills. It even hires the cognitively challenged. It meshes its staffing needs with their scheduling limitations, it helps every new employee find a way to succeed, it pays enough to attract them all, and it makes each McDonald’s a decent place to work, too. Meanwhile, lots of IS shops practice age discrimination, screen out anyone without a computer science degree, and never consider hiring high school students to work the help desk part-time, even though they know PCs better than most “IS professionals” and would kill for the job, besides.
  • Killing bad ideas: The Arch Deluxe didn’t sell, and McDonald’s unceremoniously took it off the market. What really bad idea is still floating around your organization because nobody is willing to put a bullet into it?

And then there’s the issue that started this column, speed. Anything that might slow down a McDonald’s employee in delivering an Egg McMuffin to a customer isn’t there in the first place.

Draw a circle.

Surround it with several more circles. Connect the new circles to the one in the center with lines.

This is your systems architecture. Before you read on, label each of the circles. I’ll wait.

OK, done? You almost certainly chose one of the following two labeling schemes: You either tagged the central circle with some synonym for mainframe, host, or server and the outside circles as terminals, PCs, or network computers; or you called the central circle a personal computer and the outside circles mainframe, server, minicomputer, World Wide Web, and other resources you can access through your PC.

If you chose the mainframe-centric labels, chances are you like the fat-network architectures now fashionable under the misleading “thin client” moniker. If, like me, you put the end-user in the middle of modern computing architectures, using a PC to draw on whatever resources are currently needed, you probably worry about the whole fat-network approach to systems design.

Fat-network systems come in two basic flavors: Windows terminals and “Webware” interfaces. What’s interesting about these two flavors is that they have exactly nothing in common except that they have both have been misrepresented as thin clients.

The Windows terminal approach, whether sold by Citrix, Microsoft, or any of the dozen or so remote-control vendors, is remarkable primarily because of how unremarkable it is. It ignores the application architecture entirely, instead providing an alternative for deploying the same old stuff. The term “architecture” really shouldn’t be applied to a Windows terminal solution at all, since all it does is extend the keyboard and screen across a network. It does, however, put the host firmly in the middle, since with Windows terminals IS tightly controls the resources available to end-users.

Webware is more intriguing. When you design applications around Webware, you have at your disposal browsers, JavaScript, downloaded Java applets and applications, Java servlets and server-based applications, active server pages, Notes/Domino applications, Perl scripts, and enough other choices to delay any development project for a year while you sort them all out.

A Webware architecture means some code gets downloaded for desktop execution while other code executes on the server. The only option not available to you when designing Webware is storing software (other than a “thin” 50MB or so browser) on local hard drives. In other words, you never use the fastest and cheapest storage you have. That makes sense … if you have decided to put the host in the middle.

Take a moment to go beyond cost of ownership to deal with the more interesting benefit of ownership, and you’ll discover that GUI applications installed on the desktop and Webware-based applications aren’t mutually exclusive alternatives. You’ll want to use n-tier, thin-client (in the true, skinny presentation layer sense), probably object-based architectures to build both.

As a general rule you’ll use desktop GUIs for high-use applications targeted to a known desktop platform … for example, whenever you’re building or selecting software to be used by employees as part of their core job functions.

When you do, follow the rules for easy, stable installations: Don’t touch the registry, don’t put anything in the Windows folder or any of its subfolders, test builds for memory leaks, and deploy the full application in a scale-model test environment before implementing it in production. Design every module for portability and manageability, too.

When you don’t know what end-users will run on their desktops, or when you need to deploy an application for occasional use, go for Webware. Here, the increased functionality of a desktop-installed GUI no longer outweighs the benefit of easier deployment.

When you’re building for Web access, you have no control over bandwidth, so force developers to test applications on lowest-common-denominator (another misused term; they’re actually greatest-common-factor) systems. And … remember that testing and manageability thing? Building on Webware doesn’t eliminate the need for any of that.

When you’re building (or buying) for deployment on your intranet, don’t forget: Fatten up that network.

Putting the end-user in the middle doesn’t mean you want the data center to seem remote.