Quality is a broad concept, and a big subject… or is it an object?
Can we define data in objective terms or just subjective? If so, how?
Let’s work around the concept of quality first.
If we follow the Aristotelian aphorism that “quality is not an act, it is a habit”, we understand that standing still will prevent us from ever achieving true “quality” data. What follows logically, therefore, is that we need to continuously (or regularly) measure our data quality to ensure the validity of any measurements.
Just like an audit, a point-in-time quality measurement is a useful snapshot — but it suffers from a “decay curve” (or “half life”) of usefulness.
What is the profile of that curve? Well, it depends on the data, and any political, organisational, technical and security constraints that will dictate the measurement intervals. I will expand on these constraints in future articles, but briefly:
- Political will involve External and Internal quality objectives.
- Organisational will involve Processes as well as the Business Outcomes that you are trying to drive.
- Technical will involve the technology aspect and how it impacts measurements.
- Security will involve the CIA (Confidentiality, Integrity and Availability) of your data and how that changes — or not — over time.
Analysing all these constraints and deliverables together should provide you with your “objective” foundation layer to counteract the natural woolliness (subjectivity) of the word “quality”.
So, for example:
- GDPR dictates that you have 30 days to ensure your “Data Subject Access Requests” are responded to.
- Measuring daily will provide you with both leading (“Will it breach?”) and trailing (“What has breached?”) quality indications.
- On the other hand, your Internal “Change Management” policy could specify that the Change Approval mechanism needs to be attested as valid every 12 months. In this case, a weekly “quality” check may be more appropriate.
Quality data demands quality measurements!
So, to recap, in order to turn subjective to objective:
- Quality requires measurements (of something) to validate
- Measurements should be regular or continuous
- Measurements’ definitions, scopes and constraints should be guided by these conditions:
- Political
- Organisational
- Technical
- Security
- Measurements should be correctly sized and timed (daily, weekly, monthly, annually, etc.)
- Above all, data quality should drive business benefits and outcomes
Maybe quality isn’t such a broad concept after all?
Author
Richard Taylor
Richard has over 20 years of experience in redefining and implementing processes for large, complex organisations. He delivers a greater level of compliance by supporting these businesses in managing vast quantities of data and facilitates control and maintenance of their estates.
Over the past two years, Richard has worked on the UK’s largest implementation of GRC within a highly regulated and complex environment. Working across streams and utilising automation, standardisation, efficiencies and de-duplication, he has delivered actionable insights for global stakeholders and managed the communication and delivery of the requirements of this large and agile project.