Composable IT in telecoms – is it a pathway to automation?

Composability allows us to integrate different systems – both inside our networks and externally.

Internally, this provides a means to implement new levels of process automation. How?

Composable IT – driving monetisation but also internal optimisation

Composable IT has become rather a trendy topic right now, as both executives from across the telecoms industry and representative groups – such as the TMF – embrace the concept of interconnecting business processes.

But while much of the focus has been concentrated on monetisable applications for this approach (think digital ecosystems and an outward-looking approach), we mustn’t lose sight of the fact that Composable IT as a practice can transform our internal systems and deliver enhanced value from existing platforms and processes.

Composable IT is really built on the principles of interchangeable components that can be assembled to enable integration between platforms. It’s like having a library from which you can choose the right element to bring two things together, so you can enable them to interact effectively.

Integration between platforms joins together steps in process flows and sequences – so, by doing so, you can remove gaps and manual intervention points, building automation into existing processes and flows, so that they function seamlessly.

Common, reusable components to bridge process gaps

With Composable IT, we leverage the concept of components that can be used to perform functions that bridge those gaps in flows where action is required – where one system needs to deposit data in another, retrieve information, or request a specific change, for example.

In this context, a ‘composable component represents a function that needs to be applied to complete such a task, so you can move to the next in the sequence of operations. It is abstracted from the underlying operation but completes a necessary step.

This isn’t a new concept in telecoms – the idea of abstracting functions has been around (and in deployment) for many years. But we probably didn’t push the idea hard enough – until we saw how the IT world was able to stitch together different elements in the tech stack so that they could drive business value through integration between platforms and systems.

You don’t need one system to rule them all; you just need them all to interact with each other. Composable IT gives us a methodology for enhancing these interactions, through logical but reusable components.

Logical functions – taking specific actions

That’s because, key to these integrations, is not hard coding interactions but employing components that perform logical functions and that could be used, as required. These components fulfil specific tasks – receive a signal from a system that triggers an action to retrieve data from something else, send that data somewhere, wait for a response and confirm the action request has been completed.

While this has huge value for building new ecosystems that can boost or diversify service revenue (hence the outward focus of many), it also opens the door to advancing automation internally, so that telcos can drive efficiency gains.

This is applicable to just about any domain in the telecoms’ environment – from the network to the OSS and BSS – and across the service lifecycle. Let’s take a simple example. Imagine that we want to automate the handling of alarms. Alarms send indications of system or device status into the Network Operations Centre, or NOC.

What this means is that there is a constant flow of information, some of which is interesting, some of which is noise – and some of which is actionable. If a router approaches its set capacity level, that’s interesting. If the router passes a capacity threshold, we need to do something about it and reroute traffic.

In the NOC, this could be actioned manually but with so many changes in traffic patterns to cope with, automating the response is more desirable. To achieve this, you need a generic process that can interact with both the alarm generating system and the router orchestration function, so that the capacity can be requested in the affected route, while ensuring that traffic is sent by the appropriate alternative pathways.

Of course, some modern systems can already manage these transitions. But many telcos have a mix of different generations of technology, and these may not always be aligned. And that’s the big opportunity for the practices of Composable IT.

We need components that can handle logical functions, and which can be inserted into a sequence of events. In this case, capacity management. Here, we need to recognise the alarms and filter them, based on their values and the severity of the situation for which they give reports – we want to be alerted to a possible emerging condition, while noting a condition that requires action.

Composability means configuration, not coding

We also need to know what that action is. So, our component should be able to interpret the alarms and match alarm type to the range of actions available. It does not have to understand the concept of traffic or capacity management; it simply needs to know what input A corresponds to output B, given the right context, or output C should the context be different.

As such, a component that manages rule-based responses to one set of alarms can also be repurposed to do the same for a different one. It is performing the same kind of function but for different systems or processes. In that way, it meets the requirements of composability, because it simply needs to be configured correctly for the set of alarms in question.

But what about the integration with the system generating the alarms and that which initiates and orchestrates the responses? Since the component is abstract from the underlying technology, it needs to be able to interface with both – which can be done through the support of the reporting and control interfaces available.

This means that a truly abstract component in the telecoms’ domain should natively support different kinds of interfaces, from SNMP to REST and to other protocols found in the operational domain. This is a matter of configuration, so we can take the same component and configure it for multiple use cases that have similar requirements in terms of inputs and expected responses. The component should support these interfaces out of the box.

So, Composable IT not only offers much promise for efficient interaction with third parties, and offers monetisation opportunities, it also provides a clear pathway towards enriched automation – closing process gaps so that seamless operations can be enabled.

The We Are CORTEX approach

At We Are CORTEX, we have built a library of what we call “Process Fragments”. These are components that can be used, following Composable IT principles, to assemble chains that implement any process. They are decoupled from the underlying processes and are also reusable, testable, and independently versioned process assets, so they can easily be inserted into operational journeys.

The Process Fragments also enable ‘plug-and-play’ integration with legacy systems and networks. And, users can experiment with them to assemble the correct flow, because they offer full version control, audit trails – and the opportunity to insert Humans in the Loop (HITL) for checks and where there are known gaps in a flow.

Would you like to know more?

Download our new paper, “Composable IT and process fragments – Building Service Assurance using efficient automation through component-level abstraction and integration” to find out!