Truth - Part I

nvisia is an award-winning software development partner driving competitive edge for clients.

“A single fact can spoil a good argument.” – Anonymous

One of the responsibilities of an enterprise data architect is to understand fact, or “truth”. There is a subtle difference between these two terms, at least when used here. There may be multiple facts that lead to something undisputed, but those facts, although true, are true within a specific context. Multiple facts about something may be referenced by a software application, but at an enterprise level when all software and business processes are taken into account, it is often the case that those facts provide a limited, or slightly different, perspective.

Before getting into the details behind fact and truth, and the value that truth provides the enterprise (discussed in the second installment of this series), it makes sense to discuss three different phrases commonly used in this space. While attending RSNA 2009, due to its footprint on the trade show floor, I could not help noticing a vendor display that offered “Single Source of Truth” as their trademark slogan. “Single Source of Truth” trademarked? Hasn’t this expression been used, especially by architects, for years? Let’s talk about this. In my discussions with executives at a healthcare insurance client, I recall them referring to a similarly-sounding expression phrased “Single Version of the Truth”, a term that was later used interchangeably with “Single Source of Data”.

Single Source of Truth. Single Version of the Truth. Single Source of Data. Do all of these phrases mean the same thing? Same difference, you say, right? Well, no, not exactly. I offer this discussion on these differences here because it is so common to hear these terms used interchangeably. While the executives cited may have had some of the same concepts in mind, at least on occasion, what they communicated often turned out to be different than what was apparently intended, and because there are different approaches to “truth” there existed the need to come to an agreement on terminology.

“Single Source of Data” (SSOD) typically indicates that every data element is stored exactly once. In other words, every data element is stored in no more than a single row (record or tuple) of a single database table. Conceptually, this might look similar to the first diagram below. In this diagram, you will notice that although there are multiple databases across the enterprise, the truth that a particular process needs to access can only be found in one location.

 
Single Source of Data

“Single Version of the Truth” (SVOT) typically indicates that multiple versions of the truth can exist within an organization. One of the purposes behind a data warehousing initiative is to resolve these versions of the truth and to provide an “official” version of truth to the organization. One common reason multiple versions of the truth can exist is because such data can reside in organizational silos. Bill Inmon, the “father of data warehousing”, has eloquently described this concept in material he has written over the years.

Conceptually, this looks something like the second diagram below. You will notice that the truth an arbitrary process needs to access can only be found in one location, just as with SSOD, but with SVOT there exists additional logic between this truth and the source databases. This logic resolves any disputes these individual transactional databases might have with each other, and the resolution is stored in the data warehouse for the business process to utilize.


Single Version of the Truth

“Single Source of Truth” (SSOT) is essentially synonymous with SSOD. However, once the term “truth” is referenced, it is usually the case that a data warehouse is involved, because while truth is assumed when a data element can only be found in one place, this assumption does not exist when a data element can be found in multiple places. The distinction that can be made between SSOT and SVOT is that the former can involve linkages to data elements by reference in other locales. When such data elements are updated, propagation is initiated across the enterprise so that duplicate data elements are always updated, resulting in the same “truth” regardless of which element is subsequently read by processes.

Now, as we move further away from the original concept presented, SSOD, there are more variations of methods to achieve truth, but conceptually SSOT looks akin to the third diagram below. As with SVOT, additional logic sits on top of the data in order to resolve differences, but multiple versions of truth do not exist in the original data. In this case, when the truth for a particular data element is updated, logic is initiated to propagate this data to other locales where this data element might also be stored, so that while there is a single source of truth, this truth might exist in multiple places where an arbitrary business process can access it.


Single Source of Truth

Given the history of SSOD, SVOT, and SSOT, make sure you clarify what is meant by any expressions that you use so that opportunities for miscommunication are minimized and progress toward business value can be initiated.

Related Articles