Many Telecommunications Companies Use a Diverse Number of Billing Applications that Fail to Seamlessly Interact with One Another. Here Is How This Problem Can Be Solved.
Telecom is an industry that is saddled with a huge amount of legacy software. Simultaneously, it is one that has to be developing very fast in order to be able to adopt the ever emerging relevant technological innovations.
Billing software is no exception. Billing apps are at the core of a Telco provider’s ability to make good use of, and profit from those innovations, or, rather, from the service offerings, empowered by them. And this is precisely where many Telcos hit quite a major snag: each of their multiple billing applications is used to process only some part of their service offering. Typically, one of such apps is unable to support billing for custom service packages that comprise more complex combinations of the company’s services.
In other words, if your customer wants a custom service package that includes an Internet connection, billed for by one app, and an app store access service, billed for by another one of your apps, your billing process gets thwarted, and you cannot bill the customer for the whole of the newly created service package.
What would be the more optimal way out of the above quandary?
As you can, probably, imagine, the usually large and diverse number of services and service combinations make it extremely difficult, if impossible, to find a solution by trying to make one’s multiple billing software applications and other systems interact with one another directly. This would only create a tangle of interactions that can easily cause your system to malfunction.
System Integration: How to Achieve Better Results with Integration Use-Cases
A much more optimal approach would be to implement a standalone application that will instantly create custom workflows by calling the multiple apps, involved in the billing process.
Does this approach, actually, work?
We bet it does. However, your Billing Orchestration application must not only be in possession of all the required functionality, but it must, also, allow for a bunch of nuances that can make or… well, damage considerably your billing orchestration project.
So…
What Functionality Does a Billing Orchestration Application Include?
Simply put, a billing orchestration application is a set of APIs and the logic that governs them. The governing logic is represented by Web services. These Web services are called in certain cases and in a certain order. The input parameters of one Web service can be derived from the output parameters of another Web service.
When a request to create an account is generated by an Ordering application, the Billing Orchestration app instructs all billing software and other systems involved to create corresponding accounts. These accounts are then linked by the Billing Orchestration app using a mapping table. This mapping table becomes central to any future transactions, performed in relation to, or on behalf of the account owner.
The Billing Orchestration application synchronizes the systems, involved in the processing of an order, and defines the sequence of the operations, performed by them. That’s how the whole thing looks. Well, in brief.
However, there are many devils in the details, and you’d better be aware of them before you start the development.
What Does One Need to Be Aware of While Developing a Billing Orchestration Application?
It would not be a massively difficult task for a skilled software development team to implement the above set of functionality. On the other hand, if they’ve never done that before, it would be lots harder to implement this functionality in a more optimal manner and preempt some of the impactful negative issues that tend to crop out during later stages.
What are those issues? And are there any best practices that should be adhered to while implementing a billing orchestration app?
The following are some of the empirically gained insights we can share with you to help you avoid the more typical pitfalls:
-
Keep as Much of Your Business Logic, as Possible, Out of Your Billing Orchestration App
Regardless of the number of systems involved in your billing process, or of how difficult it is to make modifications to their functionality, try to always keep as much of your business logic, as possible, out of your Billing Orchestration app.
As a rule, a full-value Billing Orchestration application has a database/data schema of its own. This application is unable to access directly the data tables of the billing applications it is linked with that contain the various configurable parameters (lookup values, entity types, statuses, and so on), employed by the business logic.
Consequently, if part of the business logic, used by your billing or other software, becomes part of your Billing Orchestration app, your business processes will frequently be disrupted due to the inability of this app to support them.
For example, in order to run, even, a simple validation of some kind, you will have to copy the data that resides in the DBs of the other apps, store it separately, and then synchronize it with the originals. As an alternative, you would have to build a separate interface to query this data, or perhaps, even, create a separate data-processing application. It is for this exact reason that whenever your developers get tempted to cram something other than integration logic into your billing orchestration software (be it a validation procedure of some kind, a newly introduced account entity, or some other part of your system’s business logic), it would only be smart of you to put an end to those attempts right away.
-
Keep Any Bulky Data Processing Out of Your Billing Orchestration App
Typically, the data models of the various Telecom applications are different. It is a regular part of the Billing Process that data (for instance, Product Catalog data), retrieved from one app, is processed to fit the data model of another app.
Similar to the business logic, Data Processing can upset the applecart for you too, when included in your Billing Orchestration app excessively.
In particular, any Data Processing, related to the processing (creation, deletion, modification, etc.) of such billing entities, as accounts, products, subscriptions, and invoices, must be handled by your billing software and kept out of your Billing Orchestration application. Your Billing Orchestration application must only be used to harness the corresponding Web services to initiate the required data-processing.
-
Include Two Different Types of Interfaces
Unlike it may seem at first glance, not all the operations your Billing Orchestration app will perform will be those, performed instantaneously, or within short timeframes. Some of them, for example, those involving stage-by-stage installation processes, will take longer to be completed.
Correspondingly, unless you provide support for such operations by implementing not only synchronous, but also asynchronous APIs, your app will, sooner or later, inevitably crumble, leaving you with a total mess on your hands.
-
Implement a Single Point of Control
In all probability, your Billing Orchestration app will be used to manage extremely large volumes of data and to create complex data flows. This will make it difficult to track errors to their source and maintain the system otherwise. Unless you fancy rooting around in a truckload of various data, strewn across several apps, every time your Billing Orchestration app is in error, you need a single point of access to easily manage the whole of your Billing Orchestration process.
In other words, you need to develop a Frontend application that will allow you to visualize a flow, identify the part of the flow in which the error has occurred, and give you the corresponding error code. The app must, also, provide the ability to remedy the situation without having to delve into the DB.
In addition, a good Billing Orchestration app can also be designed to provide a range of useful reports, for example, those on the distributions of calls by operation, result, or flow type.
-
Provide the Ability to Configure the Flow Interface Sequence
It is essential that you allow for the ability to easily modify the sequence of the APIs that make up a flow without having to make any modifications to the corresponding code.
This ability will allow you to quickly and effortlessly build and launch the Billing Orchestration process for any new account, regardless of the number of systems, involved in this account’s servicing.
In the absence of such functionality, your only alternative would be to delve into the code in a couple of dozen different spots and modify it manually.
-
Ensure Easy Traceability and Maintenance: Log and Store It All Correctly
It is utterly imperative that you log literally everything, - all calls, all responses, - everything. This will help you iron out any errors that may occur a lot faster and make the process a lot less of an effort.
Another good practice to follow would be to store all your logs in a database, and not in files.
Maintaining a Billing Orchestration application is not an easy task. It involves a significant number of discrete maintenance activities that are much easier to perform when your data is stored in a database. There is always a high percentage of relatively small orders that can be easily located by writing a simple SQL query. With file-based storage, locating such orders would be a great deal harder.
It is, also, advisable that all your logs be archived at frequent intervals (for example, every 24 hours) in order to prevent the DB tables from getting bloated and becoming barely usable.
-
Use Tools That Can Facilitate Your Development Effort
Lastly, but importantly, from our experience, many of the technical hurdles that are bound or likely to arise can be avoided or efficiently dealt with using TIBCO.
TIBCO Software Implementation Services
This awesome system integration platform gives you the ability to quickly re-use your existing resources (for example, Web services) for the creation of other resources, - multiple times and without having to write any code.
With TIBCO, you can create libraries of the more frequently used functions, and then use these libraries as standalone extensions of your services or applications.
