Native werkt al sinds de beginjaren met architectuurplaten voor gemeenten. Collega Martin van Dijk was er vanaf het begin bij. In dit interview blikt hij terug op de ontwikkeling van architectuurplaten: van handgetekende Visio-overzichten tot dynamische architectuurmodellen die gemeenten helpen sturen, verantwoorden en verbeteren.
Wie een gemeente van binnen kent, weet: het applicatielandschap is zelden eenvoudig. Gemeenten voeren tientallen soorten taken uit, van burgerzaken tot sociaal domein, van vergunningverlening tot openbare ruimte. Al die domeinen hebben hun eigen processen, applicaties, gegevensstromen, leveranciers en landelijke voorzieningen. Juist daarom begon Native al vroeg met het maken van architectuurplaten. Niet als doel op zich, maar als middel om grip te krijgen. Grip op complexiteit. Grip op samenhang. En vooral: grip op verandering. We spreken met Martin van Dijk, die vanaf de beginperiode betrokken was bij de ontwikkeling van deze aanpak.
Architectuur is niet van I&A. Architectuur is voor de business.
“Het mooie is: architectuurplaten werden al gemaakt door de voorloper van Native. Phanos Management Advies deed al veel voor gemeenten en begon rond 2010 met het maken van dit soort platen. In het begin gebeurde dat nog echt met de hand, in Visio. De eerste versies waren vooral tekeningen van applicaties en koppelingen. Maar wat toen al bijzonder was: we keken niet alleen naar de applicaties zelf. We vroegen ook meteen: waar ontstaat data? Wie gebruikt die data? Welke persoonsgegevens worden waar verwerkt? Toen ik in 2012 bij Native begon, waren er al een paar van die platen gemaakt. Die aanpak hebben we daarna verder uitgebouwd.”
“Eigenlijk hetzelfde als nu: grip krijgen op het landschap van de gemeente. Een gemeentelijk applicatielandschap is complex. Dat komt doordat een gemeente eigenlijk bestaat uit heel veel verschillende ‘bedrijfjes’ onder één dak. Burgerzaken is iets heel anders dan het sociaal domein. Openbare ruimte is weer iets anders dan ruimtelijke ontwikkeling. Al die onderdelen hebben eigen processen, eigen applicaties en eigen informatiebehoeften. Het is dus helemaal niet vreemd dat een gemeente honderden applicaties heeft. Maar dan moet je wel weten: wat hebben we eigenlijk? Hoe hangen die applicaties samen? Welke gegevens gaan waar naartoe? En welke landelijke voorzieningen of externe partners zijn verbonden met dat landschap? Daarnaast waren de platen vanaf het begin ook een communicatiemiddel. Niet alleen voor I&A, maar juist ook voor de business.”
Met zo’n plaat kon je aan lijnmanagers laten zien: dit is het landschap waar jouw medewerkers dagelijks in werken. Dit is waarom beheer, verandering of verbetering soms ingewikkeld is.
“Precies. Dat is altijd het verschil geweest in onze manier van kijken. Natuurlijk moet de techniek kloppen, maar wij hebben architectuurplaten altijd gemaakt vanuit een functionele en businessgerichte blik. Er waren ook andere architectuurpartijen, maar die keken vaak veel technischer. Dan kreeg je platen met protocollen, componenten en technische details waar de business weinig mee kon. Onze aanpak was anders: we wilden iets maken dat ook in gesprek met managers, proceseigenaren en domeinverantwoordelijken bruikbaar was. Een architectuurplaat moest helpen om het gesprek te voeren. Wat gebeurt hier? Waar zit de afhankelijkheid? Wat betekent dit voor jouw afdeling? En wat gebeurt er als we iets veranderen?”
“We gingen met functioneel beheerders in gesprek en maakten applicatielijsten. Omdat we op een gegeven moment al meerdere gemeentelijke landschappen hadden gezien, konden we relatief snel een eerste plaat maken. Zeker in die tijd zag je dat gemeenten vaak bepaalde ‘smaken’ hadden. Je had bijvoorbeeld gemeenten met veel PinkRoccade-oplossingen en gemeenten met veel Centric-oplossingen. De technische patronen en koppelingen kwamen daardoor regelmatig terug. Als je een paar gemeenten had gezien, kon je vrij snel een eerste versie van een nieuw landschap opbouwen. Daarna bespraken we die plaat met de betrokkenen. Dan kwamen de echte vragen: is dit een handmatige koppeling? Worden bestanden overgezet? Gebeurt dit via FTP? Of wordt er dynamisch data uitgewisseld? In de periode rond 2010 tot 2015 kwam handmatig overzetten nog veel voor. Dan werd er letterlijk een bestand uit de ene applicatie gehaald en in een andere applicatie gezet. Door het landschap zichtbaar te maken, werd dat soort afhankelijkheid ineens bespreekbaar.”
“Zeker. Een voorbeeld is het kopiëren van inwonersgegevens. We kwamen situaties tegen waarin een kopie van gegevens uit Burgerzaken werd gebruikt in een applicatie in het ruimtelijk domein, bijvoorbeeld om te controleren of iemand op een bepaald adres woonde. Terwijl je eigenlijk een goede koppeling met de basisregistratie zou willen.
Voor de gebruiker werkte zo’n applicatie misschien prima. Maar aan de achterkant gebeurden dingen die risico’s met zich meebrachten: kopieën van gegevens, verschillen tussen administraties, onduidelijkheid over welke bron leidend was.
Later is door wet- en regelgeving, zoals de AVG, veel strenger geworden wat wel en niet mag met persoonsgegevens. Maar die architectuurplaten maakten al zichtbaar wat er in de praktijk gebeurde. Zonder zo’n overzicht was dat vaak niet zichtbaar voor de hele organisatie.”
“Ja, dat denk ik wel. In die periode ontstond ook steeds meer aandacht voor het principe ‘eenmalig registreren, meervoudig gebruik’. Dat sluit precies aan op wat wij met die platen inzichtelijk maakten. Als je niet weet waar gegevens ontstaan, waar ze gebruikt worden en waar kopieën bestaan, kun je ook niet goed sturen op informatiekwaliteit, privacy of beheer. Architectuur helpt om dat zichtbaar te maken.”
“In het begin waren het vooral Visio-tekeningen met daarnaast een aparte applicatielijst. Later hebben we die werelden meer met elkaar te verbonden, bijvoorbeeld met Excel-lijsten die gekoppeld waren aan de tekening. Maar we kwamen erachter dat dit onvoldoende was. Zo’n mooie A0-poster hing dan aan de muur. Als je geluk had, werden wijzigingen er met pen bijgeschreven. En soms belde een klant ons één keer per jaar met de vraag of we de plaat konden updaten. Het up to date houden van het overzicht maakte duidelijk: als je architectuur echt wilt gebruiken, heb je goede tooling nodig. Niet alleen een statische tekening, maar een beheersbaar model dat actueel kan blijven.”
“Ja. We hebben verschillende tools bekeken en geprobeerd. Uiteindelijk past BlueDolphin goed bij de manier waarop wij wilden werken. Niet alleen omdat je er landschappen mee kunt modelleren, maar vooral omdat het beter aansluit bij onze functionele manier van kijken. Wij zagen bovendien dat niet alleen grote organisaties behoefte hadden aan dit soort tooling. Juist kleine en middelgrote gemeenten hadden behoefte aan overzicht, maar dan wel op een manier die praktisch, betaalbaar en bruikbaar was. Daar hebben wij een rol in kunnen spelen.”
“Ja. Vroeger kon je in een paar weken een eerste applicatieplaat maken. Dat kan soms nog steeds snel, maar tegenwoordig gaan we vaak verder. Doordat we met architectuurtooling werken, kunnen we naast applicaties ook processen, gegevens, koppelingen en afhankelijkheden in kaart brengen. Dat maakt de waarde veel groter. Als een gemeente een proces wil verbeteren, kun je laten zien welke applicaties geraakt worden. En andersom: als een gemeente een belangrijke applicatie opnieuw wil aanbesteden, kun je laten zien welke processen, gegevensstromen en koppelingen daarmee samenhangen.”
De vraag is niet meer alleen: welke applicaties hebben we? De vraag is: wat gebeurt er als we hier iets veranderen?
“Dat architectuur helpt om betere beslissingen te nemen. Werken onder architectuur gaat veel verder dan een mooi plaatje maken. Je gebruikt architectuur om te begrijpen hoe je organisatie werkt, waar afhankelijkheden zitten en welke risico’s of kansen er zijn. Ik zeg vaak: architectuur is niet van I&A. Architectuur is voor de business. Natuurlijk heeft I&A een belangrijke rol, maar de waarde ontstaat pas echt als proceseigenaren, managers en bestuurders het kunnen gebruiken om keuzes te maken.”
“Ja, zeker. Wet- en regelgeving gaat organisaties steeds meer dwingen om hun informatiehuishouding aantoonbaar op orde te hebben. Denk aan het inzicht in applicaties, gegevensstromen, archivering en verwerking van persoonsgegevens. Een simpele lijst is dan niet meer genoeg. Je moet kunnen laten zien hoe je landschap in elkaar zit, waar informatie ontstaat, waar het naartoe gaat en welke systemen geraakt worden als er iets verandert. Daarom denk ik dat architectuur steeds minder vrijblijvend wordt. Het wordt een noodzakelijk instrument voor sturing, verantwoording en verbetering.”
“Ja. Een goed voorbeeld is het verwerkingsregister. Veel gemeenten houden dat nu bij in complexe spreadsheets of in losse documenten per applicatie of organisatieonderdeel. Dat is kwetsbaar en moeilijk actueel te houden. In een architectuurmodel kun je veel beter vastleggen welke applicaties persoonsgegevens verwerken, in welke processen dat gebeurt en wat de relatie is met systemen en gegevensstromen. Dan wordt architectuur nog belangrijker voor governance en compliance. Niet alleen beschrijven wat er is, maar ook helpen aantonen dat je grip hebt op wat er gebeurt.”
“Ik zie twee belangrijke mogelijkheden. De eerste is ondersteuning bij het maken van architectuurmodellen. Als je AI voedt met goede voorbeelden van gemeentelijke applicatielandschappen, kan AI helpen om sneller een eerste versie te maken. Gemeenten verschillen natuurlijk in namen, inrichting en keuzes, maar veel basisprocessen en patronen lijken sterk op elkaar. Met een lijst van applicaties en organisatieonderdelen kun je dan misschien al snel een eerste model genereren dat voor tachtig procent klopt.
De tweede mogelijkheid zit aan de proceskant. Veel gemeenten hebben procesbeschrijvingen in documenten of systemen staan. AI kan helpen om daar procesflows uit te halen, inclusief betrokken rollen, stappen en mogelijk zelfs applicaties. Als je dat koppelt aan architectuur, ontstaat een krachtig hulpmiddel om sneller inzicht te krijgen. Op termijn kan AI misschien zelfs helpen bij procesverbetering. Als je veel goede voorbeelden kent, kun je ook aanbevelingen doen: zo ziet een goed ingericht proces eruit, en hier wijkt jouw proces af.”
“Ja. We hebben door de jaren heen veel gemeentelijke landschappen gezien. Daar zit enorm veel kennis in. Natuurlijk moet je zorgvuldig omgaan met klantdata, maar op geanonimiseerd niveau kun je daar patronen uit halen. Je zou kunnen zeggen: we kunnen leren van een soort ‘kunstmatige gemeente’, gebaseerd op reële patronen uit de praktijk. Daarmee kun je blauwdrukken ontwikkelen die gemeenten helpen sneller te starten en betere keuzes te maken.”
“Minder dan ze soms denken. Natuurlijk heeft iedere gemeente eigen accenten, maar 90 tot 95 procent van de processen is vergelijkbaar. Een omgevingsvergunning of een bijstandsaanvraag volgt voor een groot deel dezelfde wettelijke logica. De verschillen zitten vaak in beleidsruimte of lokale keuzes. De ene gemeente hanteert bijvoorbeeld andere grenzen of regelingen dan de andere. Maar het primaire proces lijkt sterk op elkaar. Dat maakt architectuur ook zo interessant. Je kunt patronen herkennen en hergebruiken, zonder de lokale context te negeren.”
“Doorgaan met architectuur als belangrijk onderdeel van onze dienstverlening. En vooral blijven uitdragen dat architectuur onlosmakelijk verbonden is met een succesvolle informatiehuishouding.
We moeten nog beter vertellen dat architectuur niet iets technisch is dat ergens binnen I&A hoort. Het is een instrument voor de hele organisatie.
Voor Native blijft het ook een manier om snel inzicht te krijgen in de complexiteit van de gemeentelijke wereld. Nieuwe collega’s leren door architectuur hoe processen werken, hoe functioneel beheer werkt en hoe bijzonder complex én interessant gemeenten zijn.”
“Zeker. Rond 2013 kwamen de eerste signalen over de decentralisaties in het sociaal domein. Per 1 januari 2015 kregen gemeenten er grote taken bij, onder andere rond jeugdzorg, Wmo en participatie. Wij hadden in die periode wat ruimte en hebben die gebruikt om met de benen op tafel na te denken: hoe complex wordt dat sociaal domein eigenlijk? Welke organisaties spelen daarin een rol? Welke applicaties gebruiken zij? Welke gegevens gaan rond? Toen hebben we een integrale architectuurplaat van het sociaal domein gemaakt. Niet alleen van de gemeente zelf, maar van het hele domein met alle betrokken partijen. Die plaat hebben we actief gedeeld en die werd heel veel gedownload. Voor gemeenten maakte die plaat zichtbaar wat er op hen afkwam. Wat betekent deze decentralisatie? Welke complexiteit komt erbij? Waar moeten we rekening mee houden? Dat heeft Native destijds enorm geholpen om op de kaart te komen. Van Limburg tot Groningen hebben we gemeenten kunnen ondersteunen bij de voorbereiding op het nieuwe sociaal domein. Architectuur was daarin geen bijzaak, maar juist de manier om overzicht, gesprek en richting te creëren.”
Werken met architectuur: van overzicht naar verandering
De geschiedenis van architectuurplaten bij Native laat zien dat architectuur nooit alleen over techniek ging. Vanaf het begin stond de vraag centraal: hoe maken we complexiteit begrijpelijk, bespreekbaar en bestuurbaar? Wat begon als handgetekende Visio-platen, groeide uit tot een volwassen manier van werken met architectuurmodellen, processen, gegevens, applicaties en afhankelijkheden. Voor gemeenten betekent dat: beter inzicht, betere keuzes en meer grip op verandering. En misschien is dat nog steeds de kern van werken met architectuur: niet het plaatje zelf, maar het gesprek dat daardoor mogelijk wordt.
Wil je meer weten over dit onderwerp, neem dan contact op met Martin.
Partner / Adviseur
m.van.dijk@nativeconsulting.nl
Hier komt detail informatie over datagedreven besluitvorming.