“Opportunities multiply as they are seized.”
Sun Tzu.
This triumvirate of tools (OSS, BSS and GIS) can provide a CSP with incredibly powerful and flexible information.
There are a few considerations to take into account:
- These tools are often operated by different business units and have different objectives for the data sets
- Connecting two entities requires a single interface. Connecting three entities (ie OSS, BSS and GIS) needs up to three interfaces. [Note: The complexity keeps on climbing exponentially as more entities are added by the way.]
- When there is one interface, it’s usually relatively easy to decide which entity is the data master and which is the slave. Sometimes this is not so easy when there are three or more entities
- More importantly, you need linking key pairs on each of the interfaces and possibly a consistent linking key across all interfaces
- Each of the interfaces may have different interface mechanisms (eg XML, ODBC, SNMP, etc)
Let’s use the example of an inventory use-case across the three entities.
- The OSS stores an inventory item (eg a router). The OSS stores its device_name, location and optionally stores GPS_coordinates and serial_number
- The BSS stores the inventory item in its Fixed Asset Register (FAR). The BSS stores purchase_date, expiry_date, serial_number and might also optionally store device_name and location
- The GIS simply plots objects based on object_type at the nominated GPS_cords
There’s a fourth entity, the router itself, which also comes into play but we’ll just assume that it presents via the OSS for now.
Assuming we already have all the interfaces developed and operational, we now have to identify a workflow that allows the data to correlate and synchronise between systems.
The following example might work:
- The router is purchased by the procurement team and lodged in the asset register in the BSS
- A work order is raised to install the router out in the field and the field configuration of the device will include setting up a host_name / device_name
- Once installed, the OSS auto-discovery tool polls the network and hopefully identifies the new device by its device name and possibly other configuration values
- Once this new device record is loaded into the OSS, additional data can be stored against this object (eg cards, ports, in-service status, location, etc)
- This new device might inherit GPS_coords from being associated with a location that already has geo-codes loaded. But in this instance, we’ll assume the GPS_coords field remains blank
- Now we wish to plot the router in a GIS so we search through the inventory items that it has searched from the OSS. Since it doesn’t have the GPS_coords field populated, it just plots the router in a default location
- The GIS operator then drags the router object to the required location on the map, effectively assigning GPS_coords to the object. Once saved, it sends the new data back to the OSS database for future reference
- You probably then need to design a process that ensures feedback / reconciliation loops exist to maintain data integrity, which is a potential issue in this multi-interface scenario