Het bouw- en configuratieplan;

schakel 7, deel 8 architectuurketen

 

Je bouwt geen systeem, je brengt een voorziening op niveau.

 

 

Figuur 1. De bouwkalender. Dezelfde vier banen als in het realisatieplan, nu met de stand van deze maand, de vier beslissingen die deze tafel zelf mag nemen en het ritme.

 

 

1. Waarvoor je dit plan gebruikt

 

Er ligt een kalender. Nu moet er iets op komen te staan.

 

Dit plan werkt op twee niveaus, en je hebt ze allebei nodig.

 

Het eerste niveau is de bouwkalender zoals hierboven gevisualiseerd. Daarop staat alles wat tegelijk loopt, in vier banen. Die kalender toets je elke maand, en dat doe je met de hele realisatietafel.

 

Het tweede niveau is één ontwikkeling van die kalender. Eén regel, van het bouwkader dat binnenkomt tot de terugmelding aan de changetafel.

 

Daarvoor zijn er negen stappen, en die staan in hoofdstuk 9 en de hoofdstukken daarna. Je zet ze per ontwikkeling opnieuw. Wie alleen de stappen leest, bouwt keurig één ding terwijl de rest van de organisatie tegen hem in beweegt. Wie alleen de kalender leest, weet wat er speelt en niet wat hij maandag doet.

 

Je krijgt voor de bouw- en configuratie wat de changetafel aan het eind van schakel 6 oplevert.

- De kalender met vier banen en de vastgestelde volgorde.

- De capaciteitsplanning met de schaarse profielen, de absorptiegrens per afdeling en de opgetelde tussentijd per afdeling.

- De niet-nu-lijst, met datum en eigenaar.

- Het afwijkingenregister, met datum en eigenaar.

- Per ontwikkeling een bouwkader op één A4 met de vaste bijlage.

- De begroting die bouw en beheer dekt.

- Het financieel plan met de baten, hun eigenaren en hun nulmeting.

- De vier deuren met de signalen die ze openen.

 

Je levert zelf vijf dingen op: werkende voorzieningen op het afgesproken niveau, de gevulde modellen, de testcase met haar uitslagen, een beheerder met een naam met de beheerlast in de begroting, en de afwijkingen die zijn blijven staan met hun houdbaarheidsdatum. Bijlage F zet dat om in veertien opleverregels. Het bouwkader, de niet-nu-lijst en de twee componenten voor cultuur maakte je niet zelf, en die reizen mee naar schakel 8.

 

Twee regels dragen dit hele plan. Je bouwt geen systeem, je brengt een voorziening op niveau.

En je programmeert niet, je vult een model.

Bouwen, configureren en modellen vullen

 

Dit plan gebruikt drie werkwoorden die vaak door elkaar lopen. Ze zitten op verschillende plekken, en het scheelt veel verwarring om ze uit elkaar te houden.

 

Configureren is instellen wat er al staat. Een pakket dat je koopt, een dienst die je afneemt, een platform dat al draait. Instellingen, schermen, rollen en rechten. Dat is verreweg het meeste werk aan deze tafel. Je vindt het in stap 4, waar je kijkt wat er al staat, en in stap 6, waar het gebeurt.

 

Bouwen is iets maken dat er nog niet is. Dat doe je alleen voor een voorziening die je nergens kunt kopen, en het vraagt een reden die in de projectstartarchitectuur staat. Het gebeurt in diezelfde stap 6, met één verschil dat blijft: wat je configureert blijft van de leverancier, wat je bouwt onderhoud je zelf zolang het bestaat.

 

Modellen vullen is het derde, en het is het zwaartepunt. De woordenlijst per datadomein, het domeinmodel, de beslismodellen, de catalogusvermelding. Die worden niet gebouwd, ze worden gevuld, en zodra ze gevuld zijn bepalen ze hoe het systeem eruitziet. Dat is stap 5, en dat doet de eigenaar en niet de bouwer.

 

Kort gezegd: stap 5 gaat over de taal, stap 6 over de techniek, en stap 7 toont aan dat de twee samen werken.

 

De begrippen staan in bijlage E, op één pagina. Wie ze niet nodig heeft, slaat ze over.

 

2. Waar dit plan staat in de architectuurketen

 

De eerste schakel van de realisatietafel, en de eerste waar iets tastbaars ontstaat.

Figuur 2. De vier tafels van de architectuurketen, met de realisatietafel uitgelicht. Elke tafel stelt één vraag en geeft door aan de volgende.

De vraag aan de realisatietafel verandert van wanneer en waarbinnen naar hoe. Wat de realisatietafel binnenkrijgt is geen opdracht om iets te bedenken, maar een opdracht om iets te maken waarvan de bedoeling, de grens en de meetlat al vaststaan.

 

