Interoperability by Design - Part I (Connecting People, Connecting Data and Connecting Diverse Systems)
I have been talking about Interoperability last few months and have to say in summary - for 4 people I have met, I have discovered 5 different definitions and views about Interoperability. So pause for a moment if SOA and Web 2.0 have multiple definitions and views, time to add Interoperability to the mix of often less understood, over communicated and misrepresented words.
I thought of looking at the issue of interoperability from a variety of perspectives. But first why should we care about interoperability—and why.
Interoperability matters to everyone—in different ways. What it means to you depends on the type of organization or group to which you belong and the type of problem you’re trying to solve. Of course, at its core, interoperability is about getting technologies to work together—once you cross this differences crop!!
Read Interoperability: what's in a name? — Doug Mahugh for another interesting perspective.
Consumers want to be able to take their music player, plug it into their computer, and get their music – regardless of who makes each device and what software they run. They want to use whichever scanner or printer they can get a great deal on, whichever camera or pocket device they get as a present. And they want those devices to work with their computers four years from now, even though they may have changed computers twice in the interim (viola)
Enterprise customers have a more complex way of looking at interoperability. It’s about solutions from different vendors working together—because, for enterprise customers, vendor interoperability means vendor choice. And vendor choice means the flexibility to adopt the solutions they want regardless of where those solutions originate. Vendor choice also means the ability to adopt the most cost-effective solutions, and the ability to negotiate lower prices to help reduce total cost of ownership. Vendor choice isn’t just a good idea—for many companies, it’s a requirement of their procurement policies. This isn’t just an issue within companies. It’s a major issue among companies that want to work together in consortia, virtual organizations, distribution or supply chains, or other forms of organization.
Customers want interoperability and their vendors want to give them what they want. But for the companies that sell the solutions that must interoperate, interoperability is both a blessing and a curse—and, thus, a source of some tension.
1. The Blessing: Interoperability can create market opportunities for vendors if their products work with, and add value to, the solutions that customers already have or want to buy.
2. On the other hand, enabling that interoperability means using standard or commodity components rather than proprietary components that may add greater value to the solution. It means trading competitive advantage for playing nicely with others.
Both are worthwhile goals and there can be legitimate differences of opinion about when and where one makes that tradeoff. Another concern for vendors is that standards, despite their clear value, can impede innovation. No product was ever born from standard-setting activities.
Interoperability means different things to different people – so how do we define it? Here’s a simple definition that gets more complicated the more you examine it: Interoperability means connecting people, data, and diverse systems.
“Connecting people” focuses on the workflows, the collaborations, and the knowledge sharing that take place within and among organizations at the level of social or interpersonal interaction. These are the operational aspects of interoperability.
“Connecting data” focuses on the need to integrate data stores, optimize information flows, and address semantic issues that arise when structured and unstructured data—such as databases and metafiles—must be exchanged. Here, we need to translate between different ways of expressing information.
“Connecting diverse systems” speaks to the technical processes that are required for interoperability, ranging from simple connectivity between internal systems to industry frameworks that facilitate value-chain workflows.
The “data and diverse systems” part of our definition, the technical aspect of interoperability, is, in many ways, the easiest aspect of interoperability to implement. All it takes is math and science. The more difficult challenge comes when you add people to the mix. Now interoperability moves into the more subtle and ambiguous domains of law, policy, and organizational structure. The questions cease to be about how you can enable interoperability, and instead concern how you should enable interoperability and, indeed, whether you should enable interoperability in the first place.
We will discuss more on Interoperability and what Microsoft is doing to help promote interoperability in the next Part of this blog. As you would have guessed by know Interoperability is an Industry issue and more complex when you look deeper into it.
