• Frens Jan Rumph

    Profile: I am a researcher, technical consultant and software engineer based in Holland. I have specialized in Charging, Accounting and Billing architectures. From both a technical point of view (IETF, 3GPP, etc) and a business point of view (TM Forum, GBA).

    Main interests: Telecom, Charging, Accounting, Billing, Service Orientation, Software Architectures, Software Engineering

    View Frens Jan Rumph's profile on LinkedIn

    Frens Jan Rumph (image)

    Disclaimer: All data and information provided on this site is for informational purposes only.

    I do not make any representations as to accuracy, completeness, currentness, suitability, or validity of any information on this site and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use. All information is provided on an as-is basis.

    Furthermore, this is a personal weblog, the opinions expressed here represent my own and not those of my employer.

  • Meta

Building Marketplaces with Managed Syndicated Services

The TM Forum’s catalyst project ‘Building Marketplaces with Managed Syndicated Services‘ presented its results at Management World 2008 in Nice. The project aims to implement standards-based B/OSS for cross-platform next generation service management’.

The project is sponsored by BT, Microsoft and Telefonica. Further contributions are made by Accenture, CA, Iptivia, Netcracker and Tribold.

The idea of the project is to create a service delivery concept which reassembles SOA service repositories. A service provider exposes a number of services that can be syndicated by a party that combines the services into a new service for the end-user. These syndicated services could be voice or any other multimedia communication services, content services, et cetera.

The project gives the following example, it neatly shows how a service supply chain can be instantiated by syndicating a number of loosely-coupled services:

  • A conferencing service is exposed by Service Provider A to be syndicated under three contracts: small, medium and large conference
  • A real time video session delivery is exposed by Service Provider B to be syndicated under two contracts: slideware presentation and animated presentation
  • A common billing service is exposed by Service Provider C to be syndicated under one contract: detailed charging
  • A service aggregator will contract an animated video presentation for a small conference with detailed charging. The service aggregator has the capability to capture events/information related to the health and usage of services provided by SP A and SP B before using SP C for invoicing the end user.”

Phase I of the catalyst project demonstrated the end-to-end product assembly, provisioning and service quality management capabilities ready for service syndication. The next phase, scheduled for the second half of 2008, will include settlements, billing and revenue allocation.

It sounds like a very interesting project; especially the second phase is of particular interest for me personally. I have done some research on similar problems from a charging and billing perspective already in the Ambient Networks project and more recently in an in-house research project within my company. Some of these results have landed in a paper called ‘Accounting, Charging and Billing for Dynamic Service Composition Chains’ which is currently under review for the 17th International Conference on Information Systems Development. This paper gives some views on the changes required on Accounting, Charging and Billing processes and enabling systems in order for them to support service composition similar to the service syndication concept presented in this TM Forum catalyst project.

This project is definitely on my watch list!

Lifetree Convergence missing the point

I just read an article on billingworld.com about how Lifetree Convergence uses McObject’s eXtremeDB for real-time rating and credit control. On one hand interesting, for me as an engineer at least, on the other hand completely missing the point!

My two cents…

Cent 1: Added value
While speed is ofcourse a (not unimportant) requirement for a real-time rating and credit control application, it’s not going to win you the war. Adding customer value just might, and a credit control request rated within 2 milliseconds or within 20 milliseconds just might not be perceived as value by the customer.

Cent 2: Service Orientation
When checking out their website I noticed the following remark: ‘@Billity’s powerful functionality comes in a Service Oriented Architecture (SOA). This provides you a framework to integrate existing, legacy applications on to a single platform.’ This sounds good of course, SOA is a great buzz word (yes, it still is). However I’ve not seen ANYthing that leads me to thing that it has any caracteristics of being service oriented. Just to be complete, the service oriented design principles as described by Erl:

  • Service Loose Coupling
  • Service Abstraction
  • Service Reusability
  • Service Autonomy
  • Service Statelessness
  • Service Discoverability
  • Service Composability
  • Standardized Service Contract

I think that the combination of SOA and charging/billing presents some great opportunities, in terms of business agility, time-to-market and total cost of ownership. But there are also some hurdles to be taken. One of those is performance. Some billing implementations have to process millions of CDR’s per hour, but the most commonly used SOA enabling techologies (SOAP/XML webservices) are probably not going to ‘cut it’. Especially if you consider that some charging/billing processes would involve a lot of service invocations.

I wonder if any vender will ever pick up on this by itself, the benifit for them might just not be big enough…

Frens Jan Rumph