What is a ‘service delivery architecture’?  It really depends upon with whom you are talking.  Are they are a vendor trying to sell IMS (IP Multimedia Subsystem), or a Java games download platform; or are they an operator responsible for value-added communication services, IPTV, or content services.  Each will likely give quite different answers.  Service delivery architectures have a long history; their roots can be traces to the FN (Feature Node) that emerged in the intelligent network (IN) concept defined by the ITU-T back in the 1980s.  In the FN a SCE (Service Creation Environment) enabled operators to create new communication services without the need to change the software in the exchanges.

This evolved into the IN SDP (Service Delivery Platform), an architecture that enables re-use of service components.  Most operators today have IN implemented in their networks, though most of the SDP implementations tend to be bundled into a specific service implementation, for example caller ring back tone.  The IN SDP has not achieved the ubiquity of deployment as a horizontal layer within the telecommunication software stack, rather a component of a vertical application.  The move from vertical (stove-pipe) to horizontal: faster and cheaper time to market for new services and enabling service innovation independent of switch vendor did not significantly happen.

As networks have evolved from circuit-centric to packet-centric, the SDP has started to extended its reach beyond communication services, to include content services, streaming services, and even broadcast services.  With this move the use of SOA (Service Oriented Architecture) as an integration framework has emerged, given the successful implementations of SOA for BOSS (Business and Operational Support Systems) systems.

So we arrive at today, where the SDP is has come full circle and is positioned again as a platform for the creation of new communication services, but this time in the IP domain encompassing IMS.  Since 1999 IMS (IP Multimedia Subsystem) has been standardized by 3GPP, it enables service control for IP based multimedia communications, across any IP based access.  So the SDP is now positioning across all services and all access, an all-encompassing service delivery architecture, with a total market size of roughly $2B in 2007, source OSS Observer.

A commonly used service delivery platform definition is an IT-based environment, enabling service creation in an environment that does not rely on a specific network element enabler. This comes from the need to cut costs in the service creation process; in saturated markets service providers want to differentiate through their service offerings.  And the need to enable third-party companies to provision services through the service provider environment.  Typically, most SDPs include a service creation environment, a service orchestration environment, a service execution environment and third-party management.

Another way to look at the SDP is to relate it to boxes/functions we already see in an operators network:

• Content Delivery Platform, e.g. a platform that enables content such as ring-tones or movies to be successfully presented and delivered to customers.
• Communications Gateway, e.g. a Parlay server that exposes call control capabilities.
• Telco API, e.g. The exposure of network capabilities across communications and content to third parties.
• BOSS, e.g. a service creation process aligning to ‘Common Capabilities.’  A Common Capability is used by many different services e.g. IVR; an ‘authentication’ common capability that bundles the capabilities of an AAA server with some of the features of an ID management system; and accounting functions, e.g. an internal directory server.

Taking this view it becomes a little clearer why there are just so many suppliers that fall under the SDP label, a subset is listed here: Accenture, Acision, Alcatel-Lucent, AePONA/Appium, Airwide, Amdocs/Qpass, BEA/oracle, Broadsoft, CoreMedia, Comverse, Convergin, End2End/Mach, Ericsson/Drutt, Genband, HP, IBM, IMImobile, jNETx, Metaswitch, Microsoft, Motorola/Leapstone, Motricity, mPortal, NSN, NEC, NetCentrex, Nortel, OpenCloud, OpenWave, Oracle/BEA, Pactolous, Personeta, Qualcomm/Elata, Red Hat/Mobicents, Redknee, Telcordia, Telenity, Sun, Sybase/Mobile365, Ubiquity/Avaya, Verisign/mQube, Volantis.  The SDP Landscape is definitely complex, confusing and consolidating as I write.

But coming back to why an operator should consider a SDP.  The drivers for the SDP are clear: to extend the life of traditional services; lower costs associated with the development and introduction of new services; extend services across networks and devices; provide an operating environment and development tools for third-party software developers; and improve the profitability of niche services.  However, the challenges to implementation are equally as clear: managing end-to-end application performance; modular, standards-based service delivery platforms are still relatively immature; integration; service provider organizational challenges; lack of a compelling business case; lack of standards creates confusion and trepidation; and marketing challenges.

As part of the SDP (Service Delivery Platform) workshop a run I go into depth on this topic and review a number of case studies.  In general my recommendations for operators are:

• The part of SDP that deals with operations (BOSS) has a clear business case and operators are adopting the same tools as enterprises based on SOA;
• The part of the SDP focused on content services is maturing and becoming a managed service;
• The part of SDP focused upon communication services is still in an experimental stage, with some initial success focused upon enterprise services;
• The part of the SDP focused upon third parties, the Telco API is a current hot topic within the industry with a few examples of initial success such as Sprint’s Business Mobility Framework.

How the parts get integrated into an all-encompassing SDP is a question I’ll leave for another weblog entry.