For German readers: Es gibt eine deutsche Version dieses Blogeintrags.
In one of my last posts, I painted a picture of the Data Quality Middle Ages and the resulting fire storms. This post explores the elements on how to move from the Middle Ages into modern times, using a Fire Department as a metaphor.
Photo by Infidelic
Here are 5 important elements that you should have in mind when building your Data Quality Fire Department.
Firemen
Of course, there is no fire department without any firemen. Foremost, a fireman’s job is to know how to do the firefighting and be trained to do it properly.
For data quality, that means that there has to be at least one person in the organization that is dealing with data quality fires on a regular basis. This doesn’t have to be that person’s only responsibility, as evidenced by the fact the smaller towns only have a voluntary fire department. Only larger towns (larger companies) can afford a large staff (department) of dedicated firemen (DQ professionals).
Fire Alarms
When someone sees a fire, he cries out “fire”, calls 911 or uses some kind of fire alarm system like a manual pull station. For data quality, this means that whoever sees a data quality problem must have some way of notifying the DQ professionals that there is an issue. This can be as simple as a mail-address, but can quickly grow into some form of issue tracking system. (It should be noted that the notification should be as simple as possible, even if for tracking purposes a more elaborate system is used.)
Fires may also be spotted by a dedicated person to look out for a fire like a night watchman. For data quality, this means that the DQ department should of course look for data quality issues on their own. In my experience however, the focus should be on solving problems (see “Firefighting” further down), especially at the start of a DQ initiative.
One more point: Today, there are automatic devices to detect fires. (BTW: You should have a smoke detector installed in your home!) For a more advanced DQ initiative, this means that there are some automatic DQ measurements taken that may also result into DQ Alarms to be raised.
Firefighting
In order to extinguish a fire, fireman follow a procedure. If you look at the Wikipedia article on firefighting, there are a lot of issues to take into account and different ways to attack a fire. It’s certainly not as simple as dumping some water in the vicinity of a fire!
For data quality, there has to be a procedure as well. As with a lot of quality processes, this is usually a DQ-specific adaption of the Deming cycle or “plan – do – check – act”. There is a lot to discuss here, and I will cover the “DQ Cycle” in a future blog post in more detail.
Fire Trucks
The thing that fascinates kids the most about fireman is the fire truck – an the most visible example of the tools that a fireman needs to do his job.
A DQ professional also needs some tools. There are some general purpose tools to analyze data (a SQL query tool, more “clickable” tools like BI tools). There are also some DQ specific tools (for example, profiling tools, tools to find duplicates, tools focused on address quality).
Again, I would like to offer a word of caution: Buying a tool (especially if it is quite expensive) will not magically solve your data quality issues – after all, “a fool with a tool is still a fool”. Certainly, some tools are needed, but a DQ initiative is so much more than a tool selection process. I constantly have long discussions with clients in order to de-emphasize the tool aspect when starting a DQ initiative.
Fire Prevention
One of the biggest improvements compared to the Middle Ages comes from preventing fires and pre-planning in case a fire happens. This includes switching form easily flammable building materials like wood to fire-resistant materials such as steel or firewalls, minimizing ignition sources and educating people about the proper emergency behavior.
As after fires, DQ should try to determine how a DQ problem could have been prevented and apply that lesson in other areas. This is often tricky to sell, as other (yet unaffected) departments often look to data quality as just one more unloved requirement. It requires an excellent “sales pitch” from the DQ team, and it is always helpful to have built some goodwill by having solved earlier issues.
What other aspects do you think are important when building a DQ initiative? Which areas would you like to see highlighted in future posts? Let me know in the comments! Thanks.
Leave a Reply