By now I’m sure you’ve heard about graph databases. You may’ve even read my earlier article about the benefits graph databases offer when modelling network inventory when compared with relational databases. But have you heard the Graphene Database Analogy?
I equate OSS data migration and data quality improvement with graphene, which is made up of single layers of carbon atoms in hexagonal lattices (planes).
There are five concepts of interest with the graphene model:
- Data Planes – Preparing and ingesting data from siloes (eg devices, cards, ports) is relatively easy. ie building planes of data (black carbon atoms and bonds above), where each data set might come from a different source (eg different EMS, spreadsheets, APIs, etc)
- Bonds between planes – It’s the interconnections between siloes (eg cross-domain circuits, network links, patch-leads, joints in pits, etc) that is usually trickier. So I envisage alignment of nodes (on the data plane or graph, not necessarily network nodes) as equivalent to bonds between carbon atoms on separate planes (red/blue/aqua lines above).
But we can often find points of commonality between data sets. Alignment comes in many forms:
- Through spatial alignment (eg a joint and pit have the same geospatial position, so the joint is probably inside the pit)
- Through naming conventions (eg same circuit name associated with two equipment ports)
- Various other linking-key strategies
- Nodes on each data plane can potentially be snapped together (either by an operator or an algorithm) if you find consistent ways of aligning nodes that are adjacent across planes
- Confidence – I like to think about data quality in terms of confidence-levels. Some data is highly reliable, other data sets less so. For example if you have two equipment ports with a circuit name identifier, then your confidence level might be 4 out of 4* because you know the exact termination points of that circuit. Conversely, let’s say you just have a circuit with a name that follows a convention of “LocA-LocB-speed-index-type” but there is no associated port data. In that case you only know that the circuit terminates at LocationA and LocationB, but not which building / rack / device / card / port so your confidence level might only be 2 out of 4.
- Visualisation – Having these connected planes of data allows you to visualise heat-map confidence levels (and potentially gaps in the graph) on your OSS data, thus identifying where data-fix (eg physical audits) is required
- Connection Hierarchies – The interconnections between planes and the relative hierarchy of the planes can provide great insights for root-cause and/or service-impact analyses. For example, let’s say your PNI provides the physical network data plane. The second plane might be an optical transport layer. If you get a Loss of Signal alarm on adjacent devices in the optical plane, you could imply a cable cut as the root-cause and therefore suppress all child alarms from plane 2 and above in your graphene hierarchy.
* the example of a circuit with two related ports above might not always achieve 4 out of 4 if other checks are applied (eg if there are actually 3 ports with that associated circuit name in the data but we know it should represent a two-ended patch-lead).
I also see the graphene mindset as a potential mechanism for visualising data across layers such as:
- Physical infrastructure
- Logical / virtual infrastructure
- Services and
- Other overlays such as real-time data
Or also for data proximities for root-cause (refer to this earlier post) such as:
- Proximity in topology (ie nearest neighbours)
- Proximity by geography
- Proximity in time
- Proximity by object hierarchy (think OSI stack)
Note: The diagram above (from graphene-info.com) shows red/blue/aqua links between graphene layers as capturing hydrogen, but is useful for approximating the concept of aligning nodes between planes