Wat is een data architectuur?

Afhankelijk van de grootte van je organisatie is er vaak al dan niet bewust nagedacht over hoe data opgeslagen en verwerkt wordt. Misschien is er met het oog op datakwaliteit binnen jouw organisatie al een architectuur voor opgezet en zijn er processen voor ingericht.

Ook als je dat niet bewust hebt gedaan, is er sprake van een architectuur. Je hebt waarschijnlijk een mappenstructuur en hanteert bepaalde definities.

Een goede data architectuur legt de basis voor beheersbare data-processen en kwalitatief goede data. Zo’n architectuur wordt in de ideale situatie opgesteld door (een team van) Data Architecten. Maar wat doen die precies?

Wat doet een Architect in het data/IT domein?

Architectuur in het data/IT domein is een diffuse en brede term. Functietitels die je vaak ziet hebben vaak een term ervoor, zoals Solution Architect, Enterprise Architect, of Data Architect.

Wat elk van deze rollen met elkaar gemeen heeft, is dat de architect uitspraken doet over blauwdrukken, richtlijnen en beslissingen die genomen worden op een bepaald niveau in je organisatie.

Zo doet een Solution Architect een uitspraak over hoe een bepaalde solution (denk aan een softwareoplossing) geïmplementeerd wordt binnen een organisatie. Hoe zijn de interfaces tussen deze solution en de rest van de IT architectuur van de organisatie, en binnen de solution, welke oplossingsrichtingen voor problemen hebben hier de voorkeur?

Een Architect levert uiteindelijk systeemplaten op, richtlijnen en documenten, waarmee de organisatie en vooral Data Engineers verder kunnen.

Een data architectuur bouwen? Het is nét een huis!

Het werk van een Architect in het data/IT domein is vergelijkbaar met de rol van een architect als je een huis of gebouw wil laten bouwen. Je hebt een idee van wat je wil (een huis…) en ook van wat je er ongeveer van wil (woonkamer, 3 slaapkamers, 2 verdiepingen, een garage) maar daar houdt je kennis ook wel mee op.

Een architect kan dit vertalen naar een concreet plan waarin uitgelegd wordt hoe zo’n huis gebouwd kan worden, rekening houdend met je wensen en eisen. Vervolgens gaat een aannemer met deze plannen aan de slag om het huis ook daadwerkelijk te bouwen.

Het ‘bouwen’ is wat de Data Engineers doen, of een System Integrator. Het ‘ontwerpen’ is wat de Architect doet.

Om de analogie van het bouwen er in te houden, zou een architect van een huis bijvoorbeeld een Solution Architect zijn (de oplossing voor het vraagstuk ‘wonen’). Die Architect moet weer werken binnen het kader van een bestemmingsplan.

Zo’n bestemmingsplan wordt weer opgesteld vanuit een ander architectuurdomein – de gemeente wil in zijn ruimtelijke plannen hier een woonwijk hebben, met bepaalde kenmerken. Iemand die dat ontwerpt, zou in het IT landschap weer vergelijkbaar zijn met een domeinarchitect. Zo stapelen de niveaus binnen architectuur zich op.

Kijk op architectuur: ideologie versus pragmatiek

Een goede Architect kan een balans slaan tussen de wens om zaken te structureren en ordenen (= ideologisch) en om zaken voor elkaar te krijgen (= pragmatisch).

Het ontwerp, de architectuur, beschrijft de ideologie van wat de Architect voor ogen heeft dat er binnen zijn scope wordt gerealiseerd. Vervolgens worden er binnen die scope ook zaken ontwikkeld en opgeleverd.

Over het algemeen levert een Data Engineer een ontwerp op, op basis van de gegeven architectuur, hoe hij of zij een vraagstuk wil oplossen. Afhankelijk van hoe een organisatie dat heeft ingericht, kan de Architect dit ontwerp goedkeuren, afkeuren, of adviseren over een andere oplossingsrichting.

Het verschil in data architectuur tussen commerciële en overheidsorganisaties

In de praktijk zien we dat commerciële organisaties minder waarde hechten aan architectuur dan overheidsorganisaties. De waarde van een gedegen architectuur betaalt zich over het algemeen pas over langere termijn uit, terwijl commerciële organisaties vaak niet zo’n lange horizon hebben. Dit proces is vergelijkbaar met het principe technical debt uit het agile werken, alleen dan op een andere schaal.

In commerciële organisaties ontstaat vaak wel een impliciete architectuur – de werkwijze die gehanteerd wordt en waaraan Data Engineers elkaar houden. Het nadeel hiervan is dat doordat het team in de loop van tijd veranderd, daarmee ook de visie en het kennisniveau verandert.

In overheidsorganisaties ontstaat vaak juist weer een te rigide architectuur – er is weinig ruimte voor een oplossing buiten de voorgestelde kaders, waarmee inefficiënte oplossingen gecreëerd worden ‘omdat het zo moet volgens de architectuur’.

Hoe je het best naar je architectuur kunt kijken

Ons advies is om wat betreft architectuur een middenweg te bewandelen. Je wil richtlijnen, kaders en een visie hebben waar je naar toe wil gaan, maar tegelijk de flexibiliteit houden om ook te kunnen ontwikkelen op een manier die werkbaar is.

Een goede architectuur biedt de mogelijkheid om af te wijken van het ideaalplaatje, en een goede Architect beseft zich dus dat de werkelijkheid regelmatig meer weerbarstig is dan het ideale plaatje dat gewenst is.

Tegelijkertijd weet een goede Data Engineer het belang van diezelfde ideale architectuur en de voordelen die het biedt in beheersbaarheid, overdraagbaarheid en begrijpelijkheid om zoveel mogelijk volgens architectuur te werken.

Om nog even terug te pakken op het voorbeeld van het bouwen van een huis: niet elk huis is exact hetzelfde, maar het is toch wel fijn dat overal de elektrische draden hetzelfde betekenen, waterleidingen met dezelfde aansluitingen gelegd worden, en er zo nog meer standaarden zijn waar we aan vast kunnen houden.

Advies nodig?

Wil je starten met het opzetten van een data architectuur of zie je ruimte tot verbetering van je huidige architectuur? We denken graag met je mee! Neem direct contact met ons op.

1x per maand data insights, praktijkcases en een kijkje achter de schermen ontvangen?

Meld je aan voor onze maillijst en blijf 'up to data':