Architecture Patterns
Data architecture is not easy if the nature of the data stores in the architecture is not understood. Usually it is good to split stores with different functionality into different architectural elements; and quite often this choice is driven by the nature of the data (transactions vs reference data). A few examples of rules are below ...- Spit reference data management from managing transactions
- Split transaction data stores from business intelligence solutions like warehouses and data marts
- Split project data stores (with data that can be changed and reinterpreted) from corporate data stores where final data resides
- Split current data from archived data
Looking at these elements it is possible to start seeing patterns; e.g. the pattern around a transaction data store where the master reference data is managed separately, the BI is arranged through data marts and retention is arranged in an archive store. Creating these patterns for specific business situations helps with understanding if proposed solutions are complete, or if designers plan to cover requirements with the wrong type of store (if you have a hammer, everything looks like a nail).
Labels: architecture, master reference data, principles
posted by Evert Ruijs @ 1:12 PM
0 Comments:
Post a Comment
<< Home