Wat schakel 7, bouwen en configureren, niet doet. De organisatie inrichten. Rollen beleggen, mandaten geven, mensen opleiden. Dat gebeurt wel, maar dat is geen configureren. Het hoort bij schakel 8 implementeren, en daar gaat deel 9 over.

 

3. De hele organisatie komt in beweging, van twee kanten

 

Niet alleen het nieuwe verandert. Alles wat al loopt, verandert mee.

 

Zodra er gebouwd wordt, komt bijna de hele organisatie in beweging. Dat gebeurt van twee kanten tegelijk, en beide kanten gebruiken dezelfde mensen.

 

Van de ene kant duwt de noodzaak. De AI-disruptie, uitgewerkt in de oplossingscontour, de datadoelarchitectuur en de AI-doelarchitectuur. Dat is wat er nieuw bij komt.

 

Van de andere kant duwt de lopende ambitie. Verbeteringen die al waren afgesproken, processen die al worden aangescherpt, applicaties die toch al vervangen worden, programma's die al draaien. Dat is wat er al in beweging was.

 

Een bouwplan dat alleen de eerste kant telt, plant een wereld die niet bestaat. Dat is precies wat het realisatieplan aanwijst als de fout die veel transformaties maken.

 

Daarom staan in dit bouw- en configuratieplan beide kanten op dezelfde kalender, in dezelfde thema's, met dezelfde negen stappen waar dat kan.

 

Niet twee werelden naast elkaar, maar één werkvoorraad.

 

 

4. De cirkel rond, van richtinggevende uitspraak tot signaal

 

Zonder voorziening geen signaal. En zonder signaal is de uitspraak vrijblijvend.

 

Figuur 3. De gesloten stuurlijn uit deel 2, doorgetrokken tot de realisatietafel en weer terug omhoog.

 

Deel 2 van de architectuurketen, de strategische verkenning, legde de cascade neer. Een richtinggevende uitspraak van een perspectief op niveau een, een sub-perspectief op niveau twee, en bij dat sub-perspectief twee koppelingen: draagt bij aan, en een stuur- en controlepunt.

 

Daarmee ontstaat een gesloten stuurlijn. Van een directiebesluit, via een bestuurbaar sub-perspectief, naar een waarneembaar signaal in de praktijk, en weer terug omhoog in de verantwoording.

 

Aan deze realisatietafel wordt dat signaal gemaakt. Een stuur- en controlepunt bestaat niet vanzelf. Iemand moet de voorziening bouwen die het voortbrengt, en die voorziening moet op niveau staan.

 

Dat is de reden dat de cirkel zich aan de realisatietafel sluit. Beginnen doet hij aan de bestuurstafel.

 

 

 

Eén voorbeeld, van uitspraak tot voorziening

 

Neem het sub-perspectief informatie en datamanagement uit deel 2, met de Data Officer als eigenaar.

 

De beleidsuitspraak daar luidt dat de organisatie een datacatalogus bouwt met eenduidige definities per datadomein. De doelstelling erbij: eind 2026 is voor minimaal twee domeinen een vastgestelde datacatalogus met eigenaarschap operationeel.

 

En de datacatalogus is component 7 uit de datadoelarchitectuur. Die wordt aan deze tafel gebouwd.

 

Daar loopt de cirkel rond. Een uitspraak op niveau een, over samenhang. Een sub-perspectief op vormgevingsniveau twee, dat er een datacatalogus van maakt, met een eigenaar en een datum. Een voorziening die aan de realisatietafel gebouwd wordt. En een signaal waarmee de Data Officer per kwartaal kan aantonen of de doelstelling gehaald is.

 

Figuur 4. De ketting van boven naar beneden, met het voorbeeld van de datacatalogus ernaast.

Eén term, drie objecten

 

Eén term kan verwarrend zijn. De term stuur- en controlepunt komt in deze reeks op drie plekken voor, en telkens met dezelfde vraag: wie ziet wat, op welk moment, aan welk signaal.

1. Van een sub-perspectief strategische verkenning. Of de richtinggevende uitspraak wordt nageleefd. Staat in deel 2.

2. Van een schakel in de architectuurketen. Of de schakel levert wat hij moet leveren. Staat in deel 1, in de “menukaart’.

3. Van een ontwikkeling. Of dat wat er gebouwd wordt ook werkt. Staat in het bouwkader uit deel 7.

Het is hetzelfde mechanisme op drie objecten. Overal geldt dezelfde regel uit deel 1: een stuur- en controlepunt zonder naam is geen stuur- en controlepunt. Zeg er dus altijd bij welke van de drie het hoort.

 

Wat vastligt en wat beweegt

 

De richtinggevende uitspraken en de sub-perspectieven (vormgevingsniveau 2) liggen vast. Die veranderen niet tijdens de bouw.

 

De doelarchitecturen, de oplossingscontour en het realisatieplan liggen ook vast, tot de changetafel ze wijzigt.

 

