LightReading’s upcoming OSS in the Era of SDN & NFV is, to my knowledge, the only industry event to explicitly reference both OSS and SDN in its title.

This is odd, given how much talk there was about Operations at last week’s (excellent) SDN Forum in The Hague.

However, it seems like perhaps the distinct communities responsible for OSS and SDN/NFV might be able to find a common purpose under a new banner: Automation.

The only question is: automating what, exactly?

In the SDN world, automation tends to mean automation of the process of updating configs across a large network.

For those with an NFV perspective, automation tends to mean automation of the processes around developing, testing and then getting a new “function” safely added to the pool of network-available capabilities.

In the OSS world, automation has tended to mean automated fulfilment, and assurance (more specifically, automated root cause analysis, alarm management and service impact analysis).

Yet all of these still only represent individual facets of the automation required to run a telco business at scale. Especially one based on ultra-flexible software-defined networks, and a platform business model in which the behaviour of “customers” (which may themselves be software applications) is difficult to predict.

I’d argue that in that context, “automation” – while it’s the right priority – needs to be understood in a much bigger context.

In its most abstract sense, what’s going on in this part of our industry is the search for a new home for the defining responsibility of a telco: responsibility for changing the network. Who does it? How do they decide what to do? How do they anticipate the impact of change? How do they balance the needs now against future requirements for change? How do they ensure the changes aligns with both business (profit, costs, green credentials…) and customer (service, resilience) needs?

In an industry discussion that constantly references the existence of organisational silos, declaring “automation” as the new priority still needs qualification. Automating a process without incorporating additional factors – intelligence, if you will – is unlikely to be transformative. Faster, yes, but smarter? That’s not a given.

A rethink that expressly seeks to combine perspectives from OSS, BSS and network processes is what is required. This is completely analogous (so we know it works!) to the lean principles that manufacturers refined over 30 years ago – yet which were still (!) being held up in The Hague last week as a model to adopt.

We’re looking forward to advancing the discussion on 1 November in a panel on AI and Machine Learning in OSS, and then right after at LightReading’s Automation & the New Carrier Network on 2 November.