OSS re-write – Integration tax

This is the second in the Complete OSS re-write series of posts and relates to the integration tax being too high. This series is designed to pose ideas on how the OSS industry could take a Control-Alt-Delete approach to all aspects of delivering operational support, which coincides with the inflection point underway in our industry via technologies such as network virtualisation (eg SDN/NFV) and sensor networks (eg Internet of Things). This series also draws inspiration from the re-write approaches that are disrupting industries such as taxis, music, hotels and many others.

“The integration tax” is one of the biggest obstacles facing the OSS industry and in turn, the customers of our solutions.  It basically refers to the complexity, time and cost of integrating various parts of an OSS suite, allowing them to share information. Common examples are the interfaces from the OSS to:

• Network devices (or their device managers) or
• Other systems (eg OSS, BSS, etc).

There are so many different variants of interconnecting systems that a majority of interfaces need to have custom software (agents) written to support them.

There have been various attempts to streamline these communications, including the Enterprise Service Bus (ESB) architecture. This is great for building web-scaled or multi-OSS suite architectures, but can become too tightly coupled to change (refer to the chess-board analogy).

I’ve worked with network equipment providers (NEPs) and the question they always ask is how to design their northbound interfaces (NBI) (the agent inside the orange box in the diagram above) to make it more relevant to integrate with OSS. In the absence of a set of guiding principles on what OSS vendors need, they tend to follow standards but have their own nuances.

Similarly OSS providers have the challenge of having to create a new mediation-device (agent inside the blue box in the diagram above) for each other system they integrate with. The blue and the orange sides of the integration are both looking for a better way, simplifying their ability to communicate and thus reducing the integration tax for their customers.

So today’s post is looking at a re-write for this interaction, producing a more standardised and simplified approach for the industry to use.

The aim is to produce an interface that draws from the Plug and Play playbook, as shown in the diagram. The “other system” vendor creates the NBI as well as a driver library. The driver library is interpreted by the OSS vendor’s Plug and Play Manager. The Plug and Play Manager is able to intepret drivers from multiple different systems.

The Plug and Play Manager:

• Receives a notification from new devices / systems being added to the network
• Determines driver library, messaging format and resource requirements
• Dynamically loads driver library (if not already loaded)
• Authorises access by the device / system and polls it using the identified messaging format
• Allocates resources on OSS platform/s
• Notifies other drivers and/or services of it’s presence
• Opens the communications session

The key to the solution is the standardisation of the messaging format. TM Forum’s SID provides a model that is already widely used and has further extensibility (although that should be strictly minimised to ensure compatibility with all Plug and Play Managers). The aim would be to minimise the number of entities used across all systems and standardise on the use of entities across implementations.

Each OSS vendor would have their own interpretation of the Plug and Play Manager to distribute messages to/from their own application data stores and relevant to the specific operating system that it resides on (for resource allocation).

I’d love to hear your thoughts on how we can re-write integrations to make other systems more easy to plug and play with OSS solutions. What does OSS’s version of the revolutionary USB architecture look like?