Alleen de bouwkalender beweegt, elke maand. Wie daar iets anders verandert, breekt de lijn.

Eén regel volgt daaruit en hij is streng. Elke ontwikkeling op de kalender is herleidbaar tot één richtinggevende uitspraak. Een ontwikkeling die dat niet is, hoort er niet op. Dat geldt ook voor wat uit de going concern komt, en daar ontstaat meestal het eerste gesprek.

 

5. Waar alles landt: drie stromingen, negen thema's

 

Eén indeling waar zowel het nieuwe als het lopende in past.

 

De Co-BiDT-praktijk kent drie stromingen:

4. besturen vanuit noodzaak of ambitie;

5. beheersen van de dynamiek door interventies;

6. beheren van het fundament met behoud van regie.

Onder die stromingen liggen negen Co-BiDT-thema’s van aandacht. Aan deze realisatietafel zijn dat de bouwthema's, en ze doen hier iets wat ze eerder in de keten niet deden.

Ze nemen niet alleen de componenten uit de doelarchitecturen op, maar ook al het lopende werk.

Figuur 5. De negen thema's met twee bronnen. Links wat de disruptie brengt, rechts wat er al loopt. Samen de volledige werkvoorraad.

 

De achtendertig componenten uit deel 5, de datadoelarchitectuur en de AI-doelarchitectuur samen verdelen zich in drie stapels, en die verdeling zegt zelf al iets.

7. Eenendertig worden gebouwd. Ze vallen in zeven thema's: afspraken en spelregels, governance, modelgebaseerde beheersing met AI, bedrijfsvoeringsinformatie, begrippen en termen, systemen en toepassingen, en het infrastructureel platform.

8. Vijf worden niet gebouwd maar besloten. Ze hangen aan thema 1, sturen op toegevoegde waarde: de besluiten uit de datadoelarchitectuur, en uit de AI-doelarchitectuur de ambitie en autonomiekeuze, het portfolio en de clustering, het investeringskader, en de vermogensladder. Die vallen aan de bestuurstafel en de ontwerptafel en worden aan de changetafel gewogen.

9. Twee worden overgedragen. Het vaardighedenprogramma en de AI-geletterdheid horen bij cultuur, en gaan door naar deel 9.

Eenendertig plus vijf plus twee is achtendertig componenten uit de doelarchitecturen. Er blijft er geen liggen. Wat aan deze tafel nieuw is: de drie thema's die vanuit de disruptie leeg of dun bleven, ze vullen zich vanuit het going concern, het lopende werk.

Thema 1 , sturen op toegevoegde waarde, krijgt niets te bouwen. Daar hangen de vijf besluiten hierboven, plus de businesscases en de investeringsbesluiten die toch al genomen worden.

 

Thema 5 , bedrijfsvoeringsinformatie, telt maar twee componenten uit de doelarchitecturen, en beide uit de datakant. De reden is dat de doelarchitecturen over data en AI gaan en niet over de bedrijfsvoering zelf. Vanuit het lopende werk vult dit thema zich met de procesoptimalisaties en de stuurinformatie.

 

Thema 6, programma's en projecten, krijgt geen enkel component, want dit thema is de werkvorm en niet iets dat je bouwt. Vanuit het lopende werk staat in thema 6 alles: elk programma en elk project dat al draait.

Dat is geen toeval. Sturen, bedrijfsvoering en projecten waren altijd al van de organisatie zelf. De doelarchitecturen voegen daar iets aan toe, ze vervangen het niet.

 

De bouwvolgorde

 

Bouw de thema's niet op nummer maar op afhankelijkheid. Governance en afspraken eerst, want die zijn goedkoop en deels wettelijk verplicht. Daarna het fundament, want zonder taal en zonder aangewezen bronnen heeft de rest geen grond. Daarna pas de beheersing, want die werkt met wat er al staat.

 

 

Thema 1 en thema 6 staan niet in deze tabel. Aan thema 1 valt niets te bouwen, en thema 6 is de werkvorm waarin gebouwd wordt. De zeven die er wel in staan zijn de zeven waarin de eenendertig componenten vallen.

 

Deze tabel is een voorzet. De niveaus per jaar staan in het groeipad van deel 5 datadoelarchitectuur en de AI-doelarchitectuur, en de kalender ervan is aan de changetafel vastgesteld.

 

 

6. Wat er tegelijk loopt, en waar het botst

 

De going concern is geen blok. Hij bestaat uit zes soorten, en ze botsen alle zes anders.

 

Het realisatieplan noemt baan vier, de going concern, in één adem.

 

Lopende programma's en projecten, wettelijke deadlines, onderhoud, releases, vervangingen. Daar, in het realisatieplan, werd die baan begrensd. Aan de realisatietafel wordt hij uitgevoerd, door dezelfde mensen die bouwen.

 

