This week, No Jitter takes an in-depth look at the platform of the future for enterprise communications. Join the debate as contributors weigh in with their perspectives over the course of the week.
Views from Dave Michels, Marty Parker, Kevin Kieller, Sorell Slaymaker, Paul Weismantel
Introduction
By Eric Krapf, No Jitter Editor
The PBX as a product may not be dead, but the idea of basing your communications architecture on a product whose core function is landline voice telephony switching—that notion is certainly declining in popularity, to say the least.
So what comes next (if anything)? What is the post-PBX platform, and what will the new architecture that’s built on that platform look like?
I posed that question to a half-dozen of No Jitter's regular contributors, and asked them to write 500-750 words in response to a set of propositions that I laid out for the sake of argument. Here are the "straw man" positions I gave them to react to:
1.) The PBX will be replaced as the core of the typical enterprise communications architecture.
2.) Centralized control of communications connectivity—be that connectivity wireline or wireless; one-to-one, one-to-many, or many-to-many—is necessary for the enterprise in order to maintain cost and policy/security control.
3.) Centralized control of connectivity does not equal centralized control of media traffic—i.e., all voice, video and data bits do not have to flow through this centralized platform—but in an ideal world, all the bits that provide call/session setup and routing would flow through it.
4.) Assuming you agree with #1-3, how does the enterprise go about migrating to that new platform? If you don’t agree with #1-3, how does your vision differ, and what migration strategy does your vision imply?
So I put the issues up for debate and asked our panelists to react to them, as a way of starting the conversation. I encourage our other contributors--and our readers--to weigh in as well.
READ PERSPECTIVES FROM:
Dave Michels    Marty Parker    Kevin Kieller     Sorell Slaymaker     Paul Weismantel
Long Live the PBX
By Dave Michels
Rumors of the demise of the PBX are greatly exaggerated. Just another "[fill in the blank]-is-dead" conversation. The tech blog equivalent of shock jock radio. I got news for you sunshine, the PBX isn't dead- it's evolving. Or, more accurately, it continues its evolution.
Communications are transforming: NoJitter is filled with PBX posts on collaboration, social networking, UC, cloud communications, mobility, etc. The role of the PBX is expanding. Its key role remains centralized control and management of voice communications. still critical but only a component. Today's modern UC, voice, and collaboration server (AKA PBX) is broader; specifically its solution includes voice, IM/Presence, mobility, CEBP/APIs, video, and collaboration. Not your father's PBX.
The important thing to note is your father's PBX wasn't his father's PBX either. The original "PBX" was corded--PBX operators manually switched people to physically connect calls. In the 1934 movie "Blind Date", Ann Sothern refers to "the PBX". The PBX evolved from its corded heritage to an electro-mechanical marvel that put thousands of operators out of work. Solid state technology transitioned the platform in the 1970s from analog to digital, and "recently" it transitioned to packet switching using VoIP. Did TVs die when they evolved past 13 channels?
During the journey, plenty of evolutionary stumps got formed. We "dial" phones because they once had dials. A turned-off phone was "on-hook" because placing the receiver on a hook turned it off. Even today, we still often describe the size of a phone system in terms of "ports" even though ports were phased out years ago. Today's PBX is software driven, packet switched, and carries little or no resemblance to the "Blind Date" co-star. It's called evolution. The PBX is no more dead today than it was when touch-tone replaced rotary dialing.
Lo and behold, nearly every "PBX" manufacturer in the 80s still around today offers "post-PBX era" solutions that just happen to still support PBX era equipment. Newer market entrants are only viable because they worked hard to emulate years of call control development.
Evolution aside, this "post PBX" PBX is a real-time computing superstar. Endpoints and networks are smarter--centralization has more to do with administration that routing. Peer to peer communications makes an Erlang as useful as a shiling as a unit of measure. Gone are the older proprietary hardware-based designs (and their long product life-cycles). The PBX is a diversified software-based powerhouse of communications, able to dynamically switch multiple traffic types across multiple time zones with tentacles extending into mobile and desktop domains. I happily embrace its future.
READ PERSPECTIVES FROM:
Marty Parker    Kevin Kieller    Sorell Slaymaker    Paul Weismantel
An Architectural View of Enterprise (Unified) Communications Architecture
By Marty Parker
Eric Krapf raises important questions about the future of Enterprise Communications Architecture. Certainly there will be several viable architectures over the next decade, so it seems the question is, "What architecture(s) will lead in enterprise adoption?"
The choice of an architectural model within an enterprise will depend on that enterprise’s business requirements and on the overall IT architectural standards that most likely already exist. In the UC world of "communications integrated to optimize business processes", communications functions are most likely to become "Services" in a Services Oriented Architecture. In that context, an enterprise can build on their existing applications architecture to provide communications to the users in the context of the business roles, functions, tasks and applications being performed. In the cases where a common "utility" user experience is preferred by the enterprise, that will most likely be driven from a current enterprise standard user experience, which will favor e-mail or instant messaging or web portals or shared (possibly social) workspaces.
Some consistency may emerge across industry sectors, but there is unlikely to the monolithic architecture we have been used to during the PBX era. Views of architectural evolutions are provided by (1) a UCStrategies.com post that extracts from a UniComm Consulting white paper; and (2) a Gartner Research report (G00158462) on the distribution of UC architecture and the effects on organization of communications in the enterprise.
In those contexts, my comments on Eric's points and questions are:
1.) "The PBX will be replaced as the core of the typical enterprise communications architecture."
Response: The PBX was already replaced as the core of the typical enterprise communications architecture. By the late 1990s it had been eclipsed by e-mail; by the early 2000s it was eclipsed by the mobile cellular communications network (wireline voice traffic peaked in 2001, according to Nokia); by the mid-2000s it was further eclipsed by enterprise-class Instant Messaging. Note that the leading enterprise IM systems include presence, peer-to-peer voice calling, peer-to-peer video calling, and desktop document and application sharing; the same is true for the leading public IM platforms such as Skype.
2.) "Centralized control of communications connectivity--be that connectivity wireline or wireless; one-to-one, one-to-many, or many-to-many--is necessary for the enterprise in order to maintain cost and policy/security control."
Response: A well-designed architecture is appropriate which can be based on communication patterns required for the business processes, but this may not require centralized control. For example, it may be more cost effective to leave mobile-to-mobile or mobile-to-client calls on the public wireless network (under a corporate plan) than to route them under control of an enterprise communications controller. For another example, already illustrated by Cisco, IBM and Microsoft, it may be appropriate to distribute conferencing resources across both the enterprise wide area network (for internally-focused meetings) and a hosted conferencing service on the public network (WebEx, Lotus Live, Office 365) to truly minimize costs (of both systems and of gateways, ports or even "trunks").
3.) "Centralized control of connectivity does not equal centralized control of media traffic--i.e., all voice, video and data bits do not have to flow through this centralized platform--but in an ideal world, all the bits that provide call/session setup and routing would flow through it."
Response: Based on examples shown in 2. above, the decisions about networks and media may be manageable by policy rather than centralized call/session control. However, if centralized control is either a preference or a requirement (e.g., in some regulated industries), then it would require several centralized architectural elements, not just one central platform. Those elements could well be: an identity management element that validates credentials and permissions and would manage identity across multiple applications, not just communications; a session management element that establishes and brokers session activities in a Service Oriented Architecture or Web Services model, as suggested; and a user interface element to interact with the user or with the user's application portal (e.g. if they are calling from Facebook or Twitter as in-vogue examples). Logging, management, and reporting could be thought of as Services in the SOA, or could be extensions of the session management. Note that session management is already being delivered on a variety of platforms other than IP Telephony systems, as suggested in the response to point 1 above.
4.) "Assuming you agree with #1-3, how does the enterprise go about migrating to that new platform? If you don’t agree with #1-3, how does your vision differ, and what migration strategy does your vision imply?"
Response: My variations to the concept of "that new platform" are outlined in the responses above, both in the view that it will not be one (the) platform, and in the view that communications will be an application within an SOA and the enterprise’s IT applications architecture will drive the options deployed. The suggested steps to this future are:
(A) the enterprise should really understand the use cases (usually 4 to 7 uses cases per enterprise) for integrating new unified communications elements into their business processes to capture the major improvements possible as a result of the radical and disruptive shifts in communications technologies and methods;
(B) the enterprise should select the optimal architectural approach for each use case. It is perfectly OK, even expected, that more than one architectural option may exist within a single enterprise based on the diversity of the use cases (e.g. the wireless communications devices used by delivery drivers certainly don’t have a PBX extension assignment/license, but those devices do provide the communications needed for those roles, supplemented by cell phones where appropriate). The options for these use cases seem to be:
Option 1. A few of the use cases may remain in traditional communication models (i.e. only voice communications with only a desktop phone and totally separate from e-mail communications) and those users can remain on their existing platforms (voice and e-mail) or can migrate with minimal effort to the latest IP PBX and e-mail application software packages.
Option 2. Communication-enabled business processes (CEBP) often presented to the user as communication controls embedded in the user’s application software package (ranging from horizontal application platforms [SharePoint, Quickr, et al.] to vertical industry packages [SAP, Salesforce.com, Cerner Healthcare, etc.]) typically based on integration via an already existing SOA or web services platform in the enterprise, or
Option 3. A common "utility" user interface that will likely evolve architecturally from the user experience already installed from one of the enterprise’s current user experience vendors, and based on that vendor’s version of identity management, session management, and user interface management.
Note that these options are reflective of those described in the UC Options sessions at Enterprise Connect, i.e. evolving from the Voice platform (Option 1 and one choice in Option 3); evolving from the Desktop business software (e-mail, IM, doc processing, collaborative workspaces) platform (one choice in Option 2 and one choice in Option 3); and evolving from the business application software platforms (Option 2).
READ PERSPECTIVES FROM:
Dave Michels    Kevin Kieller    Sorell Slaymaker    Paul Weismantel
Two Migration Propositions
Kevin Kieller
Not much to disagree with related to points 1 to 3.
It seems clear that the "traditional PBX", which focused solely on voice, is being replaced in most organizations. Every traditional PBX vendor has morphed or augmented its original voice offerings to include instant messaging, presence, and conferencing modalities. Newer vendors, such as Microsoft, offer strong voice capabilities but the core is built around a user-centric profile and not a device-centric extension number.
I believe point 2 is mostly correct. Centralized control of all communication modalities enables better security and financial controls; however, many solutions today do not centralize the control of all communication devices. I believe it is more important to be moving towards a centralized control system than to "hold out" and do nothing until all communication devices can be managed from a single console.
I agree with point 3. Centralization of control does not and should not mean trying to push all the media traffic through a giant, central bottleneck. Instead, centralizing directory, policy, reporting and signaling (likely based on SIP), helps establish centralized control but this should not preclude a peer-to-peer flow of media traffic once a session is established.
In terms of how to move to a new communication architecture, I offer two specific propositions:
4a) Choose one vendor and implement that vendor's complete communications product line--A "best of breed" approach currently does not work for unified communications. Perhaps in the future stronger standards will allow better "mix and match" solutions, but for today multi-vendor integrations often mean technical and end-user challenges.
4a) Assimilate your traditional standalone telecom department--with voice being simply another application, often tightly coupled with other applications such as IM and email and running over the same data network as other applications, keeping the telecom group arbitrarily separate slows down newer communication implementations. Troubleshooting a unified communication problem requires cooperation from the network, directory, email and application groups. A separate telecom group does not foster the necessary working relationships to facilitate this.
READ PERSPECTIVES FROM:
Dave Michels    Marty Parker     Sorell Slaymaker    Paul Weismantel
The Role of Session Management
By Sorell Slaymaker
As organizations migrate to Unified Communications, which is the integration of people, processes, information, and technology to enable effective and efficient communication, in a multi-channel/device world, the integration that glues all this together is done through Session Management (SM). New SM products are coming to market that aim to provide this capability. In the quest to provide the right person(s), at the right time, in the right context, with the right information, on the available device/network, quickly, and easily, these next generation SM products are taking out all the intelligence of the traditional IP-PBX. As SIP matures and end devices continue to evolve quickly, along with application stores that offer infinite capabilities, the SM products provide the glue and value for UC. An organization's strategic UC provider will be the vendor which provides their Session Management.
Currently, Session Management products are used primarily to integrate IP-PBXs together. The integration is required because of the sheer size of an organization, and a single centralized IP-PBX system cannot support all the end points or to integrate a bunch of disparate IP-PBX and other communication platforms. In the SIP world, the SM platform plays the role of the master SIP proxy. The SM provides:
1) Dial Plan Administration--In an E.164 10 or 11digit dial plan administration, each IP-PBX is assigned a range of numbers that it is responsible for. If one of the phones on an IP-PBX wants to dial a number that does not reside within this IP-PBX, this IP-PBX will check with the SM to find out where to send the call.
2) Call Admission Control (CAC)--In a VoIP network, the amount of bandwidth is usually constrained, so the number of concurrent calls going out over a WAN has to be managed. Basic SM capability will restrict total number of calls, no matter what the call type. More sophisticated SM products allow overall CAC management along with granular CAC based on call type such as inbound customer calls vs. outbound employee calls, conferencing, or 911.
3) Calling Policy Management--Rules on where to send a call. For example, a caller may be dialing an overseas number, and based on the calling and called phone number, a rule can be set up to go out a different trunk group to ensure optimal costs and/or quality. Some companies have Skype SIP trunks for this capability. Calling policy management is different than call routing, which is typically found in contact centers. Additional capabilities include:
a. Load Balancing--Balancing calls at the SIP level
b. Throttling--Centralized administration of total number of new calls per second that are allowed
c. Identity Aware--Assigning classes of service so that callers have different services available to them depending on their role
d. Policy Interface--Ability to use other external applications to define, manage, control, and support calling policies.
4) Logging & Reporting--Both real-time and historical reporting of all calls for an organization. (Types and number of calls (LD, Local, Toll Free, International, Emergency,...)
The below figure is an UC architecture framework. The session layer (blue shading) is what glues everything together. In the past, a PBX combined the functions of the session and media layers.
As organizations adopt video, presence, and other devices and applications that use SIP, the IP-PBX is evolving to support muti-channel communication and separate the session and media layers. Organizations that have traditionally used CTI platforms to add relevant data and process integration to communication, are looking to blend this capability into Session Management.
As SM products mature, CTI will fade away and SIP will be used to add data to the communication. This process is occurring slower than anticipated, but vendors are now realizing the importance of Session Management. A few of the reasons products are just now coming to market are:
1) Realization of the Complexity of Communication--Large organizations have thousands of rules on how communication should occur, and these rules are growing due to regulations, optimization of resources/employees, and
2) There is not a single vendor that can provide the entire UC stack--Organizations initially adopted a strategic VoIP platform, but as more channels of communication evolve and use SIP along with the desire to add information and processes that enable collaboration, a single vendor stack does not exist.
3) SIP end-to-end--Most VoIP/SIP communication is done within islands, both internal, and external to an organization. In the next 3-5 years as these islands expand significantly and are interconnected, the true value of SIP can be realized versus the least common dominator world we live in today.
4) Critical Mass--As 4G cellular networks migrate to VoIP/SIP in the next few years, the industry will get to a point where over 50% of all calls are VoIP and the desire to add video, presence, location...will be strong.
How long will it be until a customer with a smart phone can call a contact center and not only talk with an agent, but share pictures, video, location information, and web pages? Imagine how empowering this will be for both the customer and an organization, but also imagine the complexity it will introduce.
Organizations who are starting to realize the future of UC are searching for the strategic partner that will glue their communication infrastructure and applications together. The race is on!
Side note: Architecturally, SIP registration, which is where a SIP endpoint like a SIP phone registers to an IP-PBX, occurs at the session layer, but is usually not part of Session Management.
READ PERSPECTIVES FROM:
Dave Michels    Marty Parker    Kevin Kieller    Paul Weismantel
Avoid Homogenous Approaches
By Paul Weismantel
I would not agree with basic premise underlying points 2 & 3. Maintaining cost control & security are functions of agreements with suppliers on an individual basis and in many ways centralizing signaling and routing control paints a bigger target on your infrastructure from a perspective of risk and exposure to a catastrophic failure. To avoid this, extreme redundancies are demanded, which by definition works against lower cost.
In addition, one-size-fits-all PBX replacement excludes the opportunity to leverage the best solution for each user community within the enterprise network. In order to best serve the mission, desegregating the "system" and considering a mix of all options will drive what is deployed down to what is needed. Cost containment is best derived from avoiding deployment of the highest common denominator for populations that only need basic service.
This approach also offers the chance to apply the leading edge offers to smaller populations that are best served by alternative solutions (e.g., voice services embedded in a business platform rather than as a separate enterprise network).
So, I would propose starting with a new definition of user communities (one or more functions) within the enterprise based on their specific internal & external communication needs, and look to meet each team's mid- and long-term needs. You may end up desegregating the system or not, but at least the opportunities are not lost by adopting the initial homogeneous jumping-off point.
READ PERSPECTIVES FROM:
Dave Michels    Marty Parker    Kevin Kieller     Sorell Slaymaker
