Service Delivery Platform Virtualization

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, 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. 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, 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. 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 ‘’ or Ribbit’s focus on verticals such as 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.

What all this means to an individual operator’s SDP plans will be explored in another article coming soon 🙂

3 thoughts on “Service Delivery Platform Virtualization

  1. Muthu

    “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
    Business Perspective
    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
    Technological Perspective
    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
    ( 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

  2. Alan Quayle

    Hi Muthu
    🙂 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.
    Best Regards,

  3. Muthu

    Hi Alan,
    “… the size and type of operator … ” –
    That’s an inetersting dimension!!!
    Waiting eagerly for your article.

Comments are closed.