In het realisatieplan is baan vier één aandachtsgebied, en daar is dat genoeg. Je hoeft daar alleen te weten hoeveel capaciteit hij verbruikt.

 

Aan de realisatietafel is dat te grof, want de soort botsing bepaalt welke beslissing helpt. Op de mensen helpt een andere verdeling. Op de taal helpt alleen een ander moment. Op de datum helpt niets en schuift de bouw. Daarom zes soorten, elk met de plek waar ze de bouw raken.

 

Kleine veranderingen en verbeteringen. Botsen op de mensen.

Ze verbruiken capaciteit in stukjes en staan nergens op een kalender. Kleine veranderingen zijn de soort waar de bouw stilletjes op vastloopt, want niemand kan aanwijzen waar de tijd heen ging.

 

Procesoptimalisaties. Botsen op de taal

En dit is de gevaarlijkste. Wordt een proces geoptimaliseerd terwijl in stap 5 het model van datzelfde domein wordt gevuld, dan beschrijft die woordenlijst bij oplevering een werkwijze die niet meer bestaat. Het model is stilletjes onwaar geworden en niemand merkt het.

 

Applicatieoptimalisatie en vervanging. Botsen op de bron.

Voor applicatieoptimalisatie en vervanging geldt de regel uit stap 4: wat toch vervangen wordt, wordt datacentrisch vervangen. Maar dan moet deze tafel wel weten dát er vervangen wordt, en dat staat in het contractenregister en niet in het bouwkader.

 

Lopende programma's en projecten. Botsen op de planning.

Ze verbruiken de schaarse profielen en de releasevensters, en het realisatieplan telt ze al in de capaciteitsplanning.

 

 

 

Wettelijke en toezichtverplichtingen. Botsen op de datum.

Wettelijke en toezichtverplichtingen zijn als enige niet te verschuiven, en dat maakt ze tot de eerste die je inplant en de laatste waarover je onderhandelt.

 

Onderhoud, releases en storingen. Botsen op het venster en op de beheercapaciteit.

Storingen zijn per definitie ongepland, dus je plant geen storingen maar wel de ruimte ervoor.

 

Zes soorten, zes botsingen: op de mensen, op de taal, op de bron, op de planning, op de datum en op het venster. Elke botsing komt als markering op de bouwkalender te staan, en daar valt het besluit.

 

Vier eigen beslissingen en één deur

 

Wat mag deze realisatietafel zelf beslissen, en wanneer moet het omhoog naar de changetafel? Dat is de vraag waar een bestuurder het antwoord op wil hebben, en het past in vijf regels. De grens erachter is één zin: een eigen beslissing verandert wanneer en door wie iets gebeurt, niet wat er gemaakt wordt en niet op welk niveau.

10. De volgorde. Welke ontwikkeling gaat deze maand voor, binnen het kwartaal waarin de changetafel hem heeft gezet.

11. De capaciteit. Wie werkt waaraan, binnen de dagen die zijn toegewezen. Niet meer dagen, wel een andere verdeling.

12. Het tempo per stap. Een stap mag wachten. Meestal wacht stap 5 op de eigenaar, en dat is een keuze die je maakt en niet een vertraging die je ondergaat.

13. Het venster. Bouw en going concern uit elkaar trekken in de release, zodat ze elkaar niet in hetzelfde weekend raken.

En één schakel omhoog. Alles in de going concern wat het niveau, een datadomein, de voorzieningenlijst of een kader raakt, gaat terug naar de changetafel. Dat is dezelfde grens als in stap 6, maar dan over de hele kalender in plaats van over één ontwikkeling.

 

Deze vier beslissingen veranderen het tempo en de verdeling. De vier deuren van het realisatieplan veranderen de route. Een realisatietafel die aan de deuren gaat draaien, heeft de changetafel overgenomen.

Omdat de grens in één zin past, is dit ook echt een beslissing en geen gevoel. De feiten staan op de bouwkalender, de conclusie is er een van vier, en de vijfde uitkomst is dat hij terug moet naar de changetafel. Dat laat zich vastleggen in een beslismodel, net als de beslismodellen die in stap 5 gevuld worden.

 

Wat je wanneer doet

 

Elke maand komt de realisatietafel bijeen met de bouwkalender erbij. Vier dingen staan vast op die agenda.

14. De stand per baan. Welke tussenbaat is zichtbaar geworden, welke vinkjes staan er werkelijk, welke voorziening staat in welke stap, en wat er uit de going concern loopt.

15. De botsingen die zich aandienen, met de zes soorten als checklist. Per botsing een eigen beslissing of een gang naar de changetafel.

16. De afwijkingen waarvan de houdbaarheidsdatum binnen twee maanden verloopt.

17. De eigenaren die hun dagdelen niet hebben gehaald, want dat is de eerste voorspeller van vertraging.

