Saturday, March 12, 2005

Oracle Customer Data Hubs Chief Defends CDH Model

There's a few articleson EWeek that just popped up about Oracle's Customer Data Hub, which has a pretty big vision and is getting some scrutiny. I've never seen an installation, or a demo, but it sounds like a great idea to me. Oracle Customer Data Hubs Chief Defends CDH Model has some great info:

Is anybody actually using this stuff out of the box, though? Or are they all building it themselves from TCA and OCO, as Zornes suggests?

There's always an element of customization. It takes a couple of years to implement this kind of thing.




Oracle Customer Data Hubs Chief Defends CDH Model




Zornes says that CDH works best in all-Oracle shops, which kind of negates the core idea of having these hubs tie together disparate systems, doesn't it? ADVERTISEMENT
[Zornes] said that if you were an Oracle customer, there's a propensity to choose our solution. We said, "Well, so?" That's OK, there's nothing wrong with that.

This is part of my view on what he said: What we're talking about is these mixed environments. The idea is that companies have customer information fragmented around the company in multiple systems.

If one of those systems happens to be an Oracle system, we get to bid on the opportunity to be that customer master, the central master.

He somehow was discounting the fact that because we have a customer master in our application system that somehow we're not a player in the [CDI] market. Our view is that Oracle is positioned beautifully for the CDI marketplace.

We have two sides to our business: our applications side, selling ERP [enterprise resource planning] and CRM [customer relationship management] systems, which requires a customer master, and since most companies have fragmented ERP systems, you have two choices: [one is to] unify around E-Business Suite.



If you're not inclined to do that, you don't have to unify around our suite, but you can unify around our data model. You don't have to implement it in the context of E-Business Suite. You can certainly implement Oracle CDH independent of [Oracle] transaction systems.

Second, with all our technology customers, one of Oracle's core messages has always been about IT consolidation and simplification. That's what people come to Oracle to do: They have 50 databases, and they want to collapse that down to one or two.

Those companies who are trying to save money on pure IT spending find this a very interesting subject. It gives them the opportunity to retire older systems, possibly. If you can have a project that protects customer data, you have the opportunity to, quote, do some consolidation.

What's the difference between Oracle's data hub and its data warehouse technology?

A data warehouse is passive and historical. A data hub is active and current. In the data hub, you actually update data. You're creating data. We want people to update data records, change relationships, update info. It's something you don't do in a data warehouse. It's a downstream system.

Another important, important fact is that a data warehouse is unidirectional. All source systems send information to this specific place. You might clean up data as you try to normalize it and get rollups as it goes into the warehouse, but what have you done to correct data in its source? Nothing.

Data warehouse users, they make their best efforts to clean up data, but the data hub is trying to correct data at its source.



That last answer is a bit scary. I'm not sure Id be ready to take the risk of blindly trusting the results of something like that.

1 Comments:

At 8:20 PM, Anonymous Brian Macdonald said...

That last answer is a bit scary. I'm not sure Id be ready to take the risk of blindly trusting the results of something like that.

I don't think the Oracle CDH requires you to blindly trust the updating of the source. There will be rules that will dictate what fields get updated.

The CDH is trying to adjust a common problem. How to deal with dirty data. As mentioned in the article, you can do it in the DW, but that still leaves the source dirty. So how do you handle dirty data when the source system doesn't enforce appropriate data entry?

Updating the source tables is viable method, but this needs to be done carefully. I think that is why a solution like the CDH is a good solution based on the subject matter. Customer Information. If you allow this process to update certain fields (i.e. State Codes) then there isn;t much risk. However, updating a customers SS# might not be as good an idea.

I also think that in order for this process to work well, you need to incorporate some type of workflow or alerting. This will allow a review of some sort to identify what changes are occuring.

This is clearly an issue that needs a good solution, and eventually it will be solved. I am glad to see vendors starting to put together a manner to fix this problem.

We will see how succesful it is in the coming years.

 

Post a Comment

Links to this post:

Create a Link

<< Home