The drive to one central OSS tool – is it possible?


Today’s networks have now reached a critical state, in which the plethora of traditional OSS tools can no longer meet the demand of a typical communications service provider (CSP); end-to-end network visibility, cross domain customer experience management and real-time data to name but a few. This is driving OSS transformation projects across the globe, but we have to ask, is one central OSS management tool actually possible?

 

How has the landscape of OSS tools changed?

 

Firstly, lets take a look at how the OSS landscape has changed over the last 20 years. Until more recently, CSPs have relied on just a handful of equipment vendors, and so have entrusted the vendors Element Management Systems (EMS) to perform their OSS tasks. This used to be sufficient, however new technologies such as LTE and IoT have disrupted this. Operators have been forced to introduce more vendors into the mix, and as a result have been left with a plethora of multiple OSS tools. The trend towards quad-play packages has made this even worse, introducing extra tools for managing fixed line services and IP-TV into the mix.

This has left todays CSPs with a patchwork of home-grown and commercial OSS tools, often in their 100’s. Unfortunately these mixed portfolios usually lack tight horizontal and vertical integrations, making it difficult to scale, and eventually making them redundant.

 

OSS transformation is the answer, right?

 

Enter OSS transformation, the process of streamlining the disparate OSS tools into one integrated solution. The Gartner Magic Quadrant for OSS has made it clear that there is an unquestionable need for OSS transformation projects and associated OSS tools;

”The CSP service evolution necessitates single central solutions that merge fragmented processes across various organizational entities, in order to automate and expedite end-to-end fulfilment and operational processes.”

So yes OSS, transformation is the answer. However the definition of OSS transformation is so broad, it can be difficult to identify a solution which is truly capable of delivering OSS transformation, and not just a small segment of it.

What does an OSS tool actually need, to be able to deliver OSS transformation?

 

Whether the CSP is driving OSS transformation to deliver better customer experience, or more basic quality of service monitoring, today’s services such as quad-play, and technologies such as LTE require OSS tools working seemingly across vendors and domains. This is a pre-requisite to achieve an end-to-end view of quality of service and experience. To achieve just one centralised tool, the chosen solution will also need to offer:

  • Flexibility to integrate future requirements, such as the current trends for customer-centric service assurance, where new service models and cross-domain intelligence are required. Or the upcoming 5G technology, in which new standards will be defined and new network equipment will begin to appear.
  • The ability to manage not only network data bust also many other data streams, including customer data, IT data, and sales and marketing data.
  • A scalable data store, which can grow in line with the amount of data passing through the system, without compromising on speed or data quality.
  • Multi-tenancy capability, offering larger groups the ability to easily share resources and get more from their investment.
  • Improved automated intelligence through correlation of cross-domain data, and 360o view of customer experience, encompassing billing, outages, customer session QoS data, and network data.

So is one central OSS tool possible?

 

End-to-end network analytics tools are ideally positioned to be centralised, giving an up-to-date view of the customer, product, services, resources, faults, trouble tickets, performance event history, and other important data.

What is important to recognise, is that there are a vast number of tools which can be found under the ‘OSS transformation’ category, and CSPs must be careful to clearly define their specific needs and test out the available solutions through demonstrations or proof of concepts.

So yes, one centralised OSS tool is possible, but it cannot be simply unboxed and plugged in. It is an ongoing, often staggered process which requires extensive research, testing and continual flexibility to be a true success.