3 Challenges of Unified Comms on Unified Networks

I was asked to stand in for another speaker today at IPEXPO as a "pathfinder". My talk covers the key questions delegates should be thinking about when deploying enterprise unified communications (UC) services on converged networks. This is an edited version of my speaker notes that I'd like to share with you all, since it raises important issues.

There are three key issues, namely the interface between UC and:

• The enterprise network
• The enterprise systems and business processes
• The organisation and people

UC and unified networks

The problem we are trying to solve is to run multiple traffic types on converged packet networks. We mix voice, video, data -- and each has different quantity, quality and cost needs.

The key unanswered question is how to manage the quality of delivery and perceived user experience. The problems we see come from an over-focus on getting quantity right, at the expense of quality.

The received wisdom is to divide up the network by quantity using a bandwidth metaphor. We partition the network into VLANs, VPNs, SIP trunks using session border controllers. Managing priority, jitter, and QoS within each of those "virtual pipes" is then an afterthought.

We are effectivly applying simple pipe and circuit metaphors to IP. This causes three problems:

• First, the network has very low utilisation, as you have to size to both "peak demand" and "peak jitter". This drives excess capex.

• Secondly, the complexity keeps on re-asserting itself – adding multi-modal desk phones may take down the voice network for everyone else, or a device firmware update can swamp the network and block all voice calls on that VLAN.

• Thirdly, UC services on enterprise networks were never designed to be managed. UC has no way to say "no, the network is full!" It assumes unbounded resources are available, which is fine if you afford infinite capex.

Whilst we can make most use cases work most of the time, we can't use it for safety or mission critical services. We get service failures by "quality failures" where applications brown-out.

It is a bit like how we have 25 sockets in a home, but if we plug in three 13A heaters into our 32A ring main, the fuse blows. We don't have fuses on networks, we just let things melt and smoke away.

The reality is we are trying to manage a complex statistically multiplexed resource, and the tools to do the job remain immature, and do little to prevent over-consumption. The complex phasing effects between traffic types are largely invisible to network managers.

Solving these issues requires still-nascent technology. In the meantime, you need to be aware of the misalignment of vendor and user interests. Vendors are always happy to sell "quantity" of boxes and links to any "quality" problem.

The questions I would be asking UC vendors are:

• How will I know and measure what quality of experience users are getting?
• How will I prioritise and potentially exclude some usage?
• How adaptable are the applications to transient or permanent changes in network capacity and quality?
• What are the pre-requisites for my network in order to manage multiple traffic types? Do I need to partition, augment capacity, restrict usage?
• What skills do I need to manage a converged network using your product?
• What are the levers of control I have over quality?
• How can I accommodate ‘native’ (enterprise-supplied) and ‘foreign’ (transient unmanaged device) modes of use?

UC and unified processes

UC serves three general purposes:

1. Personal Productivity, brinigng your communications to a single place to be managed.
2. Group Collaboration, allowing the sharing of media between many people.
3. Enterprise Workflow, allowing humans to direct the "machine" of the enterprise.

The problem is that the sum of these means Unified Communications is a denial-of-service attack on humans. It concentrates and boosts the pressure of the inbox to the mind. The third in particular involves an increasing level of automated messages.

For example, one US mining company saved over $100m/year by tightening the loop on authorising purchase orders from a week down to hours. These "Communications Enabled Business Processes" (CEBP) are a major growth area. Avaya is a notable pioneer in the CEBP enterprise space.

What the user cares about is "What happens next?" and "What’s my next action?". The communications services are not yet fit-for-purpose for a converged IT/comms enterprise, as they have yet to adapt to a CEBP-centric world. When the machinery of the enterprise needs a human prod to know what to do next, it tends to overwhelm the humans.

It means making messages "smart", know how to prioritise themselves, carry security context from end-to-end of the process, be interactive so I don't need to switch tools to express my intent. A simple "press 1 to approve adding Bob Smith to the payroll", not a request to log in to another application.

If I were shopping for a UC solution, here are some of the questions I would be holding:

• How can users create their own filters, flows and practises to manage complexity?
• How do you see the automation of the enterprise fitting in to your product roadmap?
• How does this UC solution integrate with standardised ERP business processes (finance, HR, MRP), as well as more informal business processes?

UC and unified leadership

We take our communications tools for granted too easily. Telephony is a magic of a whisper in the ear where we succumb to the illusion of talking to someone -- yet we never think of the miracle. We take conference calling as something that is obvious how to use. It is not, and when we introduce new tools of communication, they disrupt the social and relational norms of the organisation. Managing this change of "working together at a distance" is a distinct and new activity. The human side of the technology is all-to-readily neglected.

I have been reading the excellent PhD thesis of Ghislaine Caulat of Ashridge Business School. She has been studying the impact of virtual working on the role of leaders, and notes:

One of the main reasons that virtual working has remained unsatisfactory is that the leadership aspect of this work has been underestimated, if not completely forgotten. Most literature speaks about ‘managing virtual teams’ and focuses on the tasks at hand and the things to do and not do. My research shows that leading virtually represents a new discipline, different from traditional leadership, that needs to be recognised as such and learnt.

She notes how on a conference call sense-making slows down, whereas understanding rises and social connections deepen.

There is a big difference between conference calling services that show a face of someone who is speaking, and those that do not. When we have shared problem-solving, then the use of slide sharing is appropriate. However, for shared decision-making you should avoid slides, as the control of the slide deck can become a proxy for control over the decision. We are more truthful when we know we are being recorded. Video works for establishing relationships, but does not for continuing them; it lacks eye contact, and is hard to make sense of body language. It can also be exclusionary of non-video users, or those with poorer connections. Meanwhile, a shared scribble board gives a sense of “hyper-togetherness”, and changes group dynamics.

Understanding all this requires reflective practises – to be aware that there is a thing called "virtual leadership" and you need to pay attention to what happens!

The key questions for organisations embarking on this journey include:

• Who need to sponsor adoption of UC and IP comms as an organisation development project, not an IT project?
• How does this fit with teleworking and estate management policies?
• What are the practises that let me make best use of this technology?
• What are the communities of practitioners and learning that each vendor supports and curates?

Conclusion

New UC technology has impact on all three of Network, Processes and People. Managing these holistically is deeply challenging. In embarking on the journey, choose partners who are humble about the limits of technology, and are more interested in your business and organisation problems than their technology solutions.

-- Martin Geddes