Entry Point: Architecture or Crumbling Foundation

Let us talk for a moment about architecture.

Good architecture is built to last, to withstand the elements and the test of time. Good data architecture will allow you to extract data quickly, will help prevent data errors from occurring and promote easy integration of future data assets.

Bad architecture will see the following persist like vermin in your basement:

1) Increases data retrieval times;
2) Data retrieval becomes more difficult;
3) Integration and migration projects become cumbersome;
4) Fosters the spread and creation of bad data.

Soon the walls around you will begin to crumble as more and more data becomes questionable. Your users will question the data and eventually your system will become synonymous with the term “poor data quality”.

When building your data warehouse remember the following:

1) Ensure you size it properly and measure future capacity for continuous growth;
2) Bad data does occur, allow it to be cleansed by your data analysts, don’t build overly complicated data models, remember the KISS principle;
3) Improves speed to delivery and reaction time;
4) Improves query and data retrieval times.

When defining your architecture and/or database system remember the following steps to help prevent bad architecture from occurring:

1) Define the objective of the data warehouse;
2) Research the data and datasets (understand the business and it’s processes);
3) Design the data model;
4) Define the database relationships;
5) Define rules, triggers and constraints;
6) Create views and/or reports;
7) Implement it.