Pipeline Publishing, Volume 4, Issue 8
This Month's Issue:
Serving Up Service Delivery
download article in pdf format
last page next page

Service Delivery Frameworks:
The Service Provider's Mashup

back to cover
article page | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |

well thought out approach to a select service area. But perhaps the most comprehensive working architecture from a single vendor is the Microsoft Connect Service Framework in its largest context. Among service providers, we are impressed with AT&T’s architecture and with Swisscomm Mobile.

SDF differs from SDPs in some important but subtle ways. One way of looking at SDF is as a super-framework that allows many different SDPs to be linked together. Indeed, with some architectural constraints, even heritage systems may be used in service composition, abstracted thru a SOA interface. Importantly, SDF’s will incorporate the architectural notion of domains with different resources, policies, and security. This enables not just the assembly of a service that spans multiple platforms supplied by multiple vendors – it enables the composition of services that cross operator boundaries using networks, resources, and application components from multiple service providers. This extends the notion of wholesaling from circuits to service components.

Lastly, and quite powerful in an SDF “Any application rendering a service may in turn become a component.” (TR139) The SDF should not only provide the fast and reliable assembly of the service components but also provide the fast and reliable reassembly of any service component in another assembly. This recursive principle brings SDF right to the starting edge of the principles of Autonomic Communication.

Technical issues aside, a simpler way of looking at the difference between SDPs and SDF:

  • SDPs allow creation of services.
  • SDF allows services to be mashed up: service calling service, calling service.

For instance, an address book lookup gives a name which is used to find a person’s location which brings up a map of reasonable trip routing, resulting in a call, once connected, linking in web co-browsing, with a location, type search to find for a restaurant along the trip route, clicking the restaurant’s advertisement, resulting in a reservation, and a message to social-network shared friends to met them with directions inserted from that person’s location. This Mashup is becoming possible with some Over-the-Top (OTT) service platforms; network operating providers must meet this challenge.

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. We call this open, yet controlled, strategy the “garden club.” Many different players in the ecosystem contribute both to the resources

If this extended ecosystem realizes the potential of SDF and then gets organized - it significantly broadens the coalition for SDF.

.
in this smart middleware and also to the composition of Mashup service products. Yet the network operator vets the garden membership, collects the dues and fees, and distributes the rewards.

All this Mashup complexity will require service creation and operation discipline. The ability to deliver the operators’ comprehensive style of management and policy controlled QoS also might be a competitive edge for providers over OTT services. Tony Richardson: “[besides] the issue of SDP interoperability – the major aspect that TM Forum is progressing is the need for commonly agreed Management capability – and this will be TM Forum’s principle focus.”

Service Lifecycle Management

TR139 lays out a principle requirement for the SDF. “The SDF lifecycle management must be able to support the versioning, testing and configuration management of individual software components, as well as the creation, deployment and execution of application X and its versioning and testing.”

This is not simply a product catalogue with gates indicating the step or state each service is in during its life; this is a true process flow with active management of the evolution of a service, its expectations, and its value as it progresses from concept to implementation through useful life and finally to retirement. It is a child of the experience the TMF has gained with eTOM.

Indeed, the enablers, components, and service lifecycle create a new framework for NPI, as we stated in an earlier article [NPI for Life]. Specifically the various SDPs enable rapid development of components and resources. The SDF will lay out the interaction architecture for these enablers and components. Using the SDF, these parts will be assembled into composite services. The SDF Service Lifecycle Management will orchestrate the value curve for the composite service. The SDF Lifecycle phases should include:

  • Conceptualization and design
  • Lifecycle Management
  • Operations Planning
  • Configuration
  • Campaign management
  • Usage / run time execution of service
  • Retirement

During the in-service period, Lifecycle management allows for basic BOSS services:

article page | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
last page back to top of page next page
 

© 2006, All information contained herein is the sole property of Pipeline Publishing, LLC. Pipeline Publishing LLC reserves all rights and privileges regarding
the use of this information. Any unauthorized use, such as copying, modifying, or reprinting, will be prosecuted under the fullest extent under the governing law.