|
article
page | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
-
Identification of service enablers and application integration touch points (interfaces, interactions and other architectural definitions)
-
Standard Metadata definition for service description and cataloging
-
Standard Meta-capability specifications for lifecycle management
-
SOA-based NGOSS management framework to support SDF
-
Support for a complex B2B value chain
-
A SOA-based governance definition to ensure multi-vendor interoperability
Also, Alan Quayle believes that an SDF must not have simply service management as its goal, but must take yet again a fundamental shift in management viewpoint. This from services to customer experience. “Consumer Experience is defined as an integrated digital life independent of access method.” This is delivered by rich applications running on many elements, devices, and user terminals. So is everyone just jumping in with their wish lists to bloat the SDF project? Or is this part of a necessary whole that will not work without all these properties? We have yet to hear from the service providers weighing in on this, they have been specifically vague about their SDF deployment plans, but we can examine the technical and architectural environment for answers.
SDPs as Components
SDP is a broad and perhaps overused term, covering:
-
Communications and content based service creation, orchestration, and delivery;
-
BOSS (Back Office and Operational Support Systems) for service definition and integration;
-
Application Network Interface i.e. how network capabilities are exposed to internal, 3rd party and internet-based applications.
Typically, most SDPs include:
- a service creation environment
- a service orchestration environment
- a service execution environment
- a mechanism for service management
SDPs are here now. A large number of vendors are building and selling SDPs or parts that can be assembled into SDPs. Alan Quayle identifies over 40 active vendors. They come in all sorts of favors, some hosted, some pure development platforms, some SI best-of-breed aggregations, some specifically for mobile services, many geared toward IMS. They are deployed today in many operators around the world, both large and small. HG3 Italy, Amena Spain, BT, Mobilkom Austria, SKT South Korea, Swisscom Mobile, SFR France, Telefonica Spain, Telenor Norway, Telus
|
|
What we propose is that a fully realized SDF could enable creation of a middle-ground strategy between the wild west OTT services and the existing ‘walled garden’ approaches typical of network operators. |
|
Canada, T-Mobile International, & Vodafone Spain.
Some of these are trials and some are small “get-your-feet-wet” projects, but some are quite comprehensive offerings. Vodafone Live used a home-built SDP to launch its offering back in 2002, a product that provides an integrated service across handsets, networks, content, and services. It includes video content, music downloads, and games. Perhaps among the most ambitions of projects, Sprint Nextel USA launched its Business Mobility Framework in 2004. It enables third parties to develop services using capabilities of the Sprint network. Sprint’s approach focuses on IMS. Multiple vendors have been involved (including IBM, Microsoft, and AePONA) and even the basic development platform has been swapped out once.
Indeed seldom is one vendor supplying a whole SDP to a service provider. Again, Alan Quayle:
“SDP, like IMS, is not something that an operator pops down to their local mega-mart and buys off the shelf. It’s a complex architecture; decisions on what components are required must be driven by service and operational need. An operator’s strategic services roadmap, its multi-year view on how its customers’ experiences evolve, is critical to prioritizing and phasing the implementation of a SDP.”
Moreover, the costs of a SDP are still very high: starting thresholds to get in this game are millions of US$ - eventually working out to between $.50 and $3 per subscriber. The eventual returns from new services are expected to greatly exceed these costs, so SDP projects are multiplying. Indeed, business cases are being built on fractional benefits that can be easily quantified. Alan Quayle:
“SDP’s generic drivers are: speeding time to market for new services, and lowering costs in launching new services through re-using common capabilities across services. However, in reality we see drivers such as capturing revenue leaking for prepaid content, and outsourcing expensive content portal software.”
From these project trials and deployments our industry has learned some important lessons. It is important to have a lifecycle that allows
article
page | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
|
|
|
|
