Telecom IT Management

There are so many standards for telecom system managements. The challenge comes to all these standards are from the dynamics of the communication industry. Any product in this industry has a very small life cycle, the complexities further fueled by the complexities of the products.

The major forum is telecom management forum. This forum is trying to establish guidelines to manage telecom management processes and systems. The major accomplishment is the complete process framework for any telecom enterprise; this processes model is called eTOM. Blow is the Level 0 of the e-tom process map.

Given this complete process map, the problem still exists in the IT layer of the telecom enterprise. When the telecom wants to automate the processes defined, the problem starts.

As there are too many standards, there are too many tools and software products also available to automate these processes. As per the industry standards, these process can be automated using two types of systems calls OSS & BSS (Operation Support System and Business Support System). The former is the one specific to the telecom companies and later is mostly common with other industries.

The major issue is that there is not even a single product vendor in the market, who provides systems or products which covers the process end-to-end. As each of these vendors excels in their own area of process automation, they tend to miss the overall scenario of a telecom enterprise. Due to these scattered and isolated systems, the telecom struggle to get a complete system in place. The following can illustrate the list of various OSS systems required, which are

By looking at the excellence of each of the individual products, telecom IT decides to go for COTS (Commercially off the Shelf) products, which reduces their system implementation and maintenance cost. But unknowingly land into a messy world of system integration.

Following is a pictorial explanation of the COTS product in the telecom enterprises.

As the enterprises run away from their legacy working system towards the COTS system, they end up in spending more than what they were during the legacy systems time, which had the issue with Scalability, Maintainability and Time to Market titles. All the time the management tries to reduce TCO. Which forces the IT departments to go for COTS product from the software vendors shows the rosy picture, which is just a tip of the iceberg shown in the above illustration.

Now let’s get inside the system integration part of the whole story. The major implication after buying these COTS product is to make them talk to each other. Here each product talks its own language and claims that their language is the standard one to talk to. As in real life also we have so many standard languages, each of them again excel in some areas.

Finally the solution is to have a common translator who can talk to different products in their own language and translate to the rest, which is in technical terms having EAI/SOA architecture. Finally the architecture ends up to something similar to the following one. This I have taken from the OSSJ initiative overview.

So the final system to be happens to be a loosly couppled, may not be complex as the legacy system.

Meet you with more information on next post.

- Saravana Kumar (Since 1976)