The five make-or-break WebRTC challenges you need to address

WebRTC is a great piece of technology, assuming you can develop a coherent strategy on how you plan on using it.

There are two extremes happening in the enterprise communication space, and they are quite opposite in nature. On one hand, companies are striving towards more automation and this is coming to their contact centers by way of machine learning and bots “replacing” humans. On the other hand, many of us are striving for better and more meaningful communications. Be it for long distance relationships (personal as well as business ones) or by the use of machine learning (again) and context, to guide us through an interaction – being able to know beforehand the intents of people for example.

Enter WebRTC, which enables communications to take place anywhere – be it a mobile application, a physical device or a modern web browser. What WebRTC brings with it is better context of sessions and lower barrier of entry for enterprises to make use if this technology. Some enterprises use it to improve business agility or lower their operating costs. Others use it to create new businesses never before seen or to improve the communications with their customers or peers in the industry.

We are now 7-8 years since the announcement of WebRTC (depends on who’s doing the counting and from which date), but in many ways, a lot of enterprises (I don’t want to say most) have failed in to capture the value they initially envisioned from using WebRTC. In many cases, the lack of any thoughtful strategy created a rush towards initiatives that never really matured.

Through my work with many clients on their WebRTC initiatives along with discussions with many others on their projects and services – failed as well as successful ones, I’ve seen a few challenges that crop up consistently across such initiatives.

#1 – Where to begin?

WebRTC is a versatile and powerful building block in your arsenal. This means that you can do a lot with it. That range of utility can be overwhelming, oftentimes leading to wasted resources. The other problem is that WebRTC can’t do everything, while the expectations of it are rather high. This leads to requirements and plans that are often not grounded in what can be done in reality or within the allocated budget and resources.

Deciding what to build using WebRTC requires an understanding of the capabilities and limitations of WebRTC coupled with a clear view of the communication problems you are trying to solve for your customers. There’s a lot of feature creep happening when it comes to WebRTC. I find myself asked about a simple video chat service for 2 people, but once you dig a layer deeper, you see requirements for group video calls, recording and even broadcasts as part of the project. Being able to see the full picture, and map it back into requirements and a roadmap comprised out of multiple phases is an important first step in any WebRTC initiative.

There are a few other things to keep in mind –

Integration with existing infrastructure

Oftentimes, you’d be planning on adding WebRTC to an existing service. This can happen in many ways:

• A chat application that gets voice/video interactions as an additional feature
• An existing telephony/communication service that needs to get guest access via the web browser
• Just a regular self service application with a new option to connect to the contact center via the application itself (instead of using expensive 1-800 numbers)

This requires extra care in how WebRTC gets introduced as it isn’t going into a green field where anything you pick immediately fits your needs.

Cloud migration and transformation

WebRTC was born in the cloud era. Many of its deployments are cloud based.

Most of its uses in non-cloud environments are actually enabling guest access from the public cloud towards the internal communications infrastructure. In other cases, it just needs to integrate with on premise data centers for things like users database and policies.

This places an additional strain on enterprises who are just starting out their migration towards the cloud.

Not your regular web application

WebRTC is different than other web technologies. It has a lot more moving parts to get to a minimal viable product, and then there’s that media quality issue to contend with. Its deployment needs to start as a global one for many of the use cases.

#2 – Who should I have on my team?

Putting a team of developers on a WebRTC initiative is a daunting task. There are multiple disciplines they need to come from and the myth of a full stack developer that can do it all gets stretched even further here, as that superhero needs to also know about media processing, WebRTC APIs, browser changes and standardization processes.

Here’s what i wrote a while back about WebRTC developers after discussing the topic with a few people who manage/hire them.

Some other aspects you’ll need to decide on:

Internal vs External

Will you be relying on your existing engineering team or will you be outsourcing some/most of the project to an external vendor? Assuming you decide to go for an external vendor, who will maintain the service on an ongoing basis?

Multidisciplinary

The team in question needs to be multidisciplinary, capable of handling anything from media processing, to mobile app development, to backend integration work and ongoing DevOps and maintenance.

There needs to be a skilled product manager and a system architect who understand WebRTC enough to know what is possible and what’s… less possible. What incurs risk and where quick wins can be found.

Which new skills are needed?

Your teams. Do they have the necessary skills?

Here it goes to a lot more than just developers. There are product managers, testers, DevOps people, support staff.

Do I need to enhance some in-house capabilities?

What skills are you missing? If you operate everything on premise and WebRTC is forcing you to start using cloud services, then this is an in-house capability you will need to start contending with.

The same goes for mobile application development, going global in how you deploy servers, etc.

#3 – What technology stack do I use?

Different companies have different DNA to them. That often dictates what their technology stack will look like and how they’d prefer to partner/hire.

There are three main aspects that need to be taken into account when picking a WebRTC technology stack:

Open source / commercial

You might favor open source components and frameworks for your WebRTC service or you might be someone who prefers a commercial offering with a company focused on that product development.

Both alternatives can come with support contracts but companies seem to prefer one or the other.

Which alternative will it be for you?

Hosted or on prem?

These two approaches means different technology stacks, levels of expertise and staffing on your end.

Are you planning on hosting this on your own, in your data centers, on bare metal or in the cloud? Or are you going to have someone else host the service for you? Which parts of it will be managed and which will be self managed?

Acquisitions

WebRTC is still relatively new, with the vendors ecosystem dynamically shifting. There have been quite a few acquisitions in this space. These acquisitions sometimes removed solutions from the market, made them weaker or made them stronger.

When selecting a technology stack, the potential acquisition scenario of the vendors in question needs to be taken into consideration as well.

Fit for the requirements

This one seems silly but it is highly relevant and important.

Are you sure the technology stack you’ve selected can do the things you want it to do?

I’ve seen too many cases where the framework used wasn’t up for the task. Things like taking signaling when media servers needs to be used, picking a CPaaS vendor when the scenario requires too much control of media processing, etc.

Just look at what WebRTC signaling alternatives people have these days.

#4 – How do I know it is working?

You built it. Tested it in the lab. Did a call or two with your colleagues. Went home and showed it to a friend.

Does it scale? Will it work properly?

I had a customer recently who is developing a group video calling feature. He wanted to test the service with around 20 people in a single room. It wasn’t easy to find 20 people to run that one scenario. And when he did – things broke and needed fixing. So he had to find 20 people to run it again once a fix was put in place.

Testing is often neglected when it comes to WebRTC applications and it shouldn’t be. Take this one seriously. You can cobble up a testing environment on your own (there are even a few open source projects that can help you out here) or you can just use testRTC (I am a co-founder there) and start running tests within a couple of hours.

#5 – What do I track?

Tracking websites is rather “easy” these days. Use Nagios, Cacti, Zabbix or any other open source tool that sounds like a disease. Or use something like New Relic or DataDog to do it managed in the cloud.

Problem is, these tools only cover the machines metrics and performance and they don’t really watch for the media and its quality (or even if a session got connected for that matter). There’s no end to end monitoring/tracking.

You will need to collect WebRTC related metrics from either the backend or the devices (or both). You’ll need to track it for quality.

You’ll need to monitor your service (we’re doing a webinar on WebRTC monitoring next more @ testRTC – register to join).

How can I get help?

There are various ways in which you can get some help for what you are doing.

The best approach is probably to get some external assistance in what you are doing as part of your research and planning – even before you go outsourcing the whole project (if that’s the path you are going to take).

You can contact me for that, or go to other consultants. Some of the outsourcing vendors offer such consultancy service as well. Whatever you do – don’t go it alone. At least not in the planning stages.