Rich Communication Conference - a few Notes and Thoughts

Yes, I have attended the Rich Communication conference - one of the few places where a mention to "work with Joyn" won't immediately result in being laughed at, frowned upon, or verbally bashed. A tryst of the die-hard conservatives within the industry to get together, shell out verbiage, and promise each other that "next year will be the year". Or is it?

I think it is not only - perhaps not anymore, or not for everyone any more for that matter. But that does by far not mean that all is well.

I wondered quite a bit what to write (and if at all), and am in parallel working on a more interesting guest post for a friend of mine, but thought nevertheless that the event deserves a separate mention for two reasons:

  1. I presented there and feel the need to annotate my presentation with a few words to make it understood what my motives where for everyone, who hasn't attended.
  2. A few observations are noteworthy, and since Tsahi did already summarize the WebRTC Summit Europe so nicely, I thought it won't hurt to add a few words on the two days after that he did not attend.
    (post scriptum: gotta work on the "few" part)

Let's begin with my presentation

I have been invited to speak about the Joyn approach of Slovak Telekom, and since I have been responsible for the local technical part I was an ideal candidate to talk about it. Just that I wasn't - or at least I thought so myself initially. See, I have been tasked to work with Joyn, but historically I have been opposing it quite a bit. I have never made any secret of my personal and professional opinion on the service Joyn - and that opinion still holds up.

The reason I attended nevertheless in the end was my work around WebRTC and an attempt to combine both my experience with the service locally and more importantly an innovative outlook beyond Joyn.

The latter was a motivation for myself similar to the reasons for attending so many other events lately: To show that there are not only mainstream opinions and boring folks working for operators, but also an increasingly visible amount of creative people that "want more" than deploying release after release after release or waiting to put standardized services into production without the need for independent thinking.

I added my presentation at the end of this post and as usual also on Slideshare. I have a few supplementary notes to my slides in order to mention also here what I stated at the event. I tried not to repeat many points in the presentation, but mainly to summarize my notes that I discussed verbally [1], so it is still worth to check the slides, if you are interested in my concrete ideas :-)

  • I set the record straight in the beginning that although I am coming from an operator that recently launched Joyn, I did not see my mission in marketing that, but rather looking at it from an innovation perspective. I tried not to debate Joyn as such (I have my personal opinion on that as said and many know), but take it rather as a given and not to waste energy on things that can't be changed.

  • There is a belief for reasons for RCS, but usually a promising business cases or hyper excitement in operators aren't among them. If you're with an operator and RCS also "fell into your lap", you may be curious what my thoughts are.

  • My slides are less about "hosted RCS" only, but rather an outlook on using the RCS platform - amongst other things of course - for building new things - mostly outside of the overrated native integration.

  • If you have an up-to-date API platform and embrace it fully you can ignore most parts of my presentation. Many points are aimed at operators that did not focus on APIs enough yet, have limited resources for building one, and may have (or are planning to have) an RCS platform. Built in the right way, this may contain their most up-to-date API portfolio yet. It won't be enough, but can be a start.

  • I clearly mention that I am speaking from the position of the platform being in place, not building a new RCS-based platform for communications. If your starting point is wondering whether you want to do comm's with or without RCS I do not give a recommendation (I'd personally do it differently, but won't elaborate on it further here). If your starting point is an RCS platform in your network (or you have no way to avoid getting one :) I may have some interesting thoughts in the presentation.

  • I'm sharing a few thoughts on our Joyn cloud deployment, again not focusing on whether to do Joyn or not, but on how I think it is done best if done at all.

  • The main part of the presentation is about RCS as a platform. Funny enough, even Joyn supporters have agreed with me on the importance of it, but there's still disagreement on how it is done best. Proponents argue that native device integration is the one killing thing, and based on that new features can be built using the platform if everyone agrees. In theory that may be true. In reality, it's too slow, requires too much alignment and consent, and thus hinders individual innovation.

  • Communications - especially beyond legacy forms such as SMS and telephony, which will still exist for some time - will evolve less in separated UI elements (such as stand-alone apps, the native dialer, and also the native Joyn integration) in my opinion, but become contextual & embedded. Since there are quite a few other people that can explain that much better than I could, I will not dive into that now.

In essence, the following summarizes quite shortly and precisely what I think:

In my understanding, more and more kinds of applications/services/products will have service-specific (i.e. contextual) communications built in and itself be the starting point for integrating communications and with it adding value to the service .

and how it differs to the main theme and hope that colleagues have in Joyn:

Joyn and its proponents believe that the communications platform/app/natively integrated part of the mobile phone will be the starting point for all sorts of new communications and applications and evolve around it. They start to look at A2P use cases, but what I've seen so far on the customer end this was always represented by a "buddy" in your address book and NOT integrated in any kind of service context.

