Why do we blame Microsoft for all our Windows interoperability problems? Let's be fair: We could blame IBM for not providing interoperability with Windows in AIX, z/OS, and i5/OS. We could blame Sun Microsystems for not providing Windows interoperability in Solaris. We could blame Hewlett-Packard for not providing interoperability in HP-UX, NonStop, and OpenVMS. We could even blame Novell for not providing decent interoperability in NetWare or Open Enterprise Server (OES). In short, there is plenty of blame to go around, so why do we heap most of it on Microsoft's doorstep?

Before I continue, let me be clear that I am far from being a staunch defender of Microsoft and its products. If you are a regular reader of my Hot or Not column, which appears in this magazine each month, you know that for more than a year, I went out of my way to avoid Microsoft technology in phones, gaming systems, handheld entertainment devices, and laptops. My goal was to live a Windows-free life. The point of this article is not to defend Microsoft; rather it is to look beneath the blame to find the source of the problem.

In my opinion, Microsoft has begged us to dump the blame for Windows interoperability problems on its doorstep — maybe not overtly, but certainly through its behavior over the years. Here are three examples of how Microsoft's behavior has set it up to be a lightning rod for interoperability issues.

#1: Early Behavior

When Windows NT was birthed (or cloned, if you prefer) from OS/2, it spawned little interest. Server computing in the early 1990s was dominated by NetWare servers, Unix variations, AS/400s, and other midrange computers. When NT 3.x came to market, most of the industry didn't see a strong value proposition. After all, plenty of alternatives existed. Even worse, NT 3.x fit poorly into existing computing infrastructures; it did not play well with NetWare, Unix, AS/400, or the other dominant life-forms in IT.

By the time Microsoft rolled out NT 4.0, it had learned some valuable lessons. Microsoft realized that NT had to fit into existing environments; NT had to play well with others. As a result, Microsoft developed a set of its own products to provide interoperability and also worked with third-party vendors to broaden the solution set. Thus, NT 4.0 came to market with products such as the SNA Server, Services for NetWare, Services for Unix, and a broad array of terminal emulation and file transfer products from third-party vendors.

You can argue about how good the individual interoperability products were, but you can't argue that they were, in total, effective. Providing interoperability with non-Windows platforms let Microsoft increase penetration of NT 4.0 — and also inherit a reputation for being responsible for solving interoperability problems. As I told my kids when they were young — be sure of your decisions; they might haunt you for the rest of your life.

Let's fast-forward from NT x to Windows Server 200x.

#2: Quest for World Domination

Make no mistake: Microsoft wants you to use Windows everywhere. And if you don't want to use Windows everywhere (silly you), Microsoft still wants you to use its technology in every nook and cranny of your infrastructure. In Microsoft's eyes, you should use Active Directory for all your authentication, Identity Lifecycle Manager for user provisioning, Systems Center for managing your infrastructure, and so on.

The theory here is simple (that theory being "world domination"), but there's a complication. To be pervasive in IT infrastructure, Microsoft technology has to embrace other types of servers. In many ways, this puts Microsoft in the same position it was in during the early days of NT 4.0 — Microsoft has to find ways to integrate with non-Windows platforms.

The Microsoft of today seems much less willing to invest in developing products that run on non-Windows platforms. (I would argue that this is a good thing because Microsoft isn't good at writing non-Windows code.) Instead, the Microsoft of today relies on third-party vendors to create integration products. Microsoft does try to take the credit for addressing interoperability, however — often pushing its partners aside to bask in the limelight.

This brings us to our third and final example.

#3: Chest Beating

If you've been to a Microsoft event lately, you've likely heard a Microsoft executive stand up and say something along the lines of "We've been listening to our customers, and they've been telling us that we need to address interoperability. So we are now investing in interoperability in all our products." Certainly, it's great that Microsoft is listening to its customers. And I'm sure that customers complain about interoperability.

But isn't Microsoft's hearing selective? Aren't customers also asking for better licensing terms? Aren't they asking for a version of Office that runs on Linux? Aren't they asking for Microsoft to explicitly support EMC's VMware? Why doesn't Microsoft "hear" those customer requests and address them? Maybe I'm the only one who hears those statements. Yeah, that must be it.

When I accuse Microsoft of doing a poor job of addressing interoperability (which is my position), Microsoft is always quick to ask, "Would you make the same statement about Novell or IBM or Sun or HP?" My answer is no, because those guys aren't getting up on stage and promising to fix my interoperability problems — only Microsoft is loudly beating its chest about it.

In other words, Microsoft is its own worst enemy here. If Microsoft didn't proclaim that it was going to fix the interoperability problem, people wouldn't have the expectation. Doh!

Psyching Out Microsoft

I'm not a corporate psychologist. If I were, I could probably spend several lifetimes analyzing Microsoft. I've never seen any other company so consistently fail to recognize the consequences of its actions.

I fully expect Microsoft to continue talking about interoperability and promising to address it in all its products — large and small. I even believe that Microsoft will elevate interoperability to the same level it gave security in its Trusted Computing initiative. Oh, and I do think that Microsoft and its partners will actually address some aspects of interoperability.

But interoperability is a broad topic. As long as companies innovate in their products, we will have interoperability problems. Microsoft could address every Windows interoperability problem on the planet as of today — but tomorrow something would happen in Linux or in the Java community or even in the Internet, and we would be facing new interoperability problems.

My advice to you is simple. You will struggle with interoperability concerns as long as you work in the IT industry. Solve your interoperability problems as easily and economically as you can and move on. Don't wait for Microsoft — or any other vendor — to solve them for you.

My advice to Microsoft is even simpler: Stop beating your chest and get back to making innovative products!

Sean Chandler is a computer and network consultant who has nearly 30 years of field experience. You can reach him at schandler@SystemiNetwork.com.