Een bestuurder vroeg mij waar zijn besluiten op rustten. Het bleef even stil.

Hij besliste elke week over tarieven, over onderhoud, over vergunningen. En niemand aan tafel kon zeggen op welke gegevens dat precies steunde, of die gegevens klopten, of wie ervoor stond. De besluiten waren er wel. De grond eronder niet. Een doelarchitectuur brengt die grond in beeld. Zij legt de data als fundament, en de besluiten als doel. Alles daartussen is te plannen, te financieren en te bouwen.

Eerst de data. De applicaties komen daaromheen.

Denk aan de fundering van een huis. Onzichtbaar als het goed is, en alles rust erop. De meeste organisaties ordenen hun gegevens naar afdelingen en functies. Maar functies veranderen bij elke reorganisatie, en een klant blijft een klant. Daarom ordenen we de data naar de dingen uit de werkelijkheid, de objecten, en niet naar wie er toevallig mee werkt. Applicaties komen en gaan. De domeinen blijven.

Datagedreven is een houding, besluiten nemen met data. Datacentrisch is een bouwprincipe, eerst de data, daaromheen de applicaties die haar verwerken.

Zes groepen, zeventien componenten.

Vier lagen boven elkaar, twee dwarsverbanden ernaast. Van boven naar beneden lees je haar als een vraag. Welk besluit wil ik 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. En de twee dwarsverbanden stellen aan elke laag dezelfde eis.

Elke laag draagt de laag erboven.

Zolang een domein leeg is of geen eigenaar heeft, is het besluit erboven een gok.

Een datadomein is een cluster van samenhangende gegevens, met één eigenaar en één set spelregels. Het datadomein is de bestuurseenheid, het concept de modelleereenheid. Een organisatie kent honderden concepten, maar hooguit acht tot tien domeinen. En een domein is pas op orde als het zes dingen heeft: een eigenaar, een woordenlijst, een bron, een vermelding in de catalogus, een kwaliteitsmeting en toegangsregels. Acht domeinen, zes vinkjes per domein. Dat is de meetlat van het fundament.

Eenmalig vastleggen, meervoudig gebruiken. Nu ook voor betekenis.

Het vak noteert werk al jaren in een vaste familie. Het proces in BPMN, de beslissing in DMN, de zaak in CMMN. Drie notaties, drie soorten werk. Maar ze verwezen alle drie naar hun eigen kopie van dezelfde gegevens. Daar is nu een vierde bijgekomen die eronder ligt. SDMN, de gedeelde datalaag. Zij legt een data-element één keer vast in een gemeenschappelijke bibliotheek, en elk proces-, beslis- en casemodel verwijst ernaar in plaats van een eigen versie te maken. Wijzigt de definitie, dan wijzigt zij overal tegelijk.

Het waardestuk is het initiatief. Het bouwstuk is het component.

Elk veranderinitiatief moet op componenten van de plaat landen, en elk component moet minstens één initiatief dragen. De toets sluit aan twee kanten. En er hoort een waarschuwing bij, want de verleiding is 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 initiatief, de begroting bij het component.

Wie dat omdraait, begroot bakstenen in plaats van huizen.

Eén kalender, vier banen.

De plaat ligt er. Daarna gaat zij naar de changetafel, waar per component de verandering wordt beoordeeld op impact, risico, samenhang en moment. En dan wordt het één planning. Baan een is de waarde, per initiatief per jaar een niveau. Baan twee is de aansluiting van de domeinen. Baan drie is de bouw, per component. En baan vier is de going concern, het dagelijkse werk dat gewoon doorgaat, met dezelfde mensen. Die vierde baan wordt niet afgeleid maar begrensd. Daar komen het proces en het project samen op één bord.