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.

With bad architecture, the following will persist like vermin in your basement:

1. Data retrieval times will increase
2. Data retrieval will become more difficult
3. The integration and migration of projects will become cumbersome
4. The creation and spread of bad data will be more likely

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.”

More Read

Measuring and improving an effective and efficient warranty process

Copulas and Wall Street

Micro vs. Macro Information Retrieval

5 Steps to Setting your Big Data Goals

TwitChimp.com Beta Announced: Seeking early adopters who use Twitter to gain insights

When building your data warehouse, remember to:

1. Ensure you size it properly and measure future capacity for continuous growth
2. If bad data does occur, have your data analysts cleanse it; and don’t build overly complicated data models — remember the KISS principle
3. Improve speed to delivery and reaction time
4. Improve 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 its 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.