One Way Telecom Solutions Collide,
Or How One of the Major Problems in Telecom Software Development and Integration Can Be Avoided
When you buy something really pricey, you, normally, want to make the most of that buy, and, certainly, seldom think of the replacement that will one day have to be made.
Surprisingly, the same, to a certain extent, holds true for costly enterprise software systems, and, in particular, Telecom software. To make matters worse, when a major Telco provider unloads a bankroll for one of the multiple Telecom applications they need, it may be extremely difficult, or plain impossible, to take into account the numerous existing nuances, as well as any constraints and business needs that may arise in the future. And this is just where one of the ubiquitous ills that plague a large number of Telecom solutions lurks: the introduction of a new Billing or Ordering Telecom system makes it necessary to integrate the Telco provider’s legacy Product Catalogs with those of their newly purchased application.
Regrettably, the result is, often, a variegated tangle of systems that can barely interoperate (and that’s only if they are patched up on the fly all the time).
As an example, here is a typical scenario many Telecommunication providers opt for, thereby planting a time bomb under their normal operation and creating lots of headache for their technical departments for years to come.
The Scenario to Be Avoided
A Telecommunications company gradually realizes their Telecom Billing software or Telecom Ordering System is no longer up to par. They make a decision to replace the system. As a new system arrives, the Telco provider’s technical experts migrate the data, contained in the Product Catalog of the legacy system, into the Product Catalog of their new system. Seemingly, all’s fine and the whole thing is supposed to come up roses. Alas, as a rule, the ensuing story is very much different.
With time, new Telco products emerge that need to be introduced into the Telecom company’s service offering. Consequently, it becomes necessary to modify the company's Product Catalogs correspondingly. A good example would be the current massive need for Telco operators to incorporate IoT-related products into their product range.
However, this is far not the only case when your Product Catalogs are bound to be modified after a new Billing software application, or Ordering system, is installed. For instance, the same can happen if you want to enable offline sales of a Telco product (and need to give your agents the ability to sell the product via your system), or launch a Self-Care portal.
As you can imagine, and as it, actually, happens in the vast majority of instances, the whole thing has to be pulled off against an appalling deadline and on a meagre budget: there is a Product Catalog already, so why squander a whole lot of funds on something we are supposed to have already?
Thus, implementing a full-blown and efficient solution is, simply, out of the question.
It is not really hard to guess that the architecture of the proposed solution, usually, reflects both the size of the budget and the, often, unrealistic deadline. As a result, the required changes are made to the new system only and both systems, the legacy system and the new one, start being run in parallel.
At first, this seems like a viable and cost-effective solution, but then all hell breaks loose in earnest: almost all clients want to receive a single invoice that clearly indicates all their expenses. Moreover, they want to be invoiced promptly if they are visiting one of your outlets in person. However, it takes your staff relatively long to switch between the two (or, under certain circumstances, even, several) different systems. The costs soar. Before long, the Telco provider’s business folks start suspecting something’s gone wrong. They begin claim that a single, comprehensive invoice be introduced: we are losing clients and money!
By the time the above happens, the part of the Telco provider’s IT landscape, associated with Product Catalogs, represents a patchwork of 3-5, or, even, more Product Catalogs, unintegrated between themselves and all developed using different technologies.
In order to keep the whole thing working, at least, somehow, their technical experts have to be continually involved in a never-ending manual synchronization effort, or, as an alternative, be endlessly exporting data from one Catalog to another.
Understandably, the costs skyrocket: one has to support a minimum of three Product Catalog-related systems: the legacy Product Catalog, the new Product Catalog and the Ordering system. One single newly introduced Marketing product can create an amount of hassle that would be enough to keep half of the company’s technical department busy for a long while. Moreover, this is just the kind of a situation, in which trouble only grows to vast proportions in the course of time.
So, what should be done by a Telecom company, looking to replace their Billing software and/or Ordering system, in order to prevent the above disaster happening?
The Right Approach
As a team, we have been involved in a great deal of development, associated with Product Catalogs and the related data migration. Here is our take on what should best be done by you in this regard to avoid big-league trouble:
If you are considering the replacement of your Billing software, or your Telecom software, define the system that will be central to the transformation process. The rest of your Telecom applications (both the existing and future ones) must be aligned with this system.
In most cases, a Product Catalog takes precedence to all the other systems of a Telco provider, and, consequently, it is the Product Catalog that should become one’s true North for the implementation of Billing and Ordering software.
Migrate the entirety of your data from the legacy Product Catalog to the new Product Catalog, and then discontinue using the legacy Product Catalog. While the ensuing expenses can, initially, be higher than under the other options, they will be compensated due to the lower support costs and the absence of the need to expand the infrastructure.
Use web services to re-write the APIs of the applications that receive data from other apps, as well as the APIs of the application that is responsible for retrieving data from the Product Catalog and sending it to the Ordering system.