Interoperability by Design - Part II (Connecting People, Connecting Data and Connecting Diverse Systems)
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.
- Standards@ Microsoft : Microsoft products and technologies support hundreds of technical standards such as FTP, HTTP, IMAP, IP, IPSec, Kerberos protocol, POP3, LU 6.2 protocol, MIME, SNA, SOAP, SSL, SNMP, TCP, TLS, UDP, WSDL, WS-*, and XML.
- Microsoft is actively engaged with more than 100 standards-setting organizations and workgroups such as ECMA, ETSI, OASIS, OMA, IEEE, IETF, ISO/IEC JTC1, ITU, and W3C.
- Microsoft engineers have authored or co-authored dozens of industry specifications and standards such as .NET CLI, C# CLI, XML, SOAP, WSDL, MTOM, UDDI, WS-Addressing, WS-AtomicTransaction, WS-Management, WS-Policy, WS-ReliableMessaging, and WS-I Basic Profile.
- Microsoft is working with industry to define a new generation of software and Web services based on eXtensible Markup Language (XML)
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.
- To enable interoperability by design through product engineering, community outreach, enabling access to Microsoft technology, and through standards engagements.
- To work with anyone, anywhere—including our competitors—for the benefit of our customers.