This is where I fundamentally disagree and believe ultimately the concept will fail, or at least evolve to some other form - to, like at the event, remain similarly less absolute in my argumentation ;-)

  • I think an integrated Joyn service will be nothing more than a bit better lowest common denominator for a small percentage of very late adopters.

  • One discussed main assumption for Joyn was: The operator owns the user interface because he has power over the handset vendors. This assumption is wrong. I kindly ask anyone to show me how operators own Apple or Google. If they do things that seem supportive for us it is almost exclusively for supporting their own business. If hell freezes over and Apple will implement RCS (what I still don't believe and am overly skeptical about), it won't be because of the good relation to Joyn operators, but merely because of other reasons (I've heard requirements in China in the rumors here - let's see, I believe it when I see it).

  • Concluding from the aforementioned argumentation, my thought and value-placement is so much platform focused. Since we do not own the interface, it looks the same for all operators. For some this is the main benefit, for me it is the problem. It is one further step to a utility and away from useful differentiation. On every Joyn panel I've been in the past I have heard countless operators say, that in general they don't mind the idea of something like it (partially because many have to say that :), and then came a "BUT" - followed by a lot of thoughts on how to differentiate. It comes to no surprise that if they want to differentiate themselves a common Joyn service is most likely not the right way to do so :) A common platform approach and similar capabilities that are used differently though may work.

  • By fearing "The OTT’s" (note the quotation marks here Dean ;-) and contributing a lot of our own problems due to the lack of innovation on our side to them, we let the industry lure us into thinking differentiation is not important and Joyn is our "only weapon"; all it shows however is it does not matter which operator you chose for Joyn, all have the same (or very similar) features. That message couldn’t be more deadly for our respective brands if you ask me.

  • I am discussing in my slides many points related to WebRTC. It is less the concrete technology that I try to mix with RCS thoughts though, but more the paradigm I am building my case on. I am not saying to build the Joyn service interface in browsers and use WebRTC. What I am trying to emphasize is that we can use platform features to support new communications applications and browser integrations thereof. Thus, the APIs are much more important than the "native Joyn" stuff. A side feature for the conservatives may become a powerful enabler for the innovative ones if you wish.

[1] In parts I am more direct here since this is my personal blog and in that role I can share thoughts a bit more diversely.

Very few observations

Obviously I am still learning to write proper (and shorter!) blogs and thus have mentioned many of my observations already in the first part, so this one is going to be short :)

  • A vendor urged that in the following year we must not have yet another "post mortem". If we won't see a push from the North American market next year there ought to be not as many people in the audience. Let's see about that, I recall similar statements from two years ago.

  • Libon made their case well and showed where their focus and value is, hope the audience grasped that and did not only focus on the assurance that "on an RCS network they can do RCS, otherwise 'OTT'". The part beyond RCS means innovating on the UI and they did that quite well (not mentioned, but one of my highlights: guest access via browser).

  • The focus on the phone/messaging icon as entry to "our services" is still very big. Hope to see that changed. We must not focus around phone calls only in the phone call interface, but on providing a richer communications experience for services (maybe using exposed RCS features, but not only, and not mandatorily). I think telephony/identity/SMS API integration is far more important here than Joyn.

  • In that context, GSMA still holds on to their "green button promise" - as mentioned they believe that the dialer as entry point for operator services is important. They emphasize native experience in the form of VoLTE and RCS. I'd summarize their presentation as "typical - as expected"; it is a pity that they are not more progressive.

There were also good parts:

  • Some were mentioning the need for service differentiation beyond RCS (and provided samples).

  • Niklas from Fraunhofer FOKUS NGNI notably looked beyond and elaborated on RCS and also VoLTE as a platform and embedding communications features as well. I believe it does make sense to do things entirely differently and look at all new services, but RCS/VoLTE will most likely happen anyways in parallel, and taking that into account as just another set of enablers where it fits is reasonable. Great talk.

  • Richard from KPN looked at next-gen comms using WebRTC and RCS in the context of business. He focussed a lot on integration of communication capabilities and in-app comm's. When discussing RCS he also emphasized capabilitites and the platform potential. It was a great talk (before mine, setting the stage in a good way) and concluded with "WebRTC is hot, RCS is not".

On Tsahi's blog I commented about two moments of joy and shock respectively:

  • Moment of Joy: Seeing the potential as platform discussed more. And it’s not mainly “buy an RCS platform and then do things”, but rather mentioned as side effect by those having deployed the service and understanding right at the beginning that this can’t be it.

  • Moment of Shock: Sitting on a panel and hearing the GSMA state that perhaps next year we will see many more launches in Europe and maybe in two years some new service will be presented. Yes, this is apparently their aim and understanding of success. A few new services popping up in the end of 2016.

Summarizing, I still hold the belief that the Joyn movement - generically based on an idea of operators federating and interconnecting in the old way and trying to do business a bit better than usual as well as native integration with "green buttons" (quoting a FoV workshop IIRC: The operator world is physical - does not only apply to SIMs but also the belief in buttons) - is the wrong way to go.

What we need are operator movement with the right partners, building ecosystems with a different drive and taking the changed world into account, building real services for this century. I am very happy that exactly that is not only theory, but practice. I've attended and been deeply impressed by the TADSummit - which aims at solving exactly that - but before writing about that I shall finally finish my guest post (it's going to be about WebRTC, and less theoretical this time).

Stay tuned!