The Owner Affinity Model for Information Management very simply means, keep the information close to the owner.  The Owner Affinity Model seeks to resolve the problem of quality and semantics that occurs with a centralised Data Warehouse.

The Owner Affinity Model states the following:

In order to avoid issues of loss of quality or semantics of data that occurs as data is copied farther from data owner, keep the data close to the owner and make the data available for queries by consuming systems.

The loss of data quality and reliability is a symptom of an environment where too much reliance for sharing of data is placed on a central Data Warehouse.  As the data is transformed and transferred about, the semantics or understanding of the data deteriorates.

The problem with the central Data Warehouse

In a central Data Warehouse strategy, data is copied from operational systems to a shared place so that is can be used by many others without having to go back to the source.

Of course, if there is some very well understood data that is common to a majority of your LOB‘s, of course, put it in a common repository or Data Warehouse.  But in this case, knowledge of how to compute the common data from local source data is also widely understood.  The responsibility to derive the common data from local data lies within each LOB system.  One example of where the information being shared is simple or homogenous is the General Ledger.  In this case, a central store works great.  Every system sending data in can do so easily because the definition of a Journal Entry is widely understood and agreed upon.

But what happens when you start loading up the Data Warehouse with complex data that is unique in each business unit or function.  As the data becomes more complex, the difficulty in collecting it and using it in a meaningful and reliable way increases.  Typically owners of a data warehouse merely know where they got the data.  But rarely do they understand the specific business meaning of the data in the way those supporting or using the system that is the original source (the owners) understand the data.

In real life

Yesterday I was in an enterprise architecture meeting discussing an integration challenge for a risk system.  The risk system provides data that is used by line of business (LOB) systems to make business decisions.

The issue was disagreement between one service consumer group who wanted the provider system to make data available for query or retrieval on demand.  The provider and enterprise architects preferred a more “loosely coupled” model where data is distributed via an ETL tool and consuming systems effectively need to keep their own copy.  In this case though, the consuming system did not want to maintain their own copy of a large amount of shared data.

To avoid coupling these two systems together by having the data consuming system access information directly from the data providing system, it was recommended to use the Data Warehouse.

But, history shows sharing complex data that is not common to all LOB’s through a Data Warehouse if fraught.  Typically, meaning of the data is lost as it is translated from the source system into a common data model.  Furthermore, with each hop, the data looses quality and traceability back to the form which was originally understood in the source.

In order to explain why I was so against resolving our problem by sending the data to the central Data Warehouse, I developed the Owner Affinity Model.

I Recommend you keep data close to the Owner

So, if you want to avoid the issues described above, I recommend you follow the Owner Affinity Model and keep the data close to source and make it available for consuming systems to access on demand.