Here’s where we used to be when it came to interoperability. 1980 was the best of times and it was the worst of times. It was the best of times in that, as long as you stayed with the products of a single vendor, you could be reasonably certain that everything in your infrastructure would work together, from the solutions and applications down through the operating system, computers, and other hardware.
But the price for this type of interoperability was too high. Customers were locked into a single vendor’s solution, a single vendor’s technology—and a single vendor’s prices. Because few vendors could truly meet all the needs of their customers, those customers started adding solutions from other vendors—and built the “smokestack” or “silo” systems with which many customers are still saddled. They built towers of Babel within their own organizations—systems that couldn’t talk to each other or share information. And, of course, as soon as a company tried to share information with others, it ran into this same problem of interoperability. These systems did what they were designed to do very well. They just weren’t designed to do interoperability
Today, of course, interoperability exists at each of these levels. It has to. Customers are not going to return to the restrictions and high prices of single-vendor environments. That means that any vendor that wants to play in today’s marketplace must support interoperability. The evolution of single-vendor environments into multi-vendor environments adds an entirely new layer of complexity to IT environments. Moreover, how interoperability is achieved is left to the vendor, and different vendors offer different ways to interoperate and different degrees of interoperability, which adds yet another layer of complexity to the IT environment.
As consumers, companies and governments look for new ways to use technology—for new forms of entertainment, new means of competitive and strategic advantage, and new ways to address public policy needs—they will require more connectedness, more interoperability. The quantity and nature of the connection points will increase and those connection points will encompass types of interoperability we haven’t seen before.
With the requirements of interoperability so multifaceted, it should be no surprise that the way to achieve interoperability is equally multifaceted. We believe that interoperability must be achieved by design, and that that design includes four key elements: product engineering, community outreach, access to technology, and standard-setting engagements.
1. Products : The “products” component is about building interoperability into products so that they are interoperable out of the box. This requires everything from documenting protocols, data formats, and APIs, through providing complimentary tools to enhance interoperability. For example, all of Microsoft’s key products include publicly available resource kits, controls, SDKs, DDKs, and connectors to promote interoperability. All of these products are designed to be more than interoperable—they’re designed to promote opportunities for interoperability. In the case of Windows, there are more than 50,000 application providers building products that work with our software. There are more than 100,000 hardware devices that work with Windows. That’s interoperability.
Some Examples:
Microsoft Not a Cathedral; Open Source Not a Bazaar (ASP.NET AJAX works on Linux)
PHP on Vista with IIS7 ; PHP on IIS7 w/FastCGI
2. Community : As those numbers suggest, the community for Windows-based products is vast. That doesn’t happen by accident. It happens when we seek ever broader ways to work with others, through industry collaborations, partner programs, training and certification, even collaborations with companies that are sometimes our competitors. In the past year we’ve announced quite a few collaborations with companies that otherwise compete with us, such as JBoss, Sun, SugarCRM, XenSource, and the OpenSource providers. We collaborate with our competitors because it’s in our customer’s interest that we do so. We want Windows customers to be successful using whatever technologies they want to use.
Other vendors aren’t the only members of the interoperability community. An important new development to promote interoperability is the Microsoft Interoperability Community Executive Council. It’s composed of customers throughout the economy and government and will convene every six months. It will provide yet another way for us to listen to customers on this issue.
Some Examples: One-page Java-to-.NET Interop cheat sheet
Connecting Office Applications to MySQL and PostgreSQL via ODBC ; Windows Media Player Firefox Plugin ;
Microsoft-Novell Interoperability Lab – Sneak Peek; Microsoft Forms Interoperability Council
Leading Identity Management Vendors Join Microsoft to Demonstrate Federated Identity Using Web Services
3: Access : Hand in hand with community outreach is the issue of providing that community with access to Microsoft technologies so that they can build interoperable solutions of their own. This is nothing new for Microsoft. We’ve made our source code publicly available for years so that others can create complimentary products. More recently, our Open Specification Promise is a way to address the legal issues surrounding interoperability – it’s a way to put a structure around our technology to make it available to everyone who wants to build a complimentary product, so they know they can do so without concern for patent infringement.
Under this agreement, we’ve released technologies as diverse as Web services specifications, Sender ID, and the new virtual hard disk image format specification. We also make our technology accessible in specific arrangements with other vendors. For example, we’ve licensed ActiveSync technology to Nokia so that its customers can access their Exchange Server e-mail from their Nokia phones. There’s no standard involved here—it’s our technology. But we made it available to Nokia because our common customers are the winners.
Eg : Microsoft Open Specification Promise
4. Standards : We ship more than 500 different products every year and all of them support relevant standards. Our deep engagement with the standards-setting organizations, consortia, SIGS, and other groups involves hundreds of dedicated employees. And the work of implementing standards involves thousands more. Standards are, of course, a crucial component of achieving interoperability. We believe in standards. We work with hundreds of standards-setting organizations and support thousands of standards in our products.
Eg; Identity Theft Prevention and Identity Management Standards Panel
This work is only going to grow, for us and for the industry, because as new technologies emerge, and as solutions become increasingly multi-layered, the number and type of standards we need will increase. But there’s an important difference between how Microsoft views standards and how some others view standards. Some say that standards alone are the way to interoperability. I hope I’ve demonstrated that we believe in standards too—but standards don’t create interoperability. They only help to create the opportunity for interoperability. How standards are implemented through product engineering, community outreach, and technology access is crucial.
There’s been a long-term trajectory to Microsoft’s approach to interoperability. A key point in our approach came with our shared source code program back in 2001. But it’s grown rapidly over the years, and especially so over the past year.
With Microsoft’s increased commitment comes an increased promise: To remain true to the principles I’ve outlined here for helping our customers access their data and bridge disparate technologies.
On the "products" point, I can think of lots and lots of examples. Just examining the application platform or middleware space, what about IBM's MQSeries (WebSphere MQ)? It certainly runs on Windows servers and works with MQ running on any other platform. But more, any .NET app (running on Windows) can connect to MQ, running on Windows or not, and can do transactional updates. And MQ works with System Center for management. Likewise any .NET app can connect to Oracle database on any platform. and so on.
Daniel has some good commentary on Microsoft's broad interop efforts and strategy. Dino says check it
It seems you're missing the point of THE Tower of Babel. If enterprises in the 80s had anything like a Tower of Babel it was, perhaps, EDI. XML is nice to read, and DTDs are getting us somewhere, but we still don't have a Tower of Babel.
We could assume things in other terms. The regulation of the marketplace seems to be the result of combined elements. Financial strength, engineering, spirit, and emotions, or movement. The possibilty for a large number of person to exchange within the technology a sum of crucial informations is a chance given for new beliefs to seal some elder ideas into the mind of people bound to work together. Considering the weight of information as a stream moving from one place to another, we can keep on believing that the new technologies cannot be anything else but the result of relevant engineering. It had to be simple, complete, not ultimate, and easy powered. Rather than a ancient model, I would think things with the eye of a biologist. The information is a product of the physical world, designed by it, that is still existing without the concept of victory or frustration, and wich is supposed to be universal. "Time" is a vital pilar for the customer, as long as time is product of the human world. I think that things have changed a bit, since a large number of person has become more responsible to answer to this simple question : what about "my lifetime" ? If anguish becomes the master of acts of a marketplace, the result will be ridiculous, in terms of possibilities, the product will be lost, and finally, the customers will loose vital informations, eaten by time itself. Technolgy provides pulsating signals. Customers provide individual answers within the silences of this legacy. A marketplace cannot be worked out without runners, rulers, and a bit of philantropy.