Speaking Engagements & Private Workshops - Get Dean Bubley to present or chair your event

Need an experienced, provocative & influential telecoms keynote speaker, moderator/chair or workshop facilitator?
To see recent presentations, and discuss Dean Bubley's appearance at a specific event, click here

Sunday, December 27, 2015

New Year Rant: 10 Awful Tech-Industry Terms to Stop Using in 2016

In the spirit of the holiday season and New Year, this is another list about 2016. 

But it's from me, so it's a rant, rather than clairvoyancy with a crystal-ball.

There's a bunch of words and concepts used in the technology industry that make you look like a fool, or at least lazy and sloppy. They're often meaningless, duplicitously-used to "misframe" an argument, or just generally cringe-worthy. Some of them I've tackled before, and yes, mea culpa, I've been guilty of some of them before too. But I've learned from the errors of the past, and apologise unreservedly for any historical fluffiness and telcowash.

So let's double-check our terminology in 2016, call out offenders, and make a collective New Year resolution to ditch the telco-industry b*llocks....

1. Digital 

Meaningless drivel. The last time the word "digital" was informative or cool was in the 1970s, or maybe, if you absolutely must, relevant for newer telecoms switches in the 1980s. But apart from retro nods to Casio, it's now just a useful short-cut to determining if someone is ignorant, tech-illiterate, or desperate for a marketing hook - think "digital agency" as cringespeak for advertising, or "digital single market" for the EU's half-witted bureaucrats and their fawning legions of lobbyists. 

And don't get me started on the clueless telco and vendor folk talking about "digital" services. Because hey, we don't want to go back to those awful days of the analogue Internet in the 1990s, do we? I suppose I should be happy that at least some of the politicos have switched over from the similarly-execrable "ICT", but frankly "digital" is even worse. So sneer at the digitalistas with both pride and prejudice – and perhaps a raised middle-digit.

2. OTT 

This one I've tackled before, but it bears repetition. "OTT" just means "bits of the Internet we don't like". It's arbitrary, divisive and hypocritical (all telcos have websites & Internet apps). It’s also a form of telecom industry self-harm, as the "O" for "over" conjures images of a vertical hierarchy, with content/apps/comms being at the top (and therefore implicitly better) than everything "beneath". Along with “dumb pipe” the false-dichotomy of ISP vs. OTT is at the base of many of the industry’s current woes, as it re-frames a simple reality in a deliberately antagonistic way. Telecoms industry regulators and lobbyists who use “OTT” are especially unfit-for-purpose, and should be fired for incompetence.

There is an exemption for anyone saying “OTT” if they also refer to networks as “UTF” (Under the Floor) providers, as that’s where the plumbing goes.

3. Transformation 

I have a little bit more tolerance of this word, as it is slightly better than some of the industry’s other gibberish. Elements of the industry are undergoing profound change, yes… but that’s mostly being forced by events, with grudging acceptance, rather than true enthusiasm. Even where networks are genuinely being “transformed”, it is rare that the culture, process and business model is following suit. More generally, it’s important to note that telcos, and their networks and services, have been in a state of constant flux for the last century, often with discontinuities in technology.

Either way, the only meaningful use of the word "transform" I've heard this year was by my Haitian guide when I visited in July - to describe a voodoo curse which he reckoned was turning him into a cow. To listen to some of the snake-oil merchants in the telecoms industry, you'd think we were watching something similarly magical occurring, rather than just mythology.

4. Seamless 

Another one I’ve taken aim at before – seams are important. Seams are borders, where important things happen. Pretending that they don’t exist denies their significance – and can lead to mistakes or complacency, in terms of user perception, technical capabilities, pricing, security and more. A prime example is the combination of WiFi and cellular connectivity for smartphones, where two very different domains exist, and blending them needs to be done with care and humility. Creating frictionless shifts between one and the other is important – much like real-world borders. But the premise of “seamlessness” removes visibility and agency from end-users and other market participants – and often presupposes (wrongly) that network operators are the only/most-important actors involved. Seamless transitions allow inertia and lock-in to be perpetuated, rather than allowing users or app-developers scope to make “wrong” decisions.

