Wat is data architectuur?

Data architectuur is de indeling van je gegevenslandschap: waar data binnenkomt, waar die wordt opgeslagen, waar betekenis wordt vastgelegd, en waar antwoorden vandaan komen. Het is de plattegrond waar elke latere keuze op landt.

Een goede architectuur herken je niet aan het aantal componenten, maar eraan dat je bij elk cijfer kunt aanwijzen waar het vandaan komt.

De vier lagen

Van ruwe bron tot antwoord. Elke laag doet één ding.

Bron en inname. Systemen leveren aan: ERP, WMS, TMS, sensoren, spreadsheets. Hier wordt niets veranderd, alleen vastgelegd wat er stond en wanneer. Die tijdstempel is belangrijker dan hij lijkt: zonder hem kun je later niet reconstrueren waarom een cijfer vorige week anders was.

Opslag. Eén plek waar ruwe en bewerkte gegevens naast elkaar staan, meestal een lakehouse. Het punt is niet de technologie maar dat er één plek is in plaats van vier.

Betekenis. Definities, herkomst, kwaliteitsregels, toegang. Dit is de laag die de meeste organisaties overslaan en die bepaalt of de rest te vertrouwen is.

Gebruik. Rapportage, planning, modellen, agents. Wat hier gebeurt is alleen zo goed als de laag eronder.

De keuzes die terugkomen

Er is geen universeel goed antwoord, wel een expliciet antwoord.

Batch of stromend. Centraal of per domein. Kopiëren of bij de bron bevragen. Eén catalogus of één per afdeling. Deze keuzes zijn niet goed of fout, maar ze moeten bewust en opgeschreven zijn. Architectuur die per project ontstaat, is geen architectuur maar sediment.

Vier vragen helpen om elke keuze scherp te krijgen:

• Wie stelt de vraag, en hoe vaak? Een cijfer dat maandelijks in een vergadering valt, vraagt iets anders dan een signaal dat een planner elk kwartier nodig heeft.
• Hoe vers moet het antwoord zijn? Versheid is de duurste eis in elke architectuur. Vraag hem alleen waar hij het besluit werkelijk verandert.
• Wie mag het zien? Rechten die je pas in de rapportagelaag regelt, zijn een lek. Ze horen bij de betekenislaag.
• Wat moet je later kunnen uitleggen? Als een controleur of een klant vraagt hoe een getal tot stand kwam, is herleidbaarheid geen extra maar de kern.

Vier patronen die je in het echt tegenkomt

Bijna elke architectuur is een variant op vier vormen.

Centraal datawarehouse. Alles wordt gemodelleerd naar één schema. Voorspelbaar en makkelijk te controleren, maar elke nieuwe vraag kost modelleerwerk, en semi-gestructureerde bronnen passen slecht.

Data lake. Alles komt binnen zoals het is. Goedkoop en flexibel, maar zonder afspraken verandert het in een archief dat niemand meer vertrouwt.

Lakehouse. Open opslag met transacties, schema en catalogus erbovenop. In de praktijk het huidige uitgangspunt voor de meeste organisaties: één plek voor analyse, engineering en AI. Wat dat concreet betekent staat in wat is Databricks.

Gefedereerd of mesh. Domeinen leveren zelf, op één gedeeld platform. Dit is een organisatiekeuze bovenop een lakehouse, niet in plaats van. Zie wat is een data mesh.

De meeste organisaties zitten op een mengvorm, en dat is niet erg. Het wordt pas een probleem als niemand kan opschrijven welke vorm waar geldt.

Betekenis is geen bijproduct

De duurste fout is aannemen dat betekenis vanzelf ontstaat als de techniek staat. Dat gebeurt niet. Zonder vastgelegde definities krijg je een technisch keurig platform waarin twee afdelingen nog steeds een andere omzet rapporteren. Daarom hoort de betekenislaag in het ontwerp, niet in de nazorg. Hoe je dat per dataset vastlegt, staat in wat is een data contract.

Praktisch bestaat die laag uit vier dingen die je kunt aanwijzen: een lijst met begrippen en hun definitie, een eigenaar per begrip, herkomst per veld tot aan het bronsysteem, en rechten per rol die op één plek worden afgedwongen.

De eisen die geen laag zijn

Naast lagen heeft een architectuur eisen die er dwars doorheen lopen, en die je vooraf getalsmatig moet vastleggen:

• Versheid. Per dataset: hoe oud mag het antwoord zijn.
• Herstel. Hoe lang mag een levering stilstaan, en hoe ver kun je terugdraaien.
• Kosten. Wat mag een vraag kosten, en wie ziet die rekening.
• Toegang. Welke rol ziet welke rij, en waar wordt dat gecontroleerd.
• Bewaartermijn. Wat blijft, hoe lang, en hoe wordt verwijderen bewijsbaar. Zie effectief data lifecycle management.

Zonder getallen zijn dit meningen, en meningen zijn niet te toetsen bij oplevering.

Waar je begint

Eén vraag helemaal uittekenen levert meer op dan een plaat van het eindplaatje.

Niet bij een tool en niet bij een tekening van het eindplaatje. Begin bij één vraag die het bedrijf elke maand stelt en teken de weg terug: welk antwoord, welke definitie, welke bron, hoe vers. Wat je daar tegenkomt aan gaten is je eerste architectuurbesluit.

Doe dat voor drie vragen uit verschillende hoeken van de organisatie en je hebt geen plaat, maar een lijst besluiten met een reden erbij. Dat is de enige vorm van architectuur die een jaar later nog klopt.

Hoe je het vastlegt

Houd het document klein genoeg om te onderhouden. In de praktijk werkt: één pagina per laag met de gekozen vorm en waarom, één tabel met de eisen in getallen, en één register met begrippen, eigenaren en bronnen. Alles wat groter is dan dat, wordt niet bijgehouden en is binnen twee kwartalen fictie.

Wil je zien hoe wij die lagen bouwen en beheren, kijk dan op de motor. Wil je eigenaarschap per domein beleggen, lees dan wat is een data mesh.