De datadoelarchitectuur

Deel 5 van de reeks architectuurketen. Een doelarchitectuur die niet financierbaar is, is niet bestuurbaar.

Datadomeinen als fundament, besluiten als doel.

Van boven naar beneden een vraag, van beneden naar boven een fundament.

Waar dit vijfde deel op voortbouwt

De datadoelarchitectuur is het vijfde deel in de reeks van de architectuurketen.

De flow tot hier is kort na te vertellen. Op de bestuurstafel is het vraagstuk scherpgesteld. Besluiten worden genomen op basis van data, en die data is niet op orde. Daar ontstonden ook de veranderinitiatieven, uit de relevante relaties tussen de perspectiefeigenaren. Dat was deel 2 en 3. Het bestuur koos vervolgens data als clusterinvalshoek, een bestuursbesluit dat van de bestuurstafel komt.

De ontwerptafel zette daarna de initiatieven met de oplossingscontour in de tijd. Dat was deel 4.

Daarna begint dit deel. De oplossingscontour gaf de kaders, dit vijfde deel geeft het ontwerp van de doelarchitecturen. En dat ontwerp draagt een dubbele opdracht. Het moet zo helder zijn dat een bestuurder het in tien seconden leest. En het moet zo compleet zijn dat de changetafel er per onderdeel over kan besluiten en financieren.

Een doelarchitectuur die niet financierbaar is, is niet (be)stuurbaar.

Waar staat de doelarchitectuur in de architectuurketen

De ontwerptafel vraagt het wat, en doet dat in twee schakels.

• Schakel 3 leverde de oplossingscontour. De kaders, geordend in de tijd, met de afhankelijkheden benoemd.
• Schakel 4 levert het ontwerp van de doelarchitectuur binnen die kaders. Omdat de oplossingscontour data als fundament meegeeft, heet het ontwerp hier een datadoelarchitectuur.

Niet de applicaties eerst met data als vulling, maar de data eerst en de applicaties daaromheen. Waarom hiervoor gekozen is, lees je in hoofdstuk 5.

Ontvangt van de laag erboven: de oplossingscontour uit schakel 3, geclusterd op data, begrensd in de tijd, gedragen door de eigenaren.

Geeft door aan de laag eronder: een datadoelarchitectuur in zeventien financierbare componenten. De changetafel beoordeelt per component de verandering, het realisatieplan ordent ze in de tijd. Het stuur- en controlepunt van deze schakel is de architectuurboard.

De componenten van een datadoelarchitectuur

Helderheid begint bij taal. Dit deel gebruikt één woord voor alles wat gepland, gefinancierd en gebouwd moet worden.

Component.

Zeventien componenten. Ze vallen in zes componentgroepen uiteen. Die zes componentgroepen zijn precies de vier lagen in de datadoelarchitectuurplaat, plus de twee (grijs gekleurde) dwarsverbanden links en rechts:

• Besluitvorming: componenten 1 en 2;
• Datadomeinen: componenten 3 en 4;
• Voorzieningen: componenten 5 tot en met 10;
• Ecosysteem: componenten 11 en 12;
• Governance en organisatie: componenten 13 tot en met 15;
• Veiligheid en weerbaarheid: componenten 16 en 17.

Een datadomein is inhoud. Een cluster van gegevens met een eigenaar. De twee componenten 3 en 4 in de groep datadomeinen beschrijven die inhoud. Je financiert geen domein. Je plant, financiert en bouwt het werk (componenten) dat een domein op orde brengt. Het datadomein zelf is geen component.

Voorzieningen is een groep van zes componenten. Waar dit deel voorziening (enkelvoud) zegt, bedoelt het, een component uit die groep.

Bijlage A nummert alle zeventien componenten. En per component de bijbehorende groep en het groeipad (de ontwikkeling ervan) in de tijd.

Van veranderinitiatieven naar ontwerp

De datadoelarchitectuurplaat met componenten is afgeleid uit de vijf veranderinitiatieven, vanuit drie ontwerpvragen.

Uit de disruptiegesprekken met de perspectiefeigenaren komen in ons voorbeeld vijf veranderinitiatieven voort. In de werkelijkheid ontstaan er meerdere veranderinitiatieven. De veranderinitiatieven hebben dezelfde behoefte en verdienen een gedeeld antwoord, geen vijf eigen oplossingen.

