Virtualization is a hot topic, made more so by IBM’s potential acquisition of Sun; two leading proponents of virtualization and cloud computing. From an enterprise perspective the drivers for virtualization are saving cost; and improving employee efficiency, manageability of IT and enterprise security. Take for example desktop virtualization, e.g Sun Ray thin clients, it’s your standard PC experience except its running in the cloud so you can use any client as your own, no boot-up time, screen as you left it the night before, and the data is kept within the enterprise. Other virtualization examples include Salesforce.com, a leading light in Software as a Service (SaaS), virtualizating the CRM (Customer Relationship Management) application.
Virtualization can be applied across a number of aspects, e.g. data center, server, application, service, desktop, database, storage, mobile device, network, and the focus of this paper the service delivery platform (SDP.) By the way, I’m going to look at the opportunities and threats virtualization presents to telcos in another article coming soon.
These virtualizations fall into two broad categories, SaaS and IaaS (Infrastructure as a Service). The SaaS model is being extended to include Platform as a Service, e.g. BT Ribbit’s (communications focused) and Sun’s Zembly (social network focused) which provide development environments. The distinction between SaaS and PaaS is more marketing, e.g. Salesforce.com has Appexchange for developers to create new applications, so could claim to be a PaaS; hence I’ll use SaaS and PaaS interchangeable until someone points out the error of my ways.
We’re seeing operators deploy SDPs as a traditional licensed product running on servers within their IT infrastructure. But what does SDP virtualization mean to operators? Are the cloud based SDPs a threat or a complement?
There are two main functions of the SDP: Service Factory (e.g. iPhone SDK) and Service Shop (e.g. iTunes). The Service Shop can sell to a number of customers, e.g. consumers, enterprises or developers, though the developer shop is really more of a factory store. The Service Factory provides the tools to ensure the application works on and can use capabilities being exposed by the device and/or network/factory. Now within the SDP there are functions such as policy, identity, security, charging, cataloguing, sand-box, etc. I’m not going to go into those details in this article.
Looking at how the cloud SDPs are monetizing themselves:
BT Ribbit’s, charge for communication APIs, e.g. seats, calling, texting, transcription, etc.
Sun’s Zembly, charge for use of their hosting infrastructure;
Mashery, charge for API use which they aggregate making it easier for developers to access;
Microsoft Azure, none made public, but given its focus on working with operators will likely look at revenue share or hosting charges; and
Salesforce.com, charge for seats and additional revenue from applications.
But back, like a broken record, to the fundamental issue – customer access. Sun’s Zembly is focused upon social networks, e.g. Facebook, where you can create cool apps, like ‘stamping on friends’ rather than ‘poking’ them, and get ad revenue from the impressions, of which Sun takes its share for hosting. Salesforce.com has an extensive customer base and sales force, the apps help sell its core service and win additional revenue. Mashery and Ribbit provide services that require enterprises to bring their own customers, e.g. Mashery’s hosting of ‘developer.nytimes.com’ or Ribbit’s focus on verticals such as Salesforce.com customers or the ‘travel and hospitality’ sector.
So the consumer/enterprise Service Shop is clearly something that an operator needs to have if it wants to sell services. Going back to the Factory analogy, there are multiple stages in production, e.g. dye factories, cloth factories, and jeans factories. A telco’s role in service exposure (location, presence, calling control), policy, identity, security, and charging means it’s the finishing factory that ensures the product is fit for purpose, wraps it up in a pretty bow and addresses it to a specific customer. Which means an operator’s Service Factory must be able to work with the many other cloud based factories, e.g. Microsoft Azure, partner operators with their development programs, Sun Zembly, etc. However, such a factory runs the risk of being bypassed, by others further up the supply chain going direct to the consumer. How operators as an industry structure their factories to minimize this threat as been discussed from an industry perspective in these articles.
- Why the Mobile Industry needs to keep an eye on Cable’s Canoe Ventures
- Options on how the Telco industry can work with the App Development Industry
- The Long Slow March towards a Utility Business Model: Mobile World Congress Summary 2009
What all this means to an individual operator’s SDP plans will be explored in another article coming soon 🙂
“But what does SDP virtualization mean to operators?”
There are a couple of models to look at it
1. Operators willing host “their” SDP on cloud
2. A third-party hosts SDP on cloud and at network-level integrates with multiple
operators and allows the higher-level services access network services in unified
Former one – CAPEX and OPEX savings can potentially attract operators. But .. the usual cloud-pessimism (cloudophobia ??!!) of security could create a barrier
Latter one – Lots could be spoken on this model
1. This is more like getting once-again into walled-garden vs open-garden debate
2. More value-addition to end-user services would come from only by such a SDP being
operated by a third-party and not by operator. This has been proved time and again
in the past in some niche services
3. Operators’ choice has been to expose their network capabilities ONLY if they could
get larger pie of what could be charged to end-users
4. (3) and (4) together creates a tension which has to be tackled
5. Considering (2), TCO of such a third-party gets reduced (thanks to the Cloud) and
hence, they would be in a better position to negotiate revenue-shares
1. Trends such as All-IP networks where both voice and data (4G-LTE) have to go over
IP may cause operators to change their mindset
2. Unified interfaces for accessing network services
(http://experiasphere.wikispaces.com/ and GSMA OneAPI kind-of initiatives)
Service Level benefits
1. Services which mashes-up network capabilities across the operators would indeed
create more user-attractive services than having services which are utilizing the
services of single operator
🙂 What it means to operators is coming in my next weblog entry, I’m just setting up the problem space. I agree with your points. However, there are some important distinctions that need to be included in understanding what it means to operators: the size and type of operator (what Vodafone does will likely be different to what a du in the UAE does); the addressable market (consumer, business and developers); the internet maturity of the market (in many countries people are experiencing the internet first through their mobile phone, not the PC,) and the operator’s cultural openness to working with the web 2.0 crowd (which for operators isn’t easy as their business models are quite different.)
In my next weblog article on this topic I’m going to be covering the points you raise, but examining the quantified benefits through some typical scenarios based on the distinctions I raised above. Virtualization is not a one-size-fits-all, it can be applied in a number of ways, that flexibility could make it easier for the variety of operators out there to monetize third party innovation.
“… the size and type of operator … ” –
That’s an inetersting dimension!!!
Waiting eagerly for your article.