Microsoft, operating systems, and organizational architectures

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.