![\"Dappermarkt](\"https://static.agconnect.nl/cropped/871a02a9-88ed-5906-a2e0-78d684d7cccf/article/09/90/099078ab-e98d-4bee-928e-fa456e7480cc/opening_image/opening_image_hero/dappermarkt_276890532_cda6b7fc4a_b.jpg\")
Lees het originele artikel op AG Connect
\n\nOntwikkelmethoden als agile development en lean startup onderschrijven het belang van de rol van de eindgebruiker, door deze vroeg en vaak te betrekken bij het ontwikkelen van software. Design thinking gaat daarin nog verder: de beoogde gebruikers worden niet alleen betrokken om gemaakte software te testen, maar ook om te bedenken wat voor software nodig is. Of zelfs om te beslissen óf er software nodig is.
\n\n
“One size fits none. Overheden moeten weer meer zelf gaan ontwikkelen. Ze hebben gekke processen,” stelt Maarten Geraets. Hij zette drie jaar geleden op verzoek van de gemeente Amsterdam het Datalab op. Zijn opdracht was om met een innovatief team datagedreven toepassingen te zoeken voor een aantal zeurende problemen in de stad. Geraets ontwikkelde daarvoor samen met zijn zakenpartner Johan Groenen de Fixxx-methode, ofwel Fast Innovation Amsterdam. Inmiddels zijn al verschillende projecten met succes afgerond.
\n", "date_published": "Thu, 01 Mar 2018 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2018/04/03/open-strategie-gemeente-amsterdam-loont/", "url": "https://www.jgroenen.nl/aantekeningen/2018/04/03/open-strategie-gemeente-amsterdam-loont/", "title": "Open strategie gemeente Amsterdam loont", "content_html": "Oorspronkelijke artikel gepubliceerd op iBestuur
\n\nHet aanpakken van overlast op straat of weten welke kraamhouders op de weekmarkt staan. Iedere gemeente zoekt er oplossingen voor, maar in Amsterdam zijn open source samenwerking en hergebruik van (open) databronnen daarbij leidend. Het leuke is dat het ook nog wat oplevert: qua financiën én qua manier van denken.
\n\n![\"\"](\"https://ibestuur-uploads.storage.googleapis.com/app/uploads/2018/03/2629.jpg\")
Sinds 2015 heeft de gemeente Amsterdam de beschikking over een DataLab. Aanleiding was een bezoek dat de toenmalige gemeentesecretaris aan Barcelona bracht en geïnspireerd raakte door de manier waarop de Spaanse stad omging met data. In Amsterdam was niet direct duidelijk hoe het DataLab er uit moest komen te zien. Helder was wel om meer data realtime in te zetten voor gemeentelijke processen, door middel van “innovatieve toepassingen”. Zo werd er gedacht aan een ruimte met meerdere schermen, waarop data uit de stad zichtbaar konden worden gemaakt. Maar die data waren er nog niet, of in ieder geval niet op een bruikbare manier beschikbaar. En welke data moesten dan als eerste beschikbaar worden gemaakt en wat heb je daar dan aan?
\n\nMet die vragen klopte de gemeente Amsterdam aan bij TiltShift en gezamenlijk werd gekozen voor een probleemgestuurde aanpak voor het opzetten van een afdeling innovatieve toepassingen. Dus zijn we op zoek gegaan naar tastbare problemen in de stad. Het eerste probleem dat we tegenkwamen was gebrekkige administratie van de straatmarkten. Daarvoor hebben we een concrete oplossing gemaakt: een digitaal bonnenboekje. Hiervoor gebruikten we een korte, intensieve methode: in veertien weken maken we een oplossing. Onder het motto ‘fail fast’ hebben we om te twee weken een uitstapmoment ingebouwd. Dat heeft als voordeel dat je snel resultaat kunt boeken, maar ook snel kunt besluiten om de stekker eruit te trekken. Deze methode wijkt af van veel andere innovatiemethodes; die focussen vaak vooral op innovatieve technologie, waar een probleem voor wordt gezocht. Dergelijke methoden leveren vaak wel mooie Proof of Concept-oplossingen op, maar verdwijnen uiteindelijk ergens onder in de kast.
\n\nDe methode, die Fixxx (Fast Innovation Amsterdam) is gaan heten, volgt Design Thinking principes: we doen alles met en vanuit de eindgebruiker. Dus liepen we dagelijks mee met de markttoezichthouders op hun rondes. Op basis van hun input en feedback ontwikkelden we wekelijks een volgende versie van de software. Daarbij werken we open source en maken zoveel mogelijk gebruik van bestaande (open) databronnen. Met het team is een modulaire infrastructuur opgezet van API’s (application programming interface), technische koppelingen. Die API’s zorgen ervoor dat data en applicaties losgekoppeld blijven en zorgt ook voor herbruikbare databronnen, die de spil vormen tussen verschillende applicaties in verschillende processen. Op die manier hebben we bijgedragen aan het tot stand komen van Datapunt Amsterdam, de plek waar alle data van de gemeente Amsterdam ontsloten, gebruikt en geanalyseerd wordt.
\n\nTot nu toe zijn zes Fixxx-projecten afgerond en wordt gewerkt aan een tweetal nieuwe trajecten (zie: kader). In de Fixxx-oplossingen speelt data vanwege het digitale karakter van de oplossingen vanzelfsprekend een rol. Maar hoe beter data vindbaar en bruikbaar zijn, hoe eenvoudiger wij deze ook kunnen incorporeren in onze oplossingen. Daarnaast zijn de oplossingen vaak zowel voor intern gebruik (door uitvoerende ambtenaren), als voor extern gebruik (door gebruikers van de stad). Als data ‘open’ zijn, dan hoeven wij als innovatieteam verder niks moeilijks te regelen voor het gebruik ervan. Daar is ook weinig tijd voor: een Fixxx-traject gaat zo snel (veertien weken), dat wachten op bureaucratische processen voor het aanvragen van toegang tot data geen optie is. Het gebruik van open data zorgt dus voor de nodige snelheid.
\n\nDe snelheid van open data is een van de voordelen die het werken volgens de Fixxx-methoden oplevert, maar ook op andere manieren wordt er ‘winst’ behaald. Dat heeft dan vooral te maken met het in cocreatie ontwikkelen, samen met uitvoerende organisaties. Dat levert die organisaties een groot aantal inzichten op, bijvoorbeeld over hun processen en manier van werken, hun dienstenaanbod, privacy en informatieveiligheid en software-systemen waar wel voor betaald wordt, maar die niet gebruikt wordt. Wat dat betreft is zo’n Design Thinking-traject veel meer dan een software-traject: het is een verandertraject, waarbij softwareontwikkeling wordt ingezet voor meer structuur. De besparingen vloeien voort uit verbetering van processen, dienstverlening (minder klachten), uitfaseren van in onbruik geraakte softwaresystemen en kortere doorlooptijden.
\n\nDe oplossingen die gemaakt worden met behulp van de Fixxx-trajecten zijn in eerste instantie bedoeld voor de gemeente Amsterdam, maar zijn ook voor andere overheden beschikbaar en interessant. Dat is een van de voordelen van opensourceontwikkeling. De trajecten worden betaald door de gemeente Amsterdam en die is van mening dat alle code die gefinancierd wordt uit publiek geld, ook publiek beschikbaar moet zijn. Hetzelfde geldt voor open data. Als er tijd is gestoken in het geschikt maken van data voor gebruik, is het zonde om het nog een keer te doen. Die houding is essentieel om effectief samen te bouwen aan de digitale overheid.
\n", "date_published": "Tue, 03 Apr 2018 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2018/04/18/gemeente-amsterdam-doet-het-zelf/", "url": "https://www.jgroenen.nl/aantekeningen/2018/04/18/gemeente-amsterdam-doet-het-zelf/", "title": "Gemeente Amsterdam doet ‘t zelf(s)", "content_html": "Gepubliceerd op iBestuur, 24 april 2018: “De gemeente Amsterdam ontwikkelt sinds twee jaar open source toepassingen in eigen huis. “Leveranciers houden de overheid vaak gegijzeld met ondoorzichtige software”, beweert Datalab directeur Berent Daan.” (https://ibestuur.nl/artikel/gemeente-amsterdam-doet-t-zelfs/)
\n\nDirecteur Berent Daan over het ontstaan van Datalab, onderdeel van Onderzoek, Informatie en Statistiek: “Ik ben in februari 2015 begonnen bij de gemeente Amsterdam met de opdracht om data kortcyclisch in te gaan zetten in primaire processen. Daarmee zijn we bij Datalab, de werkplaats voor data en datatoepassingen, begonnen door concrete softwareoplossingen te maken voor tastbare problemen. We begonnen met kleine procesapplicaties op basis van microservices, aan elkaar gekoppeld met API’s. Hierdoor waren data en toepassing duidelijk gescheiden met het oog op hergebruik. Al snel kwam Basisinformatie bij ons met de wens hun informatie ook zo te ontsluiten. Dat is de start geweest van Datapunt: het platform voor ontsluiten, gebruiken en analyseren van alle data van de gemeente Amsterdam. Ik werd daarbij geïnspireerd door Jeff Bezos, oprichter van Amazon. Die begon al in 2002 met het opdelen van zijn organisatie in serviceafdelingen, die met elkaar communiceerden via webportals. Dat maakt de diensten eenduidig herbruikbaar binnen en buiten de organisatie.”
\n\n“Nederland is groot geworden met innovaties in weg- en waterbouw van- uit de overheid. Een club van 100 ingenieurs bij de dienst IJsselmeerpolders dacht echt innovatief na over hoe we de dreiging van het water het hoofd konden bieden. Maar op het gebied van ICT hebben we als overheid vanaf het begin gezegd: daar hebben we geen verstand van, dat laten we aan de markt over. Ik wil die ingenieursmentaliteit terug bij de gemeente. Zodat we weer zelf bepalen hoe we ICT toepassen en écht snappen wat er gebeurt. Ontwikkelaars worden nu nog vaak afgeschrikt door de oude ICT-omgeving bij overheden. Weinig samenwerking, weinig ruimte voor nieuwe technieken, en werken aan software waar niemand naar omkijkt. Datalab is een veilige omgeving voor nieuwe technieken. We werken met multidisciplinaire teams die samen met de business beslissingen nemen, in plaats van een opdrachtgever-opdrachtnemer relatie. Ontwikkelaars zijn daarbij medeverantwoordelijk voor het resultaat. De namen van de ontwikkelaars staan bovenaan de gemaakte code. De belangrijke rol van ontwikkelaar wordt zo zichtbaar. Dat geeft voldoening, en maakt de overweging ‘op de markt kan ik meer verdienen’ onbelangrijk.”
\n\n“En alles is open source”, vervolgt Daan. “Leveranciers houden de overheid vaak gegijzeld met ondoorzichtige software. Ik wil af van de situatie waarin de overheid voor kernfuncties afhankelijk is van een markt die dicteert hoe we processen moeten inrichten, terwijl dat vaak verre van optimaal is. Open source is een manier om deze situatie open te breken. Ik wil de vrijheid om dit aan te passen, en open te kunnen delen met andere overheden. Open source legt veel verantwoordelijkheid bij technische mensen. Die werden daarvoor gezien als uitvoerend. Nu betrek je ze ineens op alle niveaus, want technologie is inhoudelijk. Als een ontwikkelaar kiest voor een bepaalde technische oplossing, dan kan dat organisatorische consequenties hebben. Waar fouten eerder op een leverancier werden afgeschoven, is de gemeente nu zelf verantwoordelijk. Dat is voor management en politiek soms wel spannend.”
\n\n“Ik denk dat het BRP-falen van vorig jaar voorkomen had kunnen worden door vanaf het begin met open source te werken. Als iedereen meekijkt kan er geen onduidelijkheid ontstaan over wat er in zo’n project gebeurt. Kritische professionals kunnen tijdig feedback geven. Als je vanaf het begin open source werkt, dan ben je je ook bewust van de veiligheidsrisico’s en privacyrisico’s. Dat stimuleert privacy by design. In veel projecten zit een privacyaspect. Denk aan applicaties rondom armoede of zorgverlening. Dan wil je ook tijdens de ontwikkeling garanderen dat er nul dingen online komen die daar niet mogen staan. Bij Datalab hebben we daar processen voor ingericht: een quick scan en een assessment. Dat zijn geen zware procedures. Doordat je gedwongen wordt om met je billen bloot te gaan, gaan we dit soort dingen ook professioneler aanpakken. Er is een maatschappelijke zorg over verlies van controle over onze informatie. Juist door toepassingen te maken ontdekten we dat processen rondom beveiliging en privacy ontbraken. We ontdekten dat wat mag los moet staan van wat technisch mogelijk is. Door te doen leren we snel wat we willen, wat we mogen en hoe dat veilig en snel ook kan. We willen transparant zijn over hoe we data gebruiken, ontsluiten en combineren. Daarvoor is open source cruciaal. De oplossingen die we maken zijn door de buitenwereld controleerbaar. Op die manier kan iedereen ons wijzen op kwetsbaarheden als die er zijn.”
\n\nWaarom zouden andere gemeenten moeten kunnen meeliften op software die op kosten van de Amsterdammers is ontwikkeld? Berent Daan: “De essentie van open source is dat je over je eigen schaduw heen kunt springen. Zodat er een dusdanige schaal komt dat je er zelf ook weer van gaat profiteren. Daarbij betaal je voor open source ontwikkeling niet meer dan voor aanbesteding conform specificaties, maar heb je wel de potentiële meerwaarde dat anderen die hergebruiken ook mee doorontwikkelen. Idealiter ontstaat er een community van ontwikkelteams bij verschillende overheden die van elkaar weten wat ze doen, constant kennis en informatie uitwisselen, en vooral ook code van elkaar hergebruiken. Ik wil dat gemeenten actief gaan investeren in open source ontwikkeling. Dat we bij aanbestedingen open source als voorwaarde opnemen. Dat we samen met andere overheden werken aan een netwerk van ontwikkelaars die deze toepassingen ontwikkelen, verbeteren en uitbouwen. En dat we samenwerken om de overheid interessanter maken voor ontwikkelaars.”
\n\nBoris van Hoytema is open source pleitbezorger bij Data punt Amsterdam, oprichter Foundation For Public Code. Johan Groenen is strategisch adviseur Innovatieve Toepassingen bij Datalab Amsterdam, secretaris Stichting Code for NL.
\n", "date_published": "Wed, 18 Apr 2018 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2019/09/02/open-source-voor-open-samenwerking/", "url": "https://www.jgroenen.nl/aantekeningen/2019/09/02/open-source-voor-open-samenwerking/", "title": "Open Source voor Open Samenwerken", "content_html": "Originele publicatie in iBestuur op 2 september 2019 https://ibestuur.nl/artikel/open-samenwerking/
\n\nDe kracht van open source is dat het ook ingezet kan worden bij dingen die je al doet of nog van plan bent te doen.
\n\nSinds een aantal jaar werk ik als adviseur binnen de digitale overheid. Steeds vaker zie ik daar nu ‘open source’ voorbijkomen als kernwaarde bij het ontwikkelen van nieuwe oplossingen. Dat vind ik op zich een positieve ontwikkeling. Bij open source wordt de broncode van een digitale oplossing (website, app, script, tool) online publiek beschikbaar gemaakt, zodat deze voor iedereen toegankelijk is.
\n\nDe meerwaarde hiervan wordt in voorstellen en projectplannen breed uitgemeten: transparantie van de gebruikte algoritmes, herbruikbaarheid van de gemaakte oplossing door andere organisaties, en minder afhankelijkheid van de softwareleverancier.
\n\nIn de praktijk blijkt de mentaliteit in overheids ICT-projecten vaak nog best wel ‘closed source’ te zijn: pas als het project is afgerond, wordt de code openbaar gemaakt. Vaak duurt het zelfs nóg een paar maanden, omdat de code geschikt moet worden gemaakt voor publicatie.
\n\nDat is jammer, want open source draait mijns inziens echter niet slechts om transparantie en hergebruik, maar om potentiële samenwerking. Samenwerking tussen programmeurs in verschillende organisaties die aan vergelijkbare oplossingen werken. En tussen overheid en de samenleving. Op die manier is er zicht op wat er precies gedaan wordt, en hoe dat vordert. En bestaat de mogelijkheid voor tussentijdse input, feedback, of zelfs bijdragen aan de ontwikkeling.
\n\nBij buitenlandse overheidsorganisaties zie je die open houding gelukkig steeds vaker terugkomen als de standaard bij de clubs die verantwoordelijk zijn voor de digitale transformatie en innovatie. Zo publiceerde het Engelse GDS meerdere artikelen over de waarde van open source voor innovatie binnen de overheid. Ook andere overheidsorganisaties wereldwijd zoeken vaker en vaker de open samenwerking, zowel intern als extern. Enkele goede voorbeelden zijn ook 18F in de VS, Piano Triennale) in Italië, en DTA in Australië.
\n\nDe kern is het opzoeken van open samenwerking! En dus niet het beschikbaar maken van dingen die je al gedaan hebt en die af zijn, maar juist van wat je aan het doen bent, en wat je van plan bent. En aan de andere kant ook altijd eerst kijken naar wat er al is, en welke plannen er liggen. Zo kun je op basis van gedeelde plannen de samenwerking aangaan.
\n\nCommon Ground is wat dat betreft een stap in de goede richting. De Nederlandse gemeenten bepalen hier gezamenlijk welke processen ze willen vernieuwen en maken er in samenwerking moderne, open source software voor. Common Ground richt zich echter vooral op nieuwe projecten, terwijl er ook veel lopende overlappende initiatieven zijn die baat zouden hebben bij samenwerking en kennisdeling.
\nMede daarom organiseren we vanuit Stichting Code for NL meetups voor developers en designers enerzijds, en ambtenaren anderzijds, die bezig zijn met het ontwikkelen van de digitale overheid.
Doel van Stichting Code for NL is vanuit de community van developers en designers bijdragen aan de succesvolle digitale transformatie van de Nederlandse overheid. We brengen lopende projecten over het voetlicht en proberen de mensen achter vergelijkbare initiatieven op één plek te krijgen om kennis, ervaring en code uit te wisselen. Dat sloopt de muren tussen organisaties en zorgt ervoor dat de digitale transformatie steeds meer als iets gezamenlijks gezien wordt. Daarna is open samenwerking slechts nog een kleine stap, maar een grote sprong voorwaarts.
\n\nJohan Groenen is Adviseur Digitale Innovatie bij Datalab Amsterdam; managing partner bij TiltShift, design- en innovatiebureau voor de publieke sector; en secretaris bij Stichting Code for NL, het Nederlandse netwerk van developers en designers die samenwerken aan een open en eerlijke digitale overheid en samenleving.
\n", "date_published": "Mon, 02 Sep 2019 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2020/01/01/digitaleoverheid-datagedreven-werken/", "url": "https://www.jgroenen.nl/aantekeningen/2020/01/01/digitaleoverheid-datagedreven-werken/", "title": "Datagedreven werken ondersteunt mensen in hun autonomie en professionaliteit", "content_html": "Digitale Overheid interview met Johan Groenen en Maarten Geraets, mede-oprichters TiltShift
\n\nJohan Groenen en Maarten Geraets stonden in 2015 samen met Joris Boeren aan de wieg van Datalab Amsterdam. Gedrieën richtten zij TiltShift op, een software design bureau voor probleemgedreven innovatie in de publieke sector. Na een reactie op de Toolbox Datagedreven werken spreken we Johan en Maarten over hun werk en de do’s en don’ts van datagedreven werken. Hoe moet datagedreven werken wèl en niét worden ingezet?
\n\nJohan: Ik zag een bericht voorbij komen van het Leer- en Expertisepunt Datagedreven werken (LED) over de Toolbox Datagedreven werken. Ik dacht meteen “daar zou onze Fixxx-methode ook wel tussen passen.” In Amsterdam werken we er namelijk al een aantal jaren met succes aan om data in werkprocessen te krijgen met deze methode. Daarom reageerde ik op jullie toolbox. Onze ervaringen van TiltShift zijn wat ons betreft een goede aanvulling zijn op de toolbox, omdat de link met de praktijk nu nog wat ontbreekt.
\n\nMaarten: Tiltshift is een public tech bedrijf, maar wij framen het als good public tech. Wij streven naar toepassingen die echt goed in elkaar zitten en die de mens centraal stellen. We werken daarvoor nauw samen met de mensen op de werkvloer voor wie we de toepassingen maken. Daarin zijn we anders dan traditionele softwaremakers. Zij maken eerst een toepassing om deze vervolgens bij een publieke instantie aan te bieden.
\n\nMaarten: Vijf jaar geleden gingen we van start met een datalab in Amsterdam. Dit werd al gauw een plek waar de gemeente verschillende nieuwe innovaties op het gebied van data kon laten plaatsvinden. Deze innovaties moesten bijdragen aan een breed gedragen data-ontsluiting in Amsterdam. Dat klinkt misschien heel abstract en daar hebben we juist daarom een concrete invulling aan gegeven. We hebben het datalab vormgegeven als programma, waar we vervolgens projecten in uitvoerden.
\n\nDie projecten waren allemaal innovatieprojecten. De methode die we hiervoor bedachten hebben we de Fixxx-methode genoemd, wat staat voor Fast Innovation Amsterdam. Inmiddels is de methode ook buiten Amsterdam in gebruik, maar de naam is blijven hangen.
\n\nWe vinden het heel belangrijk om dingen samen te ontwikkelen. We willen samen de problemen in bijvoorbeeld werkprocessen opsporen. Daar willen we vervolgens ideeën voor bedenken om ook samen tot een oplossing te komen. Een Fixxx-project beslaat een periode van drie maanden waarin we bekijken of we een tastbaar probleem kunnen oplossen:
\n\nDe eerste twee weken (Discovery) lopen we mee op de werkvloer, zodat we het probleem beter begrijpen. Dit doen we met het hele team, zowel designers als programmeurs. Is er bijvoorbeeld een probleem in het vuilniscollectieproces, dan rijden we in die twee weken ook mee op de vuilniswagens.
\n\nIn de twee weken daarna (Ideation) gaan we samen met alle betrokkenen aan de slag met het gestructureerd ontwerpen van een groot aantal mogelijke oplossingsconcepten.
\n\nUit de oplossingen die we gedurende die twee weken bedenken kiezen we er één uit die we in de derde fase (Development) van acht weken opbouwen tot een werkende applicatie. Deze implementeren we vanaf de eerste week in het proces. Op die manier krijgen we niet alleen wekelijks te horen wat de volgende stap moet zijn, maar zien we ook hoe de organisatie reageert op de nieuwe manier van werken. Daar kunnen we dan met de techniek op inspelen.
\n\nJohan: De link met datagedreven werken is dat veel mensen wel het idee hebben dat ze met data aan slag willen, maar dat het ze aan ‘iets’ ontbreekt om in actie te komen. Ze missen duidelijke tools om iets met data te kunnen doen.
\n\nManagers willen bijvoorbeeld, om bij het eerder genoemde voorbeeld van de vuilniscollectie te blijven, stuurinformatie om de routes en frequenties van vuilniswagens te optimaliseren. De data die zij daarvoor nodig hebben moet gegenereerd worden door de vuilnismannen. Die krijgen een scanner in de hand gedrukt waarin zij handmatig moeten aangeven welke bak zij hebben geleegd en hoe vol een bak ongeveer is. Dit moeten zij doen zonder dat zij echt weten waarom, terwijl het wel hun taken bemoeilijkt. Met als gevolg dat zij soms voor het gemak kiezen en dus altijd op de bovenste knop drukken (vuilnisbak vol). Dit zorgt voor onbetrouwbare data, waarop je beter geen beslissingen kunt nemen.
\n\nMaarten: Om tot een goede oplossing te komen, moet je weten wat er speelt. Zo bleek bijvoorbeeld ook dat de vuilniswagens soms in elkaars wijken reden. Dit had als effect dat men met de grote vuilniswagen door de nauwe stad manoeuvreerde, om uiteindelijk bij een bak uit te komen die al door een collega geleegd was. Dit leverde veel frustratie op. Als je een tool kunt geven waarop ze dat kunnen zien, dan heeft het voor medewerkers ook echt zin en levert het je direct ook waardevolle managementinformatie op.
\n\nJohan: Het wordt vaak omgedraaid. Mensen denken bij datagedreven werken vaak aan management-data en daarmee managementsturing. Managementsturing is een grote, langzame feedbackloop. Met datagedreven werken kun je echter veel kleinere feedbackloops maken, die veel zinvoller zijn voor de mensen in de uitvoering zelf. Daarom maken wij juist praktische apps voor in de uitvoering, die vervolgens data genereren voor de aansturing: ze kunnen iets met die gegenereerde gaan data doen. En ook dat levert weer data op. Zo krijg je voet tussen de deur om de datagedreven werkwijze langzaam op te bouwen.
\n\nJohan: Organisaties komen vaak met een managementwens, terwijl ze eigenlijk een operationeel probleem hebben. Het is vaak beter om dat operationele probleem op te lossen met data in het achterhoofd, dan om de managementwens te vervullen met data en het operationele probleem in het achterhoofd. Als je de echte problemen zo oplost, komt de data vanzelf.
\n\nDaarnaast is de acceptatie op de werkvloer belangrijk. Als je mensen niet vanaf het begin in het proces betrekt, kun je ze ook niet enthousiast maken voor de mogelijkheden die een datagedreven aanpak met zich mee brengt. Medewerkers moeten er wat aan hebben en daarvoor moet je weten wat er speelt.
\n\nMaarten: Je kunt het probleem daarbij het beste zo klein en concreet mogelijk maken en een oplossing ontwerpen die snel te implementeren is en waarde oplevert op de werkvloer. Data is daar in deze tijd bijna altijd een onderdeel van. Maar data is geen doel op zich.
\n\nJohan: Daarnaast is het organisatorische vraagstuk minstens zo belangrijk. Als er niemand is die commitment wil geven, dan kan de innovatie nergens landen en zakt het net zo snel weer in elkaar.
\n\nMaarten: Vaak wordt het geïntroduceerd als enkel een pilot. Dan wordt er iets tijdelijk geprobeerd en nooit doorgezet. Dat is eigenlijk zonde van het geld.
\n\nMaarten: Als ik iemand zou mogen aanstellen binnen een publieke organisatie, dan zou dit niet een Chief Data Officer zijn.
\n\nJe zou iemand op CIO (Chief Information Officer) niveau willen hebben, die veel verstand heeft van digitale transformaties. Iemand die weet hoe de geboden diensten omgevormd kunnen worden naar digitale diensten. En hoe je digitale tools (en de data die daar doorheen stroomt) inzet voor betere processen en diensten.
\n\nJohan: Je moet dus eigenlijk een Chief Digital Services Officer hebben. Of een Chief Digitization Officer of een Chief Digital Transformation Officer. Het aanstellen van een Chief Data Officer komt voort uit de vraag “we hebben de organisatie zoals die is en opeens komt daar data bij – wat nu?” Ik denk niet dat dat het geval is. De data komt erbij omdat de organisatie zelf aan het veranderen is. Je kunt beter iemand benoemen om die verandering in goede banen te leiden, dan een Chief Data Officer positie creëren.
\n\nJohan: We moeten mensen niet tot robots maken die van bovenaf door data worden gestuurd. Datagedreven werken dient uitvoerende mensen juist te steunen in hun autonomie en professionaliteit. Datagedreven werken moet niet worden gezien als een micro-management tool, maar juist als het tegenovergestelde.
\n\n“We moeten mensen niet tot robots maken die van bovenaf door data worden gestuurd.”\nMaarten: Je kan datagedreven werken op twee manieren inzetten. Als mensen denken over datagestuurd werken, denken ze “ik wil die handhaver op de best mogelijke plek hebben.” Waar wij bang voor zijn is dat de computer precies gaat bepalen wat zij gaan doen: op welke straathoek de handhaver op welk tijdstip moet staan om de meeste boetes te kunnen uitschrijven. Als je het fingerspitzengefuhl bij de handhaver wegneemt, dan ben je het werk aan het optimaliseren op een manier die het werk van elk menselijk aspect onttrekt.
\n\nWij denken dat het precies de andere kant op moet: een datagedreven aanpak dient de professionaliteit van een uitvoerder te ondersteunen. Daardoor krijg je betere diensten. Je moet niet de data laten nadenken, maar mensen laten nadenken met data.
\n\nJohan: De handhaver moet zelf de mogelijkheid hebben om grijze gebieden in te vullen, anders wordt hij of zij een robot. Dat is voor niemand goed.
\n", "date_published": "Wed, 01 Jan 2020 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2021/01/18/push-nieuwe-stijl/", "url": "https://www.jgroenen.nl/aantekeningen/2021/01/18/push-nieuwe-stijl/", "title": "Push nieuwe stijl", "content_html": "Vandaag met Tiltshift de nieuwe stijl Push voor het eerst uitgetest. Ten minste, de eerste dag: kick-off. Push is geïnspireerd door de Design Sprint van Google Ventures, zoals we die al vaker hebben, maar dan gericht op het aanzwengelen van een zeer kort (vier weken) ontwikkel- en implementatietraject van een heel stuk functionaliteit in een bestaand applicatielandschap. Het thema van deze push: vergunningen op straat.
\n\nIn de ochtend zijn we begonnen met alleen het team. In een aantal korte sessies hebben we elkaar leren kennen, verwachtingen en wensen afgestemd, huishoudelijke afspraken gemaakt, en leerdoelen in kaart gebracht.
\n\n![\"Push](\"https://www.jgroenen.nl/img/posts/push-kick-off.png\")
In de middag hebben we met het team de opdrachtgever en de eerste gebruiker doorgezaagd (op een vriendelijke manier) om de opdracht zo concreet mogelijk te maken. Met wat gerichte vragen, en fijne visuele facilitatie van teamgenoot Yvonne de Mey van Streefkerk, wisten we “de vraag achter de vraag” te achterhalen (in plaats van een technische oplossingsrichting die zich al een beetje in het hoofd van de opdrachtgever had genesteld), zodat we morgen verder kunnen met gerichte interviews over het werk van handhavers, en de manier waarop die informatie uit en over vergunningen zouden kunnen inzetten in hun werk op straat.
\n\nLeuke dag, veel geleerd, zowel over het onderwerp als over het team als over hoe we Push verder kunnen fijnslijpen. Morgen co-creatiedag met handhavers, veel zin in!
\n", "date_published": "Mon, 18 Jan 2021 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2021/01/19/waanzin/", "url": "https://www.jgroenen.nl/aantekeningen/2021/01/19/waanzin/", "title": "De waanzin van standaardapplicaties", "content_html": "“De definitie van waanzin is telkens hetzelfde doen, maar een andere uitkomst verwachten.” Schijnbaar een uitspraak van Albert Einstein, al wordt dat tegenwoordig van elke diepzinnige uitspraak beweerd. Maar goed, in ieder geval lijkt mij hier een diepe waarheid achter schuilgaan.
\n\nWat dat betreft is het natuurlijk een beetje schizofreen dat gemeenten massaal gebruik maken van de standaard aanbestedingsprocessen, waarbij software waarover iedereen al jaaaaaren klaagt omdat het niet goed aansluit op de organisatie, de processen, de rest van de architectuur, wordt aanbesteed alsof het potloden zijn. Zeker gezien het gros aangeeft digitaal te willen transformeren, te willen innoveren in de manier van werken, de dienstverlening stevig op de schop te willen nemen, en te willen aanhaken op grote, organisatieoverstijgende veranderingen zoals Common Ground.
\n\nDie processen, waarin vooraf precies wordt vastgelegd wat een stuk software moet doen, zorgen ervoor dat het ene stuk disfunctionaliteit simpelweg wordt ingeruild voor een stuk met precies dezelfde eigenschappen; vaak zelfs precies hetzelfde.
\n", "date_published": "Tue, 19 Jan 2021 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2021/01/21/open-source-licenties-en-verdienmodellen/", "url": "https://www.jgroenen.nl/aantekeningen/2021/01/21/open-source-licenties-en-verdienmodellen/", "title": "Open source licenties en verdienmodellen", "content_html": "Vandaag een leuke Code for NL meetup over open source licenties en verdienmodellen. Walter van Holst van Hooghiemstra en partners vertelde over de verschillende, ook niet juridische, aspecten van deze licenties, waarna er ruimte was voor vragen.
\n\nWanneer is iets een open source licentie? Volgens Walter is kenmerkend voor open source licenties dat ze de omstandigheden creëren om de broncode te mogen en kunnen bekijken en verspreiden, de vrijheid geven om aanpassingen te maken en te mogen verspreiden, dat ze de reputatie van de oorspronkelijke maker beschermen en waarborgen, en geen mensen, activiteiten, producten, en technologiën uitsluiten.
\n\nNaast de gebruikersovereenkomst is er de kant van de distributievoorwaarden. Dit is waar de licenties zeer uiteenlopen, van MIT aan de ene kant van het spectrum (de auteur is niet aansprakelijk, moet vermeld worden, en verder mag je doen wat je wil) via APL, MPL, GPL naar AGPL aan de andere kant van het specturm (alle code die je wijzigt of toevoegt moet ook weer worden vrijgegeven onder dezelfde voorwaarden).
\n\n![\"Open](\"https://www.jgroenen.nl/img/posts/opensourcelicenties.png\")
Redenen voor het gebruik van open source licenties, en ook het kiezen daarvan, lopen uiteen, zo vertelt Van Holst. Zo vergemakkelijkt het bijvoorbeeld het samenwerken over organisatiegrenzen heen en maakt het peer review van code eenvoudig, maar liggen er soms ook politiek-ideologische argumenten aan ten grondslag. De hele free software beweging is immers ook ontstaan als verzet tegen de praktijken die closed source softwarebedrijven er eind vorige eeuw op nahielden.
\n\nTip: publiceer wel altijd een licentie bij je broncode op github, want zonder licentie mag je code officieel niet eens gecompileerd worden door iemand anders.
\n\nTot slot bespreekt Walter nog een flink aantal verdienmodellen die verschillende grote bedrijven gebruiken rondom of op open source software, van consultancy tot maatwerk in opdracht, van implementatie tot hosting en support. Ook worden online diensten genoemd die draaien bovenop open source software en daaraan bijdragen.
\n\n![\"Open](\"/aantekeningen/img/open-source-verdienmodellen-holst.png\")
Vragen waar we niet aan toe zijn gekomen, maar die we nog wel met elkaar willen bespreken in een vervolgmeetup:
\n\nDe discussie gaat verder op de Code for NL Slack in kanaal #open-samenwerking, dus kom vooral meepraten. Voor meer diepgaande vragen aan Walter van Holst kun je kijken de website van Hooghiemstra & Partners.
\n", "date_published": "Thu, 21 Jan 2021 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2021/01/22/persoonlijke-os-happy-highligher/", "url": "https://www.jgroenen.nl/aantekeningen/2021/01/22/persoonlijke-os-happy-highligher/", "title": "pOS feature #1: Happy Highlighter", "content_html": "Om mezelf wat meer te dwingen de dingen te doen waar ik blij van word, heb ik een nieuwe “life hack” of “persoonlijk O.S.” feature. Ik heb me voorgenomen om leuke dingen wat vaker snel en kort te beschrijven in dit soort mini blogjes. Daarbij “nudge” ik mezelf om telkens te checken of ik bezig ben met de dingen waar ik bezig mee wil zijn.
\n\nMet dan aan Arjan Widlak noem ik deze feature de “Happy Highlighter”. Met een klein stukje code op mijn persoonlijke website onderstreep ik op iedere pagina of ik de woorden gebruik waarvan ik heb bedacht dat ik ze vaker wil gebruiken, omdat het de dingen zijn waar ik blij van word. Ik ga ze hier niet opsommen (want dat is vals spelen ;p).
\n\n![\"Happy](\"https://www.jgroenen.nl/img/posts/happyhighlighter.png\")
De term PersonalOS leerde ik van Martijn Aslander, die ik al jaren waardeer om zijn onvermoeibare inzet als het gaat om het promoten van delen van kennis en weggeven van creativiteit, omdat de wereld daar uiteindelijk rijker van wordt. Ik heb zelf ook ervaren dat het laten stromen van die energie ervoor zorgt dat je een onstopbare brainstormer (check die highlight!) wordt, waardoor er aan creatieve ideeën nooit meer gebrek is. Op een gegeven moment is tijd dan de beperkende factor, vandaar dus ook deze hack om er voor te zorgen dat ik de leukste dingen doe :)
\n\nCode staat op Github, en ideeën zijn natuurlijk welkom!
\n", "date_published": "Fri, 22 Jan 2021 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2021/01/24/de-toekomst-voorspellen/", "url": "https://www.jgroenen.nl/aantekeningen/2021/01/24/de-toekomst-voorspellen/", "title": "Een app om de toekomst te voorspellen", "content_html": "Een tijd geleden kreeg ik het verzoek om een Tarot app te schrijven. In eerste instantie moest ik even nadenken; ik geloof namelijk niet in dit soort zaken. [discussie: moest ik deze klus daarom afwijzen?] Uiteindelijk heb ik het appje gemaakt, en daarbij kwam er een interessante afweging voorbij.
\n\nDe functionele specificatie was als volgt: de gebruiker krijgt een geschudde pak Tarot kaarten als rij voorgeschoteld — met de rug omhoog. Vervolgens kiest de gebruiker drie kaarten. Deze worden in volgorde van selectie getoond, met per kaart wat uitleg erbij, en een telefoonnummer dat gebeld kan worden voor meer duiding door een medium.
\n\n![](\"https://mir-s3-cdn-cf.behance.net/project_modules/1400_opt_1/1d03d073302311.5c05615823c4c.jpg\")
Ik heb dit geïmplementeerd als een array van alle kaart objecten, die ik vervolgens randomiseer. Daar loop ik doorheen en maak voor ieder object een html element aan. Als je klikt op dat element, dan wordt die kaart in de selectie opgenomen, en uiteindelijk getoond.
\n\nOp die manier probeer ik zo dicht mogelijk bij de werkelijkheid te blijven: de keuze van de gebruiker vindt plaats na het husselen van de kaarten, als de volgorde al vast ligt.
\n\n![](\"/img/posts/tarot-kaarten.png\")
Een eenvoudiger manier zou zijn geweest: toon een rij “ruggen”, selecteer er drie (zonder dat dit iets betekent), en toon gewoon 3 willekeurige kaarten bij het “omdraaien”. Op die manier zou de keuze van de gebruiker echter geen invloed hebben op de selectie. De gebruikerservaring zou identiek zijn geweest, maar toch heb ik daar niet voor gekozen, omdat ik in mijn optiek daarmee de gebruiker voor de gek had gehouden…
\n\nIk ben benieuwd hoe anderen daarover denken? Heeft iemand vergelijkbare ervaringen?
\n", "date_published": "Sun, 24 Jan 2021 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2021/01/25/het-gevaar-van-priming/", "url": "https://www.jgroenen.nl/aantekeningen/2021/01/25/het-gevaar-van-priming/", "title": "Het gevaar van priming", "content_html": "Zojuist een erg interessante sessie gehad over de mogelijkheid om een “algoritmeregister” te introduceren. Iedereen heeft daar wel iets van een beeld bij, maar bij nadere verkenning blijkt al snel: wat zit er nou eigenlijk in een “register”, en wat valt er eigenlijk allemaal onder de noemer “algoritmes”. Op die manier wordt het verzinnen van een oplossing een soort taalfilosofische exercitie.
\n\nOok in andere projecten waar ik in meedraai komt dit vaak naar boven: een naam zoemt rond, of bepaalde woorden worden vaak gebruikt, en voordat je het weet loopt iedereen rond met het idee dat er al een oplossingsrichting is, terwijl eigenlijk niet eens duidelijk is wat het probleem is. Dit fenomeen staat ook wel bekend als priming.
\n\nDoorgaans is er al een besluit aan vooraf gegaan, namelijk dat (in dit geval) een “algoritmeregister” een goed idee is en dat daar dus een project van gemaakt mag worden. Het is niet altijd duidelijk of de opdrachtgever dan heel specifieke ideeën heeft bij wat dat dan inhoud, of meer ziet dat er ‘iets’ moet gebeuren op dat vlak. Dat leidt er toe dat in de uitvoer vaak veel te weinig ruimte wordt ervaren om die opdracht iets vrijer te interpreteren en “het probleem achter het probleem” uit te zoeken. Met als gevolg dat er iets ontstaat wat nooit is ontworpen, wat vanuit interpretaties van een woord en eigen ervaring van teamleden is ontstaan, waar eigenlijk niet duidelijk van is welk probleem het nou precies op welke manier oplost, en waar ook niemand op zit te wachten (inclusief de opdrachtgever).
\n\n![\"Algoritmeregister\"](\"https://www.jgroenen.nl/img/posts/algoritmeregister.png\")
Soms voelt het vervelend, maar volgens mij blijft het belangrijk om mensen daarop te wijzen. Er op te wijzen dat er daardoor een ontwerp emergeert uit een zak woorden. Waarbij het probleem is dat mensen zich daar allemaal een andere voorstelling bij maken. En dat het niet duidelijk is voor wie welk probleem precies wordt opgelost. Daarmee is het risico levensgroot dat een pad wordt ingeslagen van “tech push”: eerst maken, en daarna kijken hoe we het gaan inzetten.
\n\nDoordat dat woord er is, denken mensen dat ze weten waar het over gaat, en stappen ze dus over de stap heen van met elkaar definiëren waar het over gaat. Als ze dat wel zouden doen, dan zouden ze merken dat ze het eigenlijk niet weten. Dat ze er verschillende opvattingen over hebben. En dat ze dus een stap terug moeten: welk probleem is er, hoe zit dat precies, willen we dat oplossen, en zo ja, welke oplossingen zijn er dan mogelijk en welke daarvan willen we proberen? Om daarna pas over te gaan tot: hoe moet die oplossing er precies uit zien.
\n\nDesign methodes bieden manieren om dit te voorkomen, maar in de praktijk is het dan vaak te laat. Een goede manier om daar dan alnog mee om te gaan is om onder het motto “alles is inspiratie” te zoeken naar doelgroepen met een gerelateerd probleem. Vervolgens kun je met het woord/concept in je achterhoofd oplossingen verzinnen, en daarbij proberen het concept zo ver mogelijk om te buigen richting een oplossing voor dat probleem. Als opdrachtgever is het goed om daar dan expliciet mandaat voor te geven.
\n\nOp die manier zorg je voor gebruikers om in co-creatie mee te ontwikkelen. Alle waarde zit ten slotte in het gebruik.
\n", "date_published": "Mon, 25 Jan 2021 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2021/01/25/samen-denken-ruwe-schetsen/", "url": "https://www.jgroenen.nl/aantekeningen/2021/01/25/samen-denken-ruwe-schetsen/", "title": "Samen denken, ruwe schetsen", "content_html": "Als ik als visueel denker met mensen samenwerk, kom ik er niet omheen om ideeën ook visueel te maken en die plaatjes samen met mensen te bespreken, om te checken of ik het snap. Daarvoor is het helemaal niet nodig om mooie plaatjes te maken, heb ik gemerkt. Sterker nog, er valt veel voor te zeggen om juist hele ruwe schetsen te gebruiken.
\n\nIn de Push van vorige week maakten we samen het onderstaande plaatje. Wat je ziet in het gele vlak links is het concept dat uit de ideation is gekomen (een overzicht van relevante vergunningen bij een adres) en de meest minimale, waardevolle vorm waarin we dat in een week kunnen realiseren. Vervolgens zijn we gaan tekenen wat mogelijke vervolgstappen zouden zijn om dit concept volledig geautomatiseerd te laten werken in de huidige situatie, wanneer de “ruitenwisser” komende weken naar rechts gaat.
\n\n![\"Ruwe](\"https://www.jgroenen.nl/img/posts/ruwe-schetsen.png\")
Door op deze manier samen te schetsen (in Miro, erg handige tool voor online co-creatie), kwamen vragen en ideeën naar boven, en werd duidelijk wat we deze week gaan doen (en misschien vooral ook: wat nog niet), en hoe het pad er de komende weken uit gaat zien. Ook de verwachte moeilijkheden zijn bij iedereen in het team en bij de opdrachtgever hierdoor duidelijk.
\n\nEn door het zo schetsmatig te doen, voelde niemand zich bezwaard om te strepen, of te krassen, of aanpassingen aan te brengen. Bij co-creatie geldt wat mij betreft: alles is inspiratie, en samen schetsen past daar in mijn ogen heel goed bij.
\n", "date_published": "Mon, 25 Jan 2021 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2021/01/26/360-graden-feedback/", "url": "https://www.jgroenen.nl/aantekeningen/2021/01/26/360-graden-feedback/", "title": "Idee voor 360 graden feedback", "content_html": "Gewoon een klein ideetje, waarvan ik niet weet of het bestaat. Er zijn een aantal concepten die volgens mij mooi in elkaar haken, te weten: 360 graden feedback, 21st century skills, en retrospectief format. Ik heb nog geen uiteindelijke vorm bedacht, dus ideeën zijn welkom!
\n\nVan Milo kreeg ik de feedback dat ze als Code Fellows in Eindhoven een paar jaar terug de Sentimeter gemaakt hebben:
\n\n“Ons idee was dat je een soort virtuele een op een had. Iedereen was dan een attendee om de hierarchie er uit te slopen, en je kon elkaar dan waardering geven (score) op indicators: \nbaas - werknemer - collega en uiteindelijk ook burger(s).”
\n\nDe front-end code staat elders op Github.
\n\nVan 360-degree feedback op Wikipedia (Engelstalig):
\n\nA 360-degree feedback (also known as multi-rater feedback, multi source feedback, or multi source assessment) is a process through which feedback from an employee’s subordinates, colleagues, and supervisor(s), as well as a self-evaluation by the employee themselves is gathered.
\n\n360 graden feedback is een manier om vanuit alle relaties feedback te krijgen op jouw functioneren. Het is een vorm van functioneringsgesprek, die onderkent dat er meer is dan alleen de relatie tussen baas en medewerker. Ook terugkoppeling vanuit je team, klanten en de mensen die je aanstuurt over de interacties en relaties met hun is waardevol voor je ontwikkeling.
\n\n![\"\"](\"https://www.jgroenen.nl/img/posts/360-degree-feedback.png\")
Van 21st century skills op Wikipedia (Engelstalig):
\n\n21st century skills comprise skills, abilities, and learning dispositions that have been identified as being required for success in 21st century society and workplaces by educators, business leaders, academics, and governmental agencies.
\n\nHet is een lijst van kwaliteiten en vaardigheden die je kunt ontwikkelen, die het werken in teams en in een snel veranderende omgeving ten goede komen: kritisch denken, creatief denken, probleem oplossen, computational thinking, informatie vaardigheden, ICT-basisvaardigheden, mediawijsheid, communiceren, samenwerken, sociale en culturele vaardigheden, zelfregulering
\n\nVan Retrospective op Wikipedia (Engelstalig):
\n\nIn agile development, retrospectives play a very important role in iterative and incremental development. At the end of every iteration a retrospective is held to look for ways to improve the process for the next iteration.
\n", "date_published": "Tue, 26 Jan 2021 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2021/02/10/unstoppable-brainstormer/", "url": "https://www.jgroenen.nl/aantekeningen/2021/02/10/unstoppable-brainstormer/", "title": "Unstoppable brainstormer", "content_html": "In zijn TED talk “ADHD sucks, but not really” beschrijft Salif Mahamane hoe hij zijn hele leven te horen krijgt wat er allemaal mis met hem is, als hij weer eens niet oplet. En hoe hij wordt weggezet alsof hij niet normaal is.
\n\n\n\nKlinkt misschien wat heftig, maar wel herkenbaar. Helemaal opgaan in iets. Op de middelbare school miste ik een natuurkunde tentamen omdat ik in “crococlips” een electronisch circuit voor een automatische brug aan het uitwerken was.
\n\nHet botst wel. Dit is wat er gebeurt: ik word ergens enthousiast van. Dan komt de “hyperfocus”, maar ik zou het eerder monomaan noemen: als een gek ga ik alles wat los en vast zit verzamelen en bij elkaar gooien en doorroeren tot er een patroon ontstaat of ik voeling krijg met wat het is.
\n\nVervolgens ga ik een enorme veelheid aan verschillende ideeën spuien om af te tasten welke bij mensen resoneren, waar de ruimte zit, en hoe het geheel in elkaar steekt. Een beetje als rondrennen in een donkere ruimte om te kijken waar je tegenaan loopt, en zo een idee te krijgen van de ruimte.
\n\nAnderen kunnen hier helemaal niks mee, en worden onrustig van deze chaos. Regelmatig wordt er op de stopknop geslagen. Soms gaat dat heel goed, soms heb ik het niet goed in de gaten en escaleert het de pan uit. Ik word namelijk alsmaar enthousiaster en energieker, maar die energie kan net zo goed negatief worden ervaren.
\n\nDie energie laat zich moeilijk controleren. Als ‘ie er is, dan is ‘ie d’r. En if not, dan niet. Mijn oplossing nu is om vaker te proberen ergens in te stappen, mijn dingetje toe te staan, maar niet te lang door blijven gaan en gewoon een paar stapjes terug te doen, en van een afstandje te wachten en mensen tijd te geven om er iets van te vinden.
\n", "date_published": "Wed, 10 Feb 2021 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2021/02/15/public-code-of-source-available/", "url": "https://www.jgroenen.nl/aantekeningen/2021/02/15/public-code-of-source-available/", "title": "Public Code of Source Available", "content_html": "Onder de noemer open source wordt er gestreden voor het vrijgeven van software die door de overheid gebruikt wordt of gemaakt is. Dit gebruik maken en maken van zijn echter twee erg verschillende cases, waarbij open source ook niet per se de juiste noemer is.
\n\nTijdens de Conferentie NL Digitaal gingen Boris van Hoytema (Foundation for Public Code), Ivonne Janssen-Dings (Provincie Zuid-Holland en Code for NL) en Koos Steenbergen (Ministerie van BZK) hierover met elkaar (en de online deelnemers) in gesprek.
\n\nVan vrije software en opensourcesoftware is sprake als de broncode is vrijgegeven onder een licentie die toestaat dat eenieder:
\n\nIn het geval van software die door de overheid gebruikt wordt of gemaakt is zie je dat de accenten bij de discussie over “open source” vaak op verschillende plaatsen worden gelegd.
\n\nBovenstaande gooit open source en vrije software op één hoop en in de praktijk betreft het ook nagenoeg dezelfde dingen. Maar de purist zal stellen dat het in de Open Source beweging draait om pragmatisme: de open source beweging richt zich op het ontwikkelproces, waarbij het doel is om software “beter” te maken. De Vrije Software beweging daarentegen richt zich op het sociaal-ethische aspect van eerlijke verdienmodellen. Dit verschil in focus zie je ook terug in de discussies binnen de overheid over het hoe en wat van “open source”.
\n\nDe recent door VWS ontwikkelde applicatie “CoronaMelder” is zoals ze dat zelf zeggen “in alle openheid gemaakt”. Ondersteund door Code for NL is al vanaf het begin van het project veel code onder open source licentie vrijgegeven, en zijn discussie en bijdragen van buiten het projectteam actief aangemoedigd en meegenomen.
\n\nVanuit het oogpunt van “vrije software”, is het echter een vreemde eend, want alleen al freedom 0 slaat niet echt ergens op vanuit een coder-gebruikersperspectief. De applicatie is volledig gebouwd rondom het Google-Apple framework voor het vaststellen van nabijheid met bluetooth, en dat framework kan alleen door overheden worden gebruikt en in maar één app per land. De vrijheden zijn daarmee alleen zinvol voor het delen van de software door de Nederlandse overheid met andere overheden.
\n\nWat wel nadrukkelijk de bedoeling is, is dat de broncode bestudeerd en aangepast mag worden, om op die manier volledig transparant te maken wat de app precies wel en niet doet. Dit om te zorgen dat de samenleving de applicatie niet wantrouwt. Vooral freedom 1 en dan dus ook vooral het bestuderen deel daarvan is daarom belangrijk. Maar daarvoor hoeft de code niet “free” of “open source” te zijn; daarvoor is het alleen nodig om de broncode beschikbaar te stellen (onder voorwaarden, soms aangeduid met source available).
\n\nDit laatste is ook het primaire argument bij discussies rondom het zogenaamde algoritmeregister, waarin de inzet van algoritmes door de overheid zou moeten worden vastgelegd. Daarbij is het idee om transparant te maken welke besluiten worden genomen door en op basis algoritmes en computermodellen. In ultieme vorm is het ook daar belangrijk om de broncode beschikbaar te maken voor bestudering.
\n\nEen heel andere stroming is Public Money, Public Code. Aanhangers daarvan stellen juist dat broncode die gemaakt of besteld is door de overheid moet worden vrijgegeven voor hergebruik, omdat de samenleving ervoor betaald heeft. Dit argument heeft uiteindelijk weinig met transparantie van de overheid te maken, en meer met een redenering die stelt dat investeringen door de overheid veel beter tot hun recht komen als de resultaten daarvan ook beschikbaar worden voor burgers en bedrijven om daarop voort te borduren.
\n\nDaarbij vallen nog wel wat kanttekeningen te maken over de voorwaarden waaronder dat dan zou moeten. Afhankelijk van onder welke open source licentie de broncode vrij wordt gegeven, is het namelijk wel of niet mogelijk om de code te verwerken in closed source softwareproducten. Mijn stelling zou zijn dat de licentie dit moet toestaan. Immers, als de code wordt vrijgegeven omdat de samenleving heeft betaald, dan is het misschien niet eerlijk als de overheid vervolgens bedrijven met een closed source business model (dat zijn de meeste) benadeelt. Daarnaast gaat dit argument ook enigszins uit van de markt als motor voor innovatie, en dan is het logischer om verschillende business modellen toe te staan.
\n\nEen meer pragmatisch argument voor (een bepaald smaakje) “open source” bij de overheid is dat het open samenwerking vergemakkelijkt. Niet alleen tussen overheden, zoals dat nu tussen gemeenten al mondjesmaat gebeurt, maar ook bijvoorbeeld tussen overheid en markt en tussen burgers en overheid. In een optimaal open source ecosysteem worden ICT projecten niet door één partij aangenomen en uitgevoerd, maar is er een veelheid aan ontwikkel en implementatieteams die met elkaar samenwerken aan dezelfde (netjes opgedeelde) broncode, zodat kennis en expertise breed geborgd is, er veel controle is op de kwaliteit en voortgang van de code base, en het eenvoudig(er) is voor nieuwe partijen om mee te gaan doen.
\n", "date_published": "Mon, 15 Feb 2021 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2021/05/03/unix-filosofie/", "url": "https://www.jgroenen.nl/aantekeningen/2021/05/03/unix-filosofie/", "title": "De Unix filosofie", "content_html": "Het ontwerpen van software kent, net als alle andere dingen die door mensen verzonnen en gemaakt worden, esthetische stromingen. Een van die filosofiën is de Unix filosofie. Daarbij staat simpliciteit van toepassingen centraal.
\n\nOp de Wikipedia pagina over Unix Filosofie wordt de oorspronkelijke filosofie als volgt omschreven:
\n\n![\"\"](\"https://upload.wikimedia.org/wikipedia/commons/8/87/Contemporary_wabi-sabi_tea_bowl.jpg\")
Een mooiere formulering, die leest als een stukje poezie, komt van Mike Gancarz:
\n\nIk gebruik deze filosofie ook bij het maken van digitale tools die mensen ondersteunen op de werkvloer, maar nog altijd zie ik daar vaak de neiging tot “feature proliferation”: het toevoegen van telkens maar weer extra functionaliteit aan applicaties waar alles in zit en alles mee moet, met alle gevolgen van dien.
\n", "date_published": "Mon, 03 May 2021 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2021/06/14/open-samenwerken/", "url": "https://www.jgroenen.nl/aantekeningen/2021/06/14/open-samenwerken/", "title": "Open Samenwerken, hoe doe je dat?", "content_html": "Je project open stellen voor open samenwerking met andere organisaties, teams of “de community” is niet altijd eenvoudig. Toch is het de wens van veel overheidsprojecten om meer open te gaan werken. Code for NL organiseerde een meetup waarin vanuit drie projecten ervaringen werden gedeeld.
\n\nDrie projecten die momenteel in de Code for NL community leven werden besproken: Vrijwillig machtigen door Anouschka Scholten, CoronaCheck door Eva van Sloten en Algoritmeregister door Ivonne Jansen-Dings. Daarbij kwam een aantal vragen aan bod:
\n\nEr is niet één community: als project heb je mogelijk te maken met verschillende groepen mensen die op de een of andere manier willen meedenken of mee helpen. Code for NL is er daar één van: een community van developers en designers die heel graag hun kennis, ervaring en expertise willen inbrengen om de overheid te helpen bij de digitale transformatie. Afhankelijk van het type community zijn er verschillende manieren om dit te organiseren.
\n\nLaagdrempelige manieren van meer openheid zijn zaken als: een openbare website waarop je omschrijft wat je gaat doen en waarom, het organiseren van open meetups, een open chatkanaal voor discussie, open repositories met daarin de code die gemaakt wordt. Ook erg interessant is open posts vanuit het kernteam over hun observaties en ervaringen.
\n\nEchte inhoudelijke samenwerking is vaak pas mogelijk als bovenstaande zaken “makkelijk” gaan.
\n\nZoveel mensen, zoveel wensen. Meningen lopen vaak uiteen, en dat wil ook best wel eens botsen. Hoe zorg je er dan voor dat een project niet ontploft? Twee belangrijke factoren die naar voren kwamen: open discussie en duidelijke gedragsregels. Door continu een open discussie te blijven voeren worden frustraties in een vroeg stadium afgevangen en ontstaat er wederzijds begrip in plaats van polarisatie. Daarbij is het van belang om gedragsregels voor deze discussie daar ook op in te richten (bijv. iedereen komt aan bod, geen agressie) en die te hanteren.
\n\n![\"\"](\"https://live.staticflickr.com/6226/6278328485_22a07a4803_b.jpg\")
Op de vraag hoe je open beter mogelijk maakt, komen veel suggesties: “open tenzij”, normaliseren door het meer te laten zien. Ook het bouwen aan een betrouwbare community kan bijdragen. Maar ook het niet direct benoemen van open, maar stapsgewijs introduceren, zodat het minder “eng” is. Ook zou het goed zijn om als team expliciet te maken hoe je met elkaar omgaat, en hoe je met anderen (bijv. de community) wil omgaan.
\n\nVerder wordt genoemd dat er ook wel echt verschillende mates van open zijn, en dat “open communiceren” misschien vaak makkelijker is dan de broncode open stellen.
\n\nUit ervaringen is het wel zo dan het wachten met het aanhaken/introduceren van een open community wel een shock oplevert, waarbij een blik aan frustraties open gaat.
\n\nTot slot komt een idee voorbij voor een Code for NL OPEN WERKEN AWARD voor een persoon of project dat hier op een zeer goede manier invulling aan weet te geven.
\n\nDingen waarvan wordt gezegd dat ze niet of beperkt in de openheid kunnen zijn fraude-detectie, politiek gevoelige proof of concepts voor technische haalbaarheid, en zaken waarvoor de context te veel ontbreekt om ze te kunnen duiden als je er toevallig bij terecht komt.
\n\nDit levert best wat discussie, waarbij wordt gesuggereerd dat ook deze zaken te ondervangen zijn.
\n\nEen van de problemen die er is met volledige openheid, is dat dingen nog wel eens uit hun context getrokken worden. Journalistiek en maatschappelijk middenveld, die als tweede schil meekijken, kunnen geneigd zijn snel aan de haal te gaan met opmerkingen of ideeën die nog prematuur zijn. Ook daar is iets van een nieuwe dynamiek nodig: meer open betekent ook meer nuance en een open dialoog.
\n\nVeel manieren van werken en gebruikte technieken zitten open samenwerken ook best wel in de weg. Het gebruiken van Word documenten, powerpoints en e-mails om je project te beschrijven zorgt niet alleen voor gedoe met laatste versies, maar het is ook meer en meer onmogelijk voor buitenstaanders om op de hoogte te komen van wat er precies gedaan wordt. In lijn met de “open tenzij” gedachte zou ik daarom pleiten voor het gebruiken van publieke “websites” voor het schrijven van projectvoorstellen en presentaties en (zo veel mogelijk open) communicatie daarover. Vanuit Code for NL helpen we daar graag bij.
\n", "date_published": "Mon, 14 Jun 2021 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2021/12/20/easter-egg/", "url": "https://www.jgroenen.nl/aantekeningen/2021/12/20/easter-egg/", "title": "There be Easter Eggs", "content_html": "Tijdens mijn studie informatica was ïk gefascineerd door natuurlijke algoritmes of natural computing. Voorbeelden daarvan zijn cellulaire automaten, neurale netwerken, evolutie en zwerm-intelligentie.
\n\n![\"\"](\"https://upload.wikimedia.org/wikipedia/commons/thumb/f/f7/Cellular_Automata_running_Wolfram-rule-30.svg/789px-Cellular_Automata_running_Wolfram-rule-30.svg.png\")
Om die reden vond ik het leuk om een “easter egg” toe te voegen aan deze pagina. Klik op de hoofdpagina op mijn foto voor een visualisatie van een algoritme.
\n", "date_published": "Mon, 20 Dec 2021 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2023/02/16/algoritmeregister-vullen/", "url": "https://www.jgroenen.nl/aantekeningen/2023/02/16/algoritmeregister-vullen/", "title": "Een algoritmeregister vullen", "content_html": "Gisteren was er een bijeenkomst van de provincies in het kader van algoritmeregister, deze keer met een focus op het vullen van het algoritmeregister: wat moet erin (en wat niet).
\n\nDe vraag die iedere keer voorbij komt is: wat is een algoritme? Om dit in wetten vast te gaan leggen zal er vast en zeker een antwoord moeten komen op die vraag, alhoewel de juiste vraag dan volgens mij zou moeten zijn: “wat willen we vastleggen”, en daar dus het woord voor vinden, in plaats van vastklampen aan het woord “algoritme” en de betekenis daarvan danwel proberen vast te pinnen, danwel proberen zodanig op te rekken en te verleggen dat het past bij wat je eigenlijk vast wil leggen.
\n\n![\"\"](\"https://upload.wikimedia.org/wikipedia/commons/thumb/2/28/Polygon_Greedy_triangulation_steps.svg/260px-Polygon_Greedy_triangulation_steps.svg.png\")
Als je een stapje terug doet kom je volgens mij bij een zinvoller inzicht: wat we proberen te voorkomen is dat er beslissingen worden genomen als onderdeel van de “implementatie” van techniek, die eigenlijk discretionair zijn en waar dus verantwoording voor moet worden afgelegd. Waar we nu nog regelmatig software inzetten zonder (al te kritisch) verantwoordelijkheid te nemen voor wat die software precies doet (“zo werkt het nu eenmaal”), moet de mindset veel meer gaan zijn: als die software op een bepaalde manier werkt, dan zijn wij daarvoor verantwoordelijk, dus willen we precies weten hoe dat is, en als dat niet overeenkomt met onze waarden (of de wet), dan moet die software buigen (en niet wij, de wet of de samenleving).
\n\nWat er dus moet worden vastgelegd is precies die beslissing. En waar je dus “algoritmeregister” lees, moet je eigenlijk denken “overzicht van verantwoording bij de inzet van algoritmische toepassingen”.
\n\nVaak is er in discussies nog een onduidelijkheid: waar de een algoritmeregister zegt, doelt die op een intern overzicht van de ingezette algoritmische toepassingen, terwijl de ander doelt op een publiek toegankelijke plek (website) waarop deze informatie voor een bepaalde doelgroep beschikbaar wordt gesteld. In het ene geval betreft het dus een tool om meer grip te krijgen op de eigen inzet van algoritmes, in het andere geval gaat het om een manier van transparantie verschaffen aan de buitenwereld in het kader van een open overheid.
\n\nVervolgens speelt dan ook nog de vraag: wat is in dat opzicht de rol van het “nationale algoritmeregister” en, als we daar “gebruik van maken”, is er dan nog een noodzaak om een eigen algoritmeregister te realiseren en onderhouden, bijvoorbeeld op de eigen website.
\n\nBij het bespreken van criteria voor het prioriteren en selecteren van welke algoritmes moeten worden opgenomen in het algoritmeregister, kwamen een aantal vanzelfsprekende/bekende naar voren:
\n\nCriteria die ik voor het eerst hoorde:
\n\nEn de - in mijn optiek - mooiste:
\n\nTot slot was er nog de constatering dat de naam die gebruikt wordt voor de inzet van een algoritmische toepassing van invloed is op de inschatting van bovenstaande criteria. In combinatie met het feit dat veel van de bovenstaande vragen eigenlijk ook al antwoord zijn op de vragen die gesteld worden in de Algorithmic Transparency Standard, maakt dat mijn conclusie zou zijn: voor alle algoritmes die je tegen komt moet je even langs dit lijstje (en dus de basis van de registratie invullen), waarna je kunt bepalen of het publiceren in een publiek algoritmeregister zinvol is of eerder vervuilend.
\n", "date_published": "Thu, 16 Feb 2023 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2023/11/10/hackathon-designathon-feedback-overheid/", "url": "https://www.jgroenen.nl/aantekeningen/2023/11/10/hackathon-designathon-feedback-overheid/", "title": "Designathon Feedback Overheid", "content_html": "Donderdag 9 en vrijdag 10 november 2023 was er de Hackathon/Designathon “Feedback Overheid” bij Waag en Datalab Amsterdam. Ons team van 4 designers, “FB&4th” (Feedback and Forth), werkte aan het concept “De Feedbak”.
\n\nHet ministerie van BZK heeft de ambitie om één overheid te realiseren. Niet meer van het kastje naar de muur. Laagdrempelige feedback waar van geleerd wordt is daarbij cruciaal.
\n\nTijdens de hackathon/designathon focusten we op drie verschillende challenges op het gebied van de toekomst van overheidsdienstverlening:
\n\nWat is de beste manier om feedback te vragen?
\nHoe kan je op de website de gebruiker zo goed mogelijk helpen om zijn vraag te beantwoorden / relevante informatie te vinden?
\nLeren en acteren op behoeftes / feedback van gebruikers: feedback management binnen de overheid.
\nOns team besloot zich te richten op challenge 3, waarbij we wilden verkennen op welke manier het burgerperspectief een rol kan krijgen bij het uitvoerbaar maken en/of daadwerkelijk uitvoeren van verbeteringen op basis van de opgehaalde feedback.
\n\nTeamgenoot Rogier introduceerde daarbij de methode “Meervoudige Democratie”, waarbij hij vanuit De Weesper Vereniging betrokken was.
\n\n![\"\"](\"https://www.medemo.nl/media/posts/8/responsive/2c-6-xl.jpg\")
Onder leiding van teamgenoot Evelien brachten we het probleem in beeld op een tafelvullend vel papier; de verschillende partijen die betrokken zijn bij het proces van feedback, de verschillende stappen richting het uitvoerbaar maken en ook uitvoeren van feedback.
\n\nVanuit de ervaring van teamlid Paula - design researcher en opdrachtgever gebruikersonderzoek overheidscommunicatie - kwamen we tot het inzicht dat er een grote hoeveelheid “input” is die wordt achtergelaten op plaatsen waar deze niet thuishoort, waardoor er niks mee gedaan kan worden, omdat het op de verkeerde plaats binnenkomt. We besloten ons te focussen op de “reststroom” van “verkeerde feedback”; hoe kunnen we ervoor zorgen dat daar toch iets mee gebeurt, en hoe geven we de burger daarbij een rol?
\n\nVia een aantal omzwervingen kwamen we met een ideation, waarvoor we onder andere de crazy-8 techniek gebruikten, kwamen we tot het concept “De Feedbak”.
\n\n![\"\"](\"/img/posts/feedbak-flip-over.jpg\")
Het idee is als volgt: ingrediënt één is “De Feedbak”: een centrale service, waar alle feedback die binnenkomt bij de overheid - via webformulieren, via klantenservice, via brieven, whatever - gestuurd kan worden terecht komt. Deze kan open toegankelijk en doorzoekbaar zijn in een publiek beschikbare “feedbackfeed” (bijv. feedback.overheid.nl en api.feedback.overheid.nl).
\n\n![\"\"](\"/img/posts/feedbak-screen.png\")
We gaan ervanuit dat er geen persoonsgegevens meer in staan, een uitdaging waar onze collega teams in challenge 1 en 2 aan werken, onder andere door middel van goede inputschermen en AI.
\n\nOptioneel kan de feedbackfeed alleen toegankelijk worden gemaakt voor bepaalde groepen; daarvoor kijken we naar de tweede ingrediënt van ons concept: Initiatieven.
\n\nUitgangspunt van ons concept is het burgerperspectief. Wij zijn van mening dat de overheid het niet alleen hoeft te doen, en dat ook niet kan. De feedback is zo breed, dat het ook niet per se aan de overheid is om daar intern wat mee te doen. Er zijn veel initiatieven in de samenleving, vanuit stichtingen, onderzoeksinstellingen, politieke partijen, etc. die zich inzetten voor het verbeteren van de publieke structuren, waar de overheid er één van is.
\n\nWij gegeven deze initiatieven een rol in onze oplossing: ze kunnen aangeven met welke filter ze kijken naar De Feedbak, dus welke feedback voor hen relevant is en die zo meenemen in hun activiteiten. Dat kan breed zijn: van het doen van onderzoek en analyse, tot het gebruiken van veelgehoorde feedback als basis voor bijvoorbeeld pol.is of een politiek standpunt.
\n\nWe mikken daarbij op 1 + 1 = 3: initiatieven in de overheid én in de samenleving kunnen op die manier de voor hen relevante feedback bekijken en meenemen in hun activiteiten. Maar ook kunnen ze zien ze welke initiatieven óók naar die feedback kijken, waardoor ze daarmee kunnen afstemmen en samenwerken.
\n\nAls klap op de vuurpijl, kan de burger die de feedback geeft direct een url ontvangen naar de gegeven feedback. Op die webpagina ziet hij of zij dan niet alleen de informatie die is ingezonden, maar ook de initiatieven die geïnteresseerd (geabonneerd) zijn op die feedback en mogelijk reacties. Daarvoor is het niet nodig om persoonsgegevens achter te laten, maar het blijft toch mogelijk om te zien wat er met de feedback gebeurt (en optioneel ook om te reageren).
\n\nDus waar het voor de burger eerder met “dank u wel voor uw feedback” stopte, kan deze nu kijken of er initiatieven zijn om samen mee op te trekken. Zo kan de burger ook een rol pakken in het verbeteren van de publieke structuren.
\n\nMooie is ook dat door er een open feed van te maken, innovaties op het gebied van AI en routering en automatische reacties en dergelijke aan alle kanten kunnen plaatsvinden (bij de verschillende initiatieven), zonder elkaar in de weg te zitten; dus én-én in plaats van óf/óf.
\n", "date_published": "Fri, 10 Nov 2023 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2024/04/10/alternatieve-software-en-services/", "url": "https://www.jgroenen.nl/aantekeningen/2024/04/10/alternatieve-software-en-services/", "title": "Alternatieve Software", "content_html": "Update 13 juni 2024: Bert Hubert gaf tijdens de Public Spaces conferentie een presentatie over de noodzaak van digitale autonomie en het hebben van een open houding ten aanzien van alternatieve software en services. Deze is terug te kijken op https://video.publicspaces.net/w/usooQsSVDfgAzJdNdtz4rC. Artikelen van zijn hand zijn terug te vinden op zijn website https://berthub.eu/.
\n\nWe gebruiken iedere dag een enorm aantal stukjes software, zowel geïnstalleerd op onze computers en telefoons, als via het web. Het is moeilijk voor te stellen hoe we de dingen die we doen zouden doen zonder deze digitale tools. Des te problematischer is het dat de meeste van deze tools afkomstig zijn van een handjevol bedrijven, vaak buiten de EU, die er een verdienmodel op na houden dat niet altijd in lijn is met onze belangen.
\n\n![\"Switching](\"https://i.imgur.com/uTapMEf.png\")
Onder veel noemers wordt er gewerkt om deze situatie te veranderen. Initiatieven als Public Spaces, het sturen richting Open Source bij de overheid, discussies over Digitale Autonomie en Digitale Gemeenschapsgoederen, en nieuwe Europese wetgeving zijn erop gericht op Europese bodem een alternatief ecosysteem te ontwikkelen voor de software en services die we dagelijks gebruiken.
\n\nCheck Switching Software voor “public instances”: vrij te gebruiken instanties voor bijvoorbeeld collaborative editing.
\n\n\n\n\n\n\n", "date_published": "Wed, 10 Apr 2024 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2024/09/10/interview-over-gegevensboekhouding/", "url": "https://www.jgroenen.nl/aantekeningen/2024/09/10/interview-over-gegevensboekhouding/", "title": "Interview over Gegevensboekhouding", "content_html": "Afgelopen jaar werkte Johan Groenen, partner bij Tiltshift, vanuit het programma Open op Orde met het CDO Office van het Ministerie van Justitie en Veiligheid en Asiel en Migratie aan het Afsprakenstelsel Gegevens en Algoritmes, en daarbinnen aan het concept Gegevensboekhouding. Nu dit programma naar de lijn gaat zit zijn taak erop. Wij zijn benieuwd naar zijn ervaringen.
\n\nKun je ons vertellen wat het project precies inhield en wat de belangrijkste doelen waren toen je begon?
\n\n“Het project was onderdeel van het CDO-office van het ministerie van Justitie en Veiligheid, gericht op het justitie en veiligheid-brede afsprakenstelsel voor gegevens en algoritmes. Het idee is om ervoor te zorgen dat alle organisaties onder het ministerie beter omgaan met gegevens en algoritmes en dat daarbij een goede administratie wordt gevoerd. Een belangrijk onderdeel daarvan is het introduceren van gegevensboekhouding. Mijn rol was om dat idee van een gegevensboekhouding vorm te geven door verschillende productaspecten uit te werken en te demonstreren.”
\n\nWat waren de grootste uitdagingen tijdens het uitwerken van het concept van de gegevensboekhouding en het ontwikkelen van de bijbehorende productaspecten?
\n\n“Toen ik begon, was nog niet geheel duidelijk wat een gegevensboekhouding precies was. Er waren uiteenlopende ideeën: over het hergebruiken van bestaande oplossingen, zoals Metadata Hub, en ook verschillende use cases, zoals het vastleggen van gegevensleveringen en het monitoren daarvan, of het rapporteren over gegevensgebruik. Er was echter geen duidelijke samenhang tussen al die ideeën. Mijn grootste uitdaging was dus in eerste instantie om die verschillende wensen en verwachtingen te structureren en te vertalen naar een duidelijk concept als basis voor de gegevensboekhouding.”
\n\nHoe ben je erin geslaagd om deze uiteenlopende ideeën te structureren en vorm te geven aan een werkbaar concept?
\n\n“Ik ben begonnen met het identificeren van de verschillende stakeholders, hun rollen en hun verwachtingen. Ik wilde begrijpen vanuit welke hoek zij kwamen en wat hun specifieke behoeften waren. Daarnaast heb ik alle bestaande ideeën en elementen in kaart gebracht en deze in een soort matrix geplaatst om ze aan elkaar te linken. Dit hielp me om structuur aan te brengen in de ideeën en een samenhangend beeld te creëren.”
\n\nWat was het resultaat van deze aanpak? Heeft dit geleid tot een eenduidige definitie van de gegevensboekhouding?
\n\n“Ja, zo werd ook duidelijk dat de bestaande oplossingen zich vooral richtten op datamanagement en het laagdrempelig ontsluiten van data binnen organisaties. Onze behoefte was echter om een gestructureerde administratie te voeren van welke gegevens onder welke verantwoordelijkheid worden gebruikt en uitgewisseld. Het ging ons niet primair om de technische kant, maar vooral ook om de organisatorische verantwoordelijkheid in kaart te brengen. Uiteindelijk leidde dit tot een aantal deelapplicaties, met op de achtergrond een gezamenlijk metamodel, voor het administreren van de verschillende handelingen met gegevens en de verantwoordelijkheden daaromheen.”
\n\nKun je wat meer vertellen over de open samenwerking die je hebt georganiseerd en hoe dat verliep?
\n\n“Het andere deel van mijn opdracht was het vormgeven van open samenwerking. We hebben een design aanpak geformuleerd, waarmee we de vragen van verschillende organisatieonderdelen konden oppakken. Bijvoorbeeld, als een organisatie behoefte had aan het delen van gegevens met een andere organisatie, werkten we samen aan een concept dat zowel paste binnen de bredere visie voor gegevensboekhouding, als het probleem van die organisatie oploste. Dit zorgde ervoor dat we op een gestructureerde manier konden innoveren, samen met de betrokken partijen.”
\n\nWat zou je zeggen dat het grootste succes was dat voortkwam uit deze open samenwerking en design aanpak?
\n\n“Uiteindelijk hebben al deze verschillende projecten geleid tot een gezamenlijk beeld van wat een gegevensboekhouding zou moeten zijn. Dit ging gepaard met een metamodel om alle handelingen met betrekking tot gegevens en de verantwoordelijkheden daarbij te administreren. Dit model is de exacte weerspiegeling van het gegevensbeleid en vormt de basis voor de boekhouding. Organisaties kunnen daarmee hun eigen tooling vormgeven, hopelijk in samenwerking, en we zetten een platform op waar ze open (source) aan deze tooling kunnen werken. Het succes zit dus in het creëren van een gezamenlijke basis waarop verder gebouwd kan worden.”
\n\nNu je je rol afrondt, hoe zie je de toekomst van dit project?
\n\n“Het project gaat nu van een projectfase naar de lijn, met het CDO-office in de lead bij het schrijven van beleid en het overzien van de tooling. Dit zorgt ervoor dat er continu verbeterd kan worden. Mijn rol is hiermee afgelopen, omdat die gericht was op het vormgeven van het productconcept en het organiseren van de open samenwerking. Nu dat is opgezet, ga ik me weer richten op een nieuw project.”
\n\nWat neem je mee uit dit project naar je volgende uitdaging? Zijn er specifieke lessen of ervaringen die je in toekomstige projecten wilt toepassen?
\n\n“Ja, een van de belangrijkste lessen is dat open source werken vanaf het begin toch echt wel cruciaal is. In dit project duurde het vrij lang voordat de code beschikbaar was, wat de samenwerking bemoeilijkte. In een toekomstig project zou ik daar harder op willen inzetten, zodat er vanaf het begin een dynamische interactie ontstaat met alle betrokken organisaties. Ook heb ik geleerd dat het belangrijk is om innovatie en ontwikkeling duidelijk te onderscheiden. Innovatie vereist kleinere, toetsbare stappen, terwijl ontwikkeling lange trajecten met een concreet resultaat vergt. Daarnaast zou ik in de toekomst beleid en tooling iteratief en in kleine stappen in gezamenlijkheid willen ontwikkelen, zodat het team op ieder moment aan hetzelfde doel werkt.”
\n\nWat voor soort project hoop je hierna op te pakken?
\n\n“Ik richt me graag op publieke projecten waarin samenwerking voor de hand ligt, maar niet altijd van de grond komt. Bijvoorbeeld in het onderwijs of het erfgoeddomein, waar organisaties veel baat hebben bij gezamenlijke innovatie maar elkaar vaak niet goed weten te vinden. Het lijkt me fantastisch om in zo’n domein open source tooling en standaarden te ontwikkelen waarmee publieke organisaties zelf de toekomst vormgeven, zonder volledig afhankelijk te zijn van commerciële partijen.”
\n\nDat klinkt als een inspirerende visie! Zijn er specifieke initiatieven die je in gedachten hebt?
\n\n“Er zijn veel interessante initiatieven, zoals het gebruik van AI in het onderwijs of het in kaart brengen van innovaties. Ook in de erfgoedsector gebeuren er mooie dingen. Daarnaast wordt open source werken steeds populairder binnen de overheid. Als ik kan bijdragen aan het opzetten van open source initiatieven in een publiek domein, zou dat geweldig zijn.”
\n", "date_published": "Tue, 10 Sep 2024 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2024/10/08/coders-not-code/", "url": "https://www.jgroenen.nl/aantekeningen/2024/10/08/coders-not-code/", "title": "Coders, niet code: Hoe coders publieke organisaties kunnen versterken", "content_html": "In de publieke sector ligt steeds meer nadruk op open source code. Vaak wordt gedacht dat software-oplossingen als kant-en-klare producten in processen kunnen worden geplaatst om verandering te bewerkstelligen. Maar de echte sleutel tot succes ligt niet in de code zelf, maar in de mensen die de code maken – de coders. Coders zijn getraind in het analyseren van problemen, het vertalen daarvan naar technische oplossingen, en het continu verbeteren van de architectuur van die oplossingen. Zo zorgen ze voor goed presterende en onderhoudbare systemen. Vaardigheden die niet alleen gebruikt kunnen worden voor software, maar ook voor het verbeteren van de organisaties waarin zij werken.
\n\nEen coder is veel meer dan iemand die code klopt. Wat coders uniek maakt, is hun vermogen om problemen snel te doorgronden en om te zetten in oplossingen, die ze vervolgens organiseren binnen een duidelijke, schaalbare structuur – de softwarearchitectuur. Maar dit vermogen stopt niet bij code. Het proces van iteratief verbeteren dat coders dagelijks toepassen op hun codebases, kan net zo goed worden toegepast op de structuren en processen binnen een organisatie. Door coders onderdeel te maken van zelforganiserende teams in de primaire processen, kunnen ze bijdragen aan het optimaliseren van de organisatie zelf, op dezelfde manier waarop ze hun code continu optimaliseren.
\n\nCoders zijn gewend om hun software continu te reorganiseren, te structureren en te verbeteren. In plaats van hen te zien als slechts “de technische mensen”, moeten ze actief betrokken worden bij de bredere teams waarin ze werken. Door coders op lange termijn onderdeel te maken van zelforganiserende teams, kunnen ze hun expertise gebruiken om mee te denken over de werking van de organisatie. Ze zijn getraind in het zien van inefficiënties en het vinden van oplossingen: skills zijn die onmisbaar zijn om organisaties continu te verbeteren.
\n\nEen coder kan dus veel meer doen dan alleen de code voor oplossingen inkloppen. Ze kunnen helpen met het herstructureren van processen, het optimaliseren van workflows en het iteratief verbeteren van zowel de technologie als de manier waarop teams samenwerken, zowel in structuur als met ondersteunende tooling. Dit maakt hen van onschatbare waarde in moderne digitale organisaties.
\n\nCoders die werken binnen open source gemeenschappen hebben bovendien een manier van werken die publieke organisaties zou moeten inspireren. De “open source mindset” draait om transparantie, delen, en samenwerking. Coders delen hun werk, leren van anderen en verbeteren oplossingen iteratief. Deze manier van werken kan ook binnen organisaties worden toegepast. Wanneer coders actief betrokken zijn bij zelforganiserende teams, kunnen ze deze mindset introduceren en bevorderen, waardoor organisaties wendbaarder worden en meer leren van elkaar.
\n\nDaarnaast is ook de “hacker mindset” belangrijk: coders experimenteren voortdurend, proberen kleine verbeteringen uit, en optimaliseren processen op handige plekken. Dit iteratieve proces leidt tot voortdurende innovatie en verbetering. Publieke organisaties zouden deze aanpak moeten omarmen door coders de ruimte te geven om te experimenteren en te verbeteren, niet alleen in hun code, maar in het functioneren van de hele organisatie.
\n\nOm coders deze bredere rol te laten spelen, moeten organisaties hen niet alleen zien als techneuten, maar als veranderaars die een cruciale rol spelen in de voortdurende verbetering van processen en structuren.
\n\nEen goede stap om coders optimaal te laten bijdragen aan organisatieverbetering is de oprichting van een Open Source Program Office (OSPO). Het OSPO biedt de noodzakelijke infrastructuur en stelt standaarden vast om ervoor te zorgen dat coders kunnen werken volgens de principes van open source. Dit gaat verder dan alleen het creëren van technische standaarden; het OSPO zorgt ervoor dat coders worden gefaciliteerd en zelfs aangemoedigd om op een open en collaboratieve manier samen te werken. Het is de taak van het OSPO om de weg vrij te maken voor coders om niet alleen code te delen, maar ook ideeën, ervaringen en oplossingen, zodat ze vanuit verschillende teams en afdelingen kunnen leren en hergebruiken wat werkt.
\n\nDoor te zorgen voor de juiste tools, platformen en standaarden, creëert het OSPO een omgeving waarin open source werken een integraal onderdeel wordt van de cultuur. Dit stimuleert samenwerking en zorgt ervoor dat oplossingen snel kunnen worden geïmplementeerd en verbeterd. Coders worden zo niet alleen ondersteund, maar ook uitgedaagd om actief bij te dragen aan de voortdurende innovatie van zowel de technologie als de organisatie zelf.
\n\nDaarnaast is het essentieel dat developers tijd krijgen om te experimenteren, van elkaar te leren en samen te werken. Een gestructureerde “community time”, bijvoorbeeld 10% van hun werktijd, zorgt ervoor dat coders niet alleen werken aan hun projecttaken, maar ook kunnen bijdragen aan bredere oplossingen die meerdere teams ten goede komen. Tijdens deze tijd kunnen zij ideeën uitwisselen, best practices delen, en gezamenlijk werken aan oplossingen die passen binnen de open source infrastructuur die door het OSPO is opgezet.
\n\nHet OSPO speelt hierbij ook een faciliterende rol door ervoor te zorgen dat er platforms en processen zijn waar deze samenwerking kan plaatsvinden. Door coders op lange termijn te betrekken bij teams, worden ze niet alleen technische experts, maar ook strategische veranderaars die voortdurend bijdragen aan de verbetering van zowel technologie als organisatie. Dit zorgt ervoor dat innovatie niet stopt bij de implementatie van software, maar een doorlopend proces is dat de hele organisatie raakt.
\n\nPublieke organisaties moeten coders niet langer alleen inzetten om code te schrijven. Coders hebben een unieke set vaardigheden die hen uitermate geschikt maken om deel uit te maken van zelforganiserende teams en om mee te helpen met het continu verbeteren van de organisatie. Door hen vanaf het begin bij processen te betrekken en hen ruimte te geven voor experimenteren en leren, kunnen ze niet alleen betere software ontwikkelen, maar ook bijdragen aan de wendbaarheid en het succes van de organisatie zelf. Zo wordt de kracht van coders ten volle benut voor echte digitale transformatie.
\n", "date_published": "Tue, 08 Oct 2024 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2024/11/07/digitale-autonomie/", "url": "https://www.jgroenen.nl/aantekeningen/2024/11/07/digitale-autonomie/", "title": "De vijf F-strategieën voor Digitale Autonomie", "content_html": "Gepubliceerd op iBestuur, 7 november 2024: “De overheid moet proactief nadenken over onze digitale afhankelijkheden en actie ondernemen om onze autonomie te waarborgen.” (https://ibestuur.nl/artikel/de-vijf-f-strategieen-voor-digitale-autonomie/)
\n\nDe overwinning van Donald Trump maakt de roep om digitale autonomie luider dan ooit. Het is nu meer dan ooit van cruciaal belang dat de overheid strategieën ontwikkelt om de (digitale) autonomie van zowel overheid als samenleving te waarborgen. Johan Groenen formuleert vijf F-strategieën: Funding, Forcing, Facading, Forking en Fabricating.
\n\nDe afhankelijkheid van overheid en samenleving van veelal buitenlandse softwaremakers neemt toe. Of het nou gaat om de online platformen waarop we werken en communiceren of de technische infrastructuur waar we onze data op parkeren: vaak zijn we daarbij overgeleverd aan de grillen van bedrijven en buitenlandse overheden.
\n\nWelke strategieën kan de overheid ontwikkelen om de (digitale) autonomie van zowel overheid als samenleving te waarborgen? In dit artikel een voorzet in de form van vijf F-woorden:
\n\nOverheden kunnen investeren in open source alternatieven voor gesloten software en in Europese alternatieven voor buitenlandse infrastructuur. Dat kan zowel met koopkracht, door financiële bijdragen, als met ontwikkel-capaciteit. Door geld en middelen te steken in cruciale digitale componenten, kunnen we zorgen dat deze kunnen bestaan en verbeteren, onafhankelijk van commerciële en buitenlandse belangen.
\n\nDe overheid kan wetgeving en beleid maken om moedwillige vendor lock-in en winner-takes-all netwerkeffecten tegen te gaan. Dit gebeurt al in diverse Europese wetten, die interoperabiliteit afdwingen en verplichten dat gebruikers hun data kunnen opvragen. Ook wetgeving en beleid op het gebied van welk soort techniek de overheid zelf mag gebruiken kan helpen – bijvoorbeeld alleen open algoritmes.
\n\nMarktpartijen bieden tegenwoordig van allerhande services aan als web service (API). Denk dan bijvoorbeeld aan de mogelijkheid om SMS te versturen of databestanden in de cloud op te slaan. Daarbij is het vaak wel zo dat de aanbieder bepaalt hoe je tegen die API moet praten.\nOm ervoor te zorgen dat je door de hele overheid heen aanpassingen moet maken als zo’n aanbieder iets wijzigt, maar vooral ook als die wegvalt of zich misdraagt, kan het verstandig zijn om er iets voor te plaatsen: een nationale faciliteit die we zelf controleren, waar iedereen gebruik van kan maken. Zo kan op één plek de boel worden omgezet als dat nodig is.
\n\nOok open source projecten kunnen ineens een andere kant opgaan. Het is daarom belangrijk om voor cruciale code bases te volgen wat er in zo’n project speelt, en als het moet klaar zijn om zelfstandig verder te gaan, een zgn. “fork”. Daarbij maak je een kopie en ga je zelf aan het roer staan. Dit geeft de vrijheid om de software aan te passen aan de specifieke behoeften, maar heeft wel als nadeel dat je er weer alleen voor staat.
\n\nWanneer er geen geschikte open alternatieven bestaan voor cruciale componenten, kun je ervoor kiezen om zelf iets nieuws te (laten) bouwen. Een open optie op de markt kan een gespannen dynamiek tussen gebruikers en aanbieders doorbreken. Dit kan een volledig werkende versie zijn met alle toeters en bellen, maar het kan ook zijn dat het een basale versie is, die echt alleen als fallback optie dient.
\n\nBovengenoemde strategieën zijn niet uitputtend en ze kunnen in combinatie worden toegepast. De keuze voor een bepaalde strategie hangt af van de dynamiek van een specifieke situatie, de beschikbare middelen, en de mate van urgentie.\nBelangrijk is dat de overheid proactief nadenkt over onze digitale afhankelijkheden en actie onderneemt om onze autonomie te waarborgen. Alleen zo kunnen we ervoor zorgen dat we in de toekomst flexibel, veilig en onafhankelijk kunnen opereren in het digitale domein.
\n\nWelke strategieën mis je nog? Laat het weten in de reacties!
\n", "date_published": "Thu, 07 Nov 2024 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2025/01/15/leren-van-common-ground/", "url": "https://www.jgroenen.nl/aantekeningen/2025/01/15/leren-van-common-ground/", "title": "Wat projecten kunnen leren van Common Ground", "content_html": "Oorspronkelijk gepubliceerd op Opensourcewerken
\n\nIn een eerder artikel over gegevensboekhouding schreef ik over wat voor lessen ik uit dat project meeneem naar een volgend project. Reflecterend stelde ik mezelf de vraag: hoe kunnen publieke projecten effectiever samenwerken? Het Common Ground-model biedt hiervoor een interessante opzet. Daarbij is het wel belangrijk een paar valkuilen te vermijden.
\n\nVoor complexe projecten waarin een breed scala aan partijen samenwerken richting een gezamenlijk doel is open samenwerking en open innovatie een krachtige aanpak. Het idee is simpel: als iedereen op een proactieve, open manier werkt aan eigen innovatieve toepassingen en experimenten, is het eenvoudig om te hergebruiken, samenwerking op te zoeken en op elkaars werk voort te borduren. Zo ontstaat een centrale, open basis van (de facto) standaarden en code bases, zonder de bottleneck van centrale sturing.
\n\nDe kracht van deze aanpak ligt in de combinatie van lokale autonomie en gezamenlijke ontwikkeling. Iedereen kan werken aan wat voor hem of haar prioriteit heeft. Door gebruikte informatiemodellen en tools laagdrempelig te delen, kan een vorm van convergentie ontstaan. De facto standaarden kunnen vervolgens later worden geformaliseerd waar nodig, bijvoorbeeld in architectuur of beleid.
\n\nWat deze aanpak voorkómt, is een situatie waarin innovatie wordt beperkt door top-down controle. Het lijkt sterk op wat we kennen uit de open source-wereld, waar snelle iteraties en diversiteit in aanpak leiden tot organische groei van tools en standaarden. Het is een manier van werken die energie volgt, niet oplegt.
\n\nCommon Ground laat zien hoe samenwerking op deze manier georganiseerd kan worden. De architectuur-principes, zoals de scheiding van data en applicaties en modulaire code bases, zorgen voor ruimte voor flexibiliteit en snelle ontwikkeling.
\n\nGemeentes en andere partijen kunnen hun eigen systemen kiezen en ontwikkelen, terwijl ze aangehaakt blijven in de community en de de facto-afspraken over standaarden, zodat dit bijdraagt aan het grotere geheel. Het model maakt schaalbare samenwerking mogelijk zonder dat partijen het gevoel krijgen in een wachtrij te moeten staan.
\n\nUit de diversiteit aan oplossingen kunnen herbruikbare componenten en diensten worden gedestilleerd en doorontwikkeld. Op die manier kan een gedeelde basis ontstaan die weer positief bijdraagt aan convergentie en snelheid van ontwikkelen.
\n\nToch zie je ook wel uitdagingen bij Common Ground. Het vinden van de juiste balans tussen standaardisatie en flexibiliteit is cruciaal. Standaarden moeten ontstaan door samenwerking en convergentie. Toch is er soms de neiging tot vroegtijdige formalisering of een top-down aanpak, die dwars door het opgebouwde momentum heen kan varen. Wanneer standaarden te vroeg worden vastgelegd of te dwingend worden opgelegd, kan dit de innovatie verstikken en partijen wegduwen die er goede, maar misschien net andere ideeën op nahouden.
\n\nHet vinden van de juiste balans tussen standaardisatie en flexibiliteit is cruciaal. Standaarden moeten ontstaan door samenwerking en convergentie.
\n\nHetzelfde geldt voor software. Als een bepaalde oplossing wordt gepresenteerd als “de standaard” voordat deze daadwerkelijk breed is gedragen, ontstaat het risico dat de ontwikkeling van die oplossing zelf een bottleneck wordt, zowel voor innovatie als voor implementatie. Dit kan juist in de weg staan van gezamenlijke innovatie en zelfs de geloofwaardigheid van het hele programma in gevaar brengen.
\n\nWat kunnen publieke projecten leren van deze aanpak? De focus moet liggen op het faciliteren van samenwerking, niet op het forceren van uniforme oplossingen. En standaarden en tools te zien als hulpmiddelen die samenwerking mogelijk maken, niet als doelen op zich. Dat betekent:
\n\nAutonomie respecteren: Laat partijen zelf bepalen welke problemen zij als eerste willen aanpakken en volg de energie die daaruit voortkomt.
\nStandaarden door samenwerking: Zorg dat standaarden en informatiemodellen ontstaan door praktijkervaring en convergentie, niet door vroegtijdige formalisering.
\nInnovatie stimuleren: Zorg voor overzicht, spot kansen voor hergebruik en samenwerking, en faciliteer dit actief, zonder partijen te dwingen mee te doen.
\nDoor deze aanpak te volgen, bouwen we aan een ecosysteem waarin iedereen kan bijdragen op zijn eigen manier, terwijl we gezamenlijk profiteren van de kracht van samenwerking.
\n\nTerugkijkend op mijn ervaring met bijvoorbeeld algoritmeregister en gegevensboekhouding, zie ik kansen om deze principes in de toekomst breder toe te passen. Door te focussen op samenwerking en gedeelde, bottom-up standaardisatie, kunnen we meer betrokkenheid en creativiteit stimuleren. Dit betekent vooruitkijken, kansen zien, experimenteren en behouden wat werkt, in plaats van blijven hangen in wat al dan niet goed is.
\n\nPublieke projecten hebben vaak de neiging om top-down te denken, waardoor ze zichzelf soms onbedoeld vastzetten. Common Ground laat zien dat er een alternatief is: een toekomst waarin innovatie ontstaat door samenwerking, energie, en convergentie. Als we die lessen toepassen, kunnen we bouwen aan projecten die niet alleen efficiënter zijn, maar ook inclusiever en toekomstbestendig.
\n", "date_published": "Wed, 15 Jan 2025 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2025/03/13/bezoek-logius/", "url": "https://www.jgroenen.nl/aantekeningen/2025/03/13/bezoek-logius/", "title": "Publieke Code bij Logius", "content_html": "Vandaag bij Logius op bezoek geweest.
\n\nTom Ootes, developer relations bij developer.overheid.nl, gaf daar een presentatie over de Standaard voor Publieke Code, Nederlandse vertaling van de Standard for Public Code die we vorig jaar in opdracht van Opensourcewerken (MinBZK) vertaalden.
\n\nOpvallende misvatting: veel mensen denken dat de standaard primair bedoeld is om software “open source” te maken. Maar het gaat om iets anders: “publieke code” betekent dat beleid en software twee kanten van dezelfde medaille zijn. Uit de Standaard: “De Standaard voor Publieke Code ondersteunt het in samenwerking ontwikkelen van codebases die open, herbruikbaar, leesbaar, te verantwoorden, toegankelijk en duurzaam zijn.”
\n\nAls beleidsmakers en programmeurs in de publieke sector moeten we beseffen dat er specifieke eisen zijn aan ons werk, zoals algemene beginselen van behoorlijk bestuur en specifiekere wetten. De code die we schrijven moet daarom, net als beleid, aan een aantal eisen voldoen, waar onder:
\nDat gaat dus breder dan alleen de code “open sourcen”. De Standaard voor Publieke Code (en “opensourcewerken” als manier van denken en doen) is daarom óók waardevol in omgevingen waar openbaarheid (nog) niet de hoogste prioriteit heeft, en het bij elkaar komen en met elkaar bespreken hoe we dat in de praktijk brengen is daarom ook zo belangrijk.
\n\nMeer weten? Check de bovenstaande website(s) en praat mee op praatmee.codefor.nl.
\n", "date_published": "Thu, 13 Mar 2025 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2025/08/31/single-point-of-failure/", "url": "https://www.jgroenen.nl/aantekeningen/2025/08/31/single-point-of-failure/", "title": "Single Point of Failure", "content_html": "Recent kwamen er opnieuw pijnlijke datalekken in het nieuws: persoonsgegevens van meer dan 700.000 vrouwen die deelnamen aan bevolkingsonderzoek bleken jarenlang onnodig bewaard, inclusief naam, adres en zelfs BSN. Zulke incidenten laten zien hoe versnipperde administraties privacy en veiligheid ondermijnen. Elk lab en elke onderzoeksgroep beheert zijn eigen bestanden, met eigen routines, eigen risico’s. Juist daarom is de gedachte aan één centrale administratie zo krachtig: een plek waar bewaartermijnen strak geregeld zijn, waar alleen noodzakelijke gegevens staan, en waar unieke codes worden uitgegeven die labs gebruiken zonder de deelnemers zelf te hoeven kennen. Eén punt waar het fout kan gaan–maar ook één punt waar je mitigatie, beveiliging en vertrouwen structureel kunt verankeren.
\n\nEen single point of failure wordt meestal als gevaar gezien: één plek waar alles stuk kan gaan. Denk daarbij aan het centraliseren van bijvoorbeeld API calls naar externe providers zoals SMS en AI diensten, of dus het centraliseren van administratie voor medische onderzoeken. Maar diezelfde centralisatie kan ook een voordeel zijn. Een AI-egress gateway is niet alleen een poort die uitval kan veroorzaken, het is ook de plek waar je grip krijgt op gebruik, kosten en compliance. Één plek om wijzigingen door te voeren als de externe dienst iets aanpast. Of, in het kader van digitale autonomie, als een dienst ineens niet meer betrouwbaar is. In plaats van overal verspreid dezelfde fouten en risico’s te hebben, concentreer je de kwetsbaarheid–én de expertise. Het is makkelijker één punt robuust te maken, dan driehonderd losse koppelingen die allemaal hun eigen fouten en leemtes hebben.
\n\nHetzelfde geldt voor administratieve infrastructuur. Een centraal administratiekantoor voor onderzoeksdeelnemers en hun toestemmingen lijkt een logische kwetsbaarheid: wat als die ene database wordt gehackt? Maar tegelijk is het de enige plek waar je consistent kunt borgen dat resultaten alleen onder de juiste voorwaarden worden hergebruikt. In plaats van eindeloos individuele labs en onderzoekers hun eigen administratie te laten doen–en dus overal kleine lekken en afwijkingen te riskeren–bundel je het in één strakke, gecontroleerde laag. Het single point of failure is dan óók het single point of mitigation.
\n\nDe afweging om dingen centraal of decentraal te organiseren is dus wat mij betreft veel meer een pragmatische dan een ideologische keuze. Als één decentrale partij gegevens van 1 miljoen mensen kan lekken, dan is die schaal zo enorm dat je volgens mij beter kunt kiezen voor centralisatie, met alle bijbehorende mitigatiemogelijkheden en financiële middelen.
\n", "date_published": "Sun, 31 Aug 2025 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2025/09/01/open-source-kaboutertjes/", "url": "https://www.jgroenen.nl/aantekeningen/2025/09/01/open-source-kaboutertjes/", "title": "Open source is geen Kaboutertjeswerk", "content_html": "Steeds meer overheden stappen over op open source. Dat klinkt vooruitstrevend: bestaande open source software gebruiken, of nieuwe software laten ontwikkelen en die ook open source beschikbaar maken. Maar vaak sluipt er een misvatting in het denken.
\n\nIn de hoofden van bestuurders leeft soms het beeld van een “open source community” als een diffuse groep developers die vanuit hun zolderkamer gratis software maken en onderhouden. Dat beeld klopt half–sommige projecten die hun oorsprong vinden in academische of persoonlijke passie, zoals wetenschappelijke tools of tools voor creativiteit, kennen een actieve community van gebruikers die ook proactief bijdragen aan de ontwikkeling: gebruiker-ontwikkelaars of prosumers. Maar het is een vergissing om te denken dat dit universeel geldt en automatisch gebeurt.
\n\nAls een overheid open source software bouwt of laat bouwen, ontstaat er niet vanzelf een leger vrijwilligers in de buitenwereld dat de code onderhoudt. Er komen geen kaboutertjes langs. De overheidsorganisatie is namelijk zelf die gebruiker-ontwikkelaar, of zou dat moeten zijn. Onderhoud en doorontwikkeling moeten dus ook door die overheid zelf worden gedaan–met eigen developers of ingehuurde expertise, en door samenwerkingen op te zoeken met andere organisaties die ook prosumer willen worden.
\n\nHet denken moet daarom kantelen: niet zoeken naar “open source communities” in de hoop dat je onderhoud van je brouwsels daar kunt uitbesteden, maar zelf organiseren van een community van prosumer-organisaties. Pas dan komt de belofte van open source–gedeelde kosten, gedeelde kennis, gedeelde innovatie–echt tot leven.
\n", "date_published": "Mon, 01 Sep 2025 00:00:00 +0000" }, { "id": "https://www.jgroenen.nl/aantekeningen/2026/01/30/clean-desk/", "url": "https://www.jgroenen.nl/aantekeningen/2026/01/30/clean-desk/", "title": "Ik wil geen 'clean desk'. Ik wil samenwerken.", "content_html": "Op veel plekken geldt een clean desk policy.\nOnder het mom van de flexibele werkplek worden gebouwen er volledig op ingericht: lege bureaus, lockers, generieke stoelen, en vooral niks op muren of ramen.
\n\nDat lijkt onschuldig. Efficiënt zelfs.\nMaar het heeft structurele effecten op hoe werk wordt gedaan en ervaren, en ook vooral op hoe samenwerken werkt (of beter: niet werkt).
\n\nEen clean desk doet twee dingen tegelijk.
\n\nTen eerste maakt het werk individueel.\nJe werkplek is tijdelijk, van jou alleen, voor dit moment. Er is geen gezamenlijke plek meer. Geen spoor van gisteren. Geen context van anderen. Alles wat van jou is, zit in je hoofd of in je laptop. (Of niet, maar misschien is dat mijn probleem.)
\n\nTen tweede dwingt het werk het digitale domein in.\nNiet als hulpmiddel, maar als plaats. Werk is digitaal geworden.
\n\nDat gebeurt op twee niveaus.
\n\nPraktisch:\nHoe kan ik mijn werk doen zonder vaste plek, zonder spullen, zonder zichtbare voortgang?\nAntwoord: via documenten, tickets, inboxen, tools.
\n\nConceptueel:\nWat is mijn werk eigenlijk?\nIets wat ik alleen doe. Asynchroon. In mijn eigen context. Inbox-gedreven. Los van tijd en plaats. Op een computer.
\n\nSamenwerken kan nog wel, maar dat gaat niet zomaar.\nJe moet een vergaderzaal boeken.\nAls die ten minste beschikbaar is.\nVoor een uurtje.\nOm een grote, niksige tafel.\nWaarschijnlijk met een groot scherm erbij, anders heb je je spullen niet bij de hand.
\n\nTeamwork wordt daarmee geherdefinieerd als vergaderen.\nNiet als samen werken, maar als incidenteel overleg.\nJouw dingen laten zien aan anderen.\nHooguit zelf wat kleine aanpassingen doen op basis van feedback.\nEn dat overleg vindt plaats in een blanco ruimte, zonder gedeelde context. Geen muur met sporen. Geen half afgemaakte ideeën. Geen zicht op elkaars werk, behalve wat er op dat moment besproken wordt.
\n\nThuiswerken versterkt dit patroon.\nIedereen zijn eigen context, zijn eigen digitale bubbeltje.\nSamenwerking wordt iets wat je plant, niet iets wat er gewoon is.\nNiet de kern van werken, maar een randverschijnsel.
\n\nWat gebeurt er dan?
\n\nTen eerste worden documenten belangrijker dan nodig.\nNiet als middel, maar als object.\nEr gaat disproportioneel veel energie naar het schaven aan digitale artefacten die geen echte deliverables zijn, maar placeholders voor afstemming die nog moet komen.\nDat is zonde van tijd en aandacht.\nDat haalt de vaart en de motivatie uit samenwerken.
\n\nTen tweede vullen mensen de wachttijd.\nIn afwachting van overleg wordt er verder gepolijst, herschreven, geoptimaliseerd. Niet omdat het nodig is, maar omdat er geen gedeelde voortgang is.\nBullshit jobs liggen dan op de loer.
\n\nTen derde vervliegt de teamcontext.\nDie wordt flinterdun. Tijdelijk. Elke keer opnieuw op te bouwen. En net zo snel weer weg.\nSamenwerken is niet meer leuk.\nHet is moeizaam.\nLiever alleen werken.
\n\nDat maakt uit.
\n\nTeams krijgen hun strategie niet goed naar operatie vertaald.\nNiet omdat ze het niet snappen, maar omdat het denken niet continu is. Er is geen lopende gezamenlijke lijn.
\n\nDie context ontbreekt óf bij overleg, en dan vergeet je dingen, maak je verkeerde keuzes, wordt alles hagelschot,\nóf je moet ‘m telkens opnieuw reconstrueren. Expliciet. Met veel moeite. Dat kost ook weer tijd en energie die je veel beter in stappen vooruit kan stoppen.
\n\nDe oplossing is niet betere tooling.\nOok niet meer overleg.\nOf duidelijkere werkafspraken.
\n\nDe oplossing is fysiek en oud. En simpel. En misschien vooral ook wel: leuk.
\n\nTeamruimtes.
\n\nObeya’s.
\n\nWar rooms.
\n\nGeef het maar een naam.
\n\nPlekken waar het werk mag blijven hangen.\nWaar context zichtbaar is.\nWaar denken, besluiten en doen in elkaars verlengde liggen.\nWaar je ‘s ochtends binnenloopt en meteen ziet wat er speelt.\nWaar je was gebleven.
\n\nEn waar je samen ook alweer naartoe ging.
\n", "date_published": "Fri, 30 Jan 2026 00:00:00 +0000" } ] }