OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] RE: A Two Day Workshop for Software Architects

[ Lists Home | Date Index | Thread Index ]

> From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]

<snip/>

> A data warehouse solves the problem by creating a central server 
> for the storage of common data in an agreed upon common format that 
> is optimal for querying and doing common tasks.  A good example 
> is analysis.  Many enterprises contribute data to a statistical 
> system used to make forecasts about business conditions and needs 
> for resources.  This warehouse would not be useful for actually 
> doing the business of the business but is for managing the business. 
> Many can't see the difference or understand that the warehouse 
> may not be a common repository for all business information, that 
> in fact, multiple warehouses may be needed.

VITAL used a much richer model for guiding data warehousing efforts than
those that have become the norm. It was really about a hub and spoke model
for sharing shared information, not a single monolithic repository for
querying and analysis.

VITAL used manufacturing and commerce as an analogy. Factories produce goods
that are exchanged with distributors, who use central warehouses for
inventory. The distributors provide the goods to retail outlets, who
naturally may get goods from other sources, as well. Consumers shop at the
retail outlets, not at the distributor or factory.

In an enterprise, you tend to have information producers and information
consumers. VITAL said, define that information that must be shared across
the enterprise. Define who are the legitimate producers of that data. HR,
for instance, would be the owners of data pertinent to an employee's status
as an employee. You don't want a free-for-all where anyone can define that
info. The data warehouse is a central distribution center for shared
information, but individual groups will need info beyond that, and they may
even need a different view of that data. So they pull it into their domain,
transform it as needed, relate to other data they own, but they don't create
data that they don't legitimately own. That leads to data redundancies,
which leads to disconnects between systems, which leads to inconsistent
answers that can negatively impact decision making, or lead to a costly
foul-up in a business process. I witnessed some of those first-hand. I
specifically remember a VP going on a tirade threatening that "heads would
roll" because he got two different reports from two different IT groups that
directly contradicted each other on sales figures, and no one could tell him
why.

It's an interesting -- and powerful -- model. But of course, in the real
world, things aren't all black and white. You tackle what you can and don't
fret that you haven't achieved perfection.




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS