jbilling-telco was announced a few days ago, and the amount of interest has been tremendous. We've got a lot of questions regarding the features, architecture, etc. For all of you out there wandering about jbilling-telco, rest assured that there are people here at jbilling working hard at finishing new pages in the web site that will satisfy (most) of your curiosity. There will be a road-map page with a detailed list of all the features and the estimated date of release.

What I'd like to share with you here, is the basic architecture of jbilling-telco. How is it that we are going to take jbilling to the next level in order to satisfy the demanding requirements of the telecommunications industry?

First of all, it is important to keep in mind that jbilling is an open source product that will always try to accommodate the need of many different businesses. This is in contrast with an in-house development, when the IT department of some big (and many times, not that big) company is put in the unenviable position of having to develop a billing system from scratch. They usually fail, but they do have one key advantage: the requirements come from a singe company.

With jbilling, flexibility is paramount. The system has to be easy to modify so it can help many different business in, for example, different continents. This is not new for us, imagine how different the taxes are in Italy compared to Canada. Now with telco, flexibility goes to a whole new level. It is not just something like the taxes, but the same company needs to easily launch new products that involve bundles, special pricing, promotions, etc..

Let me bring a very practical example: I took transit the other day to go to downtown, and I saw a ad of a local cellphone provider with a new plan that allows calling 5 other numbers for free,even if those numbers belong to a competitor provider. Something like “talk to your buddies for free”. Now the billing system needs to know about this, so it doesn't charge those calls.

It is clear that a telco company needs to count with the flexibility to launch that kind of promotions easily. They have to compete hard, and they need to be able to be creative with their products.

Flexibility is then a key requirement for jbilling-telco, let's take a look to another one. A typical plan includes these kind of 'rules':
free calls after 6 PM
400 minutes included in the monthly fee
free weekends

Now imagine how the above rules would be coded. The rating engine needs to rate every call. In other words, it has to give a dollar amount to each call:

if call.date > 6PM and call.date < 7 AM
then price = 0; // it is an evening call
else if customer.totalUsedMinues + call.minutes < 400
then price = 0; // included in the monthly plan
else if call.dayOfTheWeek in (SATURDAY, SUNDAY)
then price = 0; // free weekends
else
price = calculatePrice(); //

That is a lot of 'ifs'. And it is just scratching the surface. The 'calculatePrice()' function will need to take a whole lot of other data fields in consideration: is this a local call?, a long distance call?, where is the caller located?, etc We can design the system to achieve some degree of flexibility be avoiding hard-coding parameters such as the hour of the day the evening starts, and using OO techniques such as the strategy pattern to 'isolate' these spaghetti 'ifs'. Yet, you will end up with a system that requires heavy involvement of developers to modify any business rules.

A better solution is to use a business rules framework. And even better a framework that implements the RETE algorithm. I won't be going in detail of what that algorithm is, or what a business rule framework looks like. In the end, the only one that fit our needs is Drools, since it is open source, done in Java and has a pretty rich set of features.

Most people, even IT veterans, do not know that the RETE algorithm is. Some heard of ILOG, for example. I (by pure chance) had the chance to work on a system that was using the 'ILOG Solver' in C++ many years ago. This kind of rule-based approach to solve a problem is usually associated with systems where the business rules change a lot, or with very complex problems. In my opinion, enterprise software in general is not paying enough attention to rules frameworks, specially now that there are affordable options such as Drools (ILOG was, and probably still is, very expensive).

Somehow, most projects start by thinking that the business rules won't change often. It is so common to see the requirements as a static piece of paper that will not change. But enterprise software models business rules, and businesses need to constantly change those rules just to stay in business.

For jbilling-telco, you will have a Domain Specific Language (DSL) that sits on top of Drools. In an nutshell, you will be using a GUI with drop-down boxes to pick a particular rule. The rules are simple English sentences. Instead of:

if call.date > 6PM and call.date < 7 AM
then price = 0; // it is an evening call

You will have a GUI with

when [Call is in the evening]
then [Call is free]

Using a DSL eliminates the heavy reliance on developers to change business rules, and gives product manages and business analyst a great tool to implement new products. Developers can focus on providing the Business Rule Management System (BRMS) with data and helper services, rather than writing one by one each business rule themselves in Java.

Now in version 4, Drools had come a long way. Beside the RETE implementation that makes its core, Drools also has the BRMS GUI (an Ajax web-based application for rule manipulation, versioning, etc), it support decision tables (it will be handy for call tariffs, imagine an easy way to upload the long price list of calls), rule flows,a rule IDE for Eclipse, etc.

jbilling-telco will take advantage of pretty much all of the functionality offered by Drools. We have already checked-in code for the new jbilling module “Bundling”. This new module deals with item grouping and, in general, item related rules. It is so easy to implement something like “if the customer buys these two items, add this other one for free”, or “if the customer is from Alberta, add this Tax”.
In this new module, jbilling uses Drools to implement the business rules behind bundling. It is a clear example of avoiding reinventing the wheel. Other modules that will use rules are the event record reader (for mediation) and the rating engine itself. The result will be the most flexible billing solution in the market, and (what a coincidence), an open source product.

Cheers everybody,

Emiliano Conde
Lead Developer - jbilling
emiliano@jbilling.com
jbilling