This post is a follow up to Dave Michels' piece last week, "Apps with a Voice." My perspective is a little different, although we both seem to believe that the results will be the same.
Gartner projects that global enterprise software revenue this year will be $324 billion with a 6.6% growth rate. If you calculate the growth, it comes out to just over $21 billion, or a little more than the size of the global enterprise telecom business (hardware and software). If telecom were growing, then industry insiders could be confident that enterprise telecom's unique value proposition could survive the onslaught of a desk-space competitor that is 15 times its size and growing. Unfortunately, as an industry, enterprise telecom is not growing, and it is reaping what 130 years of oligopoly has sown.
One key feature of oligopolies is that they do not move fast. Last week I was discussing a PBX replacement with a customer, and it all came into focus. My customer has made the strategic decision to engage their IT department in formulating a strategy for moving forward. The moment of truth came when the IT manager asked why he should replace a 20-year-old technology platform with a different brand that is running the same 20-year-old technology. Politically, the telecom manager is still advocating for the purchase of another legacy solution, but the IT guy cannot find a single business reason for moving in this direction. This is a microcosm of the larger dilemma that the enterprise telephony industry faces.
It was 1996 when Henning Schulzrinne and Mark Handley invented Session Initiation Protocol (SIP). Since then, the enterprise telecom industry and carrier industry have done everything that they can to make SIP, a peer-to-peer technology, work like legacy time division multiplexing (TDM) technology. Session managers and "SIP trunks" are the manifestations of this effort to make SIP work like the rest of telecom.
Today, enterprise software companies are beginning to see this as an opportunity to deliver easy-to-use communications interfaces that are far more contextual and a fraction of the cost of legacy TDM architecture.
For the near-term, there will be places where legacy technologies create barriers that prevent the new breed of telecom tools from entering. Enterprise contact centers are one example. A high-functioning contact center often has automatic call distribution (ACD), interactive voice response (IVR), quality monitoring, computer telephony, scheduling applications, real-time adherence applications, forecasting applications and myriad niche tools that make the contact center operate in an efficient manner. Change one of these applications, and you risk breaking another. In situations like this, the legacy will stick around for many years.
Plain old telephone service (POTS) or administrative access to communications is very different. Without the complex integration requirements noted above, these types of communications interfaces will change rapidly. Lync is living in this space, and they are killing it.
Today there are many vendors that have products for an alternative approach to enterprise telecom. Microsoft, Cisco, Avaya, ShoreTel, Interactive Intelligence, Unify and Aspect are just a few of the bigger names. And each has their own form of proprietary hooks.
Notably, Microsoft draws more than 95% of their revenue from things other than telephony. Recently, Microsoft recognized that there is a customer side of communications that needs to be addressed. As a result, it has delivered some usable integration between Lync and Skype, but you still have to load the Skype client. Add Google's alternative efforts with WebRTC (downloads are unnecessary) and you can see an easy path forward for enterprise software vendors to build "Communications as a Feature" into their products.
In a comment on Dave Michels' original post, I simplified my thoughts by saying: "Thick clients will go the MSFT route. Thin will go the WebRTC route. Communications Enabled Business Processes (CEBP) is the telecom perspective. 'Communications as a Feature' is the software developers' perspective."
Other comments on Michels' piece redirected my thoughts to APIs; however, upon reflection, I think that the real driver will be the skills already in use within the software development community.
Consider this comparison: The enterprise telephony business has approximately 5,000 SIP programmers; in contrast, I estimate that there are 1 million Microsoft Certified Programmers (for the MSFT approach), and Oracle estimates that there are 9 million JavaScript programmers (for the WebRTC approach). So that means that the enterprise software business has approximately 2,000 developers who can create real-time communications solutions for every one enterprise telephony SIP programmer. Add the cost advantage that either of these new platforms offers and the contextual benefit of business process integration, and a vision of the future comes into focus.
The Society of Communications Technology Consultants (SCTC) is an international organization of independent information and communication technology (ICT) professionals serving clients in all business sectors and government worldwide.
