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.