Pages

Pages

Thursday, December 17, 2015

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.

7 comments:

  1. Interesting. Facebook is doing a lot with FB Messenger. Google is reacting by proposing Telcos to subscribe their RCS/Jibe initiative. anyone knows about AT&T or Verrizon reaction?

    ReplyDelete
  2. I do see Google reaching out to telcos pitching the hosted RCS.

    ReplyDelete
  3. I do see Google reaching out to telcos pitching the hosted RCS.

    ReplyDelete
  4. The exact details of Google/Jibe/telcos proposal are still unclear. A couple of European telcos have hinted that they see some "potential". I think they are deluded, as they have been about RCS for the past 8 years.

    It's hard to tell if Google is also deluded about turning RCS into a messaging-as-a-platform concept, or if it's just trying to pull the wool over telcos' eyes while it builds Android iMessage, as I suggested recently http://disruptivewireless.blogspot.co.uk/2015/10/google-buying-jibe-mobile-is-aimed-at.html

    If I was really cynical, I'd say that Google is just nudging telcos to keep the RCS Zombie shambling along with false hope for another year or two, so they don't accidentally do some proper innovation instead.

    ReplyDelete
  5. Excellent model of the real-time battlefield ahead! This also highlights the appalling quandary of the traditional enterprise communications vendors (Avaya, Cisco-as-CM, NEC Alcatel etc) - the whole Enterprise UC strategy has been an import strategy where the PBX-reborn-as-software is the platform which will "unify" many things. But nobody wants this old clunker as a key "platform". Hence the huge market impact that Microsoft has had with Office and "Enterprise Cal" as the platform and first Lync and now Skype4B as the import into this. Hence the surprise and fear of Slack and other bright new cloud-scale things as they suddenly appear and look like much more interesting platforms to many people. And these traditional UC vendors cannot easily turn around and be exporters because exporters cannot command anything like the same level of $ value as platforms - the Twilios and other Caas choices are much simpler and more cost effective. Unify is claiming they can do both with Circuit, but while a nice theory, will this Ship-Plane actually fly? Cisco is trying something with Tropo but it continues to look like distractionary window dressing as every recent Spark announcement highlights how Tropo APIs are separate and for "other use cases". Cisco-as-Spark is, as you say, a major import play and Slack-fight.

    Fun times indeed.

    ReplyDelete
  6. This comment has been removed by the author.

    ReplyDelete
  7. Re last comment - for amusement, this was the best picture I could find to represent a "traditional UC platform" :)

    ReplyDelete