Elk kwartaal gaat datzelfde beeld mee naar de changetafel, als onderlegger bij de vier deuren. De changetafel beslist dan per ontwikkeling: doorgaan, bijstellen, verplaatsen of anders realiseren.

 

Wat de realisatietafel daar meebrengt is geen voortgangsrapportage maar de bouwkalender zelf, met de botsingen die zij niet zelf heeft kunnen oplossen. Dat is het verschil tussen melden en vragen.

 

Eén regel eronder. Wat niet op deze kalender staat, gebeurt gewoon. En het gebruikt dezelfde mensen.

 

7. Wat de omvang van je organisatie verandert

 

De architectuur verandert niet door de omvang van je organisatie . De vorm en het niveau wel.

 

Kort, want dit is geen beschouwing maar een keuze die je bij de start maakt. Zoek je eigen kolom en werk daarin.

 

 

Drie dingen kosten hetzelfde bij tien als bij tienduizend mensen, want het zijn afspraken en geen investeringen.

18. De domeinenkaart met eigenaren.

19. De aanwijzing welke bron geldt.

20. De vastlegging wie waarover besluit.

Sla die drie niet over omdat je klein bent. Dat is precies het deel dat gratis was.

En omgekeerd: wat wel schaalt, kun je ook uitstellen. Het geheugen, de kwaliteitsbewaking en de agentlaag hebben volume nodig voordat ze lonen.

 

Eén waarschuwing voor wie diep in één leveranciersstack zit. Het geheugen is dan bijna altijd te koop bij diezelfde leverancier. De goedkoopste route, en tegelijk de route die de afhankelijkheid vergroot. Dat is geen technische vraag maar een bestuurlijke, en hij hoort terug naar de changetafel.

 

8. Van capaciteit naar teams

 

Het realisatieplan wijst capaciteit toe aan ontwikkelingen. In dit plan wijs je mensen toe aan werk.

 

Er is één onderscheid dat die stap eenvoudig maakt. Een voorziening wordt eenmalig gebouwd en meervoudig gebruikt. Dat is per definitie iets wat een vast team levert aan andere teams, als dienst.

 

Een ontwikkeling uit het bouwkader is iets anders. Die loopt langs een stuk van het bedrijf, van begin tot eind, en hoort bij een team dat op die stroom werk zit.

 

Wanneer wordt iets een project en wanneer kan het in de lijn.

 

Dezelfde grens als bij de projectstartarchitectuur. Raakt een ontwikkeling meer dan één voorziening, dan moet iemand tussen die voorzieningen de volgorde bewaken, en dat is een project.

 

Een voorbeeld. Een ontwikkeling die de datacatalogus vult en tegelijk de gegevensuitwisseling aanpast, raakt twee voorzieningen met twee eigenaren en twee planningen. Iemand moet bepalen wat eerst af moet, en dat is niemand van de twee. Raakt een ontwikkeling maar één voorziening, dan hoort het werk bij de eigenaar van die voorziening en gaat het in zijn eigen ritme.

Een tweede voorbeeld. Een extra kwaliteitsmeting op een datadomein dat al op de datakwaliteitsvoorziening is aangesloten. Eén eigenaar, één planning, één besluit. Een project eromheen levert dan een stuurgroep op en geen dag winst.

 

En één regel die je niet kunt wegplannen. Wie een team een voorziening erbij geeft zonder er iets af te halen, doet hetzelfde als een portfolio dat de going concern niet telt. Het werk verdwijnt niet, het wordt onzichtbaar, en het komt terug als vertraging. Deel 7 heeft daar een naam voor: de absorptiegrens per afdeling. Die staat in de capaciteitsplanning die je meekrijgt, en ze is geen richtlijn maar een getal waar de changetafel op heeft besloten.

 

Bijlage C laat zien waar het onderscheid tussen een voorziening en een ontwikkeling vandaan komt, en wat ervan bruikbaar is.

 

9. De negen stappen per ontwikkeling

 

Van het bouwkader dat binnenkomt tot de terugmelding aan de changetafel.

Figuur 6. De negen stappen van bouwen en configureren, per ontwikkeling, met wat elke stap oplevert.

 

Tot hier ging het over de bouwkalender als geheel. Vanaf hier over één ontwikkeling daarvan.

 

De negen stappen gelden voor wat uit de disruptie komt en voor wat uit de going concern komt en meer dan één voorziening raakt. Voor een kleine verandering binnen één voorziening is dit te zwaar; daar volstaat de gewone beheerroute.

 

Elke stap sluit af met vier regels: wie erbij zit, wat je oplevert, waaraan je ziet dat je klaar bent, en de valkuil.

Bij stap 5, stap 6 en stap 7 staat er één regel extra, wat je hoort en niet ziet. Dat zijn de drie momenten waarop het geloof in een bouw wegvalt zonder dat de planning het laat zien.

Bijlage D legt uit waarom juist een bouwschakel daar gevoelig voor is.

 

