This is the fourth in the Complete OSS re-write series of posts and relates to Our requirements keep changing. This series is designed to pose ideas on how the OSS industry could take a Control-Alt-Delete approach to all aspects of delivering operational support, which coincides with the inflection point underway in our industry via technologies such as network virtualisation (eg SDN/NFV) and sensor networks (eg Internet of Things). This series also draws inspiration from the re-write approaches that are disrupting industries such as taxis, music, hotels and many others.
As we know, OSS have many moving parts – too many to be able to define all requirements on day one of any significant OSS project. Getting the requirements right is an incredibly difficult task to achieve and too many OSS projects blow out because of changing requirements. And even worse, in-flight changes seem to take millenia to deliver.
The underlying theme of this post (and the binding theme across all the others in this series) is complexity. An earlier post entitled, “The Triple Constraint of OSS,” takes a close look at how complexity impacts three primary objectives for project sponsors – schedule, budget and scope (as well as risk, resources and quality).
For an OSS project, much of the impacting complexity has occurred long before the project was even conceived. The problem for many service providers is that they are so large, have so many products / bundles (eg bundling, promotions, discounts, etc), have so many process variants and have so much legacy stuff, the complexity challenge for their OSS and BSS is overwhelming.
And it’s only going to get bigger because the industry is on the verge of massive change on so many levels that the current model for OSS is going to struggle to cope. But operational support tools are the only mechanism via which disruptive technologies like cloud delivery, network virtualisation, escalating network security threats, Big Data, Machine Learning and Predictive Analytics, orchestration and automation, wireless sensor networks, IoT/ M2M, Self-organizing Networks (SON), etc can be viably implemented. So we have to find a way. A new way.
The proposed approach is built on one of Steve Jobs’s matras, “Deciding what not to do is as important as deciding what to do.” Rather than coming up with stuff to justify your job’s existence, justify your stuff to in turn justify your existence. Whilst this applies to every single level of a service provider’s organisation, we don’t always have the chance to influence the upstream complexity that is flowing down to our OSS projects, so I’ll just focus on ruthless simplification within the OSS domain (leaving simplification via change management to one side for now).
I deal with many different OSS vendors and the current approach to sales tends to focus on:
The vendors are implicitly corralled into this approach by the service providers who build business cases and select vendors based on these factors.
If we are to cope with the next technological wave, we need a different approach. In fact, I believe that it is a 180 degree divergence, as follows:
Many of the requirements that I’ve seen over years of OSS projects are to perform activities that sound cool, but are rarely justified by how often the activity occurs and how much of an efficiency gain is derived from doing the activity via an OSS (versus other workarounds).
Does anyone actually measure activity efficiency after they’ve been implemented through an OSS? Would it make sense that if a product, function, requirement is not delivering value, then should it be culled from the OSS, thus reducing related compounding complexity?
If vendors designed these types of analytics into their tools and could demonstrate a track record of cost-benefit in sales bids, it would make it easier for customers to justify an OSS investment than on cost-out.
Would you take a different Control-Alt-Delete approach to the changing requirements challenge we face?
Have you ever had an OSS or BSS project that’s impacted by poor data quality? The problem of data integrity gets raised on almost every
“One of my favorite things about designing software is designing the defaults. The defaults define the experience for everyone out of the box. And, therefore,
Have you ever been tasked with mapping out the processes for the telco you work for? Either as a way of documenting current state, or
In the last week alone, I’ve had two potent reminders that the world of OSS is simply (pun intended) too complex. This manifests in many
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
