Communications apps, APIs & integrations: Import vs. Export models

There is a huge and growing interest in blending communications apps/services with other software capabilities. We are moving from a world of standalone voice, video and messaging to a range of contextualised, workstream-based and embedded alternatives.

But there are two very distinct philosophies emerging for app/comms integration:

• Export: this involves extending communications capabilities out from a central system (phone system, UC, messaging app, videoconferencing etc) into other applications or websites via APIs, or by offering granular service-components (eg WebRTC gateway, transcoding, recording etc) via a PaaS approach. Numerous examples exist, from
• Vendors (eg Unify's Circuit APIs, Genband Kandy, Xura Forge, Cisco Tropo, ALU's Rapport APIs, BroadSoft, Vidyo etc)
• Dedicated PaaS providers (eg Twilio, SightCall, Temasys) or niche specialists such as Voxbone (which does numbering for example)  
  
• Telcos' API platforms, which may be network-integrated like AT&T's Developer Platform, standalone PaaS like Telefonica Toxbox, or even just web-embeddable objects like Telenor appear.in
• Import: this involves treating the communications application or service as the user's primary experience, and bringing in other applications as "integrations" or mini-apps. These can be other communications tools (eg WebRTC video windows in a messaging app) or other functions (eg social or process-based integrations). This particularly fits with the "timeline" or "workstream" model, or perhaps a "dashboard". Examples exist in a number of areas:
• Enterprise is moving towards "workstream collaboration and communications" (WCC) apps, such as Slack, Cisco Spark, Unify Circuit and various others which can embed external services into a timeline. BroadSoft's Tempo concept looks more like a dashboard model than a timeline, but also brings in sources like DropBox.
• Consumers are moving towards "Messaging as a Platform" apps, notably in Asia with WeChat, which embeds mini-apps such as taxi-ordering into the message stream. Facebook is taking Messenger in the same direction, and even telcos want to replicate this - Deutsche Telekom is trying to reinvent RCS to take it in that direction, for example.

The API-led "export" model has been the primary trend in WebRTC, SMS and telcos' network/IMS strategies in recent years. We hear a lot about the "consumption" of APIs, "embedding" of communications or the "exposure" of a core system. It is definitely growing rapidly, in numerous guises. Click-to-call buttons embedded in websites or apps are a typical manifestation. (Video below is embedding AT&T capability into Plantronics' website)

But the success of apps such as Slack and WeChat have led to a resurgence of the idea of "unifying" communications, or using a "hub" approach, where a messaging/voice/video app becomes the central anchor of a user's "online life", either as a dedicated application or browser home-page.

Some vendors are trying both approaches - Unify and Cisco seem to be looking at both import and export models. It might be where Google is intending to take Jibe along with telcos and Android as well. Some UCaaS players seem to be taking a similar path (eg with ThinkingPhones acquisition of Fuze) as well as WCC specialists like Atlassian's HipChat.

Others are taking different angles - Microsoft seems to be using Office 365 as the anchor, importing its own Skype4Business UC application as well as maybe others in future, probably via ORTC. I suspect it will "export" more communications as well, in future. Apple (as usual) is different, still using iOS as its main platform for very selective import of a few comms/social tools such as Facebook and Twitter, and largely avoiding any export models at all. (There is no way to embed FaceTime or iMessage in a website, for example). Apple also tends to dislike apps acting as subsidiary platforms on mobile, especially if there are payments involved.

It is too early - and too polarised - to determine whether import or export will be most significant, and for which use-cases and customer segments. We may see different "balances of payments" for different vendors and service providers. However, there are a number of early conclusions to draw:

