Informatica Data Quality Blog

Posted by Larry English in: Data Quality ; Data Quality > Vertical Solutions

One of the root causes of poor quality information is defects in the data definition, specifically the “information product specifications.” Because information is a product of our business, manufacturing and service processes, the analogy of an “information product” is real, and the requirement for quality in “information product specifications” is a critical requirement for Information Quality.

This blog is the first of a series of three blogs on the critical quality characteristics (or measures) of information quality required to achieve Total Information Quality Management.

1. Information Product Specification data quality
2. Data content quality
3. Information presentation quality

What constitutes the “Information Product Specifications” data?

• Information standards
• Data names
• Data definitions
• Attribute valid value set or range of values
• Value format for structured attributes (VIN, SSN, Product Codes)
• Business rule specifications of constraints on data
• Information Steward accountable for data definition quality

Continue reading "IQ and Information Product Specifications Quality" »

Posted by Larry English at 04:15 AM | Permalink | Comments (0) | TrackBacks (0)

Posted by Garry Moroney in: Data Quality ; Data Quality > Management ; Data Quality > Technology ; Data Quality > Vertical Solutions

Managing the quality of customer data has its challenges: It is typically collected from a wide range of sources and channels and very often those responsible for entering or capturing data have no incentive to do so accurately. Even if they do much of it, including contact data can go out-of-date rapidly. Despite this most customer data has one major advantage over many other types of data which is agreed and accepted standards and reference data. While these standards do vary from country to country, they are at least universally understood and have an enormous impact on the approach and the effort required for managing data quality.

Because of these global standards and references, there is general agreement on what a complete, valid and correctly formatted address should look like - likewise person or business name, telephone number, date of birth, email address etc. So this means that if I am sharing my customer data with my business partners at least we have a common view of what high quality data should look like and the checks we need to make to assess the quality levels.

Another huge benefit is that third party service providers and technology vendors also understand the requirements and standards by which to measure and improve customer data and they know that these requirements are largely the same for all vendors. As a result large numbers of service bureaux and technology vendors are able to offer well developed, generic, out-of-the-box products and services to tackle customer data quality issues. These can deliver a lot of value with minimal or no customization and the effort to acquire and implement these solutions is small.

Continue reading "If all master data was like customer data . . ." »

Posted by Garry Moroney at 07:18 AM | Permalink | Comments (0) | TrackBacks (0)

Posted by Chris McCauley in: Data Quality > Best Practices ; Data Quality ; Data Quality > Technology ; Data Quality > Vertical Solutions

On reflection, dipping into details of matching technologies in my last blog entry wasn't that much of a detour from the subject of metadata. It broached the idea that one technology was better than another because of its ability to better handle the context in which it was used. There are a number of themes that run through my work on data quality at Informatica and one of them is "metadata as context".

By way of explanation, let's pretend that you are the newly hired Head of Engineering in a software company bringing a product to market (maybe a new operating system). The quality assurance team has completed its testing and you've just been told that it found no "show-stopper" defects, some usability "gotchas" and a smattering of documentation problems. The pressure is on; Sales has been promising these features to customers for weeks and Marketing announced this stuff months ago: to ship or not to ship, that is the question.

The QA stats are on the surface very reassuring, but we need to know some more about how the team arrived at those numbers before we start pressing CDs. If you found out that the team had been added late in a very long development process and was unfamiliar with the product would you still be sitting comfortably?

You can see how the words "context" and "metadata" could be used interchangeably when thinking about the scenario above. Harking back to the discussion about Probabilistic matching systems, there's value in understanding the context in which you are operating. Metadata can be used to capture some aspects of context hence "metadata as context".

Continue reading "Data Quality Metadata; a lot more than just "data about data"" »

Posted by Chris McCauley at 06:50 AM | Permalink | Comments (0) | TrackBacks (0)