Elk veranderinitiatief heeft dezelfde zes behoeften. Die komen terug bij vraag twee en leveren de zes voorzieningen.

Ontdubbel die zes behoeften en bouw ze één keer, voor iedereen. Neem bijvoorbeeld de eerste. Wijzigt het adres van een klant op die ene plek, dan klopt het overal. En hoeft niemand meer te kiezen welke versie van welk gegeven waar is.

Aan de ontwerptafel stel ik daarvoor drie vragen aan elk van de (vijf) veranderinitiatieven:

• Vraag een: welk initiatief heeft welke data nodig -> welke datadomeinen?
• Vraag twee: welke behoefte keert terug in elk initiatief -> welke voorzieningen?
• Vraag drie: wat moet er verder geregeld worden -> welke besluiten, ecosysteem, governance, veiligheid?

Vraag één levert de datadomeinen.

Cluster de benodigde data naar de dingen (objecten) waar zij over gaat, en geef elk cluster een eigenaar. Dat zijn de acht datadomeinen.

Vraag twee levert de voorzieningen.

Elk initiatief heeft dezelfde zes behoeften, en elke behoefte krijgt één voorziening:

één plek waar elk gegeven wordt bijgehouden: de bronregistraties;

overal dezelfde definities: de datacatalogus;

data kunnen verplaatsen van bron naar gebruiker: de gegevensuitwisseling;

erop kunnen vertrouwen: de datakwaliteit;

kunnen terugkijken en combineren: analyse en historie;

kunnen voorspellen en signaleren: AI en voorspellen.

Vraag twee verklaart wat generiek geregeld wordt, en waar dat inzicht vandaan komt.

Het principe is eenmalig vastleggen, meervoudig gebruiken.

Dit is de vigerende richtinggevende uitspraak van het perspectief informatievoorziening, uit deel 2.

Vraag drie levert de rest van de plaat.

Elk antwoord krijgt zijn eigen plek:

wie beslist, en volgens welke regels: de laag Besluitvorming;

met wie buiten de deur, en onder welke afspraken: het Ecosysteem;

wie is eigenaar, en wie kan ermee werken: het dwarsverband Governance en organisatie;

hoe blijft het veilig en aantoonbaar: het dwarsverband Veiligheid en weerbaarheid.

De rest van dit deel over de componenten van de datadoelarchitectuur volgt deze drie vragen, laag voor laag. En de toets aan het slot bewijst de weg terug. Elk component is herleidbaar naar een veranderinitiatief.

Datacentrisch, hoe je de doelarchitectuurplaat leest

Denk aan de fundering van een huis. Onzichtbaar als het goed is, en alles rust erop.

Datagedreven is een houding, besluiten nemen met data.

De datadomeinen zijn de fundering.

Datacentrisch is een bouwprincipe, eerst de data, daaromheen de applicaties die de data verwerken.

Besluiten rusten op de domeinen. Applicaties komen en gaan, de domeinen blijven. Dat is ook de breuk met het vertrouwde bedrijfsfunctiemodel. De organisatie ordent haar gegevens niet langer naar afdelingen en functies, maar naar de dingen (objecten) uit de werkelijkheid. Functies veranderen bij elke reorganisatie. Een klant blijft een klant.

De plaat met componenten voor de datadoelarchitectuur, leest van boven naar beneden als een vraag.

Welk besluit wil ik als eigenaar nemen, welke domeinen heb ik daarvoor nodig, welke voorzieningen houden die domeinen werkend, en welke afspraken gelden buiten de eigen deur. Van beneden naar boven dragen de lagen elkaar. Elke laag draagt de laag erboven. De twee dwarsverbanden stellen aan elke laag dezelfde eis.

En dan de leesregel, onderstaande zin die blijft hangen.

Elk domein krijgt een eigenaar, een woordenlijst met spelregels en een bron. Zolang een domein leeg is of geen eigenaar heeft, is het besluit erboven een gok.

Eén eerlijkheid hoort erbij. Legacy en vendor lock-in maken deze omkering moeizaam. De architectuur is daarom een doel, geen big bang. Elk component groeit in stappen, langs het groeipad van bijlage A.

