Hi Jim,

"I too recognize the value of leaving room in methodologies for innovation, but I must point out that leaving out so much fundamental information about the ODS has done the field - in my experience - significant harm. Specifically:

In practice, "ODS" appears (again, in my unscientific survey) to be an undefined architectural entity. Some clients have built "ODSs" for operational reporting. Some for the maintenance of "master data"

(dimension authorities). Some for the ETL process itself. Some retain full history there, others don't. You name it - we've all seen it:

simple staging areas, integrated & non-integrated, 30 days history, 5 years history, reporting, cleansing, subject aligned, departmentally aligned, normalized, semi-normalized. Never dimensional though - this

is a new one. And many hybrids of the above. Unfortunately, I have

yet to see one that I thought was optimally engineered for whatever its specific tasks were. The ODS, too often in practice, appears close to chaotic. It has become a convenient container for whatever functionality has been left out of the other CIF components.

And this, I submit, is a pity."

--Jim Stagnitto

Actually, I agree that we would all be better off if we had more solid architectures to work off. Perhaps some of us might even use them...;-)

But who is going to create these? And who benefits from these? IT people want someone to go out and create such things for free and then to give them away for free as well......eg. How many people on this list have participated in a DW project with no formal methodology in place to guide them along the build??

Also, methodologies often tend to become a replacement for 'thinking'.

Example, Method 1 at Anderson Consulting. The concept being that you could hand Method 1 to someone with 2-5 years experience and they would be able to build anything because the methodology was so good.....

Where is the middle ground? I believe designers of IT systems should get reasonable training and apply the grey matter to the problem at hand....and today we have the best facilities ever available to support designers of systems, yet I see the same mistakes Frederick Brooks described from 1965...amazing...

Vendors...

At the end of the day, the vendors need to make profit. The best way to make a good margin is by 'differentiation'. 'Being Different'.

A vendor selling commodities is taking a very dangerous path.

Vendors don't want 'standards and agreements' on how things should be done so that customers can turn their products into commodities and drive down their prices.

This is why we have no 'standard' unix, no standard C, no standard C++ and why we will have no standard Java in the future. Remember all the hype around 'unix and C' will become the standard and replace the mainframe.

The vendors are motivated to produce 'tweak' their products to 'look different' and the space of ODS, DW, BI etc is not immune to this 'tweaking'.

If you talk to IBM, NCR, Oracle and Microsoft you will see how little similarity they have in what they say the BI world should look like.

For a start, each of them says their products are the be all end all and should be at the center of everything...;-)

Just as an aside about definitions of ODSs. PwC also decided to give the ODS their own definition as the archival/integration layer with no near real time object in the picture.....now try explaining that one to a bunch of big companies...

Best Regards

Peter Nolan

Data Warehousing Consultant

Mobile: +353 879 581 732