August 2016

Mac Taylor - Editor


SDP Market Stakeholders

We consider the following segmentation of stakeholders in the SDP market:

vendors of SDP products, solutions and professional services;

buyers of SDPs including Network Operators and other Service Providers;

investors in SDP technologies and solutions; and

end-users and subscribers of SDP services in business and consumer market segments.

Vendors of products, solutions and professional services

The SDP market represents only 2% share of overall telecommunications investments of over $1.3Trillion per year. Nevertheless this is enough an opportunity for several types of suppliers to upsell their core competencies.

Network Equipment Providers (NEPs) such as:

Alcatel-Lucent, Nokia, Motorola, Ericsson and Huawei offer comprehensive SDP solutions. They approach the SDP from the network side which is their traditional area of dominance. NEPs’ SDP offerings utilize:

SOA, middleware and other solutions, e.g. identity servers, LDAP servers, and databases from leading IT vendors. NEPs often partner with ISVs to offer high quality or highly specialized software such as telecom application servers, policy engines or Content Management Servers (CMS) as well as successful revenue-generating applications.

Enterprise IT Vendors such as:

Oracle, IBM, HP, Sun, and until recently Microsoft, moved aggressively into the SDP space either by partnerships for the networks and OSS integration or by M&As. They approach the SDP from the operator’s IT infrastructure and OSS/BSS side, where their position has traditionally been much stronger than on the network side. IT vendors create an SDP by extending their Service Oriented Architecture solutions, enterprise application platforms (J2EE and .NET) with telecom-specific components (e.g. SIP Application Server or Web Services based Network Gateways), service enablers and support applications (CRM, Billing, etc.). These SDP solutions are based on standard middleware and software products which create a low cost, “ready to assemble” SDP from these vendors (e.g. Oracle’s “SDP on a CD”).

Some IT vendors such as Oracle, IBM and Microsoft “own” application developer communities, which can be leveraged in the SDP space. HP and IBM play strongly with their Professional Services arms taking over long term management contracts after launching an SDP in production.

System Integrators (SIs) such as: 

Wipro, Accenture, Atos Origin, LogicaCMG, Cap Gemini, TCS as well as regional SI players had a predominant role in the initial development of SDP market. They leveraged the fact that an SDP is not a product, but rather a set of products that needs to be integrated into the operator’s network and IT infrastructure. They build their SDP offerings from components and products offered by different vendors: NEPs, Enterprise IT vendors or ISVs.

In the future, network and OSS/BSS integration will still be required for every SDP, but new pre-integrated SDP solutions built on the SOA principles will require less system integration than before. However, the SIs will keep very busy as the number of deployed SDPs and demand for new service creation and integration services increases.

August 2016

Mac Taylor - Editor


SDP Market Structure

This is a first time analysis of what needs to be included in the SDP market in terms of scope, offerings, stakeholders, trading models and detailed segmentation, with explicit references to what is not to be included and what should be considered as secondary market driven by the primary SDP market.

SDP Market Scope

Offerings in the SDP market comprise SDP products, solutions, service enablers, middleware, software applications (identified as SDP services) as well as SDPrelated professional services. Depending on which elements from these categories are included in the SDP market and which not, the overall SDP market sizing and forecast can vary significantly. Different analysts have different opinions on the components of an SDP and use their own view as the base for SDP market sizing.

The relevant SDP market can be subdivided into three major areas of supply and demand:

Software products and solutions:

functional components such as:

service enablers, network gateways and third party gateways (Parlay gateways, Telecom Web Services/Parlay X components, XML gateways), support components common data repositories; identity and access management systems, optional content management systems or policy management and enforcement systems,

middleware and integration technology such as:

SOA middleware solutions (WS adapters, UDDI or other service registries, Enterprise Service Bus/ESB, business processes management, rule engines, application server platforms based on technologies such as J2EE, .NET, JAIN SLEE, and implementations of protocol stacks such as SIP, SMPP, etc.);

Value added services and applications:

usually neglected by analysts, these are also components of the SDP market that make up for the “long tail” of services; they have value for the end user and justify the ROI for the SDP. Several classes of services are offered today on SDPs: Mobile content and messaging (WAP/HTTP, SMS, MMS for mobile browsing, advertising and personalized content push or download),

Mobile commerce and payment (m-wallet, virtual calling card, small payments), Voice - NG IN & Telephony (free number, Centrex, PBX, VPN, Home Zone, Number Portability), VoIP & Multimedia (packet voice, mobileTV, video sharing, music, games), IPTV & Triple Play, Third Party Access (exposure of network capabilities in a wholesale model or on-boarding of applications running on Third Party platforms), other services (Presence and Location Services, Mobile Office Services, etc.)

Professional services and consulting

include business consulting to formulate the strategy for adopting an SDP, design, implementation and deployment of SDP architecture including integration with the underlying network elements, such as SMS-Cs, MMS-Cs, positioning systems, IN and IMS core elements, creation and deployment of service enablers and value added services to run on the SDP, integration between the SDP and Third Party domains to allow access to service enablers exposed by the SDP or to create SDP service enablers that need access to Third Party systems (this effort can be rolled under a certain type of service enabler), integration of the SDP services execution and management flows with Service Provider’s business and operation processes through new or existing OSS/ BSS elements such as charging platforms, service lifecycle management, customer care systems, etc.

This area requires a 2-ways optimization and re-engineering of existing processes: first to include SDP services in the common Service Catalogue so they become available for product management and marketing and second, to adapt current processes to the operation of an SDP and of services running on it by adding new software and service lifecycles management specific activities.

When it comes to SDP products and solutions, it is not decided if components, such as presence servers, identity management, policy management on one hand and SOA related technologies such as Enterprise Service Bus (ESB) and service registries on the other hand belong to the SDP or not. We consider the former set as service enablers exposed on the SDP out of the CSP’s Services Layer, hence a secondary market driven by SDPs. The latter is generic IT infrastructure: investments in SOA infrastructure are in most cases driven by operators’ IT departments to rationalize OSS/BSS systems integration and support process automation.

The cases when the adoption of SOA is driven solely by an SDP deployment are quite rare. The SOA components market driven by SDPs is limited to what is embedded in the SDP solutions. Likewise, it is not clear if all value added services and applications running on an SDP should be counted as a part of the SDP market or simply as a part of the global market for Telecom services and applications. Some analysts include for instance device management services, but do not include mobile commerce or advertising services.

A substantial number of mobile services, including content-based services, are run by third parties platforms using service capabilities exposed by mobile operators’ SDPs. Third parties build and operate their own SDPs to run such services creating a parallel SDP market, still to be analyzed. The whole market segment of SDP solutions for Third Party service providers and service integrators is usually not included in the SDP market scope by market analysts.

Similar issues occur when we analyze the scope of professional services pertaining to SDP projects. Professional services should be assigned to business consulting creating the business case for an SDP, design of the SDP to meet CSP’s requirements, custom development and integration, and eventually, project management.

Consulting on business process reengineering is an example outside the scope of the SDP market excepting the case when they address integration of SDP services in the overall business model of the CSP.

Lastly, the term SDP is often used (or rather misused) to describe service platforms that are “stove pipes” rather than “real” SDPs for example cases of services using VAS interfaces of SMS Gateways. While they include SDP concepts, such platforms focus on exploiting a specific server capabilities and should be considered at most as service enablers when they expose those capabilities to a real SDP. On the other hand, many cable operators and other service providers build and operate Service Delivery Platforms for digital TV, IPTV, Video-on-Demand, VoIP, etc. but they simply do not call them “SDPs” when architecturally these platforms comply with the principles of an SDP and should be included in the market.