• Import models need a good and usable / well-liked core product, before they can become a platform
• Export models need the right "raw ingredients", eg simple video or SMS APIs, with the right (typically freemium) commercial model to attract developers
• Import models tend to work best with a core that is text/timeline-based, ie non-realtime
• There is a risk that some import models appear as "arrogant": I can imagine some users thinking "What, you expect me to spend the core of my day in your app?! You must be joking"
• Export models face a lot of competition - external developers have many APIs to choose from, or can implement their own capabilities from scratch.
• Import models involve competition between comms tools and other apps as the "anchor" - eg a UC tool, vs. social networks, or an Office/Google Apps suite as hub, or major enterprise products like SAP/Salesforce, or a vertical-specific platform like a medical practice-management app.
• Import and export approaches often vary in implementation between Android, iOS, Windows and native chipset-level
• Telcos have been trying export models for a long time, with limited success. Often, 3rd party platforms that act as aggregators / or "export agents". Cable / IPTV companies are closer to the import model as they own the set-top box interface to "on-board" other solutions
• We might see NFV / VNF architectures helping with telco-grade import & export in future, but for communications services it's still a long way off
• Mobile app usage tends to be fragmented. With the notable exception of WeChat, it's not clear that a full import model works well with the app paradigm on smartphones. That said, we may see greater cross-linkage between apps in future.
• Certain groups of knowledge-workers may be more well-suited to "import" comms apps, especially if they are either communications-primary users (eg call centre agents) or heavily-collaborating teams.
• Design skills are paramount throughout, for integrations to be usable. 
• We will see some "importers" acquiring companies to extend the core app functions. Slack/Screenhero is a good example. This may compete with some 3rd-parties' integrations, but may also make life easier for iOS appstore approvals.
• Both import and export models make life much harder for network policy-management (or industry regulation) as mashups are by their nature hard to pigeon-hole. 
• Every export implicitly also means an import from the other side - sometimes into "product", but in many ways horizontal apps such as SAP and Saleforce are turning into full import platforms in their own right, especially where they support multiple communications integrations.

I think that 2016 is going to see some epic battles between import and export philosophies for communications in general, and WebRTC in particular. The shift of communications to the cloud facilitates both directions. Worth watching very closely indeed.

Stop Press: just as I was about to publish, I read that Facebook is trialling Uber-in-Messenger, as part of its "Transportation on Messenger" initiative. This is a great example of an import model, and "messaging as a platform". Details are here.

WebRTC platforms & distribution partnerships: From evangelists to acolytes

Over the last month I've been to a number of WebRTC and related events - AdvancedComms Asia in Singapore & HK, WebRTC World Expo in Miami, and GenBand's Perspectives customer/analyst conference in Orlando, as well as numerous meetings and calls with WebRTC-related vendors, users, investors and clients.

A couple of themes that have emerged are mostly continuations of existing ones - the overall pendulum of WebRTC swinging towards enterprise "disunified comms", a broad recognition of the equal (or greater) importance of mobile WebRTC-embedded apps vs. browser experiences, and the continued steady growth in profile of telcos and other service providers. All of these I've covered recently on this blog, or in my regular WebRTC research report updates for clients.

But one additional trend really jumped out at me last week at the GenBand event: the importance of distribution and integration partnerships, for WebRTC PaaS players. It's something I'd started seeing signs of at Enterprise Connect in March, but some of the impressive activity that's been done by GenBand's Kandy "ecosystem" really threw it into stark relief, and brough a few separate things together for me.

The headline: Evangelism is not enough. 

Lots of WebRTC companies are out pounding the conference circuit, not just for the technology itself, but also at specialist events for healthcare, finance, general web-design and so on. They are running hackathons, providing developer out-reach via web forums and other avenues, and generally "getting the story out there", especially to the long tail of developers.

That is absolutely necessary. But it's not sufficient.

The WebRTC PaaS market needs not just evangelists, but acolytes too. These are third-parties who are "devotees", or "followers", or assorted other religiously-inspired terms that imply not just "belief" but also provision of active help in the priest in performing the rites.

Translating the metaphor to IT terminology, this means systems integrators, channel-partners, consultants and others who assist in the "go to market" for the PaaS providers and their SDKs. (A fairly similar argument also applies to WebRTC gateway vendors, although that's somewhat different given upfront costs and existing infrastructure. I'll cover it in another post/report).

