Your CIO has asked you to design a data warehouse to support the analytical needs of your Organization. At first this seems like a pretty straightforward request. But then after much due diligence, talking to different vendors and browsing Web sites and knowledge databases on the subject you find yourself more than a little confused. There are many different alternative architectures and implementation approaches that organizations have adopted. There is much disagreement on the pros and cons of one approach versus another, Industry experts often disagree with one another. Does this mean that any approach is OK? Are there any pitfalls if you choose the wrong approach, and what are the implications for your organization if you choose one approach over another? This article attempts to put some context around the confusion of picking the best architecture and approach and provides several considerations you should ponder to help you make the best choice for your organization.
Recap on Alternative BI Architectures
If you look at the different approaches that organizations have adopted when architecting and building business intelligence (BI) infrastructure, the solutions typically contain one or more of the following components:
- A distributed architecture where the integration of data is maintained separately (either logically or physically) from the analytical architecture components.
- A single database solution that supports both the data integration and analytical requirements for the organization.
- Staging databases. This is a term often used inconsistently to identify either temporary data structures or database layers used to feed analytical databases. Staging Databases can be persistent or temporary in nature.
- Normalized, denormalized or combinations of different modeling approaches across or within the different layers of the architecture.
- Single versus multiple database solutions and heterogeneous versus homogenous database solutions.
- Lots of terms that mean different things depending on who you are talking to: data warehouse, data mart, operational data store, staging database and so on.
Without having a clearly defined architecture and defining a consistent set of terminology, it should be no surprise that there is much confusion regarding this subject as well as different opinions on how you should implement a solution for your organization. So with all this information at your fingertips, where do you start? Does it matter if you choose one path versus another? Choosing the incorrect architecture could have long-term implications to your organization. As with any IT solution, a BI architecture should be driven by the business requirements, but for a BI architecture to be truly successful, you must look beyond the short term needs for your organization and focus also on the long-term goals.
Choosing the Best Architecture - Key Considerations
When choosing the best architecture for your BI solution, you must focus on both the short-term requirements and long-term goals of the organization. With this in mind, what are the key considerations for choosing the best architecture and approach?
-
Has the scope of the effort been clearly defined and thought out? I.e., are you building a solution to support the requirements of a department or the foundation for an enterprise effort that must extend to support future requirements for other parts of the organization? If your focus is on a departmental solution, then often a simpler architecture and approach may suffice. But if you are striving toward a longer-term enterprise solution, then the architecture should be designed to accommodate this. The latter choice should consider both architectural options as well as alignment with organizational and IT current strategies and future vision.
-
Scope and complexity. Enterprise solutions typically have multiple database layers that separate the integration layer of the data from the analytical layer. The former layers are often called data warehouses or staging areas and may be temporary or persistent in nature. However the implementation approaches (as opposed to the choice of words) is most important here.
