SDPs, SDFs and Innovation

By Grant Lenahan (News - Alert)

Everybody needs an SDP. It's in the air, all over the press, on everybody's VGs. SDPs will let us usher in the new age of revenues, compete effectively and transform our businesses. In fact, it's not too much of a stretch to say they will empower individual companies' product managers to innovate in Internet time, intreprenerially.

Did I miss any buzzwords? If so please let me know, I checked.

For the record, I agree: The idea of an SDP, and the idea of efficient service development, is very important for our industry. The problem, you see, is that SDPs are ill-defined. And consequently, they have become whatever any one vendor wants them to be. I feel as qualified as anyone to talk about the vagaries of SDPs. Back in 2000 I floated a layered chart at several wireless-oriented VC and technology events. They were deemed odd – three-layer depictions of a world in which the network and services were decoupled, and only linked by things with even stranger names, like Parlay and OSA. Back then we were emphasizing that the business model was maybe more important than the technology

.
More recently I co-founded the TM Forum's (News - Alert) SDF (service delivery framework) effort, which began, logically enough, with an effort to define this SDP thing we wished to manage. This effort eventually resulted in some consensus – but illustrated how widely different the stakeholders' views were. Traditional mobile content vendors knew it was a box that enabled downloads and ringtones and targeted SMS. IT vendors knew it was Web services exposure of network functions. Others thought it should really be about modular, re-usable, service functions –and yes, like No. 2, exposed for third-party use as well. Telcordia (News - Alert), for the record, fell, and remains, in the third camp. But there's more to the story.

Just recently, Rob Rich, lead analyst at the TM Forum, published an insightful paper on the SDP market, and commented that "the service delivery platform remains primarily an architecture rather than a platform or a packaged instance of a platform. At the implementation level, everyone is going to [use an SDP] to build their own unique service delivery environment." This is a practical view. It recognizes that a tier 1 multi-network operator in Europe has different needs, market powers and customer market than a tier 2 mobile operator in a developing region. They have the resources to design a system to their needs, and the scale to amortize it. They also have the market muscle to realize deals others can't. So this makes sense.

I also think that operators in search of an SDP strategy and SDP vendor need to follow the money. (Remember my column from an earlier issue?) Betting on the outcome is actually useful, and innovation must accelerate. But it really helps to focus our efforts on areas of proven worth.

What are these areas? Advertising; TV/video (whether in-house like IPTV (News - Alert) or over the top); e/m commerce; and music come to mind. I'll also note that all of the above fall on Gartner's recently published list of "Top 10 Consumer Mobile Apps for 2012." A second risk-limiting play can be to recognize that we can never anticipate the next killer app, but we can predict that when they are invented, someone will want to charge for them – and ensure good quality, and implement security so that people aren't constantly facing the prospect of fraud or identity theft. This means that basic functions like charging on behalf of others, policy/bandwidth management, mobile and electronic-based payments, and proxy identity and preferences are all solid candidates for that third-party API we discussed above.

So this begins to flesh out the really important elements of an SDP – content management; IPTV or similar delivery boxes; flexible charging and account balance systems; policy and bandwidth management systems; advertising control systems; and profile/identity systems. And all of this needs multi-protocol session/call/event control for these rich events. Put this all into a framework that exposes as much capability to the application developer as possible and you get an SDP that participates in the growing value of services and applications.

My objective was to recap nearly a year's worth of column material, and make it relevant to the apparently open-ended topic of SDPs. In reality, we can use economic reality to guide the real guts of an SDP – so long as they support innovation, create modular service building blocks, and expose these for efficient internal use and to attract third-party use in a value chain business model. In my next column I'll attack the second part – the SDF, by asking "What does it take to make a service operationally viable in the new world of proliferating services, third parties, and complex two-sided business models?" Yep, operations as efficient as the shiny new SDP.

Until then, as they say in racing, keep the shiny side up!

NGN Magazine Table of Contents