This gives a multiplier effect, as various types of partner are able to reach out to their customer base, adding broader marketing and sales resouce, adding value through other products or software customisation, or giving an impression of greater credibility and stability.

I see at least important 4 go-to-market channels for PaaS providers, each with sub-divisions:

• Major software companies embedding PaaS (or components). Temasys' recent announcement with Citrix for its browser plug-ins is a good example, as is Kandy's expanding role within SAP's applications, and also as a basis for its own fring application. At Enterprise Connect, I liked CafeX's integration with Humanify for contextual-comms in B2C websites as well.
• Systems integrators. Acision announced last year that it was working with Capgemini, and Kandy is working with Tech Mahindra among others. I know from my own research sales and consulting that other major firms are interested in WebRTC, but it's less clear if they will "roll their own", work with established PaaS players, or pick-and-choose for particular projects.
• Telcos & SPs: While some telcos are developing their own PaaS offers, others are acting more as solution integrators, combining an existing platform with other elements. Tata Communications is using SightCall's PaaS, as well as various other vendors' products in its Click2RTC offer.
• Consultancies & agencies: There is a broad range of "general" web, comms and mobile-app professional services companies interested in WebRTC. They range from high-profile WebRTC specialists such as Quobis (which also has its own software products) through to "digital media agencies" that work with brands or B2C players on overall web/mobile strategy and design. Acision's work with Blacc Spot and Kandy's with Deloitte's Digital arm are examples.

The categorisation can never be perfect - various companies can exist in multiple roles, and sometimes the PaaS offer blends into the background, while sometimes it's more transparent as a "resell". But the general principle is the same - the PaaS provider gets the benefit of extra scale and reach, as their ecosystem is doing some of the heavy-lifting.

The relationships have to work two ways as well - the PaaS vendor needs to invest quite a lot of effort to turn a couple of isolated deals into a genuine "ecosystem", where there are genuine feedback effects. At the moment, I'd say Kandy is probably ahead in terms of brand-name partners, and seems to have invested quite a lot to get its message across, at least in North America. The heavily-branded tour bus is a nice touch.

There is also another spin on distribution here - some WebRTC PaaS providers have another ready-made channel: their own existing developer programme/community for other APIs. Twilio and AT&T are the two most obvious proponents of this approach, as well as Tropo although its acquisition by Cisco rather changes things.

I'm going to keep a close eye on the evolving partnerships here. I suspect some don't get much further than a press release, while there are certainly others that have not (yet) been publicly announced. 

I'm also curious to see if any of the gateway-specific SDKs evolve into full PaaS platforms (eg Oracle's, Sonus', Broadsoft's), or indeed the UC-centric APIs from Unify or Avaya. A number of those companies - notably Avaya and Oracle - could also WebRTC-ify their own company's vertical market apps via their own platforms. Cisco+Tropo is an obvious candidate for that as well, while Tokbox could potentially be leveraged by other units of Telefonica.

The bottom line is that the various WebRTC platform providers are doing a better job in 2015 at promoting their role in the industry. But signing up third parties and ecosystems should have a multiplier effect.

More detail on the WebRTC market, PaaS, gateways, channels and vertical solutions is included in the Disruptive Analysis research report & updates. The next edition, due in early July, will consider the channel/ecosystem dynamics in greater detail. To order the report & updates, click here.

If you want to discuss a more specific research project, or brief me on your company, please contact information AT disruptive-analysis DOT com .

Will more network/IT vendors launch their own WebRTC PaaS?

One of the most vibrant domains within WebRTC is that of "platform as a service", PaaS. There are numerous providers of cloud infrastructure, mobile SDKs and ancillary services that allow developers to embed WebRTC functions more easily than using "raw" JavaScript. Tokbox, Temasys, Twilio, acquired players AddLive and Requestec, telcos like AT&T and NTT and so on. 

There is a particular need for PaaS to support mobile devices which use WebRTC in apps rather than browsers (eg with iOS SDKs), or where specialised cloud functions are needed, such as video-mixing. They also appeal to developers unable to cope with complex or clunky aspects of WebRTC, such as the much-derided SDP protocol for connection setup.

