TDWI | Training & Research | Business Intelligence, Analytics, Big Data, Data Warehousing

The ABCs of a Data-Centric Culture (Part 2 in a Series)

To become a data-centric enterprise, you must first recognize what counterproductive behaviors you'll need to eliminate.

• By Jonathan Fowler
• April 3, 2018

In Part 1, we imagined a conversation at Acme Widget Corporation, a company interested in advanced business intelligence efforts. Unfortunately, its culture favors action over thought.

That is understandable, to a point. Stepping back from revenue-producing activity is difficult. When billable work and production-level deliverables are the number one priority in a company, any work that takes resources off those tasks is suspect. BI makes many promises for production-level deliverables. It is easy to want to jump ahead to that point without doing the tedious work of setting the foundation.

What exactly should the foundation be? You need a data-centric culture that addresses everyone's role in creating, impacting, and consuming the organization's data assets. Of course, any culture is specific to a company, but there are common elements we can identify. These elements are the major characteristics of a data-centric culture.

Let's look at some examples in each area that indicate an enterprise is not data-centric.

Access

Every organization has data silos, some more than others. An organization without a data-centric culture often has far too many. Imagine a typical situation in a company without some type of common environment. HR has its own system and database, Sales has a CRM it's been using for years, executives share Excel worksheets via email, the Warehouse group runs its own logistics system, Finance collaborates on Google Sheets, and somewhere individual Access databases or PDF files are used without any backup. When it comes time to share data, each unit has to figure out how to export its data in a format understandable to others. That time-consuming process is repeated for each department and each consolidated report.

Standards are critical to understanding an organization's data assets, but many enterprises think they can go without. Without standards, each attempt at crafting and viewing anything is sidelined by trying to understand the basics: What do these schemas mean? How does this system organize its tables versus that one? Who wrote this SQL query and what does this stored procedure do? If someone did take time to formulate standards, perhaps they were inconsistently adopted across different units in the organization. Maybe those units developed their own standards and did not share with others.

Buy-In

It may be true that executives love your dashboards, but if dashboards are the extent to which executives interact with data assets, they aren't part of (and certainly aren't driving) a data-centric culture. Executives must understand that data is the company's greatest asset and they can lead the charge to spread that understanding across the company. No matter how much a department or individual may advocate for a particular change or approach, if the company leadership does not see the value of its data, these best practices will not take root.

Courage

Without the courage to embrace a data-centric culture, you can get caught in a vicious cycle. There is never enough time to fix data validation or ETL issues or take a holistic look at what you're doing. Instead, a stream of ad hoc requests and issues are boiling under the surface; they are kicked down the road to some unknown future date "when we have time."

Addressing these underlying issues each time an ad hoc request arises takes more time than spending the time to correct problems before the project begins. However, in a culture that glorifies billable hours over internal maintenance, the plea to follow best practices falls on deaf ears.

Documentation

Relegating data and BI to the IT department is perhaps the biggest mistake an organization can make. It is akin to thinking a software package can solve all your enterprise's problems magically.

Technology enables problem-solving but doesn't do it alone. Likewise, IT enables the rest of the organization to function but doesn't unilaterally solve issues. A developer in the IT unit may do great work but not have the insight about the users' desired results that a subject matter expert or end user holds.

Trusting in an isolated unit or package may also mean there is very little documentation (if any) produced collaboratively. This is an extension of the ad hoc environment and enables that environment. When there is no plan, it is much easier to shoot from the hip and justify whatever happens along the way. This also reduces accountability. Whoever happens to be developing a report or dashboard has both very little direction and a lot of latitude to do whatever he or she sees fit. When it comes back to the end user, the likelihood of failure is substantial and the credibility of that developer or unit is diminished.

Empowerment

BI software is great. It does amazing things. Your enterprise may believe an analytics package offers a silver bullet that will change your organization for the better. That's tempting.

However, analytics packages won't fix your bad data. In fact, they can make the effects of bad data worse. Beyond that, the package your organization chooses might not even be appropriate for the job. I've seen companies get sold on a great sales pitch from a software company and spend an unbelievable amount of time and money trying to fit their bad data into a package that wasn't right for their situation. You wouldn't buy a car without first learning how to drive and making sure it fits your needs, so why would you invest in a software package without performing the same due diligence.

A Look Ahead

In Part 3, we will examine the other side of this matrix and outline best practices for a data-centric culture.