Put very simply, are there advantages for the customer to open interfaces over proprietary architecture in UC?

I was involved in the beginning of the convergence/UC movement when it was "CTI" - when the "big deal" was that in communication we were moving from the very proprietary environment that was characteristic of the telecom world to more open architecture, which was characteristic of the data world.  It seemed to me, at the time, that this could be a huge benefit for the end-user customer.  No longer would they be at the mercy of a single switch vendor.  As convergence and then unified communications moved forward, the customer would have the option of choosing business solutions that were developed from best of breed products rather than "you take what we have to offer".  Yet, what we're seeing today is a tendency for some VoIP and UC vendors to revert back to proprietary architecture as a means of forcing customers to "buy what we have to offer or forget it".  There are "reasons" put forth of course for why proprietary is better... tighter integration, quality control, etc.... but so far, I'm not convinced that proprietary is better for the customer - only for the vendor. 

Speaking as someone who put a lot of effort into the creation of the UCIF, but also someone who has worked hard to push the UC technology envelope, I have a foot very firmly planted in each camp.  In fact, my belief is that open interfaces and proprietary interfaces are two sides of the same coin.

The main advantage of open interfaces is the ability to integrate systems from disparate vendors (aka legacy systems).  This requirement is part of the practical reality of the overwhelming majority of UC customers, especially those who are the product of one or more mergers/acquisitions.  The downside of open interfaces is:

1. Strict adherence to standards means commoditization (see later).
2. Standards never keep pace with innovation and the standards creation process is, by definition, almost always reacting to innovation (aka proprietary development).  Regarding 'The Internet Standards Process',  IETF RFC 2026 states: "In outline, the process of creating an Internet Standard is straightforward:  a specification undergoes a period of development and several iterations of review by the Internet community and revision based upon experience, is adopted as a Standard by the appropriate body (see below), and is published.   In practice, the process is more complicated, due to: (1) the difficulty of creating specifications of high technical quality; (2) the need to consider the interests of all of the affected parties; (3) the importance of establishing widespread community consensus;  and (4) the difficulty of evaluating the utility of a particular specification for the Internet community."
3. 'Standards' are made up of an array of options for implementation which are subject to varying interpretation by vendors. So even products that are 'standards compliant' are not necessarily (i.e rarely) interoperable by default.  Note that every IETF RFC contains the following text: "In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations."
4. Because of the above, standards compliant vendors are unable to achieve interoperability out of the box (which is what the customer really wants).  Since bilateral interoperability exercises are very expensive (i.e. repetivive) we must move to multi-lateral interoperability initiatives, such as the UCIF.

The downside of proprietary interfaces is self-evident.  The upside of proprietary interfaces is simple: innovation.  Living, as we do, in a capitalist society means that:

1. Every customer wants an array of choices for their purchases.  Having meaningful choices means that products must be differentiated.  Differentiation is born out of innovation.
2. Vendors (and their shareholders) have a right to expect a reasonable economic return on their R&D investments.  Innovation is what the technology industry does.  Proprietary innovation brought us the telegraph just as it brought us UC.
3. Customer choice is the Darwinian process which determines which innovations will thrive and which will die. 

A successful innovation is rarely offered to the market as an open standard by the innovator (human nature at work).  However, once an innovation has been proven in the market place, then other vendors will attempt to emulate it.  Then customers will then demand interoperability and standards will emerge.

Sometimes innovation stagnates, as it did with telephony in the closing decades of the 20th century.  Then, like the meteor that wiped out the dinosaurs (carefully chosen metaphor...), the internet disrupted the communications business and the innovation process started all over again.

Put very simply the title of this thread is what is really important. Ultimately this all comes down to the underlying architecture and what the architecture facilitates. This is not just about adhering to a specific standard. This goes to the service orientation of your platform. Integrating on multiple planes and not just at the SIP interface.

The idea that its necessary for proprietary approaches to be used to stimulate innovation is a false choice and one that typically has an alternate motive than just driving innovation.  Everyday we see examples of innovation around open APIs and mashups that have been created with this approach. In my view, its never necessary to go with a proprietary architecture solely facilitate innovation. Is it true that a more open approach could hasten the day when a given innovation becomes a commodity? I suspect there is some truth to that but if you embrace the open approach then the innovation possibilities never really cease. There is always the next innovation to work towards.

But lets look at the idea of proprietary architectures and innovation. I may get a specific benefit with a proprietary approach but that benefit is always short lived. The amount of competition in this space is staggering. If I embrace a proprietary architecture I have locked myself out of the larger innovation opportunity. I have few choices but to embrace what a given vendor is providing or start all over.

The hit on existing voice vendors has been their proprietary architectures and approaches. This is what the new players in the market have pushed in their marketing messages ever since Voice Over IP entered the enterprise in the late 90s and its been repeated again with Unified Communications. What has really transpired since that time is that the traditional voice vendors have become far more open in their approach while some of the new players are recreating proprietary architectures/approaches while at the same time calling them open. There is an absolute desperate need to have an honest debate on the competing architectures for Unified Communications and collaboration.

UCIF: I think the intent around UCIF is a noble one but it clearly lacks buy in from all of the vendors and as such this creates a fair amount of doubt among end users. Hopefully this will change and the opportunity to create real innovation and more importantly value for customers can and will be realized.

Paul McMillan

Strategy & Technology Office

Siemens Enterprise Communications