Blog | Apr 8, 2013

BI Best Practices Series (Part 3 of 6):  Think Big, Start Small ...

Kevin ORourke -TriCore Solutions LLCKevin ORourke

Best Practices in BI: Think Big, Start Small.  Ensuring a Successful BI / Big Data Project

Part 3 of 6: BI Data Architecture Overview


Why Build a Data Architecture for Reporting and Analytics? 

Generally, organizations evolve to a data architecture based on apparent need.  An organization will experience many challenges in meeting consumer demand for its own information.  Consequentially, several manual reporting preparation processes provides static reports which are analytical dead ends. 

Typically, some of the drivers which force organizations to look for alternative information solutions are as follows:

Impact of queries on the transactional business system may be too great;

Data may be too complex for retrieval;

Too much data to needed to give adequate response times;

Data summarization may be needed first;

Data may be in separate data areas or systems and cannot be joined;

Data residing in multiple sources may be inconsistent;

v  Data needs manual preparation and transformation before it can be used by other groups;

Transactional business systems are (usually) unsuitable for reporting or analysis;

Information systems have completely different design philosophies as compared to transactional systems.

Industry Approach to Data Warehousing

With an industry perspective, there are 5 design approaches to data architectures typically found within the industry.

 describe the image

  1. Independent Data Marts (13%). Functional data marts are built independently and are not consolidated via common or shared business dimensions.  This approach does not promote reusability and does not provide a holistic view of the organization;

  2. Hub & Spoke Architecture (39%).  Widely adopted approach in a service-oriented model.  The ODS provides a consolidated view of transactional data.  Data from the ODS is moved to the data warehouse.  The data warehouse here is more service-oriented with limited business user access.  The data warehouse sources data to each individual data mart.  All data marts are conformed via shared dimensions.  The Operational Data Store (ODS) is an optional data asset.

  3. Data Mart Bus Architecture (27%).  Data marts are built with common or shared subject areas (business dimensions) which are developed once and reused where necessary;

  4. Centralized Data Warehouse (17%).  Monolith approach creates a single data warehouse to service the entire business user base.  A general lack of modular design makes this more complex structurally and more difficult to maintain.  Since all users access the DW, user access is often contentious versus distributed.

  5. Federated Model (4%).  Federated means the data stays where it is.  Several versions of federation include federation of one or more business system data sets, or multiple information data sets (ODS, DW, DM); A federated model is a viable alternative if business and performance requirements allow.  Limitations also may include data relationships, business rules not matching and longer response times.  

It is important to note that often an organization has a hybrid data warehousing solution, not strictly adhering to the types above.  Organizations may also evolve to migrate from certain types, for example moving from a Centralized Data Warehouse to a Hub and Spoke architecture.


Thank you for reading Part 2 of our BI Best Practices Series Think Big, Start Small.  Please refer to the links below for other Parts in the series:

We hope you enjoy other topics in the series as follows:

Part 1 of 6: Introduction

Part 2 of 6: Business Intelligence Fundamentals

Part 3 of 6: Common Data Architectures Used Within BI Platforms

Part 4 of 6: Organizational Readiness

Part 5 of 6: BI Strategy Roadmaps

Part 6 of 6: Emerging Technologies