But one emerging category I'm seeing is slightly different - it's where technology vendors are launching their own PaaS propositions, reaching out directly to developers with hosted platforms, rather than attempting to sell gateways or SBCs or media servers as products.

The most prominent examples are:

• GenBand's Kandy platform
• Acision's Forge SDK & PaaS [itself based on the acquired Crocodile platform]
• Intel's investment into CafeX
• Digium's Respoke
• (Primarily a virtualised IMS PaaS, Metaswitch Clearwater also offers some cloud-based WebRTC gateway capabilities)

What differentiates these from the various other client SDKs is that they are moves by "product" companies into the "service" arena, with subscription or pay-per-use business models. That runs counter to the normal vendor model of upfront product license + maintenance/support contract.

Now clearly, in other parts of the technology industry that transition is fairly common - the large network vendors like Ericsson, Huawei and ALU all make large sums from "managed services" contracts for radio networks or other bits of telco infrastructure. Cisco owns WebEx for conference services, while many mainstream software companies have transitioned to SaaS/PaaS offers for business users.

Yet it is one thing selling a "cloud" or outsourced version of a product to your existing customers (telcos or enterprises) as a service - but quite another trying to derive revenues from an entirely new audience of web or application developers. Clearly, this in an attractive idea - but it doesn't mean that it's easy to achieve in reality.

In WebRTC, it is instructive to consider which vendors are not offering PaaS propositions to developers - it includes most of the main gateway or media-server providers. While Oracle, Ericsson, Sonus, Dialogic, HP, Broadsoft, ALU et al might offer client-side SDKs, they are not offering hosted, subscription-based platforms for WebRTC developers at present. (Notably, all the previous product/service crossover vendors above also sell gateways or provide SDKs on a "product" basis, too).

My belief is that the others do not, for the most part, want to take the upfront risks of setting up infrastructures and billing systems for PaaS (especially internationally), nor incur the marketing overhead of reaching the "long tail" of developers. Not only is there a lot of competition here (with services firms having existing customers, or specialised capabilities), but there would be a risk of channel conflict if (for example) they ended up competing vs. firms that themselves are launching PaaS services, but which are also customers for core-network infrastructure or SBCs. 

For telco-facing vendors, I don't expect to see too many more launching WebRTC-based PaaS platforms, unless either (a) it ties into a much bigger NFV/SDN strategy offering telco infrastructure on a managed-service basis, or (b) it's a completely separate, rebranded initiative like Kandy, primarily targeting enterprise software ISVs. Broadsoft's Labs arm is offering an "incubation environment" for developers, but it's not the same as a full PaaS.

On the enterprise side, I can see Cisco, Avaya, Unify and others increasingly offering API access to their own cloud-based UCaaS offers. However, I'm not expecting them to offer subscription-based WebRTC gateway functionality or similar propositions aligned with Respoke. Notably, Voxeo split off its PaaS business (Tropo, formerly Voxeo Labs), before being acquired by Aspect. The deal that Avaya has done with Google for hosted contact centres & Chromebooks is a step in this direction, but isn't really a formal PaaS. It also has a platform called the "Collaboratory" which seems similar in principle to Broadsoft Labs - ie a "PaaS for prototypes" rather than a "production PaaS".

All that said, there may be some future acquisition opportunities and disruptions here over time. I could perhaps believe a major vendor might try its luck acquiring Twilio or Temasys or CafeX or another cloud player, perhaps seeing it as a way to start generating more recurring revenues, and higher-margin services. However, such actions are perhaps more likely to come from the IT side of the industry (IBM? Microsoft? Google?) than network vendors.

For now, I think the vendor/PaaS crossover phenomenon is a relatively rare one - I suspect many others will just watch from the sidelines to assess whether any of the existing batch start getting notable traction and growth, or else they might go down the route of offering selected partners a "prototyping environment" rather than a full pay-by-credit-card cloud offer.