Drieluik over het opbouwen van een organisatie vanuit haar opdracht: 1. De blauwdruk in de wet · 2. Bedrijfsfuncties · 3. Gegevensgebieden (dit artikel).
In het kort
- Eigenaarschap op gegevens hangt te vaak aan afdelingen en verdwijnt zodra de organisatie reorganiseert.
- Een gegevensgebied bundelt gegevens die qua beheer bij elkaar horen, met één eigenaar. De ordening volgt de bedrijfsfunctie, niet het thema.
- Daardoor valt eigenaarschap samen met beheer, worden grenzen helder en zijn afhankelijkheden in één oogopslag zichtbaar.
- Bedrijfsfuncties zijn stabieler dan organigrammen, dus deze ordening overleeft de volgende reorganisatie.
- Klein beginnen kan: één bedrijfsfunctie, de gegevens die zij maakt, één eigenaar.
- Letterlijk verplicht is het niet, maar de AVG, de Europese dataregels en (voor de overheid) het JenV-beleid maken het in de praktijk onontkoombaar.
De vraag die niemand kan beantwoorden.
Vraag in een willekeurige organisatie wie de eigenaar is van een bepaald gegeven en waar die verantwoordelijkheid precies ophoudt. Een helder antwoord blijft meestal uit. Vaak valt een afdeling, soms een systeem, af en toe de naam van iemand die er “ooit over ging”. En zodra de volgende reorganisatie het organigram door elkaar schudt, verdwijnt dat eigenaarschap met de afdeling waaraan het hing.
Niet alleen de overheid.
Dit is geen typisch overheidsverschijnsel. Elke organisatie die haar gegevens serieus neemt, loopt er vroeg of laat tegenaan. Bij de overheid is het alleen scherper voelbaar, omdat daar bovenop de gewone bedrijfsvoering een laag publieke verantwoording en wetgeving ligt die dwingt tot weten wat er is en wie ervoor staat.
Een opmerking over woordkeuze. In dit stuk valt consequent het woord gegevens en niet data. Data klinkt technisch, alsof het iets is van de IT-afdeling. Waar het hier om draait is juist de betekenis, de herkomst en het eigenaarschap van gegevens: een organisatievraagstuk, geen technisch vraagstuk.
Eén ordeningsprincipe.
De rest van dit verhaal draait om het gegevensgebied, het principe dat dit probleem bij de wortel aanpakt.
Wat een gegevensgebied is en wat het niet is
Niet op thema, maar op bedrijfsfunctie.
Bij een “gegevensdomein” denken de meeste mensen aan een thema of een objectsoort. Het domein Klant, het domein Boete, het domein Persoon. Dat is herkenbaar, maar als basis voor eigenaarschap is het zwak. Een objectsoort als Persoon wordt door tientallen bedrijfsfuncties aangeraakt. Wie vervolgens “de eigenaar van het domein Persoon” zoekt, ontdekt dat iedereen er een beetje over gaat en niemand echt. Waar dat ene, gedeelde persoonsgegeven dan wel thuishoort, is een terechte vraag. Daarop volgt onderaan een antwoord.
Afgebakend op beheersamenhang.
Een gegevensgebied is iets fundamenteel anders. Het is een relatief autonoom deel van de gegevenshuishouding dat is afgebakend op beheersamenhang: gegevens die vanuit het oogpunt van beheer sterk bij elkaar horen, komen in hetzelfde gebied. Het ontwerp streeft naar sterke samenhang binnen een gebied en zwakke koppeling ertussen. De afbakening volgt daarbij de bedrijfsfuncties en niet de objecten. Gegevens worden gegroepeerd rond de bedrijfsfunctie die ze maakt en wijzigt.
Wat is een bedrijfsfunctie? De verkaveling steunt volledig op dit begrip. Het wordt makkelijk verward met een afdeling, een proces of een systeem, terwijl het iets anders is. Een bedrijfsfunctie is een bijdrage die een organisatie levert, beschreven naar het resultaat in plaats van naar de manier waarop. Ze beantwoordt de vraag wat er tot stand komt. Een taak of proces gaat juist over hoe dat gebeurt. Een bedrijfsfunctie laat zich zien als de verandering tussen een begintoestand en een eindtoestand: wat gaat erin, wat komt eruit.
Een bedrijfsfunctie is dus nadrukkelijk geen plek in het organigram, geen applicatie en geen afdeling. Juist daardoor is ze stabiel: de manier waarop iets gebeurt verandert voortdurend, maar de bijdrage zelf blijft. In de architectuurwereld heet dit een bedrijfsfunctie of capability. Het CJIB-voorbeeld verderop gebruikt precies die capabilities als de beherende bedrijfsfuncties achter de gegevensgebieden.
Een beproefde aanpak.
Die aanpak is niet nieuw. Ze gaat terug op de infrastructurele benadering van informatiearchitectuur die Sturm en Van der Sanden in 1997 beschreven. Hun uitgangspunt is dat gegevens worden behandeld als een gedeelde infrastructuur met duidelijke beheergrenzen, op dezelfde manier als bij fysieke infrastructuur. Begrippen als beheersamenhang en het onderscheid tussen functiemodel, objectmodel en interactiemodel komen daarvandaan, net als het principe van eenheid van beheer: voor elk gegeven is er precies één partij die het mag opvoeren, wijzigen en verwijderen. Eén gegeven, één beheerder, dus geen gedeeld eigenaarschap en geen grijze zones.
De begrippen op een rij.
Een paar begrippen verdienen onderscheid, omdat ze vaak door elkaar lopen. Een gegeven is het kleinste betekenisvolle element. Een gegevensgroep is een set samenhangende gegevens van één objecttype. Een gegevensgebied is de verkaveling daarvan: gegevensgroepen geclusterd op beheersamenhang, met één beherende bedrijfsfunctie. Daarnaast bestaat de administratie of gegevensverzameling, een afgebakende verzameling met betekenis als geheel, zoals één samenhangend register, waarvan kwaliteit te eisen valt in termen van juistheid, volledigheid, actualiteit en toegankelijkheid. Binnen één gegevensgebied kunnen meerdere administraties bestaan. Kort gezegd ligt verantwoordelijkheid op het niveau van het gegevensgebied en kwaliteit op het niveau van de administratie.
Eigenaarschap hoort bij gegevensgebieden, niet bij afdelingen.
Waarom verkavelen loont
Stabieler dan het organigram.
De winst van beheersamenhang als ordeningsprincipe zit in de stabiliteit ervan. Een bedrijfsfunctie, opgevat als de bijdrage die een organisatie levert los van wie haar uitvoert, verandert veel langzamer dan het organigram. Bij een indeling op bedrijfsfunctie en beheer valt het eigenaarschap samen met het beheer. De partij die een gegeven maakt, beheert het ook en is erop aanspreekbaar. Daarmee sluit de kwaliteitscirkel: wie er belang bij heeft, draagt er ook verantwoordelijkheid voor.
Harde grenzen, zichtbare afhankelijkheden.
Van elk gegeven is eenduidig vast te stellen in welk gebied het thuishoort, zodat de vraag waar iemands verantwoordelijkheid ophoudt eindelijk een antwoord krijgt. Wat tussen gebieden overblijft, zijn expliciete koppelingen. Die vormen precies de integratielast, het synchronisatierisico en de gegevensuitwisseling onder de AVG. Ze zijn in één oogopslag zichtbaar in plaats van pas op te vallen als iets misgaat.
Bestand tegen reorganisatie.
En dan het belangrijkste effect. Schuift het organigram, dan blijven de bedrijfsfuncties bestaan, dus blijven de gebieden bestaan en blijft het eigenaarschap staan. Daarmee is meteen de vraag beantwoord waar dit hele stuk om begon, namelijk hoe verantwoordelijkheid op gegevens zo te organiseren valt dat een organisatieverandering haar niet wegvaagt. Het antwoord: aan gegevensgebieden, niet aan afdelingen.
Drie soorten gebieden
Eigen, invoer en referentie.
In de praktijk komen drie typen gegevensgebieden voor. De eigen gebieden bevatten de resultaatgegevens die de eigen bedrijfsfuncties maken en beheren; daar ligt het echte eigenaarschap. De invoergebieden bevatten waarnemingen die wel worden gebruikt maar niet beheerd, met een bronhouder buiten de organisatie. Die worden als gegeven aangenomen en niet veranderd. Ten slotte zijn er referentiegegevens, de naslag van een externe autoriteit, zoals tarieflijsten, codetabellen en aanwijzingen, zonder zaak- of persoonsgebonden werkvoorraad.
Het regime hoort bij het gegeven.
Dwars op die indeling staat het verwerkingsregime. Valt een gebied onder de AVG, onder een bijzonder regime, of is het niet-persoonlijk van aard? Dat regime hoort bij het gegeven en het gebied, niet bij de afdeling die de gegevens toevallig verwerkt. Dat onderscheid komt verderop terug bij de wettelijke kant.
Geleende gegevens van andere organisaties
Veel gegevens zijn niet van de organisatie zelf.
Niet alle gegevens in het landschap zijn eigendom van de organisatie. Een groot deel is geleend van andere organisaties: een adres uit de Basisregistratie Personen, een voertuiggegeven uit het kentekenregister of een politiegegeven uit een andere keten. Dat zijn precies de invoergebieden van zojuist. Zulke gegevens worden gebruikt zonder ze te beheren, met een paar praktische gevolgen.
Het eigenaarschap blijft bij de bron.
De bronhouder blijft de baas over die gegevens. De afnemer neemt ze over zoals ze zijn. Een eigen correctie levert twee waarheden op die uit elkaar gaan lopen. Klopt er iets niet, dan gaat er een terugmelding naar de bron in plaats van een lokale reparatie. Voor de basisregistraties is die terugmelding zelfs wettelijk verplicht.
Maak de afhankelijkheid expliciet.
Leg per invoergebied vast wie de bronhouder is, waarop het gebruik is gebaseerd, hoe actueel de gegevens moeten zijn en wat er gebeurt als de levering uitvalt. Die afspraken horen zichtbaar bij de koppeling tussen het eigen gebied en het invoergebied, niet verstopt in een technische interface.
Let op kwaliteit en grondslag.
De kwaliteit van de bron wordt geërfd, dus de afhankelijkheid van hoe goed de ander de zaken op orde heeft is reëel. Een kwaliteitsvlag op het invoergebied maakt die afhankelijkheid zichtbaar. Daarnaast is een eigen grondslag nodig om geleende gegevens te gebruiken, met nadruk op doelbinding: gegevens die voor het ene doel mogen worden ontvangen, mogen niet zomaar voor een ander doel worden ingezet.
Waar te beginnen
Schetsen gaat voor rekenen.
De verleiding is groot om verkaveling meteen als een rekenkundig clusterprobleem te zien. Dat is niet de aangewezen weg. De vuistregel uit de methode luidt dat schetsen belangrijker is dan uitrekenen en dat het rekenwerk hooguit een hulpmiddel is.
Begin bij de bedrijfsfuncties.
Begin met het inventariseren van de belangrijkste bedrijfsfuncties, een stuk of vijf tot tien. Een bedrijfsfunctie krijgt een naam naar het resultaat dat ze oplevert, dus niet naar een proces, systeem of afdeling. Bepaal vervolgens per bedrijfsfunctie welke gegevens ze maakt, niet welke ze gebruikt maar welke ze daadwerkelijk tot stand brengt. Alles wat één bedrijfsfunctie maakt, komt samen in één gebied. Dat is de startverkaveling, met grofweg één gebied per bedrijfsfunctie. Daarna volgt groepering op beheersamenhang, tot een overzichtelijk aantal gebieden overblijft die onderling zwak gekoppeld zijn. De waarnemingen, de gegevens die wel worden gebruikt maar niet gemaakt, gaan naar de bedrijfsfunctie die ze nodig heeft, of komen apart als invoergebied. Tot slot volgt een toets op aannemelijkheid en het vastleggen van de keuzes.
Een beslisboom voor wie verder wil.
Voor een concrete aanpak helpt het om het terug te brengen tot een paar beslissingen per gegeven. De beslisboom hieronder volgt de logica die Sturm en Van der Sanden beschrijven: eerst kijken wat bedrijfsfuncties met een gegeven doen, daaruit volgt in welk gebied het thuishoort.
Een voorbeeld.
Neem het gegeven “openstaand bedrag”. Het wordt gemaakt en bijgehouden door één bedrijfsfunctie, Inning en incasso, dus het hoort in haar eigen gebied: Vordering, inning en verhaal. Een adres uit de Basisregistratie Personen loopt anders door de boom. Dat wordt wel gebruikt maar niet beheerd, met de bronhouder buiten de organisatie. Het belandt daarom in een invoergebied.
Staan de gebieden eenmaal, dan volgt nog een korte controle.
| Signaal | Actie |
|---|---|
| Gebied te groot of te onoverzichtelijk | Splitsen, een niveau fijner. |
| Te sterk gekoppeld aan een buurgebied | Samenvoegen overwegen. |
| Gemengd verwerkingsregime | Splitsen op regime, of de beheersamenhang bewust heel houden. |
Twee dingen blijven een menselijke afweging. Wat een bedrijfsfunctie “als eerste nodig heeft” volgt uit de processtroom. Wat “te groot” of “te sterk gekoppeld” is, betreft eigen grenzen, niet die van de methode.
Keuzes die mensenwerk blijven
Hier valt een eigen afweging.
Verkavelen is geen mechanisch trucje. Het zit vol momenten waarop de methode een richting aangeeft, maar de uiteindelijke knoop een eigen afweging blijft. Die situaties zijn goed van tevoren te kennen.
Wie claimt het gegeven?
Soms claimen twee bedrijfsfuncties hetzelfde gegeven. Eenheid van beheer staat “samen” niet toe, dus de regel is dat resultaatgegevens horen bij wie het resultaat maakt. Blijft het betwist, dan volgt een splitsing van het gegeven in wat er beweerd wordt en wie het beweert. Dan zijn er twee gegevens met twee eigenaren. Een waarneming die meerdere bedrijfsfuncties nodig hebben, gaat naar de bedrijfsfunctie die haar als eerste nodig heeft. Dat vereist kennis van de processtroom en is dus een inhoudelijke afweging, geen formule. Lukt eenduidige toewijzing niet, dan is de gegevensgroep waarschijnlijk te grof en volgt verdere opdeling tot elk deel wel bij één bedrijfsfunctie hoort.
Eigen gebied of invoer?
Een terugkerende grensvraag is of iets een eigen gebied is of invoer. Wordt iets wel gebruikt maar niet beheerd, dan is het invoer. Die grens loopt precies tussen verantwoordelijkheid en afhankelijkheid en verdient een bewuste keuze. En als de herkomst van een gegeven “eigen” zegt terwijl er een externe bronhouder in beeld is, is dat een waarschuwingssignaal dat het waarschijnlijk toch om invoer gaat. Een kwaliteitsvlag en een expliciete bronhouder horen daarbij.
Splitsen of samenvoegen?
Wordt een gebied te groot of raken twee gebieden te sterk gekoppeld, dan volgt een fijner niveau met een splitsing, of juist een samenvoeging zolang het overzichtelijk blijft. Waar die grenzen liggen, ligt vast in drempels, bijvoorbeeld een maximum van acht gegevens per gebied of samenvoegen vanaf twee gedeelde gegevens. Dat zijn eigen parameters, geen natuurwet. Ook het verwerkingsregime levert een keuze op. Een gebied kan AVG-gegevens, bijzondere en niet-persoonlijke gegevens bevatten, een mengvorm dus. Een splitsing naar regime is juridisch schoner, maar houdt de beheersamenhang minder heel. Dat is een reële afweging tussen beheerlogica en juridische helderheid. Onder al deze gevallen ligt hetzelfde patroon: bij twijfel splitsen, zodat het eigenaarschap eenduidig blijft.
Hoe dat er in de praktijk uitziet: het CJIB
Een illustratief voorbeeld.
Een uitgewerkt voorbeeld maakt het concreet. Als voorbeeld dient het Centraal Justitieel Incassobureau, met twee kanttekeningen vooraf. Het gaat om een illustratief voorstel en niet om een door het CJIB vastgestelde architectuur. En het betreft uitsluitend open gegevens die zijn afgeleid uit de wetten waar het CJIB invulling aan geeft, zoals de Wahv voor verkeersboetes, de Awb, de Wpg en Wjsg, de Penitentiaire beginselenwet en de Paspoortwet. Het is dus de structuur van het landschap, niet de inhoud.
Zesenveertig gebieden.
Een verkaveling van dat landschap op bedrijfsfunctie en beheer levert op hoofdlijnen ongeveer 46 gegevensgebieden op. Een stuk of 21 daarvan zijn invoergebieden met waarnemingen van andere partijen, zoals een BRP-gegeven of een politiegegeven, waarvan de bronhouder buiten het CJIB zit. De overige 25 zijn eigen gebieden, elk met precies één beherende bedrijfsfunctie.
Het kloppend hart.
Het duidelijkst wordt het bij het gebied “Vordering, inning en verhaal”, dat wordt beheerd door de bedrijfsfunctie Inning en incasso. Daarin zitten de resultaatgegevens die deze bedrijfsfunctie maakt, met objecttypen als Aanmaning, Dwangbevel, Betalingsregeling, Sanctiebeschikking en Verhaal. Het regime is gemengd, deels AVG, deels Wjsg en deels niet-persoonlijk. Het gebied heeft een handvol expliciete koppelingen naar buurgebieden, waaronder een stevige naar Tenuitvoerleggingsregie, waarmee het openstaand bedrag, het sanctiebedrag en verhaalsgegevens worden gedeeld, plus lichtere koppelingen naar Gegevensbescherming en Rechtsbescherming. In één blik is zichtbaar wie het gebied beheert, welke gegevens erbij horen, onder welk juridisch regime ze vallen en met welke gebieden er uitwisseling is. Dat is precies de informatie die nodig is om verantwoordelijkheid te beleggen en om, op verzoek van een toezichthouder, te verantwoorden hoe het zit.
Verantwoordelijkheid eraan verbinden
Rollen per gebied.
Een verkaveling wordt pas waardevol zodra er rollen aan gekoppeld zijn. Per gegevensgebied horen een gegevenseigenaar die eindverantwoordelijk is, een gegevensbeheerder voor de dagelijkse kwaliteit en, bij invoergebieden, een bronhouder die als externe partij de waarheid levert. Waar een persoonsregime geldt, hoort daar de privacybetrokkenheid bij. Daarnaast wordt bijgehouden welke afnemers het gebied gebruiken.
En de bijbehorende taken.
Aan die rollen hangen concrete taken. De eigenaar bewaakt de kwaliteit van het gebied, verantwoordt de grondslag en het verwerkingsregime, beheert de koppelingen naar andere gebieden en de afnemers ervan. Ook beslist de eigenaar over toegang en autorisaties. Doordat het gebied stabiel is, blijven die rollen en taken staan terwijl de organisatie eromheen verschuift. Daar zit de kern van dit stuk: verkavel het landschap naar gegevensgebieden en organiseer de verantwoordelijkheden daaromheen, dan overleeft eigenaarschap de volgende reorganisatie.
Waarom dit geen vrijblijvende keuze is
Geen wet, wel onontkoombaar.
“Moet dit eigenlijk?” Het eerlijke antwoord is dat geen enkele wet letterlijk voorschrijft dat gegevensgebieden verplicht zijn. Wel dwingt een stapel verplichtingen tot precies datgene wat een gegevensgebied oplevert, namelijk weten welke gegevens er zijn, wie de eigenaar is, op welke grondslag verwerking plaatsvindt en onder welk regime de gegevens vallen. Het instrument is niet verplicht, het resultaat in de praktijk wel.
Een woord over de artikelnummers.
De beleidskaders noemen de instrumenten bij naam en niet per artikel. De specifieke AVG-artikelen hier dienen om concreet te maken waar de verplichting zit. Ze zijn bedoeld als “onder meer” en niet als een uitputtende juridische kwalificatie.
Geldt voor elke organisatie.
Een deel van die verplichtingen geldt voor elke organisatie, of ze nu commercieel is of niet. De AVG vraagt met de verantwoordingsplicht (artikel 5 lid 2) om aantoonbare beheersing en met het register van verwerkingen (artikel 30) om inzicht in welke gegevens voor welk doel worden verwerkt. Daarnaast vraagt ze om doelbinding en minimalisatie (artikel 5 lid 1) en passende beveiliging (artikel 32). Dat lukt alleen als gegevens, eigenaar en grondslag per gebied expliciet zijn. De Europese Datagovernanceverordening en de Data Act gaan een stap verder en veronderstellen dat veilig en rechtmatig hergebruik van gegevens rust op een geordend, getypeerd landschap met een aanwijsbare verantwoordelijke.
Voor de overheid komt er een laag bij.
De Wpg en Wjsg verbinden een strikt verwerkingsregime en autorisaties aan politie- en justitiële gegevens. Dat regime hoort bij het gegeven en niet bij de afdeling, wat precies is wat een gegevensgebied vastlegt. De Wet hergebruik van overheidsinformatie, de Wet open overheid en de Archiefwet vragen om vindbaarheid, openbaarheid en bewaring, wat zonder ordening niet te doen is. De Baseline Informatiebeveiliging Overheid vraagt om beveiliging naar classificatie, het liefst per gebied in plaats van per systeem. Dat dit geen theorie is, blijkt uit het feit dat koplopers het al tot beleid maken. Binnen Justitie en Veiligheid legt de JAGA, de JenV-architectuur voor gegevens en analytics, dit vast in een handreiking voor de organisatie-inrichting van gegevensmanagement, met rollen als CDO, Data Steward en gegevensverantwoordelijke, plus apart gegevenstyperings- en gegevensdelingsbeleid. Dat beleid stelt onomwonden dat voor elke gegevensdeling een wettelijke grondslag moet worden verantwoord, wat alleen kan wanneer het landschap op orde is.
Vooruit op de handhaving.
De JAGA geldt vooralsnog JenV-breed en is niet rijksbreed verplicht. De richting is echter helder en de Europese wetgeving komt eraan. Wie nu verkavelt, loopt niet vooruit op een hype maar op de handhaving.
Veelgestelde vragen van CDO’s en architecten
Is dit niet gewoon data mesh of een DAMA-datadomein?
Er is overlap, maar het vertrekpunt verschilt. Data mesh en de meeste datadomein-indelingen kiezen hun domein vaak per organisatieonderdeel of per thema. Gegevensgebieden kiezen bewust de bedrijfsfunctie en de beheersamenhang als grens, juist omdat die stabieler is. Combineren kan prima: een gegevensgebied is een uitstekende kandidaat voor een dataproduct of een DAMA-datadomein, met als verschil dat de afbakening verdedigbaar is in plaats van historisch gegroeid. De term bedrijfsfunctie sluit bovendien aan op ArchiMate. De rollen sluiten aan op de eigenaar- en stewardrollen uit DAMA.
Waar leeft het klant- of persoonsgegeven dan, bij indeling op functie in plaats van object?
Bij de bedrijfsfunctie die het registreert. Eén bedrijfsfunctie legt een klant of persoon vast en beheert dat gegeven. Alle andere gebieden gebruiken het als invoer of waarneming, niet als eigen bezit. Er blijft dus één bron van waarheid, alleen niet in een apart domein Persoon maar in het gebied van de registrerende functie. De andere gebieden verwijzen ernaar.
Moeten de systemen hierdoor worden herbouwd?
Nee, niet als eerste. De verkaveling is in de eerste plaats een logische en organisatorische ordening: ze bepaalt wie waarvoor verantwoordelijk is en waar de grenzen liggen. Pas daarna kan ze het systeemlandschap sturen, bijvoorbeeld doordat nieuwe opslag of nieuwe services rond gegevensgebieden worden georganiseerd in plaats van rond losse applicaties. Het is een groeimodel, geen big bang.
Hoe diep gaat de indeling en hoeveel gebieden zijn goed?
Zo diep als nodig is om gebieden overzichtelijk en zwak gekoppeld te krijgen, niet dieper. Het werk gaat van grof naar fijn. Een eerste niveau met enkele tientallen gebieden, bij het CJIB ongeveer 46, is voor veel organisaties een werkbaar startpunt. Wordt een gebied te groot of te verweven, dan volgt voor dat deel een niveau dieper. Een vast getal is er niet; de drempels zijn een eigen keuze.
En analyse en rapportage dan, die kruisen toch alle gebieden?
Dat klopt, maar het is geen probleem. Analyse en rapportage zijn secundair gebruik: ze lezen uit meerdere gebieden, maar ze beheren niets. Ze komen niet als nieuw eigen gebied, maar als een afnemer met eigen administraties, zoals een datawarehouse. Het eigenaarschap van de bronnen blijft bij de gegevensgebieden. De analyseomgeving erft dat en voegt geen nieuwe waarheid toe.
Samenvattend
Begin klein, begin vandaag.
Dit is geen verhaal voor één ministerie of één sector, maar voor elke organisatie die haar gegevens serieus neemt, met de overheid voorop omdat de verantwoording daar het zwaarst weegt. Het hoeft niet groot te beginnen. Neem één bedrijfsfunctie, beschreven naar haar resultaat. Schrijf op welke gegevens die bedrijfsfunctie maakt, want dat is het eerste gegevensgebied. Benoem er één eigenaar voor, met de afspraak dat die eigenaar meeverhuist met de bedrijfsfunctie en niet met het organigram. Na een paar herhalingen ontstaat geen abstract domeinmodel, maar een werkende verkaveling waar verantwoordelijkheid blijft plakken. Daar begint goed gegevensbeheer.
Zelf aan de slag, of samen?
Valorix denkt graag mee.
Het verkavelen van een gegevenslandschap is goed zelf te starten, maar de eerste keer is een ervaren blik veel waard. Valorix helpt organisaties om hun gegevens te verkavelen naar gegevensgebieden, om eigenaarschap en rollen te beleggen en om aan te sluiten op de eisen van de AVG, de Europese dataregels en het JenV-beleid. Dat kan klein beginnen, met een verkenning op één bedrijfsfunctie, of groter, als een volledige verkaveling met bijbehorende governance. Voor een gesprek over een concreet landschap is Valorix bereikbaar via valorix.nl.
Bronnen en verder lezen
Methode. Sturm en Van der Sanden, Informatiearchitectuur: de infrastructurele benadering (Panfox, 1997), ISBN 90-801270-2-7. De methodologische basis onder dit artikel, met het functie-, object- en interactiemodel, gegevensgebieden afgebakend op beheersamenhang en eenheid van beheer.
Beleid (Justitie en Veiligheid, JAGA, JenV CDO Office). Handreiking Organisatieinrichting Gegevensmanagement v1.0; Gegevenstyperingsbeleid v1.0; Gegevensdelingsbeleid v1.0; Gegevenskwaliteitsbeleid v1.0. Gepubliceerd via JenV Gegevens, jenvgegevens.pleio.nl.
Wet- en regelgeving (Europees). AVG, Verordening (EU) 2016/679; Datagovernanceverordening, (EU) 2022/868; Data Act, (EU) 2023/2854.
Wet- en regelgeving (nationaal). Wpg; Wjsg; Wet hergebruik van overheidsinformatie; Wet open overheid; Archiefwet; Baseline Informatiebeveiliging Overheid.
Wettelijke grondslag van het CJIB-voorbeeld (illustratief en open, via wetten.overheid.nl). Wahv (BWBR0004581); Takenbesluit CJIB (BWBR0045971); Organisatiebesluit JenV (BWBR0040293); Penitentiaire beginselenwet; Paspoortwet; Algemene wet bestuursrecht.
Beeld: de illustraties in dit artikel zijn gegenereerd met OpenAI (model gpt-image-2).