Print
Category: Uncategorised

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.