The Interop Stack...
In a post I made on June 14, I commented that Microsoft is careful not to forget that interoperability is, first and foremost, about business (processes and work flows), and, fundamentally, about people. The needs of both suggest how IT should behave...
This got some good feedback - moreso through hallway convos than formal posts – however, one post from James Governor made we want to revisit the topic in more detail. In his article, he offered that if “if People Ready helps Microsoft think more cogently about interoperability then I am all for it.” This surprised me a bit – although I appreciated his comments - because I think Microsoft has always thought deeply about interoperability (by design) but is now having to think more broadly about it in terms of an heterogeneous IT industry (by standards, by IP licensing, and by collaboration). Because the industry is becoming more diverse, and because different IT companies have different needs / drivers for engaging in interoperability practices, the way we achieve interoperability has to be more flexible.
This, of course, covers the technology aspect of interoperability, but the bigger question is what processes are we trying to support through technical interoperability and how can we optimize those processes to achieve the greatest results? This question brings us to the people and business side of the equation, which brings me to James’ comment regarding our Interoperability Council. He stated “If you're going to create an interoperability council its pretty much pointless without the participation of other vendors…”
Business is fundametally about relationships. Full stop. People have to work together to get things done, businesses have to work together to get things done, and technology has to work together to get things done (no news here I hope). As I stated before, the first two drive the latter (it cannot be technology first). In fact, I think of interoperability as a stack – building on the most common denominator of an economy and rolling-up to the most complex systems. Picture it this way…
· Workers collaborate (“…let’s meet to discuss the product features”)
· Collaborations are subsets of workflows (“…our product lifecycle is six months”)
· Workflows are subsets of organizational outputs (“…we launched the new product”)
· Organizational outputs are (can be) subsets of value chains (“…our product is OEM’d by company X”)
· Value chains are subsets of industries / ecosystems (“…we sell productivity sofware”)
· Ecosystems are subsets of economies…
This is not comprehensive by any means, but you get the idea. Now, consider the myriad requirements for interoperability that exist at each level of the stack. So, given the complexity of relationships required to ultimately deliver value to the market, we must look at how businesses need to work together and subsequently how people within businesses work together to determine the best technical / organizational / industrial interoperability solution. The Customer Council gives us a view into these issues. We also talk to vendors , but this council is about customers and understanding their pain points specifically. It is through this dialogue that we can clearly understand what they need out of their technology investments and how we can help them to realize full potential. From there, and with those requirements, we can plan, collaborate, and develop solutions – with competitors and partners alike - that will deliver the most value to our stakeholders.