Besluitvorming, de bovenste laag

De datadoelarchitectuurplaat begint niet bij techniek. Zij begint bij wat het bestuur nodig heeft.

Herkomst: ontwerpvraag drie, wie beslist.

Bestemming: de laag eronder. Want elk besluit benoemt de data die het nodig heeft, en die data moet in een datadomein liggen.

Besluiten (component 1)

Per perspectief komt er een overzicht van de besluiten, op een A4. Vier kolommen: welk besluit, wie het neemt, in welk ritme, en op welke data.

Voorbeelden van zulke besluiten, per eigenaar een greep:

• tarief vaststellen (Financiën en tarieven);
• investeringen in het leidingnet prioriteren (Assets en onderhoud);
• een partij drinkwater vrijgeven of afkeuren (Productie en waterkwaliteit);
• opschalen bij een storing of calamiteit (Assets en Productie);
• een maatregel voor bronbescherming nemen (Bronnen en winning);
• investeren in natuurherstel (Natuur en terreinen);
• datadeling met een partner toestaan (Partners en keten);
• een AI-model in gebruik nemen (databoard).

De kracht zit in de laatste kolom van het overzicht: op welke data. Elk stukje data dat daar staat, moet in een domein liggen, met een eigenaar en een bron. Het besluitenoverzicht is daarmee de boodschappenlijst voor de lagen eronder. Staat er data op de lijst die nergens ligt, dan is dat geen detail maar een bevinding.

Beslismodellen (component 2)

Een beslismodel is de regel achter een besluit, expliciet gemaakt. Nu zit die regel vaak in het hoofd van de vakman.

Een voorbeeld uit de storingsafhandeling.

De regel van de ervaren wachtdienst luidt: raakt een storing meer dan tweehonderd aansluitingen, of zit er een kwetsbare afnemer bij zoals een ziekenhuis, dan wordt het prioriteit hoog en schalen we op.

Zo’n regel op papier kan door een mens en door AI worden uitgevoerd, en hij blijft bestaan als de vakman vertrekt. Dit is het veranderinitiatief vakkennis vastleggen, in uitvoerbare vorm.

Voorbeelden van beslismodellen en de regels achter zulke besluiten:

• opschalingsregels bij storingen;
• afkeurregels waterkwaliteit;
• prioriteringsregels onderhoud;
• opbouwregels van kostprijs naar tarief;
• signaleringsregels bronvervuiling;
• afsluit- en aanmaanregels bij wanbetaling;
• autorisatieregels, wie mag wat met welke data;
• datadeelregels met partners.

Besluiten zeggen wat er besloten wordt.

Beslismodellen zeggen hoe. Samen vormen zij de bovenste laag.

Datadomeinen, het fundament

Acht domeinen, in de taal van het bedrijf. Grof genoeg om te besturen, concreet genoeg om te herkennen.

Herkomst: ontwerpvraag een. De datadomeinen zijn de databehoefte van de vijf veranderinitiatieven, geclusterd naar eigenaar.

Bestemming: de voorzieningen eronder, die elk datadomein gaan bedienen.

Een datadomein is een cluster van samenhangende gegevens, met één eigenaar en één set spelregels. Binnen een domein leven de concepten. Dat zijn de dingen uit het conceptueel model.

Het datadomein is de bestuurseenheid, het concept de modelleereenheid. Een organisatie kent honderden concepten, maar hooguit acht tot tien domeinen.

Voor dit drinkwaterbedrijf met natuurbeheer:

• Klant en verbruik: klant, aansluiting, meterstand, contract, factuur.
• Productie en waterkwaliteit: zuiveringsproces, monster, norm, procesdata.
• Bronnen en winning: winput, vergunning, grondwaterstand, beschermingsgebied.
• Natuur en terreinen: natuurgebied, soortenmonitoring, beheerplan, recreatie.
• Assets en onderhoud: leiding, pomp, installatie, inspectie, storing.
• Financiën en tarieven: kostprijs, tarief, investering, grootboek.
• Medewerkers en kennis: functie, bevoegdheid, vakkennis, beslisregel.
• Partners en keten: leverancier, contract, toezichthouder, datadeelafspraak.

