Concluding my thoughts on how to reuse enterprise data...

 

Transparency and Visibility
Transaction systems are designed to successfully execute business operations, but the transaction data is rarely engineered to support the types of reporting and analysis that business analysts use.

Informed decision-making relies on more comprehensive views of data; these views are materialized through the data marts and other analytical environments populated via a data warehouse.  Many business decisions hinge on having a large degree of visibility into the knowledge that resides in both operational and analytical systems.  For example, understanding climatic risks is necessary in order to purchase reinsurance.  The same holds true for analyses of other commonly-used concepts.

Enabling a high degree of visibility into any commonly-used data concept means more than just data accessibility. Integration of similar data concepts from across different data sources requires transparency – processes that ensure the data sources are compatible from a structural and semantic perspective. It is through this characteristic that one can determine whether two “policy” data sets refer to the same core concept and are therefore can be combined. Reliability and Consistency
When evaluating data transparency, the concept (and context) of “primary use” must also be considered.  While primary use of a data set can be defined as “first in order,” it can also be defined as “first or highest in rank of importance.”  Naturally, the business application that originates the data is the primary consumer; however, that application may not be the most important use of the data. If the alternate uses are high in rank of importance, they are also primary consumers. Therefore, it is critical to ensure that measured levels of data reliability and consistency are sufficient to meet all business process needs.  

This suggests a different way of thinking about soliciting, documenting, and adhering to the data set’s quality requirements.  The typical approach to defining data quality requirements only looks at the functional needs of the business process application being designed.  In turn the data quality requirements are only defined to meet an acute functional need.  In most cases, though, no one considers how data created by one application will be used by other applications.  But if the data sets are actually intended to be used by additional alternate business applications, ensuring trust in the reliability and consistency of the data becomes an organizational imperative.

It is incumbent upon the system designers to talk to any potential data consumer, to identify their information needs, and to implement the inspection, monitoring, and corrective actions associated with enterprise data quality expectations.  Establishing good data quality practices and supporting those practices with the right tools and techniques is imperative to prevent confused semantics, inconsistency, and incoherence.