Coincidentally, my company is involved with a number of
different customers who are reviewing the quality criteria
associated with addresses. Each scenario has different motivations
for assessing address data quality. One use case focuses on
administrative management - ensuring that things that need to
happen at a particular location have an accurate and valid address.
A different use case considers one aspect of regulatory compliance
regarding protection of private information (since mail delivered
to the wrong address is a potential exposure of the private
information contained within the envelope). Another compliance use
case looks at timely delivery of hard copy notifications as part of
a legal process, requiring the correct address.
But another interesting coincidence is that there are two
aspects to our customers' desire to "fix" their data problems. One
is their perception of the solution, and the other is the reality
of the root causes.
More to the point, the way a project is envisioned from the
customer's perspective is driven by an expectation of the solution.
An example might be "guidance for designing and implementing a
master data management program." Multiple applications refer to the
same data concepts but don't talk to each other; instituting MDM
will make the business processes talk to each other, therefore the
project is envisioned as an MDM activity.
Once we start to peel the onion we begin to see things a little
bit differently. For example, the business processes are impeded
because they do not talk to each other. Implementing MDM might
bring the data together into a single location, but it won't
necessarily change the communications between processes. Similarly,
other root causes of issues that lead one into drawing conclusions
about a potential solution need to be both identified and evaluated
before moving forward. As part of that, I have started to look at
the issues that originally motivate the presumption of a solution,
and, more interestingly, ways to categorize their root causes.