En metingen?

Die krijgen bewust geen eigen domein. Een meting hoort bij het object dat gemeten wordt. De meterstand bij Klant en verbruik, het watermonster bij Productie, de grondwaterstand bij Bronnen.

Een apart metingendomein zou een nieuwe silo scheppen, dwars door de eigenaren heen.

Elk domein krijgt drie dingen: een eigenaar uit de perspectieven, een woordenlijst met spelregels (in vaktaal een conceptueel domeinmodel), en een bron waar het eenmalig wordt vastgelegd.

Relaties en relatielijnen

Op de datadoelarchitectuurplaat staan bewust geen relatielijnen tussen de domeinen. De relaties bestaan wel. Een klant heeft een aansluiting, een winput ligt in een natuurgebied, maar dat is uitwerking per domein aan de ontwerptafel.

Dan de vraag die zich hier opdringt.

Aan hoeveel domeinen wordt een veranderinitiatief toebedeeld? Aan meerdere, en dat hoort zo. Elk initiatief ontstond uit een relatie tussen twee eigenaren, dus het snijdt per definitie door meer dan één domein.

Het waterbeeld raakt er drie. De waarde van een veranderinitiatief zit juist in het combineren van domeinen. Het domein is de beheerseenheid, het initiatief de waarde-eenheid.

Toebedelen betekent, benoemen welke datadomeinen het initiatief raakt, en daarmee welke eigenaren aan tafel zitten.

Daarmee ontstaat ook een simpele voortgangsmeter.

Een domein is op orde als het zes dingen heeft:

• een eigenaar (13);
• een woordenlijst (4);
• een bron (5);
• een vermelding in de catalogus (7);
• een kwaliteitsmeting (8);
• toegangsregels (17).

Acht domeinen, zes vinkjes per domein, zijn de meetlat van het fundament.

Eén keuze blijft open voor de uitwerking. Heeft de organisatie veel centrale sensordata, dan kan een apart telemetriedomein alsnog verstandig zijn. Dat is een keuze aan de ontwerptafel, geen wet.

Voorzieningen, wat de domeinen laat werken

Eén principe draagt deze groep: eenmalig vastleggen, meervoudig gebruiken.

Herkomst: ontwerpvraag twee. Zes behoeften die in elk veranderinitiatief terugkomen, ontdubbeld en één keer gebouwd.

Bestemming: elk datadomein sluit erop aan, en de besluiten erboven rekenen erop.

• Bronregistraties (5). Per domein één plek die geldt. Wie het domein nodig heeft, haalt het daar.
• Gegevensuitwisseling (6). Gegevens reizen via één voorziening, niet via honderd losse koppelingen.
• Datacatalogus (7). Waar staat wat, wat betekent het, wie is eigenaar. De etalage van de domeinen.
• Datakwaliteit (8). Meten en signaleren als doorlopend proces, geen jaarlijkse schoonmaak.
• Analyse en historie (9). Het geheugen van de organisatie. Hier ontstaat het waterbeeld van bron tot tarief.
• AI en voorspellen (10). Modellen die voorspellen, signaleren en assisteren. Deze voorziening landt op de andere vijf.

Voorzieningen worden niet per initiatief gekozen. Ze zijn generiek, je bouwt ze een keer. Wat je per initiatief wél bepaalt, is de aansluiting. Welke datadomeinen (1) wanneer (2) op welke voorziening (3) aangesloten worden, en op welk niveau. Dat aansluiten wordt gepland in één overzicht, figuur 4.

De jaartallen zijn een voorzet, de changetafel stelt ze vast.

De lege cellen zeggen dit doen we in dit voorbeeld bewust niet. Geen enkel initiatief vraagt nu om Natuur en terreinen of Assets en onderhoud, dus sluiten we ze niet aan. Net genoeg, net op tijd. In de werkelijkheid kan dat anders zijn. De kolom Datakwaliteit start overal in 2027, want die voorziening bestaat pas op dat moment. En Partners en keten wacht op het gedeelde bronnenbeeld in 2028.

De eerste vier voorzieningen werken per domein, rij voor rij. De laatste twee combineren domeinen, en daar ontstaat het rendement. Het waterbeeld is Analyse en historie over drie domeinen tegelijk.

