A Dip in IT / Telecom Management

Wednesday, April 19, 2006

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)

Friday, October 08, 2004

Provide QoS or Quit the Enterprise Business.

It was when customers getting service was the most onerous. Now it has come to the ground and customer become king, atleast enterprise customers. Here is a touch to QoS in enterprise telecom/networks.

SLA and QoS are not new to India, but it was only on paper and with the negotiators. Later no one ever know how the SLOs can be measured and claim the penalty if it breaches. Here is the time come, where maturity came in the industry to negotiate on achivable and measurable SLOs than just for the sake of asking.

It was the time when everything works with "chaltha hai" attitude. Now the pressure has come from the internal customer in every enterprise, as their systems are getting more automated across the locations and business dependencies are also keep increasing.

The another pressing requirement came when IP VPN came in. VPN, which is the hot cake in indian enterprise networking picked up lately after the FR, which was ruling for decades. The cheapest IP VPN solution comes with its own limitations of any packet switching network. The major problem with this network is QoS. The same may not be much visible when it is used only for data.

Basic SLOs commited were

  • Uptime
  • Latency or Round Trip Time
  • Packet Loss or Packet Drops

These were commited end-end ( when the lastmile belongs to same provider) , or atleast between provider edges.

The one more presseing need for QoS came when enterprises started using VoIP over VPN to cut their STD, ISD bills. Considering VoIP is very much sensitive to Jitters, the same is added to the SLOs list now.

Even though these all easy to measure using any tools, even free tools can do this. But when it comes to the reclaim, based on the SLA is breach, It raised a question on how much the tools and underlying technologies used are reliable enough to substanciate the claims.

Every provider, uses their own way to do the measuring and reporting. So the question still remains on the technologies used to measure and report the SLOs

Wednesday, October 06, 2004

OSS/BSS: The Never Easy, Never-Ending Story

Let me start this blog with the story of core IT part of any telcom industry "OSS/BSS" ( Operation Support System/Businenss Support System) . This is where I have got more insight too.

There is always a quest for slicker OSS/BSS from any telecom / network service providers. This quest always remains mistry and the story keep moving like a mega serial. Here, I am trying to look into this quest and also trying to find what is that making this piece of IT so such complex and where this constant demand for a slicker OSS/BSS comming from.

Competition and slash

Telecom industry is in such made itself so competitive, which makes the margins to bottom. This makes the telecom CEOs to cut costs to slash prices further down and increase quality to keep the competition at bay. The same concern was raised by JR Lowry, a partner at McKinsey & Co and the author of a keynote presentation at May's TeleManagement World conference in Nice, the US RBOCs will need to reduce unit costs by more than 25% by 2008 to preserve current margins.

Thus chopping the opex is an obvious place to start with. One of them would be shrinking the number of worker bees, which is simply 'eating low hanging fruits'. The real task is to look for the systems, which can automate or reduce cost of running business and network operation. This is where the the quest for a improved slicker OSS/BSS.

As an example (and by its own account), former UK monopoly BT has latterly been quite good at ongoing incremental shrinkage of its cost base. However, according to Phil Holmes, CTO of BT's research, technology and IT operations arm BT Exact, gradual efficiency gains no longer cut the desired mustard. "What we have discovered… is that if you are looking for cost transformation, simply being more efficient and automating more isn't enough", says Holmes.

So is the quest for OSS/BSS also going to remain in the future too. Now the reason for the constant quest for slicker OSS/BSS is clear and the question remains is what makes it so complex.

All Change

As we living in communication era, which gets all the focus of researchers and business community to offer new things in communication on every day basis. When this becomes habit of the industry, the changes are inevitable. This gives a changing systemic nature to the telecom industry as the whole.

The tempo of the market is shifting into a higher gear, particularly in the wireless sector. As Creaner points out, telecom product lifecycles - development, marketing, introduction and shelf-life - have traditionally been multi-year affairs. The lifecycles of some products can now be measured in months or weeks. Again, the implication is that OSS/BSS competencies need to beome much more nimble.

So, this answers that the OSS/BSS is not complex. The life cycle of these systems gets into weeks time, the systems gets obsolute and needs constant change. When there is a constant change in the running system even to its basics it becomes more messier and shows up a complex picture.

So, Where it progress

When we say its so complex and the demand for it is still stable and growing, then where is the progress ? The answer to this is getting formulated in Telecom Management Forum (TMF).

The key technology element in the TMF's 'Lean Operator' initiative is the 'New Generation Operations Support and Software' (NGOSS) programme. This is an integrated framework for developing, procuring and deploying operational and business support systems and software. NGOSS is delivered as a toolkit of industry-agreed specifications and guidelines, and packaged as follow-on 'Releases' approximately once every six months.
There will be another post on this NGOSS, as its big enough for one single post. Till then cia :)