In the last post we completed our description of the second functional domain of Open Networking: Open Network Software.
The fundamental trend in the evolution of Open Networking (outlined in the whole series to date), has been the progressive shift towards the software implementation of network functionality.
The common (and clumsy but evocative) term for this trend is the “softwareisation of the network”.
Although this series has described the historical innovations and key developments of “softwareisation”, there are multiple dilemmas: software is broadly used but not coherently conceived or developed across or within different industry domains. Software as a problem solving tool is still widely misunderstood and its practices often misapplied.
In order to successfully describe the remaining domains of Open Networking in this series, we need to invest a bit more time in this series exploring the nature of software. This will help to reduce potential misunderstanding about its significant role in the successful delivery of Open Network solutions.
So, we’re going to take a short interlude to discuss the nature of software and how it impacts and informs the field of Open Networking.
In particular we are going to drill down into key differences between the traditional networking world and the software world that cause problems in many implementation projects.
The Problem with Software
As pervasive as software has become in all aspects of life, we’d like to think that all is right with the software world. But unfortunately that’s not the case. Leaving aside any experiences you may have had in imperfect software projects, you only have to look at recent events in the world to see the impacts. For example, 2 accidents involving Boeing 737-Max aircraft (in Indonesia in 2018 and Ethiopia in 2019): although the causes of these 2 accidents have not been determined, the ongoing narrative is about software.
It’s almost a truism that software development projects are prone to run into difficulties, and this is even more true in the case of integrated solutions involving hardware, software and other components. And typically the more organisations involved in the process, the harder still it is to do well.
Open Networking solutions occupy this latter space: multi-component, multi-technology, multi-vendor projects which can be technically quite complex. All the good aspects of Open Networking that we’ve seen over the life of this series to date contribute towards this complexity, as they open up new layers or interfaces, or combine previously distinct technology and practice domains together and create a need for those domains to work together.
In Open Networking, software is both the glue and the new foundation that holds this complexity together. We a common understanding of the nature of software and the aspects of software that make it both hard to develop and so very valuable when it is done well.
There may be only a few ways to write software well, but there are many projects that find new ways to write software badly; or just find a way to re-use an old bad way of doing it.
Evolving practices in software development, mostly but not exclusively centred around Agile, are helping to improve the success rate of software projects, but we are still in the early days and the end-to-end process will need to evolve much further to improve quality and success rates.
The Software Interlude
Firstly, we look at the key question: what is software? This might seem overly simplistic, but it is an important definitional starting point from which we have to be aligned for all else that follows to also be aligned, in the upcoming post: “What is Software?”
Secondly, we’ll look at different perspectives of software and how it is used in Open Networking solutions, in the post: “Software Ain’t Software”.
Thirdly, we’ll look at the key aspects of software development and break this process down so we can compare and contrast with related but different practices, in the post: “What is Software Development?”.
Fourthly, we’ll look at why software development (and managing software development projects) is so hard, in the post: “Why is Software Development Hard?”.
And lastly, we’ll look at the development processes of software and how that relates to development processes in other technical domains in Open Networking, in the post: “Software Development Paradigms”.
After this Software Interlude, we will move on to the Open Network Integration domain.
Stay tuned for these upcoming posts.
