This is the third in the Complete OSS re-write series of posts and relates to Our data keeps deteriorating. 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.
As we all know, an OSS with poor data quality is more of an OHS (Operational Hindrance System) than Operational Support System, no matter how good the actual tool is.
We regularly discuss data integrity approaches here in on PAOSS (eg “Data Integrity Planning“). One of the most overlooked aspects of data planning is ensuring that there is a feedback loop to ensure that everything designed in the OSS is then fed back into the system after being modified (eg via As-built designs). Unfortunately the as-built process often only relates to customer services and doesn’t always cover infrastructure upgrades or ad-hoc upgrades the field workforce might do without updating documentation.
Even in environments where there is a feedback loop, it tends to be process driven. If the process doesn’t get followed, it’s possible that data quality suffers. Alternatively, reconciliation or audits are sometimes conducted in an attempt to identify and rectify data problems.
But if we are to take a new look at data quality, I think we have to take it further than just feedback processes. I believe we need feedback systems.
The system I have in mind is based around the same principle as the Double-entry bookkeeping system that has served accountants well for hundreds of years. For every activity, there is an equal and opposite activity recorded and reconciled against the original activity. The tools enforce reconciliation to achieve closure on any activity in a given reporting period.
A design is countered by an as-built. A hardware acquisition is countered by an inventory item (and ongoing stock audits [carried forward over reporting periods], particularly if the item has a programmatic interface).
I’d love to hear your thoughts on how we can re-write the data deterioration play-book and make OSS solutions that enforce reliable data. What does OSS‘s version of the double-entry book-keeping method look like in practice?Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email