OSS automation is critically linked to API enablement. All OSS entities must be connected via APIs to unlock true process automation. Why? And, what does this mean for future networks?
OSS process automation has become fundamental to telecoms operators. The reasons for this are clear. Manual processes take time and cost money. Put simply, reducing or constraining operational costs is a clear imperative for many – irrespective of the industry in which they operate, but particularly so for telecoms. That’s because, perhaps surprisingly, the telecoms industry has long seen the persistence of a number of manual processes. These have to be automated.
There’s another reason – operational effectiveness. Telecoms operators need to accelerate the speed with which they provision and deliver services, so they can monetize them faster. But automation per se isn’t new – protocols have enabled one system to convey information to another for generations, thus triggering some form of action in response to an appropriate message. So, what’s changed and how can APIs help today?
Well, as many are aware, we’ve moved to the ‘API economy’. This term artfully captures the essence of a new mode of operating, in which businesses expose APIs for “digital services and assets in a controlled way” . These APIs enable different processes, from different providers to interact effectively, so that an action in one provider can trigger a corresponding reaction in another – where there was no previous protocol that could accomplish the same task.
APIs are a means of exposing information in a way that can be understood by another process. Protocols are helpful and great but they are not easily extendible or malleable. Once agreed, a protocol does what it was specified for. Creating new possibilities has previously required new protocol extensions. APIs augment traditional protocols and, to some extent, bypass them, allowing novel requests and commands to be enabled.
So far, so familiar. But, while APIs are hardly new, they have come relatively late to telecoms. There’s some history behind that – too much to go into here. Suffice to say that, over the past few decades, there have been numerous efforts to expose telecoms APIs to other (external and internal) parties so that services and systems can be controlled by other platforms or programs to which they are not interconnected via protocol layers.
Few of these succeeded until the advent of REST and Web Services APIs just a few years ago. One of the reasons for failure was the inability to define who was trusted and who was not – with a result that many telco APIs were simply too complex or cumbersome for widespread adoption.
To some extent, this reluctance was also mirrored internally. There was no need for an API to expose control and integration functions if the entire OSS estate came from a single vendor which was responsible for ensuring its operational effectiveness – which brings us to the third reason why APIs are now in vogue for OSS process automation: vendor lock-in.
Telecoms operators want to break dependency on a single vendor and to be free to choose the best of breed to build a diversified estate that is optimized for their needs. APIs are fundamental to achieving this goal, because they enable different systems and processes to be combined into smoothly functioning and fully automated workflows.
And, it’s also worth considering that the entire framework of 5G networks – which, don’t forget, is not designed exclusively for mobile but rather as a complete, unified infrastructure for all networks – is based, not on traditional protocol interworking, but rather on API interconnection of all functional elements in a virtual environment.
So, whereas APIs were largely seen as providing the means for individual control of different elements and enabling customization, today they are central to the operations and build of all future networks. Since the OSS provides operational resources to ensure that services are delivered, it also follows that API integration is a necessary evolution.
What, then, is the role of APIs in OSS process automation? Well, the purpose of the OSS is to enable effective operations – from order and process activation, through to fulfilment and lifecycle management. This involves a large number of complex tasks – all nicely mapped to an industry-standard taxonomy and architecture in Frameworx, which includes the eTOM model as a key component.
Any given service requires multiple operations during its lifecycle. Coordinating and connecting these is a key task for telecoms operators, as is reducing the complexity of their networks alongside reducing vendor dependencies. APIs are not part of OSS process automation – they are OSS automation.
Without API exposure the elements that perform different tasks cannot be connected effectively. So, while protocols may be required to convey information, the receipt of information or instructions from external platforms via API-driven commands is thus essential. Each element in the OSS needs to be provisioned with an API, so that it can be connected into a combined, consolidated OSS control fabric. However, once this has been accomplished, new opportunities can be enabled.
That’s because wider interconnections, between OSS and BSS elements can also be achieved. Rather than separating functional layers and domains, cross-domain interconnections can be built. This allows, for example, a customer-facing tool, such as the CRM to be connected, via a series of intermediate steps with a remote device that is required in a service – such as a fiber router, or a sidewalk cabinet. Thus, on receiving an order, the requisite actions to activate a service can be taken, in the correct order, with appropriate checks regarding resource requirements, availability and delivery.
While fibers, cables and the like are the venous system that reaches all parts of the telecoms network, APIs can be seen as the immune system cells that detect and trigger responses to events. They are essentially the connectedness of all things and, the more things are connected, the more possibilities there are to drive value and enhance performance.
One consequence of this is the realization that there needs to be a single, centralized body of information regarding the network and all it contains. This should be available to all other systems and processes that may, periodically, require information to be retrieved as part of a service or operational flow.
This system is best-known as the Network Inventory and is therefore fundamental to all OSS and BSS processes. Like all other elements, it must be enabled by APIs that allow it to be integrated, interrogated and to make reports to other elements.
Just as Metcalfe’s Law relates to the power of a network and its relationship to the number of subscribers, so too can we posit that the value of an OSS is related to the interconnectedness of its constituent elements. APIs are a means of extending this connectivity across layers and functional domains, so that each element can be interconnected to each other – across the OSS and BSS estate.
The more they are connected, the more value can be derived. APIs are not simply a nice way of connecting one thing to another, they are fundamental to the creation of new value in telecoms network and truly realizing the goal of OSS – and BSS – process automation. And, if there’s one element that must be visible to all others, it’s the inventory system.