5. Carrier-grade 

This is another term which exemplifies the telecom industry’s arrogance and self-absorption. It imbues certain bits of infrastructure – or engineering practices – with a magical aura of uniqueness and competence. And while many examples are indeed praise-worthy, they are far from the only purveyors of excellent network engineering. Corporate-grade networks are often just as secure, resilient and cost-effective – but also often more flexible. Military-grade networks are often more secure. Consumer-grade networks or various ad-hoc networks are often more democratic and market-responsive. Internet-grade networks such as Google/Facebook data-centres or Akamai’s CDNs are often cleverer. 

Telecoms carriers are not “special flowers” nor sit in “ivory towers”. Continually using terms like “carrier-grade” perpetuates the arbitrary distinctions between telecom and Internet worlds, and fosters harmful distinctions that inhibit service-providers from making pragmatic, market-aware decisions.

6. Engagement 

This is not limited to the telecoms industry, but is a general example of horrific marketing-industry and social-networking semantics and practice that needs to be stamped out. “Engagement” usually involves forcing people to “interact” when they’d often rather not, or measuring social-network actions in a cringe-worthy fashion. My recent example of WiFi “monetisation” charlatans bragging of “engaging” users for 45 seconds highlights the misanthropy present in this way of thinking. The whole area of “click-bait” posts, or those stupid list-based websites that force you to find the “next page” button, or click an invisible “x” on an intrusive floating advert are others.

This is not to say that it’s a bad thing to allow people to interact with you. Yes, they should be able to comment or share if they choose. But that’s the point: they are choosing to interact. They have agency, and take action. They should not be encouraged or forced to “engage”. It’s the coercivity that is wrong.

7. Content (& especially content-marketing)

“Content” is just one-directional application data, which flows from a “publisher” to a “consumer”. Despite some commentators’ and legislators’ ignorant comments, it does not constitute the whole Internet. While the likes of Netflix and the BBC are clearly important, so too are Amazon, Twitter, Skype, SAP, email, backups to iCloud, downloaded virus definitions and innumerable enterprise applications and services. The latter are communications, transactions, applications and raw data – not “content”. Yet too many laws and structures are designed with an historical “media” mindset, rather than an IT or Internet-native one. For example, the majority of the Net Neutrality discussion was centred on “content” and “content provdiers” – although to be fair, some regulators have talked about “edge providers”, which is a slightly more generic term.

Hopefully the rise of ever more non-content mobile apps, plus also IoT devices and traffic, will make more people (especially regulators and politicians) aware that networks are used for much more than lumps of video entertainment, media websites and music. 

To be honest, “content” is mostly another sleazy, marketing-inspired word anyway – often used with a hidden meaning of “that stuff we can embed advertising in”. That also gives rise to the most repugnant use of the term – in “content marketing”, which is basically just “long-form spam”, often masquerading as journalism or analysis. The technology industry is widely infested with dodgy “content marketing” – particularly corporate blogs masquerading as independent sources of news or analysis. You know the type: one-sided puff-pieces which laud a particular type of technology or product or brand. “Why WiFi-calling is transformational & will change telecoms for ever and allow operators to fight back against the OTTs with new digital services and improved customer engagement” (posted on WiFiCallingForEver.com, with a tiny note at the bottom that it’s sponsored by VendorX.com). The worst content-marketing of all is that derived from fake, quasi-corrupt, pay-for-play industry “awards”, where marketing companies offer “sponsors” a full package of PR and churnalism “content” in exchange for a “submission fee”.

8. Rich 

