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. Furthermore, 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, for them to take into account the numerous existing nuances, constraints or 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, 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 the Product Catalog of the legacy system contains, 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 add IoT-related products to 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 to launch a Self-Care portal.
As you can imagine, and as it happens in actuality, the vast majority of instances, the whole thing has to be pulled off against an appalling deadline and on a meagre budget: we do have a Product Catalog, so why squander a whole lot of funds on something we are already supposed to have?
Thus, implementing a full-blown and efficient solution is simply out of the question.
It is not really hard to guess that usually the architecture of the proposed solution 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 the 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 too long to switch between the two (or, under certain circumstances even more) different systems. The costs soar. Before long, the Telco provider’s business folks start suspecting something’s gone wrong. They begin to demand that a single, comprehensive invoice be introduced: we are losing clients and money!
IT Project Recovery: How Software Development Projects Can Be Rescued
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 that are not integrated with one another and were 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 be done 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, the 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. Although 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 are responsible for retrieving data from the Product Catalog and sending it to the Ordering system.
