Problem definition and goal
CELINE inventory management tool was design for GNOC (Global network operation center). Its goal is to optimize network operations of France Telecom by creating one entity responsible for selected networks for European Orange affiliates. To achieve this goal, access to information about network infrastructure of these affiliates is at the core of what GNOC is doing.
Original approach for GNOC with regards to inventory management was to access whatever tools are available in the country for which they provide services. It was obvious very soon that this will be very inefficient taking into account that these systems vary from huge inventory solutions like NetCracker to excel spreadsheets with no real data correlation, in some cases localized into language of the country owning the tool. Very soon it has been identified that there should be single inventory solution for GNOC which integrates all data sources which are available. One could simply describe the situation as following:
OBJECTIFY has been part of CELINE project from the very beginning (before it had the name CELINE). Our first contribution to the project was to create study which described the problems of the GNOC to access information scattered across many data source all across Europe. Soon it was clear that we will face many non-trivial challenges
- Data diversity – The applications storing the network infrastructure data were very different from each other, both from APIs, level of detail and data models. Our goal was to create unifying view for the user. If something is a server or router it should be server or router independent if the data came from NMS (network management system), Excel spread sheet or inventory tool.
- Data synchronizations – It was absolutely not possible to replace all the tools used in affiliates because they are participating in day-to-day work of local engineers and they are integrated into other IT solutions within the given orange affiliate. To investigate and analyze them in such detail would not be realistic.
- Data quality assurance – It is common for inventory systems to have data, which are not up to date. The problem is even bigger if some 3rd party with no management authority (GNOC) needs to initiate data cleaning or update of stale data.
- Information instead of data – Even if the data from various data source will be in the same application, in order to provide real benefit these data needs to be correlated to each other, they need to be condensed into user report and accessible via standardized APIs to further automation and reporting tools.
- There are significant project management issues related with project with so many participants but this goes beyond the scope of this case-study
OBJECTIFY was active in telecommunication inventory domain long before this project. Without this expertise we could have never deliver this solution. Our solution consists of several major concepts mapping to challenging described above
- Data diversity – Using our previous experience, we have created inventory data model consisting from very generic terminology all the way to specific types, which could be extended and can document any inventory situation we might encounter in the project and in the future data sources, which were not even identified during that type. The result was “Common data model” that we’ve described in great detail
- Data synchronizations – We have created specialized data pumps that have been installed in each country in order to collect data, normalize and transform the data to “Common data model” and send the delta after each synchronization to centralized inventory located in Poland. These data pumps are extensible to allow implement custom connectors and transformation for each data source. All the downstream calculation, transformation and algorithms are generic and in depended from data source.
- Data quality assurance – In such distributed project, one needs to make sure the data presented to the user is correct. We have implemented many mechanisms to make sure we catch a problem pro-actively like ensuring the general reference integrity, implementing data invariant test (network card has to be in some chassis, connection has to have beginning and end). We have also allowed users to override data coming from a source system but making sure that such corrections are consistently visible across the application (value from data source, value corrected by GNOC), they use automated notifications and reports that are sent to data source owner.
- Information instead of data – Having the data doesn’t mean that user gets the information he/she requires. To solve this issue, we have put a lot of emphases on searching capabilities across all inventory object and all attributes. Part of the CELINE solution is integration with our own DMS tool that provides storage for unstructured data (work instructions, manuals, common problems and solutions) and integrates this information right into CELINE.
Beside of search we have design and implemented many custom reports which are Taylor made for daily information requirements of GNOC engineers. These reports have access to full set of data in CELINE and allow integrated view on data coming from standalone data source.
- Project age: 5 years
- Number of countries: 4
- Number of data sources: 14
- Inventory objects: close to 1Mio
- Users: 349
- Domain: Telecommunication
- Technologies: Java, Spring stack, PostgreSQL, Lucine index, Vue, Vuetify
- Competence: Data integration, Data modeling, High data volume processing, Microservices, Distributed applications