We all know that most customers hate vendor lock-in. They want the freedom to switch vendors whenever they want. But still, they also want all the features and functionality that vendors can offer them. And if the value is high enough, customers accept being locked in. The iPhone is a good example, the applications you buy on the iPhone cannot be moved to a new Android phone. However, there is a limit to this acceptance: if the SMS and MMS messages from an iPhone could only be read on other iPhones, then people would hesitate buying iPhones unless all their contacts also had iPhones. So, acceptance to being locked in is related to the perceived value it brings.
This is where standards come in. By implementing standards and being very vocal about “our standards-based strategy”, a vendor can make the customer comfortable that lock in is avoided. In reality, most customers are unable to resist the temptation to implement vendor-proprietary functionality (and it is hard to know when that line is crossed), so they instead settle for a compromise where a multi-vendor environment is possible, but where the most value is achieved when a “preferred vendor” is chosen. In the communications world, the word “interoperability” is thus important as the level of interoperability a vendor implements will determine how much value you as a customer can get when you choose not buy from the “preferred vendor” or communicate with somebody else using another vendor. If there was a standard for smileys in text messages and the iPhone did not implement that, but used a proprietary smiley method, well, then you could only use nice-looking smileys to other iPhone users, but they would be unreadable on non-iPhones.
However, there is more to this, in the real world, even within a single vendor, you have several generations of products and these older products may become obsolete quicker or slower dependent on how much focus the vendor has on interoperability. Again using the smiley example, if smileys from an iPhone 4 would look crap on an iPhone 3, the cool smileys are starting to become really useless.
And this is a reality in the video/telepresence world as well. For the customers it is really hard to see all the caveats that come with that new shiny feature. In video, the SVC media encoding/decoding profile is an example where the consequences can be hard to understand. It’s confusing, because SVC is without doubt a standard, but different vendors’ implementation of SVC are not automatically interoperable because the mechanisms required to reach interoperability have not been standardized. So, standard vs non-standard is not even black or white (see this exchange to see how confusing the whole SVC discussion really is).
If I still haven’t lost you, we are starting to get to the core of the standards issue: how vendors execute on their “standards-based strategy” found in their marketing material. In a previous post, I wrote about the Tandberg Multiway feature and the different options we had in trying to get it standardized. I tried to highlight the challenges and dilemmas in trying to increase the value customers get from our products through innovation. When you as an engineer create a new feature, you have the following options:
- Only use standards-based mechanisms and if nothing is available, don’t do it
- To the extent possible use standards-based mechanisms and if nothing is available, make something proprietary
- Be inspired by standards and implement something proprietary
- Just make something that will fix the problem, don’t worry about whether there might be a standard for it
The engineer’s choice is dependent on how clear the strategic direction is: should always standards be used, even if they may not really fit and it would have been easier to just invent something? Once a standard is chosen, can you add your own goodies? And if you do, will your standards-based approach really work with other vendors’ products? Or is it even important? We can still market it as standards-based (true), we just don’t tell what does not work (we haven’t even tested)…
Once you have implemented something new that is not a standard, you may want to make it a standard because management says it is important that we are standards-based. If you did your research, used standards where you could and maybe talked to the people working in standards-organizations, you may, through quite some effort and time, get something very similar to become a standard. Or, you could save some time (if you work for a big company), post it somewhere and call it a standard and hope that it becomes a defacto standard because your company’s market power will force competitors to implement your way of doing it because THEY want their products to interoperate.
However, even if you didn’t do your research, so what you did partially overlaps with existing standards or is done in a way that conflicts with standards, you can STILL post your work as a standard and hope it becomes a defacto standard (if your company is big enough). Note that all these approaches qualifies for using “standards-based” in the marketing material…
To successfully drive a defacto standard, three things need to be true:
- The market muscle of your company must be big enough
- What you are doing has not already been done widely and must be acceptable to other vendors, i.e. they see they can solve some of their problems using your defacto standard
- Customers actually get true value from your implementation and are willing to stay within your closed defacto world (until others adopt it)
Very often, successful defacto standards go through a standardization body and are slightly modified to take into account other related problems that need to be solved and that are important to the industry. But the majority of attempts at creating defacto standards fail.
Which camp do I belong in? I believe my previous posts show my conviction that we as vendors in the video and telepresence industry should pro-actively push the bar higher on what is considered the right level of interoperability. That will give more value to our customers, and I firmly believe that a standards-based strategy is way more than a marketing buzzword, and if your customers believe you and you prove that you execute on it, it will be a clear differentiator because your products offer more value to the customers. It does have a cost for vendors and it is by no means easy. I believe working through standardization bodies is key, however, most often somebody needs to lead, get something done, and then show it to the others. BUT, I do not believe in dreaming up something that is not based on existing standards where possible and then forcing it down the throats of others as a defacto standard.
Are you now able to better understand your vendors’ approach to standards? And as an engineer, do you share this analysis of your options and dilemmas?
RSS - Posts