OSS/BSS Transformation and the Chasm of Failure

“Insanity: doing the same thing over and over again and expecting different results.” Albert Einstein

OSS and BSS are central to the business of a telecom service provider. Yet for many years they have also been perceived as something of an impediment to new business and technology, and therefore in need of “transformation”.

However, as long as there has been transformation there has been failure of transformation. Especially among the very largest service providers. The legacy continues and the transformation generates more legacy and complexity. The chasm between expectation and execution seems unbridgeable.

It’s time for telecom to learn from the failures – and finally cross that chasm.

Taking Stock

Here’s a quick roundup of top-tier OSS/BSS transformation programs, informed by 20+ years of first-hand involvement:

  • OSS/BSS software transformation? FAILED.

Why? Transforming OSS/BSS while not addressing the business process, change management, data management, and current estate of the rest of your systems dooms the program to failure.

  • OSS federation? FAILED.

Why? Moving data around does not make it more accurate it simply means more copies and errors.

  • YAMS (Yet Another Management System)? FAILED.

Why? Leads to yet one more technology silo that requires system integration. Compounds the integration problem.

  • Manager of managers? FAILED.

Why? A hierarchical solution for a distributed problem. Another layer that introduces data error and process coupling. It doesn’t work for organisations so why would it for systems.

  • NFV/SDN/Orchestration? It’s not looking great…

While we don’t yet know for certain, all the signs are that this will only further complicate the management and control of network and services. NFV MANO is YAMS and Manager of Managers by another name.

If we are to avoid insanity now is the time for a different approach. The advent of virtualization and the breaking of barriers between what is network and software give us the opportunity to take a different approach. In particular we can learn from the success of the web application design that has proven success delivering complex, flexible distributed systems.

Forget Arriving, We Never Really Left

With every wave of technological change, we have witnessed an increasing need and interest for operational transformation in the telecom industry. Be it IMS or SDN or Cloud, and most recently Network Function Virtualization (NFV), we know that we have to reinvent ourselves and our operations infrastructure to monetize the promise of these technologies.  Even going as far back as the days of DSL and IP network rollouts, transforming the “incumbent” carrier’s operations was a hot topic.

Over the past 15 years, I can recall countless meetings at events such TeleManagement World (now TM Forum Live!) and Mobile World Congress in Barcelona, where carriers recognize the imperative need for change. On the other side of the table are a myriad of telecom software companies and a handful of Systems Integrators looking to help.

Both sides have been ready to play for years, yet here we are. It is 2015, and most tier 1 carriers depend on systems that were deployed decades ago for core operations.  In the US and Europe, millions of users continue to be supported on systems still running on mainframes.  These “legacy” systems are business critical to their respective operators, and attempts to migrate to newer, next-generation platforms have not materialized into successful production deployments. In the meantime, non-traditional and other OTT players continue to erode market share and margins. These legacy platforms weaken business agility and delay the introduction of new products and services to the market.

Why is this the case?  Given the critical business need, the consequences of not acting, and the promise of next-generation solutions, should we still be talking about OSS/BSS transformation?  The reality is that we still are.  The failure of large-scale operational transformation lies in the execution and not in the intent or strategy.

COTS Becomes the New Legacy

Carriers have spent 100’s of millions on large-scale programs since the dawn of deregulation. Some chose to do it themselves, while others sought the help of large systems integrators. In both cases, there was clear recognition that COTS (commercial off-the-shelf) software should be leveraged to promote best practice across the industry, reduce bespoke development costs and time-to-market, and a general understanding that “reinventing the wheel” does not make sound business sense.

However, once programs kicked-off, scope-creep and evolving requirements compelled most deployments into becoming bespoke solutions. Moreover, the multi-year nature of these deployments could not keep up with the increasing velocity of change in the underlying network technology – often the system was obsolete before it was completed!  There was also a strong tendency within systems integrators to customize COTS software. Change orders on initial scope meant increased revenue, but also meant that the complex stakeholder and user base within the large carrier organization was appeased. Unfortunately, this further exacerbated the schedule and complexity of the deployment, inevitably leading to a failed project.

In the rare cases, when a system was deployed into production, the cost of maintaining the extensive customizations stripped any benefits anticipated in the initial business case.  Over time, the promise of large-scale transformation programs has wavered.  Few carriers have budgets to support them, and those willing to embark on such a journey, with its inherent risks, still need to eke out budgets from multi-year operational savings on their current run-rates.

A New Approach

So where does this leave us?  How can we modernize and build agility into a large operator?  A different approach is needed.  Firstly, we should not try to boil the ocean. Large programs can be defined as a plan of intent, but need to be executed in manageable chunks, each of which demonstrate business and commercial value. The agility of web service development lends us a glimpse of release-cycles in days rather than months — multiple small steps mitigating risk. Scope control then becomes easier to manage given the more tactile visibility of intended outcome over a shorter time horizon.

In a lot of cases, a wholesale replacement of a system or sub-system is not warranted. A deployment strategy that allows for encapsulating functionality or data, allowing for sun-setting of a legacy system over a planned time horizon can mitigate project risk and reduce costs substantially.

A common driver for customizations is the emotional need to replicate every workflow and feature in a legacy system or manual process in the new platform. This is often driven by the need to keep the stakeholder base happy. Sadly, this also means that a good portion of realizable benefits of the new platform are left on the table.  We need to be ruthless about our objectives here.  Nostalgia and familiarity will only weaken the potential for a positive outcome.

Throughout the program, scope control must be diligent and referenced with the business objectives.  If the intent is to follow a best-of-breed or best-of-suite approach with a COTS vendor, then the chosen product(s) should be embraced. Customizations should be minimized to critical areas. This will, of course, mean that processes and ways-of-working will need to be changed, but that is not necessarily a bad thing – reinventing new ways working with the new and modernized platform has to integral to the deployment of the new platform.

And lastly, let’s touch on governance.  Program governance has to rest with the operator organization. It cannot be left to an outsider, and certainly not to the systems integrator that is responsible for the deployment. There is an inherent and inevitable conflict of interest that will arise. Managing scope and schedule priorities has to rest with the business owners of the operator.  They are the only ones with daily objectives that are aligned directly with the outcome of the project.

The problem has never been with the goals of transformation; only with its execution. Cloud and web technologies, an honest reality check, and a new approach can now help telecom escape the chasm of failure.

Jag Siva is President and CEO of Virtualized World. 

One thought on “OSS/BSS Transformation and the Chasm of Failure

Comments are closed.