What Is a Single Source of Truth (SSOT) and Why Do You Need One?

The first iteration of your shiny new data warehouse is up and running, and folks are loving it. For example, Marketing is thrilled at how easy it is to pull up the data that used to eat up their time as they copied and pasted countless columns from a variety of spreadsheets.

And then one day, the head of Marketing rips your head off in a Zoom call. "Your data is crap!" she says.

You frantically dig into your new dashboards. After hours of painful conversations, double checking your SQL, and trying not to give in to the feeling that all your hard work is about to go down the drain, the truth gradually emerges.

Your data is fine. Marketing freaked out because the numbers on one of the dashboards you set up for them doesn't match the numbers in a report generated by your company's financial software—a report they forgot to tell you they use. And the reason the numbers don't match is that the dashboard and the report aren't using the same data and definitions.

Welcome to the complexities of a Single Source of Truth (SSOT).

You probably already know that if you're going to level up your company's data-driven decision-making, you need to use your data warehouse to create an SSOT. But if you don't understand the ins and outs of SSOT, you may end up getting burned.

In this article, we'll help you understand how to ensure you create an SSOT that will help your company glean insights from its data and that will build users' confidence in your data solution.

What is a single source of truth (SSOT)?

Odds are your company has data scattered across many different systems. Sales uses Salesforce heavily, Marketing grooves on Hubspot, the accountants spend their days in your finance software, your support staff live in the help desk and your SaaS software. Each system focuses on a different set of priorities and follows a different set of rules. As a result, each system provides a partial window into your company's operations.

A Single Source of Truth (SSOT) is a data warehouse or some other repository that gives users a complete, authoritative picture of your company.

A great SSOT has 3 features:

• A centralized, standardized repository of data
• A centralized, standardized definition of key metrics
• A process for governing the SSOT

Must have: A centralized, standardized repository of data

The most basic thing an SSOT does is create a centralized copy of all the relevant data. Here's what that entails:

1. Data that provides a 360° view of your company and its users

One of the biggest payoffs of having an SSOT is that it allows you to see a comprehensive picture of everything your company knows about topics that are critical to its success. If your data warehouse overlooks some crucial component of your company—say, for example, product data—it may be a great repository, but it’s not an SSOT.

If your data warehouse overlooks some crucial component of your company—say, for example, product data—it may be a great repository, but it’s not an SSOT.

This is particularly important if you're a struggling startup in a highly competitive field. The better you understand your users, the more likely you're going to uncover insights that can give you a competitive advantage or give you a heads up when you're running into trouble.

For example, if some users are getting increasingly frustrated with your company, their irritation might show up on social media. Or it might show up in the amount and kinds of complaints your customer service people are getting. Or it might show up in the number and frequency of online order cancellations or returns. If you can only analyze those data sources in isolation, you might miss an important trend.

2. Easy access to the data users should have when they need it

Say your Marketing team really needs info that's stored in your product database. If Marketing hits the product database too hard or they start mucking about in it, they could easily cause major headaches for Operations. So, Operations keeps that database locked down and Marketing can only occasionally manage to wheedle the data they need.

Not only does that make it difficult for Marketing and Operations to do their jobs and work together effectively, but it also creates data silos. Instead of using the latest data about your customers, Marketing operates off spreadsheets that slowly become out of date. Maybe they even start storing new nuggets of data they glean about users in those spreadsheets. Multiply this across several departments, and over time you end up with a snarled rats nest of half-baked data that folks use to make decisions.

In contrast, if you create a process to move a copy of Product's database into a centralized repository, everyone can work off of the same data without jeopardizing Operations. The moral of the story: with an SSOT, users can access all the data they need without ever posing a risk to any mission-critical database.

3. Everyone using the same standardized fields

Even if grabbing data from fields across several systems isn't too much of a headache, there's still a good chance you're going to run into a buzzsaw of dueling definitions.

For example, what is the "close date" for a particular purchase? Is it the date the signed contract was submitted to DocuSign? Is it the closed-won date in Salesforce? Is it the date you bill the client through Stripe? The date the payment shows up in your company's bank account? Or when—according to your company's accounting rules—the payment shows up on your company's books? 

Complicating matters even further, all of those date fields appear in separate software, but they may also appear together under a single Salesforce opportunity. What’s more, they all reflect a close date at least to some degree, but they definitely aren’t equivalent.

Odds are different users will understand “close date” differently depending on which system they use to run a report and which field they pull into their reporting. That’s not ideal when multiple departments rely on the same metric to inform their strategy and planning.

That's why one of the most important features of a good SSOT system is that it standardizes the fields you use to report data. The end result: when users throughout the business analyze a particular metric, they all draw from the same field regardless of which systems they use, ensuring that they are comparing apples to apples.

Some people who use the term SSOT use it to refer only to where a central copy of the data is stored. But folks like myself think it's also useful to include metrics.

If you're an analyst who works at a company that has more than a handful of employees, I probably don't have to convince you that it's a good idea to ensure everyone is on the same page when it comes to how metrics are defined. But why include your metrics in your SSOT?

First, it's an easy way to ensure that everyone is using the same metrics. If someone is talking about "churn rate," you want to make sure that everyone is using that term based on the same set of assumptions and calculations. 

And if the high-level metrics are being used to drive your company's decisions, folks are gonna want to be able to slice and dice data throughout the company based on those metrics. So it stands to reason that you would want to house those metrics in the same place as the company's data.

Second, it's a good way to reinforce your standardized definitions. When there are competing definitions in your company, it's worthwhile to come to a decision about which definition your company will use because that definition is likely central to one or more metrics. Centralizing your storage of metrics is likely to encourage more conversations about the definitions behind your metrics.

Mind you, just because you're putting high-level metrics in your SSOT doesn't mean you need to put every metric there. Your Operations team, for example, may have a whole bunch of low-level performance metrics that no one else is ever going to care about. So you don't need to spend time setting them up in your SSOT.

If you're like many analysts, when you hear the word "governance," your skin may crawl. That's because if you've read any articles about data governance, you’re probably overwhelmed by the absurd number of details they threw at you about the rules and regulations you should create in order to "govern" how your SSOT is set up.

But unless you work for a giant multinational, you don't need governance that's quite that fancy. All you need to be able to do is come up with some simple, easy to understand answers for the following questions:

• Who should have access to which segments of data? You almost certainly have at least some data that not everyone can or should have access to. So before you let users go to town, figure out what needs to be locked down.
• Who gets to weigh in and who gets to decide about data definitions?
• What's the process for changing the rules of the road?

None of this needs to be super complicated—especially when you are building the first version of your SSOT. Work with a small group of high-level folks to come up with some basic rules, then iterate from there.

The one part of Governance that can get a little tricky for an analyst is recognizing that governance is inherently political.

It's very tempting to think that if folks just have good quality data, they'll make smart decisions that leave out high-drama confrontations, bickering, backstabbing, etc.

If only.

SSOT isn't magic. Politics won’t disappear because you have an SSOT or a governance strategy.

But a well designed SSOT can act like a flashlight. It can help shine a light on ongoing political issues—including political problems that could complicate your analytical work—and push the Higher Ups to resolve some of them.

Conclusion

Creating an SSOT isn't the most fun work you'll ever do as an analyst. But if you set it up properly, an SSOT can serve as a foundation for developing a kick ass data-driven culture that will help your company thrive.