OSS re-write – Data deterioration

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

4 thoughts on “OSS re-write – Data deterioration

  1. Ryan: Can you elaborate on the difference that you make between “reconciliation” and “double-entry book-keeping”?

  2. Hi Roland,

    Great question, because they have a number of similarities.

    In this context, I see reconciliation as the current way of cross-checking activities in most OSS tools. They’re usually custom scripts that are run in an ad-hoc or scheduled (eg CRON job) manner after the data has been created.

    With the double-entry bookkeeping approach, there is also reconciliation happening, but it’s built into the tools and cross-checking at data creation time to ensure the feedback loop is closed (eg what was designed has been entered, or what left the warehouse has ended up in the network).

  3. Ryan: Aren’t the latest generation inventory tools not just doing this i.e. having a constant (i.e. highly frequent) feedback/reconciliation loop to align the 2 sides of the book?

  4. Hi Roland

    I’ve seen it implemented (and done it) various ways using custom process and discovery / reconciliation (where programmable interfaces are available) but I haven’t seen a product show it in a GUI and enforce it via a double-entry before. But you’re possibly right that there are inventory tools that already do this for their customers. I’d love to hear if you know of any.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.