Inleiding: Of het nu een bus architectuur (BUS) of “the Corporate Information Factory” (CIF) moet zijn? Deze vraag werd me laatst gesteld. Zelf gaven ze de voorkeur aan de bus architectuur. “Waarom?” was mijn wedervraag. “Dan ziet de manager snel resultaat” was hun antwoord.
Achtergrond van architectuur principes
Het bouwen van een datawarehouse (DWH) strikt volgens de filosofie van de BUS of CIF is niet verstandig. Beide geven een concept dat geschoeid is op een algemene situatie. Echter is elke organisatie uniek. Ook de omstandigheden waaronder een DWH gebouwd wordt zijn elke keer anders. De vraag is welk uitgangspunt beide hanteren:
Inmon (CIF) zegt:
A DWH is a subject-oriented, integrated, time-variant and non-volatile collection of data in support of business/organisation’s decision making process.
Kimball (BUS) zegt:
A data warehouse is: a copy of transaction data specifically structured for query and analysis
En als we dan kijken naar de opbouw in de applicatie architectuur van beide zien we een groot verschil. Daar waar Kimball 2 stappen onderkent (stage en DWH (bestaande uit diverse DM’s) ziet Inmon er 3 (stage, DWH, DM’s)
De vragen die een Architect onderzoekt:
Terugkerend naar de vraag, welke kiezen we: Wat past er in de gegeven situatie het beste? Een Architect dient dat te onderzoeken.
Men moet zich dan bv. de levensduur van het DWH in ogenschouw nemen. Dit bepaalt de horizon van de aanpak. Van te voren is niet altijd alles te voorzien.
- Als het initiatief “lokaal” in de organisatie begint, is er dan een ambitie om door te groeien naar de gehele organisatie?
- Hoe dynamisch zijn de business vraagstukken die bedient moeten worden (m.a.w. hoe vaak wijzigen die?)
- Wat voor type informatie voorziening moet er nu en in de toekomst bedient worden?
- Hoe snel moet de informatie bij de eindgebruiker ter beschikking gesteld worden?
Pragmatisch blijven
Als men zich bovenstaande gaat afvragen, volgt al snel de conclusie dat het niet verstandig is om zomaar een keuze te maken. En als dan de keuze gemaakt is, is het zeker niet strikt noodzakelijk om het gekozen concept “volgens het boekje” te implementeren. Wees pragmatisch in de implementatie en vraag je elke keer af of datgene wat het boekje voorschrijft ook nuttig is in de specifieke situatie.
Kijk bijvoorbeeld naar de staging area . Bijna bij standaard zien we dit component in elk project voorkomen. Maar wat is nu eigenlijk de bestaansrede van dit component? Ooit begon het met het ontlasten van de bron. Dus snel een copy maken naar de staging area zodat het bronsysteem minimaal belast wordt. Maar wat nu als deze noodzaak er niet is? (denk bv aan EDI of XML messaging) Gaan we dan toch een staging area neerzetten omdat het moet?
Conclusie
De rede dat een architect er is, komt niet voort uit de techniek. Eerder is een architect er om de business vraag te vertalen naar de techniek. De architect brengt alle business requirements van nu en de toekomst in kaart. Daarna vertaald hij/zij dit naar een blauwprint (concept zoals BUS of CIF) waarvandaan een datawarehouse ontwikkeld kan worden.
