Wanneer gebruik je dit?
- Bij een nieuw of te vernieuwen dataplatform.
- Bij overlap tussen platformdiensten en domeinoplossingen.
- Bij het beoordelen van ontbrekende beheersing of onduidelijk eigenaarschap.
- Als basis voor fysieke uitwerking door Cloud en Infrastructure Architecture.
Wat heb je nodig?
De beoogde gebruikers, gegevensstromen en afspraken over kwaliteit, toegang, bewaren en herstellen.
Een voorbeeld uit de praktijk
Fictieve casus: Noordhaven Servicebureau
Het fictieve Noordhaven Servicebureau ontvangt iedere ochtend gegevens voor de werkverdeling. Het platform moet de levering ontvangen, controleren en pas daarna aan de gebruikers beschikbaar stellen.
Een afgewezen levering gaat naar een hersteldienst. Een catalogus bewaart de betekenis en versie van de leveringsafspraken. Ontvangst en publicatie zijn afzonderlijke logische zones; daarmee is nog geen technische beveiligingsgrens gerealiseerd.
De diensten beschrijven wat nodig is. De keuze voor concrete software, capaciteit en fysieke inrichting volgt later. Prestatie- en herstelvereisten moeten nog worden bevestigd en beproefd.
Bekijk de visuele samenvatting
Open op volledig formaat (nieuw tabblad)Aan de slag
- Bepaal gebruiksscenario's en de gegevens die daarvoor nodig zijn.
- Identificeer logische diensten en hun verantwoordelijkheid.
- Groepeer diensten in zones met een expliciete betekenis.
- Teken gegevensafhankelijkheden en beheerafhankelijkheden afzonderlijk.
- Koppel eisen aan eigenaar, dienst en verificatiebewijs.
- Leg keuzes, open punten en de overdracht naar technische ontwerpen vast.
Controleer je resultaat
- Gebruik en scope zijn aan de benodigde diensten gekoppeld.
- Elke platformdienst heeft input, output, verantwoordelijke en afnemer.
- Zones hebben een betekenis die geen onbewezen fysieke isolatie claimt.
- Datastromen en beheerrelaties hebben verschillende, verklaarde labels.
- Contract- en modelversies zijn traceerbaar.
- Kwaliteit, levenscyclus, toegang en metadata hebben een eigenaar.
- Eisen noemen scenario, meetpunt, verificatie en status.
- Herstelroutes en de gevolgen van een ontbrekende dienst zijn zichtbaar.
- Leverancierskeuzes en fysieke topologie zijn onderscheiden van logische diensten.
- Open punten hebben effect, eigenaarstatus en vervolgactie.
Verdieping en begrippen
- Logische dienst
- Een afgebakende verantwoordelijkheid, los van de software die haar uitvoert.
- Zone
- Een groepering van verantwoordelijkheden; de technische grens vraagt een eigen ontwerp.
- PA / SV / Z / NR
- Templatecodes voor platformmodel, dienst, zone en niet-functionele eis.
Wat is het?
De Data Platform Architecture beschrijft welke logische diensten nodig zijn om gegevens te ontvangen, te beheren, te verwerken en beschikbaar te stellen. Zij verbindt die diensten met gebruik, gegevensverantwoordelijkheid en eisen aan kwaliteit, lifecycle en bedrijfsvoering.
Een logisch platformmodel
Een dienst levert een benoemd resultaat aan een afnemer. Een zone groepeert diensten of gegevens op grond van een gedeelde verantwoordelijkheid of verwerkingsstatus. Een zone is in dit product geen bewijs van fysieke isolatie. PA is het platformmodel, SV een logische dienst, Z een zone, DP een gegevensafhankelijkheid, NR een vereiste en DD een keuze. De codering is een EAW-werkafspraak.
Van gebruik naar diensten
Begin met het gebruik en vermijd een inventarisatie van populaire technologie. Beschrijf per dienst de input, output, eigenaar, afnemer, gegevensverantwoordelijkheid en afhankelijkheden. Onderscheid de bronhouder van de platformbeheerder. Een platformbeheerder mag niet zonder mandaat de betekenis van brongegevens veranderen. Beschrijf ook wie metadata, definities, toegangsbeleid en observatie beheert. Deze functies kunnen gedeeld zijn zonder alle data centraal te maken.
Zones en stromen
Geef een zone één afbakeningscriterium, zoals ontvangen gegevens of gecontroleerde publicaties. Teken waar validatie plaatsvindt en wanneer een gegevensset naar de volgende zone mag. Maak de bron van iedere stroom en de verantwoordelijke dienst zichtbaar. Afgekeurde data krijgen een expliciete afhandelroute. Beheerrelaties, zoals catalogisering of autorisatie, hebben een eigen legenda en mogen niet lijken op kopieën van gegevens.
Eisen toetsbaar maken
Een eis noemt scenario, meetpunt, eigenaar en verificatiemethode. Actualiteit betreft de ouderdom van gegevens voor het gebruik. Beschikbaarheid betreft het kunnen gebruiken van de dienst. Hersteltijd en maximaal aanvaardbaar gegevensverlies vragen afzonderlijke afspraken. Vul geen standaardwaarden in zonder onderbouwing. Kosten hebben een afbakening en ramingstatus nodig. Een tekening bewijst geen capaciteit, herstelbaarheid of toegangsbeheersing.
Uitwerking en acceptatie
Draag de logische diensten en eisen over aan Solution, Cloud, Infrastructure en Security Architecture. Zij bepalen technologie, netwerk, capaciteit en controls binnen hun eigen scope. Registreer terugkoppelingen wanneer een eis niet realiseerbaar blijkt. Een vendorselectie of cloudlogo maakt een logisch model niet compleet. Acceptatie vraagt bewijs per kritische dienst en een expliciet besluit over resterende beperkingen.
Verder werken
Gebruik een verwant onderwerp om een volgend deel van je vraag uit te werken.
Je accountvoorkeuren worden geladen.
Achtergrond en bronnen
EAW-werkwijze en werktemplate. Voorbeeldcasussen zijn fictief.
EAW-werkafspraken. Codes, views en statussen zijn lokale modelconventies. Alle casusgegevens, rollen, normen en planning zijn fictief. Open punten blijven expliciet open.
Versie 1.0 · Gepubliceerd
Microsoft — Big data architectures
Samenvatting: de referentie beschrijft logische componenten voor onder meer opslag, verwerking en analyse. Een oplossing hoeft niet alle componenten te bevatten. De EAW-uitwerking schrijft geen Azure-producten of big-data-architectuur voor. Geraadpleegd 20 september 2026.