OSS Call for Innovation

An OSS Call for Innovation

In the eyes of many in the communications industry, OSS have become a disappointment. Some even believe that the term is no longer relevant because of the associated negative connotations. But being Passionate about OSS, this is something we must attempt to remedy.

There is no prize for this Call for Innovation… other than the prize of adulation you’ll receive from anyone reading your words of inspiration, and the potential clients that will be beating down your door when they read about you here. We want to help make your OSS innovations go viral.

How did we get here?

How did we arrive in this situation and what does the future hold? This Call for Innovation is seeking to identify the technologies, people, companies and processes that will transform, disrupt and, more importantly, improve the world of OSS.

In some ways I’m disillusioned with OSS from repeatedly facing the same challenges on projects over the last two decades. Conversely, I’m in awe of what OSS can achieve and the brilliance of the multitudes who have brought them to life. Most importantly though, I’m Passionate About OSS because of the opportunities that await, to improve our tools, to improve our skills and to improve the lives of the vast population that interacts with comms networks, services and OSS / BSS.

We have arrived in a state where cynicism and disillusionment pervades for a number of reasons. The two that stand out most vividly are the entwined features of complexity and incrementalism. We have contributed to our own complexity and had complexity thrust upon us from external sources. The layers of complexity entangle us and this entanglement forces us into ongoing cycles of incremental change. Unfortunately, incremental change is impeding us from reaching for a vastly better.

Exponential opportunities

Exponential technologies are landing all around us from adjacent industries. It becomes a question about how to remove the constraints of current OSS and unleash them.

We’ve all heard of Moore’s Law, which predicts the semiconductor industry’s ability to exponentially increase transistor density in an integrated circuit. “Moore’s prediction proved accurate for several decades, and has been used in the semiconductor industry to guide long-term planning and to set targets for research and development. Advancements in digital electronics are strongly linked to Moore’s law: quality-adjusted microprocessor prices, memory capacity, sensors and even the number and size of pixels in digital cameras… Moore’s law describes a driving force of technological and social change, productivity, and economic growth.”

Moore’s Law is starting to break down, but it’s exponentiality has also proven to be helpful for long-term planning in many industries that rely on electronics / computing. That includes the communications industry. By nature, we tend to think in linear terms. Exponentiality is harder for us to comprehend (as shown with the old anecdote about the number of grains of wheat on a chessboard).

The problem, as described in a great article on SingularityHub is that the exponentiality of technological progress tends to surprise us as change initially creeps up on us, then overwhelms us in situations like this:
Singularity Hub's power law diagram

Hardware is scaling exponentially, software is lagging and wetware (ie our thinking) could be said to be trailing even further behind. The level of complexity that has hit OSS in the last decade has been profound and to be honest, has probably overwhelmed the linear thinking models we’ve applied to OSS. The continued growth from technologies such as network virtualisation, Internet of Things, etc is going to lead to a touchpoint explosion that will make the next few years even more difficult for our current OSS models (especially for the many tools that exist today that have evolved from decade-old frameworks).

Countering exponential growth requires exponential thinking. We know we’re going to deal with vastly greater touch-points and vastly greater variants and vastly greater complexity (see more in the triple-constraint of OSS). Too many OSS projects are already buckling under the weight of this complexity.

The Use Cases haven’t changed much

The OSS use cases haven’t really changed since the 1990’s. We still want to monitor and improve network health. We still want to bring appealing products to the market quickly and get them billed efficiently. We still want to ensure customers have efficient interactions with our tools via elegant interfaces and processes.

Let’s take those use cases to an even higher level and pose the question about customer interactions with our OSS:

  1. For how many customers (eg telcos) is the OSS buying experience an enjoyable one?
  2. For how many customers is the implementation / integration experience an enjoyable one?
  3. For how many customers is the user experience (ie of OSS operators) an enjoyable one?

Actual customer experiences in relation to the questions above today might be 1) Confusing, 2) Arduous and 3) Unintuitive.
The challenge is to break these down and reconstruct them so that they’re 1) Easy to follow, 2) Simple, based on auto-discovery and 3) Navigable by novices.

What we are looking for?

The topics related to this Call for Innovation can be wide and varied, yet sharp in focus. They can relate directly to OSS technologies or innovative methods brought to OSS from adjacent fields but ultimately they’ll improve our lot. Not just change for the sake of the next cool tech, but change for the sake of improving the experience of anyone interacting with an OSS.

