-
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
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.
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