Busy, busy, busy. So many things going on at once. I have been meaning to write about a few items all week and just haven't gotten to them. In the middle of all the excitement around the BRM, there have been some very positive steps taken on the interop front.
I wrote a simple news blog post about the basics of the interoperability principles announcement. There was a good deal of press coverage and most of what I saw had reserved optimism in it. In other words, Microsoft said the right thing but words are just words. Even Linus Torvalds seemed to express that sentiment.
So, the question becomes one of walking the talk. The scope and reach of the interop principles represents significant work to be done over the period of years, not days or weeks. There are some good steps being taken now - but these principles are extensions of more than 2 years of focused work on interop, and they will reach well into the future. But - rather than waiting a few years, there are a few immediate items worth looking at.
The principles provide an overall set of guidelines that will drive specific tactical actions over an extended period of time. Each individual action represents a building block in the bridge that organizations need to see the effects of interoperability in the real world.
Any software company considering the future of ICT for its customers must take into account the changes coming about through the constant move toward ubiquitous connectivity coupled with the opportunities opened up by the inexorable increase in processing power. Neil Macehiter of MWD Advisors (blog) provided me with some real insight on interop from the customer's perspective a while back. He cautioned that the perspective of a commercial software producer and that of a customer are very different regarding interop. Producers think about products and the boundaries of those products. Customers look at solutions and within that context interop is necessarily ignorant of product boundaries. So an underlying truth of interop is one of balanced friction.
Isolated innovation tends to be interesting but ultimately of relatively limited value. Innovation smoothly integrated into a larger set of complementary technologies and packaged for easy implementation, support, etc. has real value. (Why have Linux distributors vs. just downloading all of your own components? Why does MS Office as a product suite do better than any one app alone?)
Overlay these two things (Neil's insight and my observation on innovation value) and you start to see where interop becomes challenging. A basic precept of commercialization is that uniqueness increases value. In other words, competitive differentiation happens for a reason. But the need for interop is one where customers are looking to connect their people, or their data, or their diverse systems - and that is where they want those barriers of "uniqueness" brought down.
The interop principles from Microsoft fundamentally are about establishing the sign posts on the road for high volume products (think Windows, SQL Server, Office), each with the defined barriers of a commercialized product, so that interoperability may coexist with the commercial interests of the producer of the product.
Personal note - it was so nice writing a blog posting about something other than the ballot resolution meeting. :-)