Have you ever received a phone bill with all of the various calls and data usage and wondered how they got it right? Have they ever gotten it wrong? A lot goes into getting you your bill every month. It has to have all of the right information, subject to both business rules and to governmental regulations.
Let’s take a look at some of what goes into the whole process. Here we’ll pretend like we are a newly minted graduate working in the world of Oracle’s Billing & Revenue Management (BRM).
Wait, are you sure? But, billing systems aren’t sexy! While people may commonly assume that working in a billing system isn’t sexy or exciting, continue along and we can see that there is more to it than just the current flavor of the month.
When we sign up for a service for our phone, there has to be something that represents this and keeps track of things like how many texts we’re allowed, or the data speed we have, or the number of minutes for phone calls. All of this is stored in Oracle BRM in the form of accounts, services, deals, products, and resources. Setting these things up isn’t so bad. The client tools do their job; sometimes they’re a bit nuanced, but they work.
Now, we have things set up that represent what we need. But what happens when business rules require that customer service representatives (CSRs) need to have a custom front end for accessing a customer’s information? What happens when the out-of-box behavior doesn’t match what we need? Then it’s time for customization!
You want me to do what? In what language? With what API? Can’t we just use Java? Really, billing isn’t sexy and now you’re telling me I have to use something like C? Welcome to the world of Billing & Revenue Management. This world may not seem exciting, but hopefully you can already see that there is more to it, and that it plays an important role. Let’s persevere and see if there is more to it.
There are several APIs for BRM. The APIs are in Java, Perl, C++, and C. Sure we can use the Java API for certain things, but not all of them. Most of the Oracle BRM business logic is in C, and there are many hooks in that logic that allow us to change the out of box behavior.
Policy code is what we call this business logic. Most of the policy code hooks for customization are in the C API. This API is quite a nice thing. It handles the brunt of the memory allocation for us! So we quickly get over the shock of getting to work in (awesome) C. It also provides us with a convenient data structure of maps of maps (with key-value pairs at every level). That is a great data structure that we can use for pretty much anything. We have the power to change how accounts are created, how services are handled. We can do quite a bit! With all this power, there are a lot of issues that can arise. So even though there is a learning curve in the API, we get a lot of options in return.
While we’re working on implementing business logic, we have to keep in mind: everything we do will affect all of the customers! The things I tend to notice fastest about any service I have is when the service stops, and my bill. We’re working on code that can completely affect the bill! More than that, Oracle BRM is used for the internal accounting ledgers. So not only are we impacting the customers, we are also impacting the accounting parts, and so all parts, of the business.
So, when working as a developer in BRM, we get to help design and implement the products and services that the end customer can purchase, along with the logic around how these are handled. That’s pretty cool. To make matters even more interesting, BRM is a large and complicated system. Oracle has provided us with many different methods, called opcodes, to perform pre-defined actions on the objects. These opcodes can range from simple things such as updating a field in the data base, to complicated ones that can affect every part of an account. So every time we want to make an update, there could be far reaching affects.
Here is another wrinkle: the provided documentation is not always complete, or accurate. We have a large complicated system with a map that isn’t quite complete. Sure it can give us a pretty good idea most of the time, but the picture isn’t always clear.
How in the world can we know if what we plan to change will work, or have unintended side effects? Isn’t that a huge pain?
It may be a pain, but it is also a challenge. Figure it out; try it; test it. These are the things that make something interesting. If it’s too easy, it’s boring. Doing prototypes is not an overly involved process, so it’s relatively easy to prototype changes. We even have access to a utility to move the BRM time forward. This lets us test how billing will run, how products and resources will behave as time advances. That is a great boon for working in a billing system.
Here we are, we’re working in Oracle BRM, the work is challenging, but we have all the tools we need to be able to develop, prototype, and test. The work we do will directly affect every single customer, and there is always more than one way to get to the end result!
Do you want more? I mentioned a Java API earlier. This API allows you to modify policy code and data managers as well as the C API. But that isn’t all it can do for us. With this, we can expose all of the BRM operations to a Java framework like Spring, and we now have a way to create web-based applications to allow access to customer information, both for retrieval and for updating.
As you can see, BRM is a rich system that is at the core of a business: making sure the customer is correctly and promptly billed, meeting all of the business’s requirements. This is an important role, and when we do the work well, the customer will be happy with what they see from the information on their bill to the structure of the invoice and the front end presentation of their services. With how crucial the billing is for the customer and how central the ledgers are to the business, being a BRM developer is an important role. It is a central, crucial, and challenging role! This is what makes being an Oracle BRM developer fun, exciting, and yes even sexy.
Alexander Cornelius is a BRM Consultant at SSG specializing in Oracle BRM. He has several years of experience in development for BRM, including Java based Web Services, at several companies including Sungard AS and Bell Aliant. While consulting he has filled many roles including: Software Developer, Software Design, QA Test, and production support. He has helped to lead SSG Ltd with development and deployment of Oracle BRM Pipeline.