Innovation at the speed of software

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?).

  • The ramification for SDN / NFV is that it might be wonderfully fast to make change in a network, but first you have to get through all the people and process…. then you also need to get through the management and orchestration frameworks before you can truly claim service agility or efficiency
  • The ramification for OSS is that they tend to be so complex that the people and process parts get too easily bogged down – the confused mind says no… or simply procrastinates

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.

Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email

2 thoughts on “Innovation at the speed of software

  1. 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…

  2. 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 A tip for readers who haven’t visited there yet, James’ blog is well worth a read!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.