Mac Taylor - Editor
The Service Delivery Platform (SDP) market can be
defined as a market for products,solutions and
professional services used in designing, implementing
and operating SDP architectures as well as services
running on these architectures.
The SDP market is a part of the Telecom Service Layer
and IT Infrastructure market. Unfortunately, there is still a lot
of confusion and misunderstanding around the SDP market and SDP as such.
In this introductory section we provide an answer
to two important questions: what is the scope of SDP market
and what makes a ‘real’ SDP. We also analyze SDP
market drivers and inhibitors, SDP investment
patterns and dynamics in operators’ decision processes.
SDP Definition and Scope
The term SDP was coined around year 2000 to describe a common service architecture designed to deliver mobile content and mobile messaging services. Since then the concept and the scope of SDP has evolved embracing new classes of services such as voice, multimedia or realtime charging, and new technologies such as IMS, SOA, and Web Services. Today’s ‘third generation of SDP, often referred to as SDP 2.02, puts more stress on the business and management aspects. It also plays a key role in bridging Telecom with the Internet and Web 2.0 and in helping Communication Service Providers to transform their business models.
The concept of SDP is so general that it can be used for a broad range of services that are not strictly communication services. For example, these include: IPTV, Video-on- Demand, social networking, Web search engines, or emerging Software as a Service (SaaS) platforms.
Horizontal, layered architecture, abstraction of network and IT capabilities and the use of standard technologies, enablers and reusable components are paramount characteristics that distinguish a Service Delivery Platform from traditional ‘vertical’ stove-pipe solutions. IN-based Prepaid services, messaging services built on SMS Centers and other vendor-specific service ‘stove-pipes’ should not be considered as part of the SDP market.
The stove-pipe investments continue today and will continue in the future. However, the pressure for new blended services which can provide differentiation and improve customer experience pushes telecom architects to consider SDP as a viable solution for the long term.
On the enterprise side, architects working on Software as a Service projects have adopted from the beginning the SDP paradigm.
Key SDP characteristics –
what makes a ‘real’ SDP
A service platform must have certain characteristics to be classified as an SDP. It should provide an open environment exposing network and IT capabilities as well as intangible assets (e.g.: user identity) in ways that enable cost and time efficient service creation, composition, orchestration, execution and management.
Services running on an SDP should share common execution environments, data repositories, reusable service components, and standardized sets of service enablers. An SDP may also provide secured and managed Third Party access to selected network services. Each Service Provider should be able to monetize services running on an SDP in one or more business models.
There is no standardized reference architecture for SDP that can yield repeatable implementations. To qualify hundreds of service platforms deployed today, Moriana has created a test for a ‘real’ SDP based on five principles:
• Use of standard technologies:
SDP software and hardware components are based on commercial products that expose open standard interfaces facilitating extension, replacement, and integration.
• Horizontal, layered architecture:
the platform consists of clearly defined functional layers (see picture below) starting with the service enablers which can spawn multiple networks and protocols to expose a set of commoncapabilities
• SOA-based system integration:
distributed capabilities of an SDP are integrated using SOA principles applied either to components at a certain functional layer or to interactions with external systems such as OSS/BSS orThird Party platforms3
• Common, reusable components:
Services running on an SDP share building components, execution environments, management interfaces, and data repositories
• Open APIs for services creation:
Services can be easily created on SDP using standardized open APIs. They can be deployed on SDP execution environments or run remotely using Third Party interfaces.