A sentiment repeated again and again related to Data (Information) Quality improvement goes like this:
“It’s a myth that Data Quality improvement is all about technology”.
In fact you see the same related to a lot of other disciplines as:
- “It’s a myth that Master Data Management is all about technology”.
- “It’s a myth that Business Intelligence is all about technology”.
- “It’s a myth that Customer Relationship Management is all about technology”.
I have a problem with that: I have never heard anyone say that DQ/MDM/BI/CRM… is all about technology and I have never seen anyone writing so.
When I make the above remark the reaction is almost always this:
“Of course not, but I have seen a lot of projects carried out as if they were all about technology – and of course they failed”.
Unquestionable true.
But the next question is then about root cause. Why did those projects seem to be all about technology? I think it was:
- Poor project management or
- Bad balance between business and IT involvement or
- Immature technology alienating business users.
In my eyes there is no myth about that Data Quality (and a lot of other things) is all about technology. It’s a myth it’s a myth.
Liliendahl on Data Quality 
It’s an interesting issue. Some people may not say that it’s all about the technology but act as if it is. I have worked on projects in which individuals’ preoccupations with PeopleSoft or whatever other app became paramount to the function of the app.
Thanks Phil. The ink wasn’t dry before you commented. Agree. Data Quality improvement isn’t all about DataFlux, driving isn’t all about Toyota (not at least these days) and so on. Sometimes someone has to learn when to start selecting the trademarks.
DQ/MDM/BI/CRM — IS — all about technology!
(Sorry, but as usual, I couldn’t help myself 🙂 )
***
Henrik,
Obviously, in all seriousness I agree with you.
It’s definitely a myth that any mythology exists claiming any enterprise information initiative is all about technology.
As for those projects that unquestionably were carried out as if they were all about technology – well, there are many lies we choose to believe that lead to project failure – especially when we focus exclusively on meeting a deadline somebody wrote in project plan.
However, lies are lies – not myths.
True myths tell meaningful stories relating important lessons – or simply provide entertainment – or both.
There is definitely nothing meaningful or entertaining about believing data quality (or anything else for that matter) is all about technology.
Best Regards,
Jim
P.S. I can’t believe Phil tweeted and commented before I did!
Jim, thanks for pointing at that it’s a myth you can use TLA’s and get away with it 🙂
Hey, you can’t win them all, man.
Now that I’m a cartoon character with superhero-like abilities, I might even start making sense.
Now let’s not get carried away, Phil!
Just because this comments section counts as our third blog and you are now a cartoon character, doesn’t mean you have superhero-like abilities . . .
Or that you could ever start making sense.
🙂
* * *
Oh, by the way – Henrik, how much do you charge for third blog hosting fees?
I can’t compete with Phil or Jim (and wouldn’t want to), but here are my two cents.
Henrik, all too often what you bemoan is true. I guess the reason for that is that for a lot of IT people it is much easier to “deal with a tool” than it is to “deal with people”. This is probably quite stereotypical, but true nonetheless.
So when starting a DQ initiative, a lot of time, energy, and management attention can be spent on selecting and implementing shelfware .. while dealing with the “root causes” of the problem can be avoided.
The trick is to move the focus away from costly tools and showing that you can reap benefits even with a pretty simple tool by dealing with the underlying issues. Not too easy …
Thorsten
P.S. Phil/Jim: I’m waiting for you to comment before the blogpost is published. Scary …
Interesting post/comments;
Quite funny on the subject actually, I saw a job advert for a ‘Data Quality Analyst’ this week. The only required skill was that you were an expert user of Trillium.
Here is my opinion on why people think it is about technology. Business initiatives like MDM/BI/DQ and the like are being presented, sold on, and driven by technology experts. Information technology has carried business forward to the point where we are the chauffeurs for change and progress. Without the ability to integrate new technologies into a business, the business fails.
In this way, I believe that these disciplines are about technology. Afterall without the technology piece there is no business piece. However, these disciplines are not exclusively about technology. The business folks need to “pony-up” and adopt technology. I’ve met my share of business folks that out right refuse to evolve and learn new technological skills.
In summary, BI/DQ/MDM and the like are not ALL about technology but they are so rooted in technology that you need to embrace technology and be willing to learn new technologies.
William,
Like your phrase “chauffers for change” – is it an original quote?
Anyway, I have to agree with Jim on this one, MDM etc. are clearly technology based and, to get the most out of them, you need to understand how to use them effectively. However, this will only identify (and possibly resolve) some of the symptoms of DQ problems, there is still a requirement to resolve the root causes of the DQ problems, which typically and people and processes.
The many small fixes required to resolve these problems are not sexy and require patience and resilience to sort out. Despite these activities being hard graft, it is essential that they are undertaken otherwise any good work with the technology tools will be ‘polluted’ by poor incoming DQ.
@Julian – That is an original, feel free to use it anytime (but I expect a royalties check!) 🙂
I hear your point about DQ being of some root cause that needs to be weeded out or the problem just returns and I agree. Not that this changes that point in anyway, BUT what are some of the “root cures”, if you will, of poor data entry (be it practice or process)? More technology improvements like UI validations or entry aids like text suggestions and drop-downs are the few that come to mind.
To me business issues are sales, budgeting, customer service and marketing. Everything else like operations and reporting are so fused with technology now that they are, in a sense, a technology issue. Although I don’t have extensive experience with MDM, let me take this theory of mine for a spin in that context. Let’s say we are driving, or chauffering, a business executive towards a list of master product entries. Does he/she know these entries off the top of their head? Most likely not. How would you “steer” them in the right direction? Probably by querying the data and beginning with a list of values? The decision of which ones are selected might even require a count of popular values? In this way, technology is the vehicle to the master data destination and the business folks are in the back seat selecting routes from the suggestions provided by his/her driver.
Maybe we are saying the same thing and the business and technology fusion is so tight that we are using different words to label the same thing? But I do believe that if you are performing a business function in front of a keyboard, it is really a technology issue. If you are using your intuition, practical operational experience or sales acumen — it’s a business issue.
Anyway, that’s my two cents. Generally that is what it’s worth too!
Thanks Phil S., Jim, Thorsten, Phil W., William, Julian for all the comments.
I guess I may add the following bullets to my list on why some projects seems to be all about technology (though never expressed to be so):
• Preoccupation with specific products / vendors
• Use of TLA’s – sorry Two- or Three-Letter Acronyms
• Lies about why unrealistic deadlines wasn’t met – lack of patience and resilience
• It is much easier to deal with a tool than it is to deal with people
• Business folks that out right refuse to learn new technological skills
PS: The Phil S. / Jim intermezzo has a side story anchored on Twitter. I’m not sure how to conclude on that.
Hi Henrik,
Interesting discussion.
We data quality professionals understand that DQ is not all about technology. We know that “a fool with a tool is still a fool”.
We know that Data Quality is a “Business Issue”. However, when one seeks to engage senior management in an organisation, they usually respond with “Our IT dept. looks after that”.
Our message does not reflect well on the “IT Dept”… If the Data Quality is poor – what has the IT dept. been doing for the past ‘n’ years? Why have they not been doing their job?
Like it or not – there is a perception among senior management, and others, that “Data Quality is all about technology” – and “perception is reality”.
One of the symptoms in the number of job ads for “Data Quality Analyst” – with the pre-req of must have “3 years experience with tool X”.
As Data Quality Professionals, we need to develop our message “in business language”. We need a message that engages both senior management AND the IT dept. We need a message that the IT Dept. can bring to senior management (if that is the only available route).
Ken
Henrik,
An underlying issue here may be the relative size of marketing budgets:
* Technology vendors have deep pockets and are able to ‘sell’ their products through numerous channels
* Data Quality experts tend to be smaller organisations/individuals with arguably less marketing clout
A busy senior manager may tend, through time pressures, to opt for what has been ‘sold’ to them through media, conferences etc. A subsequent internal project may be easier to approve for the same reasons. For these managers to attempt to undertand the wider issues and implement a suitable improvement programme will take more time and effort.
Additionally, since staff in many of these senior roles will tend to move on within 2-3 years, they will be seeking a quick success to put on their CV ready for their next role. Boy, am I getting cynical in my old age!! 🙂
Julian
Great debate here Henrik.
As you well know, I have a preoccupation with technology’s role in any Data Quality ‘solution’. My opening gambit on my last MDM series being entitled ‘MDM – It’s not about the Technology’ kinda shows where I stand.
What I find most frustrating is reading / watching (on Twitter) / listening to a number of leading analysts and industry “gurus” who constantly bang on about the latest bit of technology, or capability that XYZ software vendor has provided. The ‘noise’ in the press about Informatica and Syperian and IBM and Initiate focused predominantly on the technical capabilities that will be gained / lost by these marriages.
We need more people to talk about solutions and how we can drive companies forward, only then will the fixation on technology start to become less of a factor.
Technology is important, but as an enabler, not a leader in solution provision.
My 10 cents worth … 🙂
Thanks Ken, Julian again and Charles for making this a great debate.
I have noticed some more root causes why some Data Quality and Master Data Management projects seems to be all about technology:
• Senior management perception
• Technology vendor marketing budgets
• Analyst babble
Let’s also not forget that many of us technologists think that we can solve most problems with the right use of technology. Not that the conversation starts out that way. In the best of situations, we sit down in a room and start talking with business partners about their responsibility and the role of technology in an holistic solution that includes both business process and technical components. We draw some sort of business context diagram that shows “here’s where business units change behavior” and “here’s the new technology we’ll add to help out here.” I think the self-inflicted problem often comes in as we talk through each one of the business components.
It’s natural behavior for technologists to want to inject some kind of technical solution into most business process. It makes sense. Nearly every process can be made simpler or fully automated with enough effort. And that’s the direction that a technologist’s mind tends to drift.
So, even as we partner between business expertise and technology expertise, we suggest technical ways to solve a lot of things that would be better off without.
I’m not saying this is always the case, just that sometimes technologists dig their own holes. I know that I’ve done it before.
As a general comment I’d like to add that we should distinguish a technologist with good business savvy from a “tool jockie”. Business savvy includes the ability to take the technology and apply it IN CONTEXT to solve a business problem. A tool jockie knows how to weild his/her tool of choice to accomplish a result but lacks the ability to deliver the result to solve a problem.
A good technologist uses technology to deliver a business initiative. A good tool jockie use technology.
I have found that there are similarities with implementation of all projects and not just those related to DQ/MDM/BI/CRM. Business requirements tend to be articulated as functionality rather than goals and objectives. Now what happens is business asks for functionality and IT delivers. This ensures fast, speedy delivery so IT can get on to the next project delivering functionality. The problem is this method perpetuates the misconception that IT needs to ‘handle’ the quality of data. What needs to happen is that every project needs to start with questions geared to understanding goals, objectives, current issues, stakeholders, accountability, escalation processes, etc… This will help flush out better requirements, establish business accountability, and gradually move the organization towards management of information, process, and data as assets.
Paul, William again and Jill, thanks for adding even more sense to the debate.
I will continue to gather the root causes for why some DQ/MDM/BI/CRM/ERP/DW/SOA/ITIL/XYZ projects seems to become all about technology:
• Technologists sometimes dig their own holes when settling too much for automation
• No or too few business savvy technologists (or technology savvy business folks)
• Focus on functional requirements instead of goals and objectives
Henrik … agree, agree and agree on your bullet points. Bullet point one and three reaffirm bullet point number two and my assertion that business savvy is a distinguishing factor in this debate/discourse.
Like it or not, businessmen and women look to us technologists for guidance and direction. We need to respect that and their trust in us.
Henrik – always shaking the interesting trees, and this discussion is no exception.
To paraphrase Hedi Lamar: Technology would be awesome if it weren’t for the people. Going the opposite direction: Technology would be awesome if it weren’t for the computers.
Like all religious debates, the extent to which a believer can put himherself in the shoes of the other side will directly determine the success of their efforts in either direction.
The other side of this discussion is the belief that doing ‘more of the same’ will move us out of the current situation. Until someone figures out that the binary ‘geometry’ of the digital world needs at least two more dimensions to catch up with humans, each camp is going to be lobbing stones for a long time.
John O’
Henrik – root cause from my experience is the immaturity of technology in PIM / MDM spaces magnifies the poor project management and the requirement commitment of business and IT involvement. Right now, it is a full time job for business involvement to manage defect work arounds and spearhead basic 101 data management requirements to the COTS solution that they considered “configurations”.
We need an industry standard of minimum required qualifications and capabilities before a software solution can claim that they are a PIM or MDM solution. Any ideas?
Henrik,
This is as many have already said a good debate that has pulled out many useful ideas. I think that part of the problem is that roles within companies reflect the ‘industrial’ model – Fordism if you like – of work. Perhaps it is true that many of our business leaders are still operating from an angle of ‘clearly-defined roles’ for each cog in the machine and in the case of data we definitely do need some roles in a company to be a bit fuzzy. The idea expressed earlier of a business-savvy technologist and vice versa is a useful model for this fuzzy sort of roles. I think it is true that most people at work like to know what they are required to do and business people don’t do data (they should) and techies are not brought up to want to know (or even care) what’s in the carefully installed virtual idea that is a database sitting within the context of a database server etc etc. Companies need to adapt (from the top-down) otherwise the whole point is missed, and provide data governance strategies that make it clear that someone DOES have to care about what’s in the database. However, like in my main speciality (I’m I suppose a techno-savvy Learning and Development specialist), business leaders still don’t get it about data and don’t pay them enough attention, after all the data don’t contribute to the bottom line…
Tom
“Fordism” … I like that! I think this is really something that this discussion and ones like it skim over.
The business “leaders” I meet are not remotely interested in “techie” stuff. Which is one the center stones of the fault that most technical projects are built on.
A lot of “techie” people I meet are, however, at least trying to get the business context.
I don’t meanto point fingers, because no one role is at fault.
Personally I think it is “our” responsibility as business savvy technologist to chauffer those that do not see the inherent dependence of business on technology to the correct destination.
In my humble (believe it or not) there is no such thing as a “business issue” or a “technology issue”, they are so codependent there is no problem that doesn’t belong in both domains.
This is just a really good string. I actually linked to it on my post today.
@Tom – Maybe our tendency to specialize is a result of Scientific Management and Frederick Tayloy/Henry Ford?
I didn’t think of that but it’s a potential lineage.
@Phil – I think that is true – Unfortunately, all data don’t just come in black! If data and data management are important then we need to think about how we can prepare people entering jobs for the increasingly data and information bound workplace – wherever that is in our increasingly connected world until such a time as that they fall seamlesssly into the background
Tom
Phil, I’m afraid I’m the recruiter responsible for the ‘Trillium expert’ job advert, or one of them anyway.
I have been in this game long enough to know (and have tried to convince enough hiring managers of the fact) that a good ‘person’ is much better than an average person who knows a tool well. I have had a very real work example recently, but that’s another story.
However there have always been examples of when an organisation has a heavy investment in a particular product and then when the vendor’s consultants have left the building, of there being no one left who really knows how to use it.
That is the case in this particular example; they really need someone who can mentor the DQ team in how to get the best out of the Trillium product suite. They have spent their money (rightly or wrongly) and need to get pay back. There will be other roles where more generic data architecture skills will be a good fit, but that is not the case this time. Sorry!
Jackie thanks for joining. It looks like your experience on root causes are close to my initial bullet points. More industry standards may also in my eyes be one of the ways forward for aligning business and technology.
Also thanks to you John – as always an excellent perspective from you.
William, Tom, Phil S. and Mark, the discussion on mixed skills ranging from business domain knowledge to specific tool skills covered by the same person is indeed very interesting and close to me, as I have always strived to be such a person.
Being a Data Quality professional may be achieved by coming from the business side or the technology side of practice. But more important in my eyes is the question whether you have made serious attempts and succeeded in understanding the side from where you didn’t start.
Mark – thanks for the insight.
I completely empathise with the example you give and I’ve previously been on both sides of this knowledge transfer issue. I’ve often found that with DQ tools in particular there is a fair amount of pressure to demonstrate the ROI of the toolset, and this ROI isn’t going to completely maximised without people who know how to utilise the technology.
Regards
Phil
@Phil This has always been one of my arguments within a company – there is still not enough attention given to knowledge transfer either for specific skills such as the ‘Trillium’ example given above or job roles when people leave, move on or are ejected through redundancy. I was made redundant as director of education (a software company) 15 months ago and the company also took out 4 data expert roles, several technical writers and 25% of the Knowledge and Learning Department. We were not contributing to the bottom line – after all we only trained people and looked after data! Tom
Just to get some silly SQL in:
SELECT MAX(IRONY)
FROM MyLastPostsLastSentence
Tom
Odin the All-father with his Ravens? I don’t recall their names, one began with the letter H, the other with the letter M….
Ellie, Odin it is and the two ravens Huginn (from Old Norse “thought”) and Muninn (Old Norse “memory” or “mind”).
Yes, Thought and Memory. Thank you for answering my question, and for leaving comments open on this article. You are an alert and responsive blogger as well as a Data Quality expert.
I am a former Data Governess, umm, Manager of Data Governance, although I’m not representing myself in my official capacity as such. It is quite easy for that to happen on your site, as it is not a chore to read at all!
I have sent this to Mythbusters for resolution. Can’t wait for a great show!
😉