Stap 1. Lees het bouwkader en maak de bouwopdracht

 

Het kader zegt niet hoe je bouwt. Het zegt waarbinnen.

 

Het bouwkader komt van de changetafel.

Eén A4 per ontwikkeling, plus een vaste bijlage voor wat aantoonbaar moet zijn.

Op dat A4 staan negen dingen, in de woorden van deel 7:

1. de doelstelling waaraan deze ontwikkeling bijdraagt met de eigenaar erbij;

2. de componenten die geraakt worden en het niveau dat gehaald moet zijn;

3. de datadomeinen die de ontwikkeling nodig heeft en welke vinkjes daar al staan;

4. de voorzieningen waarop wordt aangesloten;

5. de kaders die gelden;

6. de nulmeting van het bestaande fundament met de norm en de naam van de eigenaar daarvan;

7. het stuur- en controlepunt waarmee gemeten wordt of het werkt;

8. de vier deuren met hun signalen;

9. de verwachte tussentijd van deze ontwikkeling, en wat er in die maanden voorzien moet worden.

 

Lees het, en herschrijf het niet. Een realisatietafel die haar eigen opdracht herformuleert, heeft de changetafel overgeslagen.

 

Wat je wel doet: de definition of done eruit afleiden. Die volgt uit twee dingen die al vaststaan. Het niveau dat in het bouwkader staat, en de zes vinkjes van de datadomeinen die de ontwikkeling raakt: een eigenaar, een woordenlijst, een aangewezen bron, een vermelding in de catalogus, een kwaliteitsmeting en toegangsregels.

 

Aanscherpen mag. Verlagen niet.

 

Wie de definition of done laat bepalen door het team, laat de lat bepalen door wie eroverheen moet springen. In Scrum staat dat trouwens net zo hard: is de definition of done een standaard van de organisatie , dan moeten alle teams die minimaal volgen.

 

Kenmerkend voor de definition of done .

 

Wie erbij zit. De solution architect en de eigenaar van de ontwikkeling. Niet het hele team, want er valt nog niets te bouwen.

 

Wat je oplevert. Een bouwopdracht op één A4, met de definition of done eronder als afgeleide en niet als afspraak.

 

Klaar als. De eigenaar het niveau herkent en de definition of done zonder discussie uit het kader volgt.

 

De valkuil. Het gesprek over de definition of done openen. Dat gesprek hoort aan de changetafel, en daar is het al gevoerd.

 

Stap 2. Maak de testcase, voordat je bouwt

 

Een testcase die je pas achteraf bedenkt, toetst de aannames van de bouwer.

 

Dit is de stap die het vaakst wordt overgeslagen, en het is de stap die de rest draagt.

 

Een testcase is in deze keten geen scenario dat een tester later bedenkt.

Het is één herkenbare operationele situatie, vooraf besproken en vastgelegd, met de mensen erin die het werk werkelijk doen.

 

Rollen die een proces uitvoeren, een keuze maken, data valideren en beoordelen, en het resultaat terugzien in het instrument dat ze toch al gebruiken.

 

Bespreek met de eigenaar en met twee of drie mensen uit de situatie zelf. Laat ze de situatie vertellen in hun eigen woorden. Schrijf op wat ze zeggen, niet wat het systeem zou moeten doen.

Reken op een dagdeel. Meer kost het niet, en minder werkt niet.

 

De testcase doorloopt vijf stappen, en elke stap draagt één vraag.

10. Handelen. Kan de rol zijn stap zetten, in zijn eigen werkvorm en met het mandaat dat hij heeft.

11. Verwerken. Wordt wat hij invoert gevalideerd, en volgens welke vastgelegde regel.

12. Onthouden. Landt het met zijn herkomst erbij. Wie, wanneer, op grond waarvan.

13. Besluiten. Is het besluit dat eruit volgt herleidbaar tot een mandaat, en staat vast wie het nam.

14. Terugzien. Ziet de rol het resultaat terug in zijn eigen instrument. En klopt dat getal met wat iemand anders in een ander instrument ziet.

Die laatste vraag staat in geen enkel standaard testprotocol, en hij is van de vijf de belangrijkste. Het is de test die twee managers met twee verschillende getallen uitsluit, en dat is precies het probleem waarvoor de hele datadoelarchitectuur bestaat.

 

 

Kenmerkend voor de testcase .

 

Wie erbij zit. De eigenaar van de voorziening en de rollen uit de situatie. Niet de bouwer, en niet de tester alleen.

 

Wat je oplevert. Eén testcase-record, met de situatie, de rollen, de keuze, de data en de instrumenten. Bijlage B geeft de velden.

 

Klaar als. De mensen uit de situatie hun eigen werk erin herkennen zonder uitleg.

 

De valkuil. Een situatie kiezen waarin geen keuze zit. Dan test je een invoerscherm en geen voorziening.

 

Stap 3. Vul de projectstartarchitectuur

 

