Introduction

This documentation applies to version 2.1.1

Kuwaiba is an enterprise-ready network inventory platform geared towards the Telecommunications industry, but easily adaptable to other domains. It was designed to not only serve as an asset repository, but also to orchestrate complex business processes such as Service Provisioning, Activation, Modification and Termination, and to greatly speed the creation and integration of OSS (as in Operation Support Systems) applications.

Kuwaiba’s architecture was designed with four principles in mind: modularity, scalability, extensibility and interoperability. In this section we will describe how all these elements play a role in the diagram above. Although initially Kuwaiba used a relational database (Oracle or Postgres), the technical team quickly realized that this was not the best way to model and store a telecommunications network, that’s why the decision of switching to a graph database was made. The Persistence Abstraction Layer makes the access to the database transparent to the rest of the application, so upper layers don’t know what kind of DBMS is being used. This layer defines a so-called Persistence API, whose reference implementation provides support for Neo4J, but support for other graph databases (or even non-graph ones too, though with a higher degree of complexity) can be added if needed. This API, defines a set of capabilities to manage inventory assets (network devices, infrastructure elements, etc) and application objects (users, reports, processes, automation, etc). On top of this layer, the Integration Layer manages the lifecycle and interactions of application modules (physical/logical connections, navigation, reporting, Outside Plant Management, external services, etc). The so-called Integration API makes the task of creating modules easy and painless. The modules access the inventory and application objects through the abstraction layer and push (and listen for) messages to the Messaging Services component, which is in charge of propagating the changes and informing the registered components of events in the system. The Integration Layer ensures the coexistence between core, open-source modules and commercial ones.

A separate component implements support for southbound interfaces, chiefly the Synchronization Framework, which is an extensible component that enables Kuwaiba to keep the inventory updated by fetching data from network devices, NMS and other information systems using a broad range of protocols, finding the differences with the information existing on the inventory, and finally conciliating the deltas according to business rules set by the customer. The synchronization process may require that (potentially) thousands or millions of devices to be queried, thus requiring to be highly scalable. The recollection process is performed by agents distributed throughout the network (o simply running on the same server depending on the scale of the operation). Integrations with new data sources can be done by creating the so-called Synchronization Providers, which implement the Synchronization API. More details about the Synchronization Framework can be found here.

The northbound interfaces allow Kuwaiba to talk to other higher-level systems, such as BSS platforms (ERPs, CRMs, etc) or OSS platforms (alarm/performance monitoring, billing, trouble ticketing, etc ) or simply to support the access from clients such as browsers, mobile or third-party clients. The load and response time requirements of both types of consumers, may make necessary to use different kinds of mechanisms to deliver the information required give the time restrictions under certain stress. To meet these needs, Kuwaiba provides so-called “regular-performance” interfaces (REST/SOAP webservices) which are more structured and implement more validations and procedures to ensure the security and integrity of the information, as well as “high-performance” interfaces, with less overhead and aimed do a lot of stuff in little time by keeping processing time to the bare minimum. At its core, Kuwaiba is a platform, that is, a piece of software that is meant for other components to be built on top of it. Kuwaiba may serve as an inventory system for other domains such as utilities, oil & gas or power transmission and distribution. It can be extended by creating domain-specific frontends which we call “Portals”, or UI-less mediation components (pieces of software that translate requirements from one domain to another).