Kimball or Inmon in an enterprise environment
datawarehousing out of the book?
In the last few years I have seen a dozen of data warehouse projects. more than 70% were build upon the (Kimball) Bus architecture having a 2-tier layer. Most of the time build “out of the book”. With other words the architecture has not been applied to what the business needs, but how it is common to do in the field of datawarehousing. Read more…
Spaghetti code
Spaghetti
Nobody ever say so, but for so many years now I have been confronted with DWH spaghetti projects. No matter the tools used, somehow it seems an utopia to create a clear architecture / ETL / Datamodel in time.
The problems are huge. People come and go. Without a clear view of what new people have to do they start their own way with their own vision and methods. The beginning of the end. And where does it end? High and rising maintenance cost, disappointed users etc etc. Read more…
(e)DWH Architecture of the Shelf
It is such a pity that so many designers and -even worse- architects of data warehouses use only 1 architect design for all their customers. It is not called designing under architecture. There is no “one-size-fits-all” architecture for data warehouses. I can image that people still do so because of simplicity in for example implementation. That way even a non data warehouse consultant can implement a data warehouse. It however most often results in poor solutions or failed programs.
de waarde van architectuur voor beheer
Enkele praktijk ervaringen, door Henk Binnendijk
Inleiding
Kenmerkend aan een DHW / BI project is dat het dynamisch is en dat er na oplevering regelmatig om wijzigingen gevraagd wordt. De wijzigingen komen voort vanuit de business of vanuit de bron. De eerste via changes en/of requests en de tweede vaak door incidenten. In dit artikel worden ervaringen gedeeld over het continu beheren van dynamische DWH / BI omgevingen. Hoe voorkom je dat je een inflexibel en/of niet continue BI omgeving hebt?