The Myth of Expertise Transference
During the long course of my professional life, I’ve observed a disturbing trend. People sometimes claim expertise in one field based on experience in another. This is a fallacious and deceitful claim. I have extensive experience in visual design, but I cannot claim expertise in architecture. Any building that I designed would most certainly crumble around me. I’m a skilled teacher, but this does not qualify me as a psychotherapist. That hasn’t stopped me from occasionally giving advice to friends, but without charge, which probably matches its worth. Although these fields of endeavor overlap in some ways, expertise in one does not convey expertise in another. No concert violinist would claim the transfer of that virtuosity to the saxophone, but IT professionals sometimes make claims that are every bit as audacious.
The field of business intelligence (BI) provides striking examples of this trend. When BI initially emerged, data warehousing was the pre-existing field of endeavor that supplied BI with most of its initial workers and technologies. Years earlier, relational database theory and management supplied most of the initial workers and technologies of data warehousing. Today, the field of endeavor that goes by such names as analytics, data science, data visualization, and performance management, is the domain of workers and technologies that were previously associated with BI and in many cases still are. I know several individuals who began their careers as experts in relational databases, who then moved into data warehousing, and then into BI, and finally into analytics and its kin without actually developing expertise in any but their initial field of endeavor. Instead, they made names for themselves in relational databases or data warehousing, and then transferred that moniker to each subsequent field of endeavor with little study or experience, and thus little skill. Many of the people who give keynotes today at BI/Analytics/Big Data conferences and who write white papers on related topics fall into this category. This is one of the reasons why domains related to analytics are so confusing, hype-filled, and poorly realized.
The skill sets that were needed to design and build relational databases or even data warehouses are significantly different from those that are needed for expert data sensemaking. I know this quite well, because early in my career I studied and taught relationship database design, but when data warehousing emerged, I found that most of my skills were not transferable. I learned this the hard way by initially trying to build data warehouses using my relational database skills and failed miserably. Over the course of years, I retooled. When BI stole the limelight from data warehousing, I became fascinated by its intentions and vision, defined initially by Howard Dresner as “concepts and methods to improve business decision making by using fact-based support systems.†This harkened back to my first full-time job in IT, when I worked in the “Decision Support†group of a large semiconductor company. Even though I began my career helping people use data to support better decisions, when I began focusing on BI, relatively little that I had learned about data warehousing was useful. I had to shift my technology-centric focus back to a perspective that was line with my university studies in the social sciences. I needed to understand the human brain, the process of decision making, and the ways that technologies could assist in this essentially human activity. This took years and led me to entirely new areas of study, including human-computer interface design. Later, when I narrowed my focus to data visualization, once again I had to humbly accept the position of a novice. My previous studies and diverse areas of experience contributed a great deal to the eventual richness of my expertise in data visualization, but it did not bestow upon me the mantel of expertise. That, I had to earn through diligent study and years of deliberate practice. It is by these same diligent means that I continue to deepen and broaden my data visualization expertise today.
Many of those who think themselves data visualization experts today base this belief primarily on experience in graphic design. While it is true that expertise in graphic design can contribute to the development of expertise in data visualization, there is a great deal more to learn and practice if you wish to understand and effectively practice data visualization. As an expert in data visualization, I have as much of a right to claim expertise in graphic design as an expert graphic designer can rightfully claim expertise in data visualization, which is very little.
I’m tempted to say that “Expertise isn’t what it used to be.†It certainly seems that people make claims of expertise today with little actual knowledge or experience, but I suppose this might have always been so. I doubt it, however, for I believe that the ready availability of information on the web has inclined people to think that expertise is equally accessible. It isn’t. Whereas information can be looked up easily and quickly, expertise requires effort and time. It’s worthy of both.
Take care,
19 Comments on “The Myth of Expertise Transference”
One thing to keep in mind is that each of these technologies is a castle of sand, built on top of a previous castle built of sand. There are many folks in the IT world with a job title of ‘enterprise architect’ or ‘software engineer’, but these folks are nothing like real architects and engineers. A Structural Engineer would be misrepresenting his skills if he presented himself as an Electrical Engineer. He might have some of the same basic fundamental skills, but Engineers carry with them an expectation that they have a body of well-researched knowledge in how Things Are Done. Even with all of this, we still have bridges collapse and buildings sink (http://sf.curbed.com/2016/8/1/12341914/millennium-tower-sinking).
Modern Business IT has nothing like the rigors of an Engineering discipline, but many folks like to pretend that it does. In some edge cases there is more rigor (real-time systems for missiles and planes), but generally, we have a large group of people that have no real structure in place. Instead we get things like ITIL and the SDLC and other management consultant insanities, which deal with pretty much everything except the *actual work* that is being done and the *actual product* which is delivered!
Relational Database technology never reached its potential, mostly due to the failures of education of application & database developers, vendors who focus on supporting the latest fad, and some poor decisions made in the SQL language due to physical limitations of the hardware at the time. One can see in the ‘new’ NoSQL database technologies the same problems that caused RDBMS’ to be invented in the first place.
Data Warehousing was built on top of these flawed platforms, fell into the Kimball/Inmon wars (often because of the flaws in RDBMS), and to this day continues to struggle to really add value to most organizations.
BI (or ‘reporting’) seemed to have developed alongside of data warehousing, and it’s in worse shape than even that field. The vast majority of business reporting these days seems to be performed by one of the following individuals:
– Someone in the business unit, by extracting their data from whatever BI system they are given and loading it into MS Excel.
– Someone who used to work in the business unit, learned enough SQL to be dangerous, possibly moved to IT, and has no interest in learning any more than they have to
– A cheap contractor who follows the letter of the ‘requirements’ and no more, and again, has no interest in learning any more than they have to.
The revival of “User Experience” consultants is slowly making inroads in some IT organizations, but reporting is almost always last to get any kind of assistance there.
Generally, I think that we really need to start just knocking down those castles and building on a firm foundation. Capturing data with actual business meaning, modeling it relationally to describe what *actually* happens in the business, and then feeding data to analysts with training in data sense making, so that decision-makers can use that data to make changes and implement programs that will improve the business’ decisions.
Nate,
Beautifully said. Your assessment is painfully accurate. I agree that it’s time to tear down the sand castles and build on a new and firm foundation.
It seems like “expertise transference” is easier to get away with in some fields than others.
The examples used of visual designers being unable to claim expertise in architecture, teachers being unable to claim expertise in psychotherapy, and concert violinists being unable to claim expertise in the saxophone, are telling. Each of these areas areas of expertise are easy to define, either through common sense (in the case of the musician) or some sort regulation of professions with a formalised process and set of criteria for induction. (Architects and psychotherapists, for instance, are regulated professions in Ontario, my home province. I imagine they’re regulated in many other jurisdictions, too.)
Once we turn our attention to fields like BI, data visualisation, and big data, things get a lot more confusing. Why? There’s no single source of authority to tell us who can and cannot call themselves, say, a BI expert, because there’s no commonly-accepted definition of what BI is.
The solution, in my mind, is to strive for clear definitions of what BI or big data or visualisation actually means. That’s not an easy task, especially since these fields are continually changing, but it’s something to strive for. At least we’d then have a better of what to expect from a keynote speaker at the next BI conference we attend!
Bravo, Stephen. You’ve identified a major problem in my/our profession, one that has been with us for decades, and shows no sign of abating.
I agree with the great majority of your observations, and with Nate’s comments, with one substantial caveat: relational databases were never a solution to the problem of helping make sense out of data. A properly normalized relational database is a wonderful thing for helping a DBMS guarantee that data anomalies won’t be created, but it’s horribly bad at helping people approach and understand that data.
Data warehousing became popular largely because of the difficulties inherent in making relational data make sense to people lacking substantial relational technical skills. And data warehousing failed to deliver on its promises for its corruption from an effort to make data more understandable to a monumental, and monstrous, imperative to acquire and control all of an organization’s data before letting anyone try to understand it.
I’ve been dismayed to see the degree to which the same people and companies that made a mess out of data sense-making are prominent in the current environment. These are the included in people Stephen writes about, only it’s worse: they claim expertise in new areas based upon their dominant presence in a field with truly abysmal failure as its primary legacy. Yet the media fetes them because, well, the media is clueless.
I recently moved to Ottawa, Canada’s national capitol, and have found to my dismay that the government is run almost exclusively on a management by Gartner basis with a healthy dose of TDWI thrown in when “experts” are brought in to show the bright new future. The same people that wasted years and years are being looked to for a new direction, leading to the same programs of big-this, enterprise-that, consolidate everything, that fail to recognize that making sense out of data comes first, for everyone instead of being an end-point activity that happens with all the “real” work has prepared the way.
On the other end of the scale, we see the emergence of personal, intimate tools making it possible for individual people to produce charts, graphs, tables, and other useful data analyses. However, these same tools make it possible to create truly spectacular, visually stunning things that, although they contain data, are more art than informative, see: https://storify.com/ChrisLuv/a-discussion-on-edgae-cases-in-tableau?es_p=2270932 and https://public.tableau.com/profile/vizde7382#!/vizhome/FROZENscript/FrozenViz
Sadly, the more gloriously visually stunning are increasingly promoted and praised as exemplars to be admired and emulated. This leads to the promulgation of bad advice, and the suppression of good principles and examples that could otherwise help people learn and develop the expertise that Stephen points out is missing. I fear that we’re only going to see the sins of the past repeated.
Well said Stephen, people believe a few minutes or days googling a topic makes them an expert in it.
Chris,
It appears that you don’t actually disagree with anything that I wrote in this blog piece, for I did not say that relational databases were ever a “solution to the problem of helping people makes sense out of data.”
Do you know of any decent, semi-objective articles or books which go over the evolution of the field of BI, from relational databases to data warehousing to today’s analytics? I have seen some of this evolution in my (short) 10-year career so far but I would be interested in getting a good overview of the 30 years that preceded it!
Thanks in advance,
Nicolas
Nicolas,
I’m not aware of any articles or books that cover the history of BI in this way. The subject matter doesn’t warrant a book, in my opinion, but an article would be useful. Unfortunately, most of the people who know this history are the same people who have created the myths that misrepresent it.
Nicholas,
From a database-only perspective, one thing to try is to go to Academia and see what was taught for years. Dr. Jeff Ullman at Stanford wrote some books in the late 80’s “Principles of Database & Knowledge-Base Systems”. There’s a lot of in-the-weeds computer science in those books, but they go through a lot about the evolution of data management systems. I believe much of this material is available in their updated book. You can find more info about it here: http://infolab.stanford.edu/~ullman/dscb.html . It is not for the faint of heart. But chapter 1 is available for free and gives a great overview of the evolution of database systems. http://infolab.stanford.edu/~ullman/fcdb/ch1.pdf
I don’t know of any comparable studies done in the BI or visualization space.
Thanks both!
I think there’s scope for a lot of interesting scholarship here actually… For example, Brinton’s “Graphic methods for presenting facts” from 1914 includes a chapter entitled “Curves for the executive” which includes a recognisable description of data warehousing and visualization for business intelligence purposes, all using pen and paper. I’m curious about how widely-adopted such methods were and when, and how they were displaced by more electronic methods… Brinton’s book is available online here: https://archive.org/stream/graphicmethodsf00bringoog#page/n274/mode/2up
Nate’s first reply was, as you stated, “beautifully said” and just completely spot on. Your conclusion from that, otoh, “it’s time to tear down the sand castles and build on a new and firm foundation.”, is completely spot off. No, we don’t need a “new and firm foundation”. We need to finally build that firm foundation that has always been there ever since 1969/1970 (The relational model of data).
Chris Gerrard,
“fail to recognize that making sense out of data comes first”
No. What comes first is designing data structures to represent particular meanings ***and not lose track/sight of those meanings*** (that’s where the real problem is). Were that done, there simply wouldn’t be any problem named “making sense of data”. We would all know upfront what the data means.
From my observations, it’s easier to claim data visualization expertise (falsely) simply because most people are not good judges of the quality of the visualization. It is often not evident at a glance that the visualization is poorly designed for the decision-making task at hand. Therefore, people who are expert graphic designers can make a good looking chart that is not helpful at all, but it will be received well since it is visually appealing. This feedback then propagates. More bad visualizations, but more evidence that the designer is good at them.
The inverse is not true though. Poor graphic and visual design is evident right away to most observers, and the feedback accurately reflects the quality of the work.
Erwin,
Data sensemaking does not benefit from the relational data model. Dr. Codd’s rules for relational modeling were designed to improve efficiencies in data processing and storage, not to make data more intelligible. In fact, structuring data relationally makes the work of data sensemaking more difficult, which is why Dr. Kimball created dimensional data modeling and also why an entire industry of middleware products emerged to hide the complexities of relational models.
You might be interested to know that a fellow named Fabian Pascal, who is apparently an expert in relational data modeling, has taken issue with the statement that I made above in my response to Erwin. Here’s what he had to say:
“‘Dr. Codd’s rules for relational modeling were designed to improve efficiencies in data processing and storage.’
This reflects total ignorance of the RDM and its objectives. The RDM support of physical independence separates logical models from implementation, such that vendors can do whatever they damn please to maximize performance without disrupting apps and users. Whoever does not understand this should not utter anything about the RDM.
‘…not to make data more intelligible.’
In a sense you are correct: his intention was certainly not to make data more intelligible TO THOSE FOR WHOM INTELLIGIBILITY is impossible–a majority of data management professionals.”
In response to him, I wrote the following:
“The primary benefit derived from the relational data model that drove it’s adoption was the efficiency in storage and processing that it promoted through the reduction of redundancy. My blog is not concerned with the intricacies of RDM. The point I was making is that expertise in RDM does not create expertise in data sensemaking. Their purposes and the skills that are needed to pursue them are quite different. My readers won’t benefit from a nuanced debate about relational theory. In other words, what concerns you as an expert in RDM does not concern my readers.”
Mr. Pascal is rather upset that I am not allowing him free rein is posting comments on this site. I trust that most of you have no difficulty understanding my concern. Mr. Pascal poignantly illustrates the technology-centric perspective that separates most information technology professionals from the real world of human needs on which their work should focus.
To Erwin Smout, Fabian Pascal, and anyone else who believes that I have misrepresented the relational data model (RDM) by saying that it was “designed to improve efficiencies in data processing and storage,” I should not have presented this as Dr. Codd’s intentions. The point of my original blog post above has nothing to do with the intentions of RDM, so please accept my apology and quit trying to hijack the discussion that I am trying to encourage by changing the topic.
I’m sorry about stirring the pot with my first comment! I only meant to say that in the business world, we need to do better in every area, and it starts at the end, with the people who are actually trying to make decisions.
Nate,
You’re not guilty of stirring the pot. Those who objected to your comment don’t understand or appreciate our concerns. They apparently live in a world that is out of touch with the true value and use of data–that is, to promote understanding, leading to better decisions and actions. While it might be true that the practice of relational data modeling has never fulfilled its potential, the failures of the information age will not be resolved by fixing this. They are living in a dream in which Codd is God.
In response to my own inquiry (which perhaps interests only me, in which case I apologize for taking up space in the comments) I finally did stumble across an article which gives a century-long perspective: http://www.sciencedirect.com/science/article/pii/S037722171400664X