Van documenten naar data. Van de zes blokken vul je er zelf één in.

 

Het bouwkader zegt wat er moet en waarbinnen. Nu moet iemand opschrijven hoe dat binnen dat kader gaat gebeuren, zodat een ander het kan toetsen.

 

Wat iemand dan opschrijft, heet de projectstartarchitectuur.

 

Het bouwkader komt van de changetafel, dit stuk komt van deze tafel. Twee stukken, twee tafels, één richting.

Er staan zes blokken in de projectarchitectuur.

1. Wie de ontwikkeling is, wie eigenaar is, en wat de status is.

2. Waar het stuk op antwoordt: de bedoeling, de grens, de meetlat en het niveau.

3. Wat de ontwikkeling raakt: voorzieningen, datadomeinen, bestaande systemen en te vullen modellen.

4. Hoe er gebouwd wordt: kopen, configureren of bouwen, de standaarden, de definition of done, de testcase en de overdracht naar beheer.

5. Waar wordt afgeweken, met verwijzingen naar het afwijkingenregister.

6. Wat de ontwikkeling raakt buiten zichzelf: andere ontwikkelingen, de going concern, de beschikbaarheid van de eigenaar.

Van die zes vul je er zelf één in, en dat is het vierde blok. Hoe er gebouwd wordt.

De rest komt ergens vandaan. Het bouwkader levert de opdracht, het componentenregister levert de niveaus, het domeinenregister levert de vinkjes, en het afwijkingenregister levert de afwijkingen.

 

Daarom: maak er geen document van maar datavelden, met verwijzingen naar wat er al ergens staat. Dat scheelt niet alleen typewerk. Het zorgt er ook voor dat het stuk blijft leven tijdens de bouw in plaats van te verstenen bij de start. Wat verandert, verandert zichtbaar en met een datum.

 

Eén projectstartarchitectuur per ontwikkeling die meer dan één voorziening raakt. Daaronder volstaat het bouwkader zelf. Zonder die grens krijgt elke configuratieklus een architectuurdocument, en dan is de projectstartarchitectuur binnen een half jaar nutteloos. Dat is precies de reden dat ze in veel organisaties een slechte naam heeft.

 

En let op één veld dat in elk los document ontbreekt: welke andere ontwikkelingen dezelfde voorziening of hetzelfde datadomein raken. Het register weet dat, dus niemand hoeft het op te schrijven. Daar komt in de praktijk de meeste ellende vandaan.

 

Kenmerkend voor de projectstartarchitectuur .

 

Wie erbij zit. De solution architect, samen met de eigenaar van de voorziening.

 

Wat je oplevert. Een gevulde projectstartarchitectuur met de status op vastgesteld. Bijlage A geeft alle velden, met per veld of hij overgenomen, gekozen of afgeleid is.

 

Klaar als. Het testcase-veld gevuld is. Zonder testcase kan de status niet op vastgesteld.

 

De valkuil. Velden overtypen in plaats van verwijzen. Dan heb je twee waarheden en geen bron, en dat is dezelfde ziekte als twee managers met twee getallen.

 

Stap 4. Kijk wat er al staat, en sluit aan waar het kan

 

Een voorziening bouw je één keer. Wat je per ontwikkeling bepaalt, is de aansluiting.

 

Bij deze stap gaat het in de praktijk het vaakst mis, en de oorzaak is een begrippenpaar dat door elkaar loopt.

 

Component en voorziening zijn niet hetzelfde

 

Een component is de waarde-eenheid.

Alles wat gepland, gefinancierd en gebouwd moet worden. Achtendertig stuks, zeventien uit de datadoelarchitectuur en eenentwintig uit de AI-doelarchitectuur.

 

Een voorziening is de beheerseenheid.

Wat je eenmalig bouwt en meervoudig gebruikt. Aan de datakant zijn dat er zes, en ze staan met naam in deel 5:

1. bronregistraties, per domein één plek die geldt;

2. gegevensuitwisseling, gegevens reizen via één voorziening en niet via honderd koppelingen;

3. de datacatalogus, waar staat wat, wat betekent het, wie is eigenaar;

4. datakwaliteit, meten en signaleren als doorlopend proces;

5. analyse en historie, het geheugen;

6. AI en voorspellen, dat op de andere vijf landt.

Deel 5 is er streng over, en die regel geldt aan de realisatietafel onverkort. Voorzieningen worden niet per initiatief gekozen. Ze zijn generiek, je bouwt ze één keer. Wat je per ontwikkeling wél bepaalt, is de aansluiting. Welk datadomein sluit wanneer op welke voorziening aan, en op welk niveau.

 

Twee vragen, in deze volgorde

 

De eerste vraag. Welke voorzieningen heeft deze ontwikkeling nodig, en bestaan ze al? Bestaat er een, dan sluit je erop aan en bouw je niets. Dat is het hele punt van eenmalig vastleggen en meervoudig gebruiken.

