October 2016

Mac Taylor - Editor

Inhibitors for SDP market growth

Lack of an eco-system for “ready-to-deploy” services at SDP architectural level, able to bring a quick answer to each CSP expectations: from those seeing the SDP as the vehicle for the next “killer application” to those expecting their SDP to support the “long tail” of services. Finding the application developer and the system integrator who can perform an adequate job within a specified budget and a time-frame remains a challenge; every SDP project is different, the design must meet specific needs of the operator while there is no standard SDP architecture and very few components specified by industry organizations (e.g. some of OMA’s Service Enablers). This is especially true for core telecom voice services or services such as IPTV. For example, the early adopters of voice enabled SDPs faced issues with finding Third Party application developers who could create revenue-generating services while assuring the quality of core telecom services; this type of work is not for “garage” start-ups and requires partners who can guarantee the quality, delivery and future maintenance of such services.

Lack of a standardized and largely adopted framework for CSPs business and operation processes which would include management of SDPs, expanding the value network and enabling new business models. Today, each new service deployed on an SDP must be ”plugged” into existing OSS/BSS infrastructure and its lifecycle integrated through custom solutions, when possible, into business processes such as order management, fulfillment, provisioning, charging and assurance. For this reason, many SDP services are offered for free as part of voice bundles, diminishing the value of the SDP investment. There is no framework for common SDP services lifecycle management and many SDP services do not count as assets for the CSP.

With the exception of TeleManagement Forum’s Service Delivery Framework (SDF) initiative, there aren’t any efforts to show how SDPs enable Network, Device and Service to come together in product offerings and how services can be managed end2end for a rich Customer Experience. Consequently each SDP project requires a complex integration plan preceded by a business consulting stage to explain how the SDP can enrich the current business and operations environment. On the bright side, the rapid adoption of SOA in Telecom for OSS/BSS transformation enables the third generation SDP to be designed around standardized IT architecture which not only facilitates rapid integration but to great extent compensates for the lack of SDP specific standards.

Conflicting Internal Interests

– business organizations who control budgets will support a “stove pipe” solution with proven market traction and coming from a known provider even if it has a higher CAPEX than an SDP-based solution because they must minimize the time-to-market and limit the risks for launching new services. This choice conflicts with the recommendations from CTO office and IT departments seeking long-term advantages from a common SDP architecture and an open framework for service creation. This situation often leads to indecision and unresolved debates that have put many SDP projects into a state of limbo. Moreover, with the push for the broadband strategies, a new conflict between business and operations is looming around monetizing network usage: to invest in platforms that create an intelligent service layer for commercial content and services managed by the CSP or to rely on the abundance of Internet content and “over the top” applications from other providers and increase the revenue generated by their traffic demands?