“Innovation has nothing to do with how many R&D dollars you have. When Apple came up with the Mac, IBM was spending at least 100 times more on R&D. It’s not about money. It’s about the people you have, how you’re led, and how much you get it.”
Steve Jobs.
I love this concept – “Innovation at the speed of software.”
It’s one of the premises upon which software defined networking is based – to allow network operators to make rapid changes to their networks through software / configuration change rather than rack / stack / patch. It’s also one of the reasons why SDN and NFV are creating such a buzz in the industry.
But OSS are also highly software-centric right? So you may reasonably ask why OSS projects take so long to implement?
The answer to this question has ramifications for SDN / NFV that rarely seem to be mentioned as well as ramifications for the future of OSS:
Speed of innovation is alive in OSS. It is actually quite fast to innovate within OSS – to make innovative code changes that revolutionise a product, to configure off-the-shelf products to design innovative new networks / services, to create / load data that allows a large network map to evolve almost instantaneously.
Where it all comes unstuck is in the people and process – the release management, the change management, the process mapping, the design approvals, the contract approvals, the data centre access, the cross-checking, the i-dotting, the t-crossing (is there any coincidence that this spells IT I wonder?).
SDN, NFV and OSS all need as much engineering (or more) given to the people and process side as they get on the technology side. And OSS needs to be simplified at every conceivable level so as to become a more manageable management platform.
As an example, I recently worked on a project that took 18+ months of torture on the people and process side to subsequently take less than 10 days on the technology side once all the right procedures were proceeded and approvals approved. That’s 18+ months of my life that I won’t get back and untold amounts of money that the customer won’t get back either.
That was innovation at the speed of software and process at the speed of a glacier.
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.
2 Responses
I forsee a turning point where network change (and OSS) makes a step-change in agility and speed.
Thinking about NFV as an example… Today if I want to upgrade capacity in my mobile network with, say, a new RNC or gateway. I might spend $1m on the hardware and another $1m on planning, engineering, installation, testing etc.
With NFV I can spin-up a new VM running an RNC image, turn up some more CPUs and RAM etc. Probably spending a few $1k on the Cloud/datacentre and a few $1k for the ‘virtual’ RNC license.
Now, if I can start or reconfigure that VM in just a couple of minutes I can also ‘undo’ it as quickly, incurring very little time and cost.
So, while I wont be making unplanned changes willy-nilly, the risk of a change having a massive roll-back impact or massive cost has disappeared.
My logic being that the CSP can go ahead and make major network changes with a lot less layers of approval because the worst that can happen is someone has to roll-back a software change…
Hi James
You’re absolutely right! Network virtualisation will undoubtedly allow customers or operators to spin up ‘service’ instances quickly once the frameworks are built.
I intended to describe the complexities of building the frameworks, the complexity involved with building the orchestrations that allow self-service provisioning, the design of systems that co-habit well with legacy constructs or multi-domain networks, getting approvals from operators who don’t understand these fundamentally different concepts, etc. Unfortunately I didn’t articulate it very well 🙂
Thanks very much for your insights here James and keep up your great work over at OSSline.com. A tip for readers who haven’t visited there yet, James’ blog is well worth a read!