Imagine corporate headquarters is an operating system, each business unit is an application, and the departments within corporate and the business units are threads.

If you can successfully imagine this, you have some nerd in you and fit right in here at KJR Club Central. But never mind that. It’s time for some serious analogizing.

Next, imagine corporate puts the nerds in charge of organizational design. Working the analogy, the nerds will list such issues as:

• What services should be provided by corporate and which should be left to the business units.
• How corporate should allocate resources among the requesting business units.
• How business units should request services from corporate.
• How corporate should evaluate requests and set task priorities.
• Where business units must conform to centrally-established standards and where they are free to make whatever decisions they like.

These are standard information technology design issues, translated into business terms. Chalk one up for the nerds.

Since both information technology and businesses are systems, it’s unsurprising that they have similar design challenges. Because information systems are processed in silicon while businesses are run by human beings, it’s a good bet those questions will have different answers.

For example: In an information system it usually makes sense to build sharable services into the operating system, increasing consistency while making application development easier. If too many applications are open, demanding too much in the way of system resources, the task scheduler and virtual memory share available physical resources among the applications according to a parameter-driven algorithm.

If, on the other hand, too many departments in too many business units demand more of corporate shared services than corporate shared services can handle, the situation is very, very different.

First, system memory and CPU cycles can be allocated to any and all tasks with equivalent efficiency. The same can’t be said for the staff at corporate: Generic employees can’t move back-and-forth between Accounting and Marketing to accommodate shifts in demand.

Second, the question of how to allocate system resources is algorithmic. The question of how to allocate business resources is, in contrast, algorithmic only in theory. In practice it is inescapably political. The word is governance. The specifics are budgeting, capital project evaluation, and the day-to-day under-the-radar exchange of favors.

And third, in business, questions of consistency are more ego-laden than in information systems.

While it’s surely true that (for example) some applications generate bursty network traffic while others transmit steadier streams of data, and each would benefit from a network interface tailored to its unique pattern, few would argue that each application should roll its own.

Compare that to a business — maybe one that has one business unit that sells through an ecommerce retail channel and another that sells the same products, in quantity, to business customers. They can make a very plausible case for owning their own marketing departments, probably independent websites, and possibly even their own distribution facilities, since fulfillment (pick, pack and ship) has very different properties from logistics (pallet- or truck-level) shipping.

Which is why the idea of hypervisor as operating system makes little sense (“Microsoft, operating systems, and organizational architectures,” Keep the Joint Running, 8/11/2008), but the organizational equivalent — decentralization — can be exactly the right choice.

There’s another argument in favor of decentralization, and that’s speed. Every good project manager knows the difference between putting tasks on a project plan and putting them into a request queue served by people who aren’t on the project team. Being served through a request queue causes unpredictable delays.

Whenever a business unit depends on corporate to get something done, it’s in the same situation. It’s a built-in trade-off between the more economical choice of shared services and the more nimble one of owning your own resources.

Business design and system design do have this in common: When an information system responds slowly, end-users and technical professionals frequently confuse unnecessary services with important but badly written services that use more resources than they should. And, for that matter, with well-written and important services, installed on an underpowered machine.

The same is true of organizations. The managers and employees in business units frequently complain about corporate, much as the Taxpayer’s League complains about the federal government: “Everyone knows” corporate/the government wastes a lot of resources without anyone knowing whether the waste comes from frivolous services or from important services run inefficiently.

Or, for that matter, from important services that run efficiently but we’d rather avoid the bill.

Imagine you’re Steve Ballmer, thinking about basketball.

In basketball, teams that hold a big lead wisely but boringly choose to run out the clock. They score no points themselves, but minimize the risk of making mistakes that would allow their opponent to score.

That works for basketball, where each game is self-contained. In the long run it’s a losing ploy for a business, because the clock a business must run out is of infinite duration.

It’s fair to say that Microsoft spent years running out the clock: What passed for new features in Windows was plugging leaks, and what passed for new features in MS Office was … was … sorry, I’m drawing a blank.

You’re Steve Ballmer and you decide you can sell a lot more product when new versions cause excitement, rather than ennui or trepidation.

The design decisions that might cause excitement also might cause avoidance, though — serious product innovation entails serious risks.

Which means your first step just might be to recognize that avoiding risk has become riskier than taking some. And so …

Microsoft already took the first step by moving its MS Office file formats to XML. Even with the complaints about Open XML’s poor documentation, any XML-based format will be easier to reverse-engineer than the old .doc, .xls and .ppt formats.

That means MS Office will, in a near-inevitable future, have to compete on features and functionality.

Which in turn explains the Ribbon. It is, while detestable in so many ways, a radical change.

Not all risks pay off, after all. That’s why it’s called “risk” and not “sure thing.” Whatever else the Ribbon represents, it was the opposite of running out the clock.

What’s next? Here’s a radical possibility: MS Office for Linux.

Most important change begins with culture change. If you’re Steve Ballmer and want to re-shape Microsoft’s corporate culture, driving everyone to create products customers want to buy instead of products customers are dragged into buying just to avoid obsolescence, you need to blow up the old product strategy of market dominance through the reciprocal lock-in of MS Office and Windows.

If MS Office ran on everything, Windows would have to stand on its own.

MS Office for Linux isn’t as far-fetched as it might seem. Microsoft already sells MS Office for OS X, after all. If it didn’t, Mac sales would plummet.

What would make Linux a stretch isn’t the damage to Windows sales. It’s the challenge of supporting all of those semi-incompatible distros.

Which would, if you were Steve Ballmer, lead you down one of two paths: Either build next-generation Windows as a services layer wrapped around a Linux core, or build it using the current hypervisor-as-OS buzz as the starting point.

Windows on Linux is philosophically no different from OS X, which is built on top of BSD Unix. The effort would be difficult, but predictable.

If you’ve missed the VMWare-press-release-driven articles on the hypervisor as operating system, the story goes like this: The full-featured OS is passe. Future computers will use a paper-thin hypervisor on which applications run directly, accompanied by only those services they really need.

It’s male bovine excreta (MBE). Ignore it.

There’s a reason modern desktop OSs are as bulky as they are: They do a lot.

Early desktop OSs did little more than provide a limited level of hardware abstraction. Windows, OS X and the various desktop Linux distros abstract, in addition, printers, fonts, and networks.

In other words, they provide centralized shared services. Applications built for a hypervisor architecture will be thicker. Presumably, few customers will want to buy (for example) a word processor that manages an independent collection of fonts that aren’t available to any other application; need their own collection of unique printer drivers; and take control of the network interface when they need to communicate with other systems.

Which brings up the real subject of this week’s column (at last!): The parallel between the hypervisor vs traditional OS “debate” and the perennial organizational question in business management: Centralization vs decentralization.

Centralized businesses are the traditional OS. They make extensive use of shared services (Accounting, Human Resources, and IT) rather than having the business units (applications) run their own. This allows each business unit to be skinnier than it otherwise would be. It’s how companies create economies of scale.

Decentralized businesses resemble the hypervisor-as-OS architecture, except there’s a compelling case to be made for decentralization.

Sadly, we don’t have the time and space to explore it this week. Maybe next week, if I don’t get distracted.