- Béatrice PIQUER DURAND
- Ipanema Technologies
(Sponsor-Contributed Paper)
Whilst Telecommunication service providers are the actual providers of the cloud (the network) they face difficulty to be seen a "cloud providers". Ask IT people to name a few cloud providers and you'll get many Salesforce, Google, Microsoft, IBM, Rackspace, Equinix, Amazon, Netflix... and few BT, Orange, NTT, AT&T... OTT ("over the top") and software editors get most of the cloud mindshare.
At the same time, to streamline operations, lower cost and accelerate transformations, enterprises have consolidated applications within a few private datacenters and in the cloud (e.g. SaaS applications); the network (private VPN or Internet based) is in charge to connect users and customers to these application servers and data warehouses. As a consequence there is a direct connection between the business performance and the way applications perform across the network.
So isn't it weird that, despite a growing offer of cloud services (application hosting, server and storage, unified communications...), Telcos's cloud offering are not more successful and that they are not seen as natural providers of connected cloud services? We believe that the root of this (relative) lack of success is due to the cultural shift between IT and network that are different in many of their aspects: technology, know-how, pricing... Telcos' DNA is selling transport capacity at a fix monthly price. The chasm between providing and selling network and cloud services is wide, and sales team struggle to pitch and position cloud offerings that are often more pricy than the network they used to sell; synergies between the offerings are not easily articulated; cloud and network business units work in silos.
So where is the light? As the chasm is wide, let's build a bridge between its network shore and its application shore: application aware network. Networks that speak, learn and adapt to applications to guarantee their performance in a dynamic environment. Make applications visible, control and accelerate them. Some Telcos already provide such services to their enterprise customers (e.g. BT's Connect Optimisation, Orange's Network Boost, Easynet's Smart Application Assurance, Swisscom's APM, Telecom Italia's TIPAM, KDDI's Applicot...) as added-value services on top of their MPLS (or hybrid MPLS + Internet) offering.
The next evolutionary step is to move from an IP network to an Application network by embedding these features within the network and to hook communication services (UC) and cloud services in order to provide a true end-to-end cloud delivery service.
The missing link you are so worried about for business (not just person-to-person) communications is being taken care of by the advent of WebRTC that adds flexible IP-based communication connectivity to online/mobile apps. It also provides "contextual" user information to any mode of contact initiated by the online user from within the app, rather than a separate contact action from a person unconnected to an application.
Isn't WebRTC limited to browser-based applications? (And only some browsers at that?) My understanding is/was that WebRTC is primarily for session control for audio and video.
What am I missing?
What I see is that the online apps will offer more than one option to make contact, e.g., chat, email, voice/video. The voice/video option will use WebRTC, while the others can use the normal browser forms of access (links to messaging options.)
With online self-service apps, the main reason for live assistance might well be something in the self-service app not working right for the user, but rather than placing a separate phone call, the option to "click-for-assistance" by phone is there with WebRTC instead. Many online apps are already using chat for online assistance, and Amazon's "Mayday" button offers one-way video, two-way voice, plus shared control of the screen for live assistance in helping a user with their Kindle device, but gives no choice to the user. If you are going to generalize the online self-service application needs for mobile users, you really have to offer the user their choice of interaction mode, but that can be done at the app level user interface.
You are right about browser-based applications, but that's how mobile apps will be accessed by "dumb" smartphones and tablets.