By
Tim Young
Cast your mind back to, say, 2005 or 2006. Service Delivery Platforms were heralded by many as a game-changing advancement that would revolutionize the OSS/BSS segment and, by extension, the entire communications space.
The troubled waters that SDPs have navigated in the time since is proof that nothing is as easy as it seems. Microsoft, famously, killed its SDP efforts (dubbed the Connected Services Framework) back in December, citing its internal shift away from service delivery infrastructure and enhanced focus on services and partnerships like its Exchange Online.
Microsoft's CSF faced the problem of attempting to be too complete, to the point of being unwieldy, and other SDP efforts have had more success by remaining agile, flexible, and easily customizable. At the end of the day, after all, no two CSPs have precisely the same needs and wants, so SDPs are not one-size-fits-all.
|
|
“SDP” is nebulous. It's loosely defined. |
|
“Today's SDP does not provide a real competitive edge for the CSPs,” said Huang. “Today's SDP does allow service providers to jump onto the bandwagon and to provide new services more quickly, however, many of the solutions are taking a green field approach, which leaves the CSP with a large
|
|
|
|
Identity
Because, after all, the term “SDP” is nebulous. It's loosely defined.
Jenny Huang, of AT&T Labs, has been heavily involved in the TM Forum's Service Delivery Frameworks working group, which attempts to give specific parameters for what an SDP is, or can be.
The SDP products coming from specific vendors, Huang says, “are very self-contained, often providing only a very limited range of services and also often including their own limited and closely integrated management capability.” Rather than providing a freeing platform for new and better services, this has “left the service providers with yet another set of stovepipe systems that require costly integration with their backend OSS/BSS.”
Indeed, these SDPs are not conceived as yet-another silo. They're intended to be a platform for unification. Yet that ignores the complexity that pervades most CSP systems.
|
|
amount of Diving into Service Delivery work to do on current systems and services.”
“A Different Way to Do Business”
However, in order to avoid SDPs becoming nothing more than another stove pipe in need of integration, Martin Creaner, president of TM Forum, asserts a somewhat broader definition for SDPs: “SDPs are essentially the realization of a different way a CSP wants to do business,” said Creaner. “It wants to offer services and create services in a really flexible fashion. It wants to meet the needs of its customer base. It wants to move from the traditional model of service creation, which was a very painful, long term model, in which it would take, not atypically, 12-18 months to roll out a new service. From that, to a model in which they can roll out a new service in hours, days, or weeks, depending on the complexity of the service.”
Well, that takes care of the SDPs as a stove pipe.
|
|