Obviously exemplified by the ludicrous RCS of zombie fame, the word “rich” also crops up in various other telecom and Internet contexts as well. It usually means “we didn’t have any proper designers involved, so we just threw in as many random features as we could, hoping that people would muddle through and ignore the incoherent clutter”. I don’t think I’ve ever seen Apple use the word – or even Facebook. I’m scared to look, but it wouldn’t surprise me if Yahoo or LinkedIn have used it, though. Rich services or apps don’t even have the redeeming benefits of rich food – they’re unpalatable as well, as bad for you.

Applications should be right not rich.

9. End-to-end

Whenever you see anyone in the telecom talking about “end-to-end” capabilities – especially QoS – you should laugh and dismiss them and their products/services immediately. In almost every case, the so-called “ends” just refer to arbitrary points over which they have some modicum of visibility and control. They are never the actual ends where a service is generated or consumed, just points on an architecture diagram where somebody else takes over responsibility. So for a streamed video, there are origination servers (perhaps even the production, editing and encoding process) and the end-device, with screen and associated processors and memory. Quality of experience ends at the retina, the eardrum – and maybe even the cortex of the brain. A great example of the end-to-end fallacy is around VoIP, where much of the quality and performance is gated by the device’s silicon and its microphone and speakers, as well as the various processing algorithms used. The network is important – and bits of it may indeed be well-managed. But they’re not “ends”. 

I’m writing this in an airport, where BA takes responsibility for getting me from gate to gate. It conspicuously doesn’t refer to my journey “end-to-end”. The handful of airlines which offer limo-service  to and from your home and hotel would have a better claim – but even they can’t control the traffic on the roads outside Heathrow, just the seat you sit in. 

10. Ecosystem

This is the term beloved of people who used to say “value chain”, especially as it allows a temporary warm & fuzzy feeling from its environmental and natural background. But for that very reason, it’s a lousy analogy. Ecosystems aren’t “built”, they evolve. It means a group of interacting organisms AND their (physical) environment and resources. It implies co-dependency – if one part of an ecosystem gets removed, damaged or destroyed, it has an impact on everything else. It’s not just a convenient term for a software or web company’s developer and partner programme.

While real ecosystems might have some symbiosis, they also typically have an apex predator, plus lots of unfortunate other creatures and plants that get eaten, or just manage to scratch a living, before rotting after their death with the help of microbes and parasites. Hmm, maybe it is a decent analogy after all. I’ll leave it to the reader to identify the parasites in the mobile “ecosystem”.


So let’s have a collective New Year’s resolution to avoid telecoms-sector “trigger words” and acknowledge what we actually mean in 2016. Let’s get rid of:

  • Digital
  • OTT
  • Transformation
  • Seamless
  • Carrier-Grade
  • Engagement
  • Content
  • Rich
  • End-to-End
  • Ecosystem

And, I’m sad to admit, there’s also probably a number 11 that’s past it’s sell-by: “Disruptive”. But yeah, let’s forget about that one, given that I was disruptive before it went mainstream. I reckon I can claim some form of retro-irony exemption…

Rant over. 

Happy New Year!

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.

Wednesday, December 09, 2015

Contextual communications - using device sensors as context

