Exploiting the Functionality Gap

Jun 15, 2012 by Dylan Jones in Data Quality

One of the more common challenges most businesses face is knowing where to commence their data quality initiatives. Laying down frameworks, policies and governance is obviously important but at some point you’ll be tasked with physically implementing data quality improvement and prevention activities.

So, where to start with Data Quality?

What I typically try to build first of all is a performance model that combines something the business values and is trying to improve strategically with an underlying data quality model that highlights all of those rule metrics, profiling results, defects and so on.

When you’re discovering your data quality rules and building out your initial data quality framework one area to focus on is identifying any application “functionality gaps” that exists. By this I mean the difference between the functions an application was originally intended to perform and the functions it is currently performing. You will nearly always find a gap between the original design and “intent” of the application compared to how the business currently uses it.

What do functionality gaps look like?

They come in many shapes and guises but obvious starting points are attributes that have been overloaded i.e. data structures that are now performing multiple functions, some of which were never adequately designed for at the inception of the application.

Other functionality gaps are clearly evident just by asking the users to walk you through any processes that they find cumbersome and require manual workarounds. There may be operating procedures that were clearly never conceived when the application was first designed, particularly if the system is a COTS (Custom Off-The-Shelf) product so just ask around, they’ll quickly surface.

So what next?

Document the gaps. Start to convert this knowledge into data quality rules that can be historically measured and proactively monitored moving forward. There is a far higher likelihood of defects emerging in these functionality “cracks” between original system design and often localised fixes that the business need to get their jobs done.

Finally, you can gain some instant allies by helping to use your data quality tools and processes to prevent transactional failures occurring that can make everyone’s life far less stressful whilst dramatically improving the bottom line. In one past client we had a situation where the users would have to manually check through daily printouts of stock items because the application display only returned 50 records at a time due to a COTS design constraint. By implementing a fuzzy-match search tool and web front end users were able to complete more accurate stock searches in a fraction of the time.

Tags: Data Quality, functionality gap