Technologie- en softwareadvies

Advies loont op momenten waarop een verkeerde keuze lang doorwerkt. Dat zijn er meestal vier.

• Voor een aanbesteding of offerteaanvraag. U wilt eisen opstellen die technisch kloppen, toetsbaar zijn en de markt niet onnodig beperken.
• Bij een contractverlenging. Het bestaande systeem werkt, maar u wilt weten wat een overstap zou vragen voordat u weer jaren tekent.
• Bij een vastgelopen project. De planning schuift, de kosten lopen op en niemand kan uitleggen waarom. Een frisse blik op code en architectuur maakt de oorzaak vaak zichtbaar.
• Bij een keuze tussen bouwen en kopen. Er is een pakket dat bijna past, en een voorstel voor maatwerk. Welke route is op termijn goedkoper en minder riskant? De gids maatwerk of standaard software geeft de beslistabel; het advies past die toe op uw situatie.

Advies is minder zinvol als de beslissing al genomen is en alleen nog onderbouwing zoekt. Dan levert een review vooral bevestiging op, en daar betaalt u niet voor. We zeggen dat liever vooraf.

Het advies gaat over software, data en geo-informatie, met de focus op overheden en organisaties die met open standaarden werken. Voor de bouw zelf verwijzen we naar maatwerk software of GIS- en kaartoplossingen.

Een architectuurreview kijkt naar hoe een systeem in elkaar zit en of dat past bij wat de organisatie ermee wil. Het is geen code-audit van elke regel, maar een beoordeling van de keuzes die het moeilijkst terug te draaien zijn.

De review eindigt met een rapport in gewone taal en een prioriteitenlijst. Elk punt verwijst naar de plek in code, configuratie of documentatie waar het op is gebaseerd, zodat uw eigen mensen of een andere leverancier het kunnen nalopen.

Het Forum Standaardisatie beheert een lijst met open standaarden die Nederlandse overheden (Rijk, provincies, gemeenten en waterschappen) en instellingen uit de (semi-)publieke sector moeten uitvragen of krijgen aanbevolen. Bij de status 'Verplicht (Pas toe of leg uit)' moet de standaard worden uitgevraagd en toegepast, tenzij u gemotiveerd uitlegt waarom niet.

Die lijst verandert. Een voorbeeld uit de geo-hoek: WMS en WFS staan op de lijst als 'Aanbevolen', terwijl het pakket Geo-standaarden met de status 'Pas toe of leg uit' onder meer OGC API Features en OGC API Tiles bevat. Over WFS schrijft het Forum:

WFS is onderdeel van de eerste generatie OGC API-standaarden, toen nog 'services' genaamd, en is gebaseerd op XML en SOAP. Deze standaarden zijn nog steeds geldig en in gebruik, maar worden gaandeweg vervangen door een nieuwe generatie op REST gebaseerde OGC API-standaarden.

Bron: Forum Standaardisatie, gelezen op 11 oktober 2026. Een uitvraag die alleen WMS of WFS noemt, loopt dus achter.

Voor REST API's die overheidsinformatie of functionaliteit ontsluiten, staan de NL API Design Rules van Logius als verplichte standaard ('pas toe of leg uit') op de lijst. Daarin staan afspraken over onder meer versiebeheer, foutafhandeling en transportbeveiliging.

In de toets zetten we per standaard naast elkaar wat de lijst vraagt, wat het systeem doet en wat het verschil betekent. Waar u bewust afwijkt, helpt dat overzicht bij de 'leg uit'-motivering.

Bijna elk contract noemt een exitregeling. Veel van die regelingen zijn in de praktijk niet uit te voeren, omdat ze vaag blijven: 'de leverancier werkt mee aan een overdracht'. Een goede exit-eis is concreet genoeg om vooraf te testen.

De volgende vragen werken we daarom in een advies uit.

• In welk formaat komen de gegevens terug, en is dat een open formaat dat een ander systeem kan inlezen? Vraag om een proefexport tijdens de looptijd, niet pas aan het einde.
• Komt ook de configuratie mee, zoals kaartlagen, stijlen, gebruikersrollen en zoekinstellingen? Zonder die configuratie begint de opvolger alsnog opnieuw.
• Is de broncode beschikbaar, en zo ja onder welke licentie? Bij software als dienst is dat vaak niet zo; dan wordt de gegevensexport belangrijker.
• Hoeveel uren ondersteuning bij de overdracht zijn inbegrepen, en tegen welk tarief daarna?
• Wat gebeurt er met kopieën en back-ups bij de oude leverancier na afloop?

