The intersection between HR strategy and HR technology

, ,

Data Hubs versus Business Intelligence

systematicHR Avatar

I keep seeing organizations that try to use their data warehouse platforms as data hubs.  While on the surface this might seem like a good idea, it really might not be depending on your utilization of each.  The data warehouse serves primarily as a business intelligence and analytics tool.  If implemented correctly, it contains vast amounts of data from many disparate HR sources and therefore, it’s a good assumption that perhaps this might be used as the integration engine for HR as well.  After all, HR usually has way too many interfaces sitting around requiring constant maintenance.  If you could perform all integration out of a single platform rather than maintaining one of those octopus-like diagrams, all the better.

The truth of the matter is that data warehouses are inherently bad at being data hubs.  An essential part of the data warehouse is the ETL engine.  ETL stands for Extract, Translate, Load, and it’s the translate part that gives us problems.  When the translations occur, what is actually happening (simplistically) is the data goes through a transformation so that when you report in the end stat of a data warehouse the data definitions are the same.  The transformation is really an alteration of the data so that analytics are made simpler and possible at the same time.  However, transformed data does not really work well for integration.

Let’s take salary grades as an example.  When you do a global analysis of salaries, you would probably load in global employee salaries, currency conversion rates, and then perform a calculation to convert the data into the home currency.  The report then might look at the distribution of salaries across several bands.  These bands however, have been transformed into global bands as opposed to using the home country’s salary grades.  In many cases, the original salary grades may not have gotten into the data warehouse intact.  (just an example I thought of off the top of my head).

I would suggest that to be a true data hub, you would want to have the original data from the original system.  Let’s say that you need global employee data from many sources to load into a single global succession system.  Not only will you be taking employee indicative data, but you’ll want performance scores, education, goals, etc…  Once again, the problem with a data warehouse here is that performance scores in each country may utilize different rating scales, etc.  The normalized data out of a data warehouse may not be suitable for the succession application depending on the decisions you make when you implement.

The alternative is to use what is usually called the ODS, or the Operational Data Store.  The ODS often exists within the DW application, but is a loading area (after the E in ETL, but before the TL).  The ODS is not ideal because it’s really just a storage tank before translation, but does hold untransformed data from all the systems.  While not intended as an interface engine, its tables could be used for it (I suppose), but the actual transformed data tables are simply not appropriate for use as an interface engine in my opinion.

Tagged in :

systematicHR Avatar

3 responses to “Data Hubs versus Business Intelligence”

  1. Tony Johnson Avatar

    I agree with much of what is said in this article. Our company sells performance dashboard software and we regularly talk to companies who are going to invest a lot in a BI warehouse solution and want dashboard after. In many cases they could save a lot of money and more importantly maintain original data by using a product that can pull data from many original sources and combine them to create meaningfull KPI’s. Our product has a built in snapshot system which saves all KPI’s and data so comparatives can be shown without disturbing original sources.

  2. George Hudgens Avatar
    George Hudgens

    Very good post.

    Another perspective: the HR ODS/DataHub can serve to insulate multiple external software vendors from each other and insulate other internal functions from having to deal directly with HR’s vendors. The ODS does not need to have every data element, instead use the 80/20 rule and use it as a clearinghouse for the most commonly used elements. The hub-and-spoke will save repeating the same common integration transformations. The ODS can also insulate your integrations from many (but not all) changes and upgrades to the transactional systems. I agree the modeling of an ODS needs to be distinct from data warehouse techniques, but the ODS can have some added transformations to extend usability. The more hybrid your systems, the more the data hub makes sense.

    On the fly integration is great for many things but in a large company performance is a challenge, especially if you trying to get executives to use them. 25 seconds waiting for a query to patch together data from 3-4 databases can be all it takes to kill adoption.

    Bottomline is that the best approach is probably a mix of methods.

  3. […] HR JUNE 25, 2009 Data Hubs versus Business Intelligence The alternative is to use what is usually called the ODS, or the Operational Data Store.  The […]