Which came first, the Data Quality Tool or the Business Need?

This recent tweet by Andy Bitterer of Gartner Research (and ANALYSTerical) sparked an interesting online discussion, which was vaguely reminiscent of the classic causality dilemma that is commonly stated as “which came first, the chicken or the egg?”

An E-mail from the Edge

On the same day I saw Andy’s tweet, I received an e-mail from a friend and fellow data quality consultant, who had just finished a master data management (MDM) and enterprise data warehouse (EDW) project, which had over 20 customer data sources.

Although he was brought onto the project specifically for data cleansing, he was told from the day of his arrival that because of time constraints, they decided against performing any data cleansing with their recently purchased data quality tool.  Instead, they decided to use their data integration tool to simply perform the massive initial load into their new MDM hub and EDW.

But wait—the story gets even better.  The very first decision this client made was to purchase a consolidated enterprise application development platform with seamlessly integrated components for data quality, data integration, and master data management.

So long before this client had determined their business need, they decided that they needed to build a new MDM hub and EDW, made a huge investment in an entire platform of technology, then decided to use only the basic data integration functionality. 

However, this client was planning to use the real-time data quality and MDM services provided by their very powerful enterprise application development platform to prevent duplicates and any other bad data from entering the system after the initial load. 

But, of course, no one on the project team was actually working on configuring any of those services, or even, for that matter, determining the business rules those services would enforce.  Maybe the salesperson told them it was as easy as flipping a switch?

My friend (especially after looking at the data), preached data quality was a critical business need, but he couldn’t convince them, even despite taking the initiative to present the results of some quick data profiling, standardization, and data matching used to identify duplicate records within and across their primary data sources, which clearly demonstrated the level of poor data quality.

Although this client agreed that they definitely had some serious data issues, they still decided against doing any data cleansing and wanted to just get the data loaded.  Maybe they thought they were loading the data into one of those self-healing databases?

The punchline—this client is a financial services institution with a business need to better identify their most valuable customers.

As my friend lamented at the end of his e-mail, why do clients often later ask why these types of projects fail?

Blind Vendor Allegiance

In his recent blog post Blind Vendor Allegiance Trumps Utility, Evan Levy examined this bizarrely common phenomenon of selecting a technology vendor without gathering requirements, reviewing product features, and then determining what tool(s) could best help build solutions for specific business problems—another example of the tool coming before the business need.

Evan was recounting his experiences at a major industry conference on MDM, where people were asking his advice on what MDM vendor to choose, despite admitting “we know we need MDM, but our company hasn’t really decided what MDM is.”

Furthermore, these prospective clients had decided to default their purchasing decision to the technology vendor they already do business with, in other words, “since we’re already a [you can just randomly insert the name of a large technology vendor here] shop, we just thought we’d buy their product—so what do you think of their product?”

“I find this type of question interesting and puzzling,” wrote Evan.  “Why would anyone blindly purchase a product because of the vendor, rather than focusing on needs, priorities, and cost metrics?  Unless a decision has absolutely no risk or cost, I’m not clear how identifying a vendor before identifying the requirements could possibly have a successful outcome.”

SaaS-y Data Quality on a Cloudy Business Day?

Emerging industry trends like open source, cloud computing, and software as a service (SaaS) are often touted as less expensive than traditional technology, and I have heard some use this angle to justify buying the tool before identifying the business need.

In his recent blog post Cloud Application versus On Premise, Myths and Realities, Michael Fauscette examined the return on investment (ROI) versus total cost of ownership (TCO) argument quite prevalent in the SaaS versus on premise software debate.

“Buying and implementing software to generate some necessary business value is a business decision, not a technology decision,” Michael concluded.  “The type of technology needed to meet the business requirements comes after defining the business needs.  Each delivery model has advantages and disadvantages financially, technically, and in the context of your business.”

So which came first, the Data Quality Tool or the Business Need?

This question is, of course, absurd because, in every rational theory, the business need should always come first.  However, in predictably irrational real-world practice, it remains a classic causality dilemma for data quality related enterprise information initiatives such as data integration, master data management, data warehousing, business intelligence, and data governance.

But sometimes the data quality tool was purchased for an earlier project, and despite what some vendor salespeople may tell you, you don’t always need to buy new technology at the beginning of every new enterprise information initiative. 

Whenever, and before defining your business need, you already have the technology in-house (or you have previously decided, often due to financial constraints, that you will need to build a bespoke solution), you still need to avoid technology bias.

Knowing how the technology works can sometimes cause a framing effect where your business need is defined in terms of the technology’s specific functionality, thereby framing the objective as a technical problem instead of a business problem.

Bottom line—your business problem should always be well-defined before any potential technology solution is evaluated.

Related Posts

There are no Magic Beans for Data Quality

Do you believe in Magic (Quadrants)?

Is your data complete and accurate, but useless to your business?

Can Enterprise-Class Solutions Ever Deliver ROI?

Selling the Business Benefits of Data Quality

The Circle of Quality

Comments

[Ken O'Connor]

Hi Jim,

I enjoyed your post - but also found your examples depressingly familiar.

I discuss this "Load and Explode" approach to data population in my blog post:

Common Enterprise wide Data Governance Issues #9: Data Migration and ETL projects are Metadata driven

Regards, Ken

[Julian Schwarzenbach]

Jim,

Another excellent post and cautionary tale.

A recent conversation of mine with a current client also fits this theme pretty well.

I am engaged on a large project, but looking at specific information aspects. One of my deliverables is a requirements spec for one of their core systems. I have already issued the first two drafts (which are pretty much complete) final version will be completed this week.

One of my key contacts had been 'got at' by a supplier who gave him a flashy demo and lots of promises and is now trying to set up a cross departmental presentation to allow the supplier to sell to a wider audience. This supplier already has another key system in the organisation which could also comply with this requirements specification.

I needed to remind him that the requirements specification provided the benchmark and provided a means for them to select the most appropriate system rather than have a supplier "sell" a possible solution.

In this case, as in many others, there is a combination of impatience (Why can't we do it now?) combined with the an overly optimistic view of what a potential system could provide.

Caveat emptor

Julian

[Jim Harris]

Thanks for your comments, Ken and Julian. Your feedback is always greatly appreciated.

@Ken — Yes, these stories are depressingly familiar, and Load and Explode seems to be a common real-world practice — even though no one would claim that it is a best practice :-)

@Julian — The Machiavellian salesperson strikes again! And he was aided, as always, by his trusted sidekicks Impatience and Overly Optimistic :-)

[Ken O'Connor]

Julian's comment highlights the challenge of "expectation management" among senior management (system purchasers).

All vendors pitch their system in glowing terms, describing the nirvana their system can deliver, a nirvana delivers the perfect results management have long wished for. Most systems deliver excellent results when perfectly populated - and this leads to the crunch question - "How is the system populated".

Julian, I suggest you provide a list of questions to your key contact to ask the supplier with the "flashy demo", starting with:
- How does data enter the system?
- What data validation is performed on data entering the system?
- What business rules are applied in the validation?
- Where did the business rules come from?
- Who owns the business rules?
- How does the data in the new system related to data in our other Enterprise systems?

The above is just a starter set off the top of my head.

Perhaps Jim, you could host a "Questions to ask suppliers with Flashy Demos" debate?

I discuss business rules further in my blog post:

Business Rules Case Study (Part 1)

Regards, Ken

[Jim Harris]

@Ken — Thanks for the follow-up comment, and I definitely agree that Questions to ask suppliers with Flashy Demos would make a great blog post debate :-)

From the LinkedIn Group for IBM InfoSphere, Thomas Gulledge commented:

“The business need, of course. What is a tool without a need? It is an academic endeavor, a science project.”

And I responded:

I definitely agree that without the business need, you have a science project and not a business-problem-solving project.

From the LinkedIn Group for Data Quality Pro.com, Duane Morrison Smith commented:

“Based on both the proliferation of tools and the continued focus on technology rather than 'real solutions' regardless of technology, it might seem as if the chicken came before the egg.

However, in light of the continued persistence of data quality issues and the fact that most of them have been around for some time I would have to give the egg the vote on this one.”

And I responded:

I vote for egg over chicken, as well (i.e., business need over technology).

But there certainly seems to be a whole lot of chicken on the menu at many organizations these days :-)

[Jim Harris]

From the LinkedIn Group for Enterprise Data Quality, Amer Malik commented:

“Why should the business need come before the data quality tool?

In the modern way of working, the right tools in the right places will ensure less problems. It's obvious that this should be the case because in this way one is mitigating any risks and potential harms to the business.

Not every one will agree with the above method, but I think there's enough experience in real life situations to warrant the data quality tool coming first - every time!”

And I responded:

Simply for the sake of argument, let's say that I accept your premise.

Doesn't the obvious next question become which data quality tool is the right tool?

I think that this is a slippery slope that inevitably leads to technology bias, where the focus on the specific functionality of the data quality tools being evaluated results in framing the objective as a technical problem requiring a technical solution, instead of a business problem requiring a business solution, which is enabled by technology.

And Amer responded:

“It should never be solely a technical solution, nor should it ever solely be a business solution.

As for your question which data quality tool is the right tool, surely it's a case of understanding the architecture, reporting requirements, technologies used, sources of data, transformations performed, volumes and finally, what is the business question. One would hope that one doesn't build information repositories without any thought for the whole end to end process these days and that concerns around data quality are a prerequisite for any implementations.”

[Jim Harris]

From the LinkedIn Group for IBM InfoSphere, Brian Caldwell commented:

“If your technology partners are innovators, then the data quality tool. Businesses have been working around poor data quality for decades, its the job of IT to ease that pain.”

And I responded:

I agree that innovative technology can help. And the data quality market continues to evolve away from esoteric technical tools and toward business-empowering suites providing robust functionality with increasingly role-based interfaces tailored to the specific needs of different users, and especially interfaces designed to better engage business people, thereby making it easier for them to leverage their business process and data expertise without being forced to be a technical guru.

However, I still believe it's necessary to avoid technology bias, where the focus on the specific functionality of the data quality tool results in framing the objective as a technical problem requiring a technical solution, instead of a business problem requiring a business solution, which is enabled by technology.