Vergelijk de antwoorden op deze vragen tussen inschrijvers. Een eerlijke beperking in de exit is beter dan een belofte die niemand kan nakomen. Wie de infrastructuurkant van een exit wil uitwerken, vindt meer op de pagina over cloud- en data-infrastructuur; contractclausules staan bij vendor lock-in en exitstrategie.

Voor gemeenten is Common Ground de informatiekundige visie waarmee zij volgens de VNG collectief de informatievoorziening eenvoudiger, flexibeler en slimmer gaan inrichten. GEMMA beschrijft het doel als meer regie op de eigen informatievoorziening en minder afhankelijkheid van softwareleveranciers. Gegevens worden eenmalig vastgelegd en in verschillende processen gebruikt, en functioneel afgebakende componenten werken gestandaardiseerd samen. Het vijflaagsmodel laat zien hoe die lagen zich tot elkaar verhouden.

In een advies vertalen we dat naar vragen over het concrete systeem. Haalt de applicatie gegevens bij de bron, of maakt ze een eigen kopie die uit de pas kan gaan lopen? Zijn interactie, logica en opslag gescheiden, zodat u één laag kunt vervangen zonder de rest? En zijn de koppelingen gedocumenteerde API's, of maatwerk dat alleen de huidige leverancier begrijpt?

Niet elk systeem hoeft volledig volgens Common Ground gebouwd te zijn. Een kaartviewer die open data van PDOK toont, heeft andere eisen dan een zaaksysteem. Het advies maakt zichtbaar waar afwijken verstandig is en waar het later geld kost. Meer over de gemeentelijke context staat op de pagina over gemeenten.

TechinFlow bouwt zelf ook software. Daarom maken we vooraf duidelijk hoe advies en een eventuele latere opdracht zich tot elkaar verhouden.

Aanbesteding later? Wat u van ons krijgt, is zo opgesteld dat u het met alle inschrijvers kunt delen. Een scan of PoC geeft geen voorkeurspositie en kan gevolgen hebben voor onze deelname aan een latere aanbesteding.

Dat betekent in de praktijk dat het advies geen eisen bevat die naar één product of leverancier wijzen, dat het rapport geen vertrouwelijke kennis bevat die anderen missen, en dat u zelf beslist of en hoe het in een uitvraag terechtkomt.

Het advies wordt opgesteld door Tekin Uslu, oprichter van TechinFlow. Tekin werkt volgens eigen opgave sinds 2006 aan geo-informatie, data engineering en IT-architectuur. Eerder werk van de oprichter is geen referentie van TechinFlow B.V. Wie Tekin is en welke code hij publiek heeft gezet, leest u op zijn profielpagina.

Wilt u eerst weten welke vragen u in een uitvraag voor een kaartviewer stelt, lees dan de gids over eisen bij een aanbesteding van een GIS-viewer.

1. Vraag scherp krijgen. In een eerste gesprek bepalen we welke beslissing het advies moet ondersteunen en wat buiten de vraag valt.
2. Stukken en toegang. U levert documentatie, contracten voor zover relevant, en leestoegang tot code of configuratie. Waar die ontbreekt, interviewen we beheerders en gebruikers.
3. Analyse. We lopen de onderdelen uit de tabel hierboven na en toetsen claims van leveranciers waar mogelijk zelf, bijvoorbeeld door een export of API-aanroep uit te voeren.
4. Conceptrapport. U krijgt de bevindingen eerst als concept, zodat feitelijke fouten eruit kunnen voordat het rapport wordt gedeeld.
5. Eindrapport en toelichting. Een rapport met prioriteiten en een mondelinge toelichting aan de mensen die moeten beslissen.

De omvang hangt af van de vraag. Een toets op exit-eisen in een conceptuitvraag is kleiner dan een review van een volledig applicatielandschap. Daarom maken we de afspraak pas na het eerste gesprek. Het rapport blijft van u; u mag het intern en extern gebruiken, ook als u daarna met een andere partij verdergaat.