The following is just a small list of starting points where exponential improvements await:

  • A natural language user interface, like a Google search, with the smarts to interrogate data and return insights. Alarm lists, trouble tickets, inventory lists and their ilk are waiting to be usurped by more intuitive UIs
  • Data-driven search-based interactions rather than integration, configuration or programming languages wherever possible, to cut down on integration times and costs
  • Service / application layer abstraction provides the potential for platform sharing between network and OSS and dove-tailed integration
  • New styles of service and event modelling for the adaptive packet-based, virtual/physical hybrid networks of the future
  • A single omni-channel thread that traces every customer omni-channel interaction flow through OSS, BSS, web/digital, contact centres, retail, live chat, etc, leading to less fall-outs and responsibility “flicking” between domains in a service provider
  • Repeatable, rather than customised, integration. Catalogs (eg service catalogs, product catalogs, virtual network device catalogs) are the closest we have so far. Intent abstraction models follow this theme too, as does platform-thinking / APIs.
  • True real-time data collection and management (eg traffic management, billing, quality of service, security, etc) as opposed to near-real-time
  • Unstructured, flexible data sets rather than structured data models
  • Highly decentralised and/or distributed processing using commoditised hardware rather than the centralised (plus aggregators) model of today
  • A standardised, simplified integration mechanism between network and management on common virtualised platforms rather than proprietary interfaces connecting between different platforms
  • An open source core that allows anyone to develop plug-ins for, leading to long-tail innovation, whilst focusing the massive brainpower currently allocated to duplicated efforts (due to vendor fragmentation)
  • Cheaper, faster, simpler installations (at all levels, including contracts between suppliers and customers)
  • Transparency of documentation to make it easier for integrators
  • Ubiquitous training / learning programs – like what Cisco has achieved with it’s CCIE (and similar) certifications (not to mention the unlikely competitive advantage it has delivered)
  • Capable of handling a touchpoint explosion as network virtualisation and Internet of Things (IoT) will introduce vast numbers of devices to manage
  • Machine learning and predictive analytics to help operators cope with the abovementioned touchpoint explosion
  • Increasing the perception of value provided by OSS, reversing the pervasive sentiment that OSS can only ever be a cost centre. OSS are too important to just be cost centres

Increasing Trust

The web-scaled, cloud model (ie hosted by a trusted partner) becomes attractive from the perspective of repeatability, from the efficiency of doing the same thing repeatedly at scale. Unfortunately this breaks down in a couple of ways for OSS (currently at least).

Firstly, the term “trusted partner” is a rare commodity between OSS providers and consumers for many different reasons (including trust from a security perspective, which is the most common pushback against using hosted OSS). Secondly, we haven’t unlocked the repeatability problem. Every organisation has different networks, different services, different processes, even different business models. Cloud-hosted OSS represents a big opportunity into the future if we first focus on identification of the base ingredients of repeatability amongst all the disparity. Catalogs (eg service catalogs, product catalogs, virtual network device catalogs) are the closest we have so far. Intent abstraction models follow this theme too, as does platform-thinking / APIs.

We wanted flying cars

In the words of Peter Thiel, “We wanted flying cars, instead we got 140 characters.”

This meme speaks of the innovation occurring in the world of technology. It seems that we are making fewer major innovations (eg flying cars) compared with the world-changing innovations that are technologically insignificant (like Twitter’s 140 characters).

The Idea Factory: Bell Labs and the Great Age of American Innovation,” highlights the groundbreaking changes brought about at Bell Labs (eg OSS, transistors, lasers, solar cells, satellites, communication theory, Unix operating system, the C and C++ programming languages, etc) and British Telecom during the mid 1900’s. It bears no comparison to our current innovation-in-software age, yet clearly shows our roots in major innovation.

Is the corresponding slow-down in OSS innovation occurring due to OSS maturing? After all, we’ve had alarm management, performance management, inventory management, traffic management, service order management, provisioning, etc for years now. If we had’ve needed something else, would we have already thought of it through necessity?

Yet as OSS nears 50 (the first OSS were developed in the 1970’s) it feels like we need quantum change more than ever to remain relevant and deliver what our customers need.

So give it your best shot – Tell us how you (or someone else) is going to rock our world.

Read the Passionate About OSS blog for more.