In mijn vorige blogs heb je kunnen lezen, wat Big Data is en hoe je het kunt herkennen, de verschillende type databases en hoe zij hun data opslaan en welke spelers er op de markt zijn en hoe je hieruit een keuze kunt maken. In deze blog wil ik een start maken met het uitleggen van BI Architectuur (de grondleggers) en waarom deze architectuur zo is opgebouwd.
Architectuur
Vanuit BI en Big Data is het voor de organisatie belangrijk om te wetenwaar Big Data een plaats krijgt. Hiermee wordt bedoeld waar en hoe het gaat bijdragen in de bedrijfsvoering. Om dit goed te kunnen beschrijven is een IT Architectuur noodzakelijk. In deze blog gaan we niet heel diep in op de verschillende architecturen, ik wil alleen de samenhang van deze architecturen en de noodzaak hiervan beschrijven.
IT Architectuur
IT Architectuur is het beschrijven van de samenhang tussen bedrijfsstrategie, IT strategie, rollen, informatie voorziening en infrastructuur. Bij het beschrijven/modelleren van architectuur staat de onderlinge communicatie en relatie (samenhang) centraal (zie figuur 1).
![Big Data - deel 4: Architectuur - Bluefrog (1) Big Data - deel 4: Architectuur - Bluefrog (1)](https://i0.wp.com/www.bluefrog.nl/wp-content/uploads/2020/07/denkmodel_architectuur_2.png)
Informatie architectuur
In deze blogs wordt dan ook vooral ingegaan op de informatie architectuur. De informatie architectuur beschrijft de communicatie van systemen en de gegevens modellen. De informatie architectuur dient dan ook als basis te dienen om BI met succes te kunnen realiseren binnen organisatie(s). Informatie Model dient eenvolledigebeeld(model) weer te geven van de hierboven genoemde componenten. In figuur 1 is het informatie model van een website gemodelleerd. Let wel, een model is een weergave van de werkelijkheid en dient begrijpbaar en overdraagbaar te zijn.
Een goed beschreven/gemodelleerde informatie architectuur voorkomt:
- onvoldoende datakwaliteit;
- beperkte integratie van verschillende systemen;
- beperkte aanleveringen van data;
- infrastructuur niet afgestemd op de oplossing;
- systemen ondersteunen onvoldoende de bedrijfsprocessen;
- schaduw IT.
Voor meer informatie:
- (DAMA)https://technicspub.com/dmbok/
- (Archi / TOGAF)http://blog.goodelearning.com/subject-areas/togaf/togaf-vs-archimate-what-are-the-differences/
![Big Data - deel 4: Architectuur - Bluefrog (2) Big Data - deel 4: Architectuur - Bluefrog (2)](https://i0.wp.com/www.bluefrog.nl/wp-content/uploads/2020/07/information_architectuur.png)
BI Architectuur
De BI architectuur richt zich alleen op een klein maar belangrijk onderdeel van de informatie architectuur en is in de meeste organisaties niet meer weg te denken. Binnen de BI Architectuur worden alle processen, rollen en informatie stromen beschreven welke nodig zijn om BI te kunnen realiseren binnen organisatie(s). In tegenstelling tot de IT en Informatie Architectuur welke 100% maatwerk is, kun je bestaande BI Architecturen adopteren en implementeren. Binnen de BI Architectuur zijn er verschillende goeroe’s die op basis van hun visie de informatie architectuur voor BI hebben beschreven.
Deze goeroes zijn:
- Ralph Kimball (Kimball Bus);
- Bill Immon (Corporate Information Factory);
- Dan Linstedt (Data Vault).
Kimball Bus
De Kimball bus is de meeste simpele architectuur voor het starten van een Data Warehouse in een statische omgeving. De Kimball architectuur was oorspronkelijk ontwikkeld om de performance van rapportages te verbeteren en de bronsystemen te ontlasten. De Kimball architectuur bestaat uit twee lagen (zie figuur 3):
- Staging Area:1 op 1 kopie van de bron op een aparte database;
- Data Mart Area:Historische, vraag georiënteerde laag.
![Big Data - deel 4: Architectuur - Bluefrog (3) Big Data - deel 4: Architectuur - Bluefrog (3)](https://i0.wp.com/www.bluefrog.nl/wp-content/uploads/2020/07/Kimball_Bus-1024x484.png)
Daarnaast is het belangrijk om te weten dat de Kimbal (bus) volledig is geadopteerd door Microsoft in hun beleving van een DWH. De stermodellen die Kimbal gebruikt in de Data Marts worden nog steeds gebruikt door de andere goeroes.
Corporate Information Factory
Bill Immon heeft een variant bedacht op de Kimball Architecture. Namelijk een laag tussen de staging en de Data Marts. Deze laag wordt het “Operationele Data Store” of wel de historische integratie laag. Deze laag behoud de logica van de bron en probeert op deze wijze gelijkwaardige informatie aan elkaar te koppelen. Met als resultaat een datamodel dat geschikt is om Data Marts uit af te leiden. (zie figuur 4).
![Big Data - deel 4: Architectuur - Bluefrog (4) Big Data - deel 4: Architectuur - Bluefrog (4)](https://i0.wp.com/www.bluefrog.nl/wp-content/uploads/2020/07/Inmon_Architectuur-1024x548.png)
Data Vault
De architectuur van Dan Linstedt lijkt erg veel op die van Bill Inmon. Behalve dat het data model is afgestemd op de terminologie van de organisatie. Dit levert als voordeel op dat het model getoetst kan worden in de organisatie of deze voldoet. Daarnaast houdt deze architectuur rekening met Big Data (ongestructureerd/semi gestructureerde data). Deze worden opgeslagen (wanneer het waardevol is) in de “Raw Vault”. De Business Vault is hier ook bij gekomen om de informatie te tonen vanuit het oogpunt van de “Real life world”.
![Big Data - deel 4: Architectuur - Bluefrog (5) Big Data - deel 4: Architectuur - Bluefrog (5)](https://i0.wp.com/www.bluefrog.nl/wp-content/uploads/2020/07/Data_Vault-1024x545.png)
Vergelijking van de BI/DWH Architecturen
De flexibiliteit en voorspelbaarheid van de verschillende architecturen onderscheiden zich van rechtlijnig tot flexibel. In de tabel hieronder staat beschreven welke architectuur het meest geschikt is voor een Agile omgeving.
Architectuur | Voordelen | Nadelen |
---|---|---|
Kimball Bus | – Snel op te zetten; – Lage initiële kosten; – Techniek onafhankelijk. | – Geen corporate informatie; – Beperkte Informatie beschikbaar vooreindgebruikers; – Self Service BI niet mogelijk; – Changes worden steedsduurder (doorloop tijd); – Is niet geschikt voor Big Data; – Is niet geschikt voor Mining. |
Corporate Information Factory | – Integraal data model; – Geschikt voor Data Mining; – Techniek onafhankelijk | – Self Service BI niet mogelijk; – Changes worden steeds duurder (doorloop tijd); – Is niet geschikt voor Big Data. |
Enterprise Data Warehouse | – Snel op te zetten; – Integraal data model; – Geschikt voor Data Mining; – Geschikt voor Scrum/Agile teams; – Genereerbaar Template based extraction; – Hoge vorm vanstandaardisatie. | – Hoge initiële kosten – Werkt het beste direct tegen de database aan. |
Conclusie
Voordat je begint met Big Data in je organisatie is het handig om te zorgen dat het aansluit op bestaande (BI) architectuur principes.Voor BI hebben bepaalde goeroes al bedacht hoe je BI generiek kan opzetten in de verschillende smaken. De keuze van de smaak is afhankelijk van de compliciteit, omvang en variatie van de leverende systemen. Naarmate de organisatie Agile en flexibel wil zijn zal er sneller gekozen worden voor een Data Vault implementatie.