CloudLink: Mitel’s On-Ramp to Cloud and the Internet of Things
CloudLink is central to Mitel’s acquisition and IoT strategy
At its June 2017 analyst meeting, Mitel announced a strategy, called CloudLink, that has become a focal point of Mitel’s product roadmap and a key element in its ability to absorb future telephony acquisitions. CloudLink is also part of Mitel’s IoT enablement planning. At a high level, CloudLink provides
- A bridge to enable any Mitel call control platform to interface with cloud-based applications.
- Access to vertically-focused micro applications.
- An aggregation point for an organization’s IoT sensors that can trigger communications actions or responses.
- APIs for third-party developers to create their own applications.
- A zero-code application development environment for non-programmers to create their own apps.
- An integration point for using third party cloud apps like Salesforce, Zapier, If-This-Then-That, etc., using call control signaling and notification in the workflow.
CloudLink as a “Bridge to Cloud”
With the Aastra and soon-to-close Toshiba acquisitions, Mitel has a larger variety of call control platforms than any other vendor. One of the company’s mantras has been that it does not require newly acquired end user customers to upgrade to a Mitel-branded call control solution and handset; rather, customers with any of these platforms can continue to use the call control engine they currently have, and Mitel will continue to support it. These customers will eventually need to upgrade, and Mitel will be there with new systems and/or cloud-based offerings when needed.
Why is CloudLink strategic? Because CloudLink gives application developers access to the 60 million telephones that are connected to the many Mitel call control platforms. CloudLink does this by normalizing proprietary call control signaling so that an application built in CloudLink can use nearly any PBX a customer already has in place. Plus, it makes it easy for Mitel to do additional acquisitions and to provide an immediate pathway to cloud applications for the new customers.
The CloudLink Architecture
CloudLink has two elements: one is the CloudLink application server that runs in the Amazon cloud, and the other is called the CloudLink gateway. The CloudLink gateway is physical device about the size of a small router that can be deployed on-premises or in the cloud. This gateway is programmed with adaptors that are used to communicate with the underlying call control platforms. Communications can be done using a specific PBX’s signaling protocol, or the gateway can use generic SIP or QSIG, which ever is most appropriate. The CloudLink gateway normalizes these signaling protocols so that there is only one signaling and messaging protocol between the gateway and the CloudLink application server. This is a compelling part of Mitel’s acquisition strategy because should Mitel acquire additional telephony companies, an adaptor would be written so that the CloudLink gateway works with the newly acquired call control engine. (An interesting side note is that the Aastra acquisition provided Mitel with 20+ call control adaptors from one of the Aastra’s European divisions.)
Figure 1. Mitel CloudLink architecture showing integration with both on-premises and cloud-based call control.
The CloudLink application server provides APIs and development tools for application builders who can create applications programmatically as well as a new zero-code development environment (available late Q3/early Q4) for non-programmers. The zero-code environment provides a drag-n-drop interface and intuitive toolset so that communications workflow applications can be created by nearly anyone. I wrote about such an environment in an earlier NoJitter.com post (Integrations and Mashups Via the 'Un-API').
Both development mechanisms allow apps to be created that work with any of the call control engines supported by the CloudLink gateway. The CloudLink application server also provides a run-time environment for the applications to execute in. Applications can be customized for a particular customer, or applications with broad appeal can be multitenant, purchased and run by any Mitel customer. Finally, the application server provides hooks to select third-party cloud-based applications for which Mitel has built an interface, like Zapier, Salesforce, and others.
Micro Apps
Mitel’s own software developers are using the application programmer interfaces (APIs) available in CloudLink to create what Mitel is calling micro apps. Micro apps will generally focus on a particular vertical and they will generally have limited scope and functionality. They are intended to provide highly valuable, broadly-needed, reasonably-priced functionality that customers in a particular vertical can easily license and use.
Third-party developers can also create applications in CloudLink and make them available through an online store capability for end user companies to purchase. This is similar to what other vendors are providing in their online stores and development environments.
A prime example of a micro app would be a notification application: when a notification event occurs and people need to meet, telephones on any of these systems can ring, bringing people into a conference.
Connecting with IoT Sensors for Real-Time Communications Processing
One of other capabilities CloudLink offers is a way to integrate with IoT sensors, and then trigger communications processes and events based on sensor state. The company demonstrated a notification process based on sensors connected via a LoraWan Low Power Wide Area Network. In this instance, notifications were sent via SMS and email to emergency personnel in an airport when a defibrillator door was opened. A second demo showed an on/off switch that also triggered alerts including dialing out to someone.
To be completely accurate, this demo used the Mitel Mass Notification capabilities based on the recent Benbria acquisition, which has not yet been fully been integrated into CloudLink. However, integrating the Benbria capabilities into CloudLink is on the immediate roadmap, and one can easily conceptualize how CloudLink can be used to create complex communications-enabled business processes that use data from IoT sensor data.
Some Analysis of CloudLink
Creating a gateway so that a particular vendor’s unified collaboration capabilities can work even if someone else’s call control is part of the mix is not new. Nortel did it with ACE, so that Nortel’s other applications could use underlying third-party call control. IBM did it with Sametime Unified Telephony, the idea hear being that anyone could deploy Sametime and integrate it with any vendor’s call control so that the Sametime client could be used as a telephony endpoint. And there have been others who have tried. None of them gained any traction.
Creating Vision with CloudLink
What’s different with CloudLink is that it is not relegated to using Mitel’s apps. Customers can build their own apps, their own communications-enabled processes, and their own IoT-enabled communications processes, as opposed to just relying on those provided by Mitel. Furthermore, these apps become easy to consume because they are cloud-based. The capabilities we saw with IoT sensors triggering communications processes were indeed compelling.
But more than that, CloudLink allows Mitel to create vision.
One of the challenges facing PBX manufacturers, with the exception of Cisco and Microsoft, is the ability to create a vision for the future in hearts and minds of the partner channel and the user base. Telephony vendors, for the most part, have been unable to create a compelling vision, and where there is no vision, the PBX vendor falters. Cloud has helped establish vision to some extent for companies like RingCentral and 8x8, Vonage, and others, but by and large, the major PBX manufacturers like Avaya, Unify, and Alcatel Lucent create little excitement in the user or prospect base. Mitel has had the same challenge: it has been looked at as a sort of stodgy PBX company, who happens to be growing through acquisition. CloudLink may allow Mitel to break through this barrier.
I also have to wonder if the micro app idea is going to work like Mitel thinks it will. By definition, the micro app is a very specific, limited functionality, application. These may be easy for Mitel to develop, but can they generate enough revenue to be sustaining? One of the challenges with software is that the real costs start once the first version is released. They must be maintained forever. Will there be enough money generated by any of the micro apps to support the sustaining effort required, and how will Mitel keep micro apps from transitioning over time, due to software bloat, to mini and on to major apps over time accompanied by major support costs? We will see how this plays out.
Overall, I like the concept behind CloudLink. It enables an instant on-ramp to cloud-based app consumption for all existing and future Mitel customers obtained through acquisition. CloudLink will be released later this year, and we will watch with great interest to see how application attach rates and IoT-enabled business processes roll out across Mitel’s customer base