Believe it or not, there is no way one can create a data architecture model flexible enough without a clear - and unique - understanding of the business -and what represents more the way a company uses its data than a business data model?
Some call it an ODS - Operational Data Store - a "clean" representation of the business mostly used data elements - No repetitions, clear set of rules that represent any given data entity, standard naming, and aliases - in short, the ideal representation of a company's data set.
So, creating this unique model must be the first goal of any architect, which in return provides a unified view of the data we are going to deal with on a daily basis.
But why a centralized model even before understanding how data flows through the company systems? You may say it makes no sense - but it does. As I said before it is a clean model, just like every person in the company actually sees their information. An enterprise model provides references for how data should properly be and behave, without any vices or misunderstandings.
Along with the model come the integrity and security rules that will maintain the model integrity. The model, coupled with the rules ensures that each component - or entity - will be understood individually and that we can now look at the other systems in the company to verify all inconsistencies and standard deviations.
How to Proceed - As the newcomer, the architect must first identify all elements of a company structure in terms of functions and data used, map how data is treated in each area, and what makes it correct. So it is not only the data model but a full set of elements around it. The output is a fully documented ODS. But so far you have noticed that we are not even touching Analytics, right? It is all for a reason - we can only reach good analytics results from a solid data set without any misinterpretation. Analytics under the umbrella of an enterprise model is a mere consequence.
Data Model components - We have the company hierarchy, the data sets and entities used, divided into master and non-master sets. For example, when there is a bank customer, there is the master set of data that uniquely defines a customer, plus the specific data for each of the operations and products offered; bank accounts, load data, savings data, credit information. To create a detailed model we first perform functional analysis which derives the full information flows inside the bank which leads to the complete customer structure.
For each master and specific data sets, there are rules which govern the ACID properties of that information. ACID stands for Atomicity, Consistency, Isolation, and Durability of that data structure.
We repeat the above process for each discovered entity until a core view is set. Enclosed in the enterprise model we reach the first delivery of the Polymorph method. And as we go, we put all that into a data catalog to preserve that information - or metadata.
Where and how we will store the ODS will happen after we clearly map the sources to feed the model, the volumes involved and the integration issues which will arise, not to mention the available budget. And this is where I confirm that Polymorph is way faster than anything in the market today - Polymorph is oriented from day zero to set up the data management environment as a platform, not only documentation, there is a purpose.
As we build the catalog from our analysis and modeling activities we are also tailoring a tool or set of tools to deal with the new environment - the model and its feeding ecosystem.
The diagram below serves to represent the structure of the first processes around the enterprise model.
Comments
Post a Comment