It is vitally important to give data consumers an indicator of the quality of your information. This helps to build a trust in the completeness and review state related to what they are consuming. What we have implemented is real-time, includes embedded business rules and a pretty little display.
So what did we do?
- Created a Five tiered rating system Data Quality(DQ) State
- Moving through each tier means that data completeness and audited quality checks are performed
- As the software application moves through its life cycle, additional data elements become mandatory, which effects the dynamically calculated rating
- DQ State value exposed for interfaced consumption
- Shown on-screen with graphical representation
What is involved in each DQ State tier level?
- DQ State 0: does not meet minimum required data
- DQ State 1: Name, Business Description, Status, Manufacturer, Owner (Group/Contact)
- DQ State 2: State 1 plus - Host, Software Type, User (count/location), Data Classification, Technology categories
- DQ State 3: State 2 plus - Cost Assessment
- DQ State 4: State 3 plus - Capability categories, Network communication details, Business Continuity details
This tiered approach begins to define higher quality for the data completeness as it moves up the defined levels. Not only having the blanks filled in, but the application of embedded business rules-based analysis to validate content, drives the state calculation. These are updated based on any change to any of the evaluated content.
What do you do in your organization? How do you ensure that the data "freshness" is preserved?
Previous topics include Application inventory, what do you capture?, Application inventory starts with a definition, Application inventory as a cost savings initiative and Application Inventory, the start of data sustainability?.
Hi, I've been reading the IT@Intel blogs for the past few months. This post was actually very timely for me, and I just wanted to say thanks.
We're in the process of redoing our IT Strategic Plans for the year, and we recently added some Business Continuity (The Business Part)/ Disaster Recovery (The IT part)information for each of the applications we support. For DR we have broken down systems into Tiers(0-4) depending on the Recovery Time Object (RTO) and the Recovery Point Objective (RPO).
It never entered my mind to attach the same sort of thing to our Application Inventory. The information that you captured will help us further define our DQ needs for the organization.
Thanks