There are two main definitions of contextual communications that I encounter:

  • Communications ina context (ie in-app or in-website)
  • Communications using contextual data (ie what you're doing, or inferred/analysed information about the communications session)
A lot of the discussion in telecoms and WebRTC circles is about the first one - extending voice/video/realtime data uses, by embedding them into web pages or native mobile apps. These could be anything from video-chat in a banking app, to realtime voice chat in a game, or extending a corporate videoconference system to guests. This has many clear and obvious vector for innovation and value.

But the other dimension is perhaps slightly harder to grasp - using contextual data to improve a communications session in some way. Some examples are fairly straightforward - for example letting a contact centre agent know which page you were on when you hit "click to call", or do a database lookup: ("Ah, Mr Bubley, I see you were looking at flights to Singapore. Thank you for being a frequent flyer - would you like to redeem your miles, as the system shows that you have enough?"). 

That type of use is still in its infancy, and has a huge potential not just for customer service / call-centres, but also social network/comms, and enterprise UC/WCC implementations - as well as countless other niche software and web applications in consumer, telecom and business realms. Using contextual data during a call or conference or other session can meaningfully improve the "outcome" - whether that's making a sale, making a complaint, or working out how to meet up with friends.

But another area is less obvious - using contextual data from sensors as part of a voice/video session, to improve the interaction in some way. I've come across two examples in the past week:

  • Talklessnow.com using the mic & your speaking patterns to tell you if you're dominating the conversation too much, or gabbling.
  • Talko.com using motion-sensors in a phone, to allow callers to make better decisions about how/when to interact with you
The first one is a demo, not a full product, based on the idea that the microphone in a PC or smartphone is actually a general-purpose audio sensor. It's a project that's been driven by Chris Koehncke, and developed by &yet under the capable guidance of Philipp “fippo” Hancke, although the original idea came from me, which I then discussed over a beer in SF with Chris in October. My original vision was for this to be implemented in a wearable - so for example, a conference presenter could get a vibrating alert that he or she is talking too fast, and get a reminder to slow down, and add pauses. As Chris discusses on his post (here), when added to a browser it's also suitable for salespeople and others who really ought to be listening more and talking less.


There's many other use-cases for what's basically a simple idea - using the microphone as a sensor, answering questions like "how much of the time is sound coming in?" or "how fast is the person speaking compared to the pauses between words & sentences?". This is obviously different to the normal use of a mic, which is to actually capture and encode the content. This is more like audio metadata, which can then be applied to the logic of the communications application itself - whether that's a sales tool, or perhaps a conferences-speech coaching app.

I'm really excited by this - as it illustrates perfectly how a voice-app idea can go from a casual discussion in a bar to reality (or at least, proof of concept), with very little pain. I'm not sure exactly how much time Fippo and his team spent on this - but it wasn't a huge project. It's also only using one of the WebRTC APIs (to access the mic) so it's not hugely sophisticated, but that doesn't matter. It's the results and opportunities and services that are the point here.

The other example of sensor use + context + WebRTC is from a company I've talked about before - Ray Ozzie's Talko. This is a mobile collaboration app for teams, that blends one-way voice messages, text messages, two-way calls etc. into recorded and conversations-specific timelines.

I just reinstalled it on a new phone, and was interested in the permission it requested to get access to my iPhone's motion API, "so that, for example, others may choose not to disturb you while you're driving". Firstly it's great UI/UX design for an app to illustrate why it wants access to an API - it allows the user to make a more informed decision about privacy ad security. But more importantly, it's a great way to improve the communication experience.

Basically, the current concept of "presence" in IM is broken. "Offline" is usually a lie meaning "Don't talk to me". "Online" is usually a lie meaning "I forgot to reset my status" and so on. But by using the phone's sensors and APIs it's possible to get more useful presence indicators: "Dean is driving"; "Dean is at the airport and running"; "Dean's phone is on charge and in a timezone where it's 3am".

All of these are important contextual inputs for either the application, or the other people using it - to decide whether to interrupt you, initiate a "call" or send a message, and so forth. If the desired outcome is a successful collaboration, without unnecessarily disturbing people at the wrong times, this is a huge positive.

These are both comparatively simple examples of using available contextual data in new ways, to enhance a given instance of communications. This is where the value is in future for the telecom industry: not minutes, not filling in coverage gaps with WiFi, but actually helping voice/video become more useful and fulfil the actual user needs and purposes involved. But to do that, you need to have insight into specific problems that need to be solved for the user - whether that's dramatic pauses.......... in a conference speech, or avoiding interrupting someone while they're navigating Hyde Park Corner.

(There's a lot of other potential uses for this general idea, and various possible extensions, enhancements and integrations for Talklessnow and similar concepts. Get in touch with me if you'd like to discuss them, or if you want to arrange a speech or workshop about contextual communications more generally - information AT disruptive-analysis DOT com)