Another cost-effective way to provide a single-tenant solution is to have smaller individual software deployment footprints. This would facilitate deployment of a large number simultaneously using a large number of VMs. Interestingly, for Avaya IP Office or other smaller key system-derived offers, deploying the relatively small software footprint of the core softswitch for each customer into a multi-VM-per-processor structure enables single instances to be cost-effective for sub-100 seat customers. (By the way, this is why many VARs use a company like
Asterisk to deliver small cloud solutions.)
In our opinion, whether a UCaaS deployment is multitenant or single instance, the fact that it’s purchased on an MRR basis and is operated by the third party makes it a cloud solution. Whether the contract includes discounts or requires a time commitment doesn’t change the cloud MRR delivery model.
This begs a question: Is a deployment where everything is the same except where the software is deployed a cloud solution or not? Should the location of the processing determine cloud versus non-cloud, MRR versus non-MRR? In the old days, a managed PBX was a complete stand-alone system. Today, deploying a cloud UCaaS solution in the customer’s data center means deploying just a few VMs (and a real-time capable infrastructure). In some cases, there are no physical resources to manage since the customer data center does that for the vendor and just provides VMs to deploy into. In many ways, this is akin to deploying software in the Amazon Web Services cloud.
From the customer perspective, a service in which the communications solution runs on premises but is managed by a third party is still an OPEX monthly cost and is perceived exactly the same as if it were a cloud solution. The only difference is where the software runs. By enabling the software to run on the customer premises, generally in a private-cloud deployment, two major advantages accrue. First, the security concerns of data being in the cloud are dramatically alleviated; even though it is a billed under a cloud/MRR business model, the core servers, software, and data stay on the customer premises. Second, in a deployment where the core software runs on the customer premises, the customer pays for all the infrastructure required in the data center (compute, storage, network access, etc.), making it less expensive for the managed services provider.
The conclusion appears obvious. Larger customers from Cisco, Avaya, Mitel, and NEC will move to the MRR cost models typically seen in “the cloud,” but they will generally move to dedicated single-instance deployments, running either in their own private clouds or in private clouds hosted by service providers. For both the financial industry evaluating the performance of the companies in this sector and the end customers, multitenant, single-instance, and varied/hybrid deployment locations all have the same impact: They transition from the capital-intensive periodic purchase with its accompanying operational expenses to an MRR-based, OPEX-oriented, managed services model.
For enterprise customers, the financials and the implementation specifics will be resolved via market competition and the pricing impact it will have. For many Cisco UCM, Avaya CM/Aura, Mitel MiVoice on-premises, and NEC on-premises customers, their sheer size will minimize the cost penalties of the single-instance deployment. For smaller companies, however, these solutions won’t scale down to the SMB and smaller mid-market levels, so Cisco, Mitel, and NEC have developed or purchased their own multitenant offers and Avaya has indicated it will have one soon.
Conclusions
We believe the three views of what constitutes a viable cloud solution: customer, vendor, and financial may converge to a common view that cloud is more appropriately defined as an MRR business relationship where the customer never “owns” the software. Focusing on MRR/subscription relationships as the defining factor of cloud enables a true evaluation of the offers and market success. With this viewpoint, we can draw a few key conclusions.
- We believe that the financial markets will consider MRR in multiple forms as viable cloud business models. This may/should include all the MRR models emerging in the market:
- Multitenant cloud
- Managed services regardless of who owns the equipment and where it’s operated
- Subscription services (like Cisco Flex Plan), even if the organization runs the solution itself
- We believe that in the mid-term, Cisco, Avaya, Mitel, and NEC will try to migrate many of their larger customers over to an MRR model in which these vendors themselves manage the dedicated- instance solution, regardless of whether it runs in the vendor’s cloud, in a private on-premises cloud, or in a third-party data center. Their valuations depend on migrating a sizeable portion of their bases to this model and the financial markets see this as attaining “cloud” evaluations.
- The overall UCaaS market will migrate to this more general view of MRR being the valuation driver rather than cloud multitenant technology being the valuation driver.
As the concepts of cloud and MRR in the UCaaS space mature, the movement to cloud will drive acceptance of the different deployment models. Large organizations with security and operational concerns can move to a cloud-based model that incudes local or dedicated cloud deployments but reflects the operational and MRR values of cloud. Smaller organizations will tend toward the large multitenant clouds that can deliver lower cost with small numbers of users. This broader definition of cloud will accelerate the adoption of cloud by enabling optimized “cloud” solutions for a range of customer requirements.
The result of enabling large enterprises to migrate to MRR/cloud easily, even with the security of having the software running in their own private clouds, will be dramatic. If the current large enterprise telephony premises incumbents can migrate a substantial portion of their installed bases to the new range of cloud/MRR models, the financial outlooks could be very interesting.
