Blog Post

Data Warehouse Maturity Model

,

I have talked about the Business Intelligence Maturity Model (see Business Intelligence Maturity Assessment), but I wanted to dig further into one area and talk about the Data Warehouse Maturity Model.  The graphic below, from Wayne Eckerson, is very accurate based on my dozens of interactions with clients:

200411_034_1

Business value increases as you move along the stages.  Most clients I have seen are between the child and teenager years, with a surprising number still stuck in the infant stage.

Stage 1 – Prenatal; Structure: Management Reports; Scope: System; Executive Perception: Cost Center.  This is simply canned static reports that come from the source systems (i.e ERP, CRM, etc).  These reports are usually printed or emailed to a bunch of employees on a regular basis.  If the end-user requests custom reports, it is up to IT to create these reports within the source system, which usually has very limited capabilities for doing so.  And IT usually is backed up in filling these requests, frustrating the users.

Stage 2 – Infant; Structure: Spreadmarts; Scope: Individual; Executive Perception: Inform Executives.  Those frustrated users from the previous stage (who are usually business analysts or power users) take matters into their own hands and circumvent IT by extracting data from the source systems and loading it into spreadsheets or desktop databases.  These are like personal, isolated data marts that don’t align with any other data marts.  Because spreadsheets are easy and quick to create, they spread like weeds.  I have seem some companies with thousands of these spreadsheets.  They prevent companies from having accurate and consistent reports, but they are very difficult to eliminate as you can imagine.

Stage 3 – Child; Structure: Data Marts; Scope: Department; Executive Perception: Empower Knowledge Workers.  This stage is when departments see the need to give all business users timely data, not just the business analysts and executives.  A data mart is a shared database that usually includes one subject area (finance, sales, etc) that is tailored to meet the needs of one department (see Data Warehouse vs Data Mart).  From the data mart an SSAS cube may be built, and the business user will be given the use of a reporting tool to go against the cube or data mart.  Many times the data mart is in a star schema format.  But data marts fall prey to the same problems that afflict spreadmarts: each data mart has its own definitions and rules and extracts data directly from source systems.  These independent data marts are great at supporting local needs, but their data can’t be aggregated to support cross-departmental analysis.

Stage 4 – Teenager; Structure: Data Warehouses; Scope: Division; Executive Perception: Monitor Business Processes.  Data warehouses are a way to integrate data marts without jeopardizing local autonomy.  After a company builds a bunch of data marts, they recognize the need to standardize definitions, rules, and dimensions to prevent integration problems later on.  The most common way to standardize data marts is to create a centralized data warehouse with dependent data marts built from the data warehouse.  This is usually called a hub-and-spoke data warehouse.  A data warehouse encourages deeper levels of analysis because users can now submit queries across multiple subject areas, such as finance and operations, and gain new insights not possible with single-subject data marts.

Stage 5 – Adult; Structure: Enterprise DW; Scope: Enterprise; Executive Perception: Drive the Business.  Just like the problem of having overlapping and inconsistent data caused by spreadmarts and multiple independent data marts, a large company can have a similar problem with multiple data warehouses.  Many organizations today have multiple data warehouses acquired through internal development, mergers or acquisitions, creating barriers to the free flow of information within and between business groups and the processes they manage.  The solution is to create an enterprise data warehouse (EDW) that will be the single version of the truth.  This EDW serves as an integration machine that continuously consolidates all other analytic structures into itself.

Stage 6 – Sage; Structure: BI Services; Scope: Inter-Enterprise; Executive Perception: Drive the Market.  At this stage you are extending and integrating the value of a EDW by opening the EDW to customers and suppliers to drive new market opportunities.  Customers and suppliers are provided simple yet powerful interactive reporting tools to compare and benchmark their activity and performance to other groups across a multitude of dimensions.  At the same time, EDW development teams are turning analytical data and BI functionality into Web services that developers — both internal and external to the organization — can leverage with proper authorization. The advent of BI services turns the EDW and its applications into a market-wide utility that can be readily embedded into any application.

I would probably add a stage 7 dealing with SQL Server Analysis Services (SSAS) data mining.  SSAS features nine different data mining algorithms that looks for specific types of patterns in trends in order to make predictions about your data.

Whether you already exhibit the characteristics of a sage or you’re still trying to hurdle the gulf between the infant and child stages, this maturity model can provide guidance and perspective as you continue your journey.  The model can show you where you are, how far you’ve come and where you need to go.  It provides guideposts to help keep you sane and calm amidst the chaos and strife we contend with each day.

More info:

Gauge Your Data Warehouse Maturity

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating