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 🙂