• Bronnen en winning;
• Productie en waterkwaliteit;
• Financiën en tarieven.

Drie domeinen, drie eigenaren, één beeld.

AI en voorspellen start bewust later, en dat is een harde volgorde. Een voorspelmodel is zo goed als de data eronder. Ontbreekt de helft van het waterbeeld, dan komt er gewoon een voorspelling uit, met dezelfde stelligheid, alleen klopt zij niet. En niemand die het aan het getal ziet. Daarom staat in bijlage A,

AI en voorspellen begint pas als het waterbeeld op zilver staat.

Ecosysteem, de buitenrand

Data houdt niet op bij de eigen deur. Daar begint zij pas waarde te maken.

De groep Ecosysteem regelt het verkeer met de buitenwereld, met twee componenten.

• Datadeelafspraken (11) zijn de spelregels met partners, leveranciers en toezichthouders. Welke data wordt gedeeld, in welke kwaliteit, wie mag wat, en wat gebeurt er bij een incident.
• Het externe koppelvlak (12). Eén voordeur waarlangs dat delen van data loopt.

De groep Ecosysteem komt rechtstreeks uit één initiatief; het gedeelde bronnenbeeld met ketenpartners. De bronnen verslechteren door oorzaken buiten de eigen organisatie, en ketenregie vraagt een gedeeld beeld met dezelfde definities. Dat is geen technisch koppelvlak maar een afspraak, met techniek eronder.

Dit sluit aan bij het gedachtegoed over datawaardecreatie. Waarde ontstaat waar data de organisatiegrens over gaat, mits de spelregels staan.

De twee dwarsverbanden

Geen eigen laag, wel eigen componenten. Zij stellen aan elke laag dezelfde eis.

Governance en organisatie. De mensen.

• Datarollen en eigenaarschap (13) belegd, per domein en per perspectief.
• Een databoard (14) dat definitiegeschillen beslecht en de samenhang bewaakt, als verlengstuk van de architectuurboard uit deel 2.
• En een vaardighedenprogramma (15), want een fundament dat niemand kan lezen draagt niets. De verandering zit meer in dit verband dan in de techniek.

Veiligheid en weerbaarheid. Het principe uit deel 4 geldt hier onverkort. Compliance wordt aangetoond uit systemen, niet uit rapporten achteraf. Dat vraagt

• logging en aantoonbaarheid (16) als bijproduct van de voorzieningen;
• toegang en autorisatie (17) per domein.

De kaderlaag begrenst dit alles. NIS2, de AVG en de AI act veranderen de plaat niet, zij stellen er eisen aan. Dit verband komt vrijwel volledig uit één initiatief. Compliance is aantoonbaar uit systemen. Dat initiatief levert weinig inhoud voor de domeinen. Het levert de rand van de plaat.

De toets: dragen de componenten de veranderinitiatieven

Een doelarchitectuur bewijst zich niet met volledigheid, maar met draagkracht.

Eerst links de rode draad van boven naar beneden, met het waterbeeld als voorbeeld naast elke stap.

.

De vijf veranderinitiatieven van het datacluster uit deel 4 zijn hieronder als toetssteen uitgewerkt.

Elk veranderinitiatief moet namelijk op componenten van deze plaat landen, en elk component moet minstens één veranderinitiatief dragen. De nummers verwijzen naar de componenten in bijlage A.

De toets sluit aan twee kanten.

Geen veranderinitiatief zonder componenten, geen component zonder veranderinitiatief.

En dan de waarschuwing die erbij hoort. De verleiding wordt om per component een project te starten.

Doe dat niet.

De veranderinitiatieven blijven de eenheid van waarde, de componenten de eenheid van bouw. De businesscase hoort bij het veranderinitiatief, de begroting bij het component.

Wie dat omdraait, begroot bakstenen in plaats van huizen.

Wat bewust niet in dit deel zit

Drie dingen, en alle drie horen zij verderop in de keten thuis.

Het logische en fysieke datamodel. Dat is realisatiewerk, gestuurd door de conceptuele domeinmodellen.

De techniekkeuzes. Opslagvormen, platformen en pakketten kiest de keten na de changetafel, binnen dit ontwerp.

En de vakstandaard DAMA DMBOK als structuur. De plaat spreekt de taal van de eigenaren, niet de taal van het vak. De vaktoets staat in bijlage B.

Wat hierna komt in de keten

De output van dit deel gaat samen met de oplossingscontour naar de changetafel.

Daar wordt het één planning.

De datadoelarchitectuur ligt er. Zes groepen, zeventien componenten, elk met een groeipad. Daarmee is schakel 4 klaar en is de ontwerptafel afgerond.

Het volgende deel start met de changetafel, schakel 5. Daar wordt per component de verandering beoordeeld, impact, risico, samenhang en moment.

Het realisatieplan van schakel 6 ordent alles in de tijd en vertaalt het naar programma’s en projecten. Het groeipad in bijlage A is daarvoor de voorzet, geen besluit.

Hoe de twee invalshoeken samenkomen, is nu al te schetsen. Er komt één kalender met drie banen:

• Baan een is de waarde -> de oplossingscontour. Per veranderinitiatief per jaar een niveau.
• Baan twee is de aansluiting -> per datadomein de zes vinkjes, in het jaar dat het veranderinitiatief ze vraagt. Figuur 4 is daarvan het werkinstrument.
• Baan drie is de bouw -> per component een niveau, net genoeg voor de banen erboven.

De uitwerking volgt in het volgende deel, aan de changetafel.

De planning van het bestuur voor de veranderinitiatieven is absoluut leidend, inclusief businesscase en financiering.

De basis gaat per veranderinitiatief vooraf, maar alleen het benodigde deel. Net genoeg, net op tijd.

Nooit eerst drie jaar de hele basis bouwen, want dan ziet niemand boven waarde.

En de botsingen tussen de banen worden zichtbaar op één kalender. Zoals, AI en voorspellen wil starten, maar baan een zegt dat het waterbeeld nog niet op zilver staat.

Tot slot

Het inzicht van dit deel is opnieuw klein en daardoor bruikbaar.

Een doelarchitectuur is pas af als zij twee lezers tegelijk bedient. De bestuurder, die in tien seconden ziet waarop zijn besluiten rusten. En de changetafel, die per component kan beoordelen en financieren.

De plaat doet het eerste, de bijlage het tweede, en de toets op de veranderinitiatieven verbindt ze.

Het gereedschap maakt de delen. De mens maakt het verschil aan tafel.

Klaas van der Heijden, Co-BiDT Advies en Interim B.V. Methodologisch kader: General Enterprise Architecting (Roel Wagter, Groeiplatform GEA). Vaktoets: DAMA DMBOK. Gedachtegoed datawaardecreatie: Ken van Ierlant en Fiona van Maanen. Opgesteld met AI als gereedschap.

Bijlage A. De zeventien componenten van de architectuur

Elk component is een financierbare eenheid. Afgebakend, met een eigenaar, een groep en een groeipad.

De niveaus komen uit deel 4:

• Brons: het werkt, deels met de hand.
• Zilver: het werkt breed en is geborgd.
• Goud: het stuurt zichzelf bij en leert.
• Een streep betekent bewust later starten.

Het pad is een voorzet voor de changetafel, geen besluit.

Zes componenten zijn voorzieningen, 5 tot en met 10.

Zes componenten vormen samen de checklist per datadomein, 4, 5, 7, 8, 13 en 17.

Drie daarvan zijn allebei, voorziening en checklist. Bronregistraties 5, datacatalogus 7 en datakwaliteit 8. Dat zijn de voorzieningen waar elk datadomein afzonderlijk in moet landen.

Bijlage B. De vaktoets op DAMA DMBOK

DAMA DMBOK is de vakstandaard voor datamanagement, met kennisgebieden rond datagovernance als kern.

De standaard is hier geen structuur maar een volledigheidstoets, dekken de componenten het vak. De nummers verwijzen naar de componenten in bijlage A.

De organisatiekant van het vak, volwassenheid en vaardigheden, wordt gedragen door het vaardighedenprogramma (15) en het governanceverband.

Daarmee is de toets rond.

Elk kennisgebied heeft een plek, en de ene uitzondering is een keuze, geen omissie.