* How the contentious and lengthy standards process impacts IT
This is the fifth in a series of newsletters devoted to the standards process. This newsletter will discuss the impact on IT organizations of the contentious and lengthy standards process that was discussed in the two preceding newsletters.
As noted in a previous newsletter, the participants on the various standards committees typically represent vendors that have already done significant development of the technology under discussion. These vendors want the standard that eventually gets ratified to reflect their approach. Hence, one of the roles of the members of the standards committees is to advocate for the approach taken by their employer and to lobby against any approach, particularly if it is advocated by a direct competitor, if it is contrary to the approach taken by their employer. This jousting between vendors serves to exacerbate what would inherently be a lengthy process. The jousting also has the tendency to produce a standard that is the least common denominator of what has been suggested. By that we mean that the standard that gets ratified only contains requirements for what the majority of participants can agree on.
One of the affects of the lengthy standards process is that vendors often develop their own proprietary solution to the problem. Since a single vendor is typically much more nimble than a committee made up of tens of competing vendors, the proprietary solution gets to the market much quicker than the standards based solution. The advantage of this approach is that IT organizations have a solution that they can implement much sooner than if they waited for the standards-based solution. The disadvantage of this approach is that IT organizations are then faced with either migrating to a standards-based solution or sticking with a proprietary solution.
We will use the next newsletter to wrap up the discussion of standards by looking at SIP (Session Initiation Protocol). As we will discuss in that newsletter, we believe that for SIP to have an impact, it must be highly interoperable. However, after a decade of discussion, few SIP implementations are highly interoperable.
In the meantime, we want to hear from you. Have you looked at SIP? Have you implemented SIP? What do you think of the state of SIP interoperability today?