De tweede vraag, en alleen voor wat er nog niet is. Kopen, configureren of bouwen.

Die tweede keuze valt één keer, voor de hele organisatie, en geldt daarna voor iedereen die erop aansluit.

 

Daarom vraagt bouwen een reden en configureren niet. Wat je configureert blijft van de leverancier. Wat je bouwt is voor altijd van jou, en dat is soms precies wat je wilt.

In de projectstartarchitectuur staat per voorziening welke van de twee vragen aan de orde was.

 

En nu iets ontzenuwen

 

Voordat je aan het bouwen denkt.

 

D e datadoelarchitectuur vraagt niet om een groot nieuw datasysteem. Dat is te controleren aan de zeventien componenten zelf.

 

De domeinenkaart en de domeinmodellen zijn taal. Acht domeinen met een eigenaar, per domein een woordenlijst met spelregels. Dat is geen systeem, dat is een afspraak die je vastlegt en die iemand beheert.

 

De bronregistraties zijn een aanwijzing. Per domein één plek die geldt. Je wijst het bedrijfssysteem aan als bron voor klant en verbruik, en het geografisch systeem voor assets en leidingen. Je bouwt niets, je schrijft op wat al waar is.

 

De datacatalogus is een lijst met metadata. Bij een kleine organisatie een spreadsheet, bij een grote een product met een beheerder.

 

Gegevensuitwisseling en het externe koppelvlak zijn koppelingen, en die bestaan meestal al.

De koppeling die ervoor zorgt dat een monteur bij zijn werkorder de leidinginformatie ziet, wordt niet gebouwd maar erkend en gedocumenteerd.

 

Datakwaliteit is een meting en een routine, geen platform.

 

De Governance componenten zijn mensen en afspraken.

 

Logging en toegang staan er bijna elke organisatie al in, want dat eist de wet.

 

Wat overblijft is analyse en historie, component negen.

 

Het geheugen. Dat is het enige component van de zeventien dat een echt nieuw platform vraagt, en het is te koop bij meerdere aanbieders.

 

Figuur 7. Bouwen op wat er al staat. Twee lagen erbij, niets eruit, en elk systeem wordt datacentrisch vervangen zodra het aan de beurt is.

 

Ernaast, eroverheen of erin

 

Geen van drieën. Er komen twee lagen bij en er gaat niets weg.

 

Boven de bestaande systemen komt de taal.

De domeinenkaart, de woordenlijsten, de catalogus, de beslismodellen. Die raken die systemen niet aan, ze maken ze leesbaar.

 

Naast de bestaande systemen komt het geheugen.

Het leest uit de bronnen en houdt vast wat er was, over de domeinen heen.

 

En de bestaande systemen blijven bron.

Wie net zwaar heeft geïnvesteerd in een vernieuwd fundament, gaat dat niet ombouwen omdat de architectuur mooier kan.

 

En wat als een systeem toch vervangen wordt

 

Elk systeem heeft een moment waarop het aan vervanging toe is.

 

Een contract loopt af, een versie wordt niet meer ondersteund, een leverancier stopt, de afschrijving is rond.

 

Daar zit de praktische regel van deze hele schakel. Vervang niets vanwege de architectuur, en vervang alles datacentrisch zodra het toch vervangen wordt.

 

Datacentrisch vervangen betekent drie eisen bij elke vervanging.

7. Het nieuwe systeem levert zijn data aan het geheugen, in de taal van de domeinenkaart.

8. Het nieuwe systeem is niet de enige plek waar zijn data leesbaar is.

9. En bij de aanbesteding staat de datalevering in het bestek en niet in de wensenlijst.

Met die drie eisen wordt het landschap datacentrisch zonder dat er één euro extra naar migratie gaat. Het duurt langer, en dat is de prijs. Het kost niets extra, en dat is de winst. Eerder vervangen mag natuurlijk, als dat goedkoper of effectiever is, maar dan is dat een besluit met een reden en geen gevolg van de architectuur.

 

Kenmerkend voor het bouwen .

 

Wie erbij zit. De solution architect, de eigenaar van de voorziening, en bij vervanging de eigenaar van het bestaande systeem.

 

Wat je oplevert. Per benodigde voorziening: aansluiten op wat er staat, of de keuze kopen, configureren of bouwen met de reden erbij. En per geraakt systeem de rol: bron, afnemer, of wordt vervangen.

 

Klaar als. Er maximaal één voorziening in de lijst staat waar bouwen bij staat. Staan er drie, ga dan terug naar de vraag wat er echt niet te koop is en wat er echt nog niet staat.

 

De valkuil. Een voorziening opnieuw bouwen omdat de bestaande niet precies past bij deze ontwikkeling. Dan is het geen voorziening meer, en dan vervalt de hele winst van eenmalig vastleggen.