Monday, August 20, 2007
The Data Repository Layer
In charting our shop's path to Fusion Applications, the plan for the Data Repository layer probably represents the most radical break with Oracle's overall direction. The Oracle product targeted for this layer is Master Data Management ("MDM"), formerly known as Data Hubs. However, we already have a data warehouse in our shop - I'm not sure MDM buys us much additional value.
Don't get me wrong: I like the concept of MDM. Centralizing all my data from all my data sources in a single, standardized repository used to drive all my reporting and business intelligence is a great concept. It not only makes my reporting and business intelligence consistent (I'll get the same answer to the same question, regardless of who asks, it can also help improve the performance of my transactional database.
The cause of my departure from Oracle's overall direction is really pretty simple: at JPL, I think we've already built our data repository in the form of a data warehouse. Our data warehouse centralizes and standardizes data from multiple data sources, and it drives our reporting and business intelligence. So, at the moment, I'm not too sure what additional value I'll get from MDM.
As you review the roadmap for this layer of the architecture, you'll see that I do have an initiative planned to compare our data warehouse with MDM. If MDM adds additional value, we should find it as part of that initiative. It may turn out that we do need to replace our data warehouse with MDM. It may also be that MDM and our data warehouse compliment each other, so we'll need both. There is also the challenge of integrating our data warehouse with the other components and architectural layers - it may be a fairly complex and expensive challenge.
As always, your situation and decisions may play out differently. I would strongly encourage you to become familiar with MDM before deciding if to use the product or how to use the product.
Note that I've also included an initiative to investigate the Oracle Common Object model. As Oracle develops standard enterprise business objects, those objects will appear through Oracle's ERP and CRM products. We'll need to track this development and possibly emulate those objects in our data repository in order to integrate well with the Oracle reporting and business intelligence tools.
NEXT UP: The Process Integration Layer