Cloud- en data-infrastructuur voor geo- en dataplatforms

Een geo- of dataplatform bestaat uit meer dan de applicatie die gebruikers zien. Daaronder draaien een database (vaak PostgreSQL met de ruimtelijke uitbreiding PostGIS), een kaart- of featureserver, achtergrondtaken die data ophalen en omzetten, opslag voor bestanden en een omgeving die logs en meldingen verzamelt. Die onderdelen bepalen of een platform snel, veilig en betaalbaar blijft.

TechinFlow ontwerpt en beheert die onderste laag, los of samen met de toepassing erboven. Denk aan het inrichten van een databasecluster voor een dataplatform, de hosting van een GIS-viewer voor een gemeente of de servers achter een open data platform.

We beschrijven de infrastructuur als code (infrastructure as code). Elke server, elk netwerk en elke databaseinstelling staat dan in tekstbestanden in een repository. Daardoor kan een omgeving opnieuw worden opgebouwd, is elke wijziging terug te vinden in de versiegeschiedenis en kan een andere beheerder precies zien wat er draait. Dat maakt een test- en productieomgeving ook gelijk aan elkaar, wat verrassingen bij livegang voorkomt.

Wat we niet doen, is zelf een datacenter exploiteren. De rekenkracht en opslag komen van een hostingpartij of cloudaanbieder die u samen met ons kiest, of die u al hebt.

Deze dienst past bij organisaties die een eigen geo- of dataomgeving willen draaien en daar grip op willen houden, met de focus op overheden en organisaties met vergelijkbare eisen aan beveiliging en verantwoording.

• Wel passend als u een applicatie of dataplatform laat bouwen en de hosting niet bij de bouwer wilt laten verdwijnen in een zwarte doos.
• Wel passend als een bestaande omgeving handmatig is ingericht, niemand meer precies weet hoe, en u die reproduceerbaar wilt maken.
• Wel passend als u wilt weten wat een verhuizing naar een andere aanbieder vraagt voordat u een contract verlengt.
• Niet passend als het alleen om beheer van een bestaande GeoServer gaat; daarvoor is er GIS-beheer en hosting.
• Niet passend als u werkplekbeheer, e-mail of kantoorautomatisering zoekt. Dat is een ander vak.
• Niet passend als uw organisatie al een centrale hostingvoorziening heeft die alle applicaties verplicht afneemt. Dan leveren we liever een installatiepakket en documentatie aan die afdeling.

Twijfelt u welke variant bij uw situatie hoort, dan begint het bij een gesprek over wat er nu draait en wie het beheert. Soms is het antwoord dat er niets hoeft te verhuizen en alleen de documentatie ontbreekt.

Ons uitgangspunt is dat gegevens en back-ups in de Europese Economische Ruimte blijven. Dat is een ontwerpkeuze, geen certificaat. Of een aanbieder daar werkelijk aan voldoet, controleert u in de contractstukken en niet op de homepage van die aanbieder.

Let daarbij op drie dingen. Waar staan de servers en de back-ups fysiek? Welke subverwerkers gebruikt de aanbieder, bijvoorbeeld voor support of monitoring, en waar zitten die? En onder welk recht valt de moedermaatschappij van de aanbieder? Het tweede punt wordt vaak vergeten, terwijl juist ondersteuning op afstand toegang tot gegevens kan betekenen.

Verwerkt het platform persoonsgegevens, dan bepaalt de feitelijke rolverdeling wie verwerkingsverantwoordelijke en wie verwerker is. De Autoriteit Persoonsgegevens legt uit dat een organisatie die gegevens alleen in opdracht verwerkt een verwerker is, en dat u met een partij die zelf het doel en de middelen bepaalt geen verwerkersovereenkomst hoeft te sluiten. Bij hosting is de hostingpartij meestal verwerker van de gemeente of organisatie, en TechinFlow als beheerder ook. Leg die keten op papier vast voordat er data in de omgeving komt.

Gaat het om open data zonder persoonsgegevens, dan zijn de eisen lichter. Maar ook dan wilt u weten waar de bron staat en wie erbij kan. Wat het rijksbrede cloudbeleid hierover zegt, staat in de gids EU-cloud voor overheidsdata.

Digitale Overheid omschrijft de Baseline Informatiebeveiliging Overheid zo:

De Baseline Informatiebeveiliging Overheid (BIO) is het basisnormenkader voor informatiebeveiliging binnen alle overheidslagen. Het vormt daarmee ook de basis voor verantwoording over informatiebeveiliging.

Bron: Digitale Overheid, pagina laatst gewijzigd 9 september 2026, gelezen op 11 oktober 2026. De laatste versie van de BIO staat volgens die pagina op bio-overheid.nl. De verantwoordelijkheid blijft bij de overheidsorganisatie zelf. Een leverancier kan maatregelen uitvoeren en aantonen, maar neemt de verantwoording niet over.

Deze tabel is een startpunt. In de verkenning vullen we hem samen in voor uw situatie, zodat er geen taak tussen twee partijen in valt.

Een exit is pas geloofwaardig als hij uitvoerbaar is zonder de oorspronkelijke leverancier. Bij infrastructuur betekent dat drie dingen: de infrastructuurcode staat in een repository van de opdrachtgever, de data is te exporteren in open formaten, en de applicaties draaien in containers die niet aan één cloud vastzitten.

Voor gemeenten is Haven daarbij een nuttig referentiepunt. Haven is volgens de eigen documentatie een generieke laag tussen applicaties en de IT-infrastructuur van een gemeente, zodat applicaties overal kunnen worden gehost zonder aanpassing aan die specifieke infrastructuur. Alles van Haven is open source, inclusief hulpmiddelen en referentie-implementaties. Draait uw gemeente al een Haven-omgeving, dan richten we de applicatie daarop in in plaats van op een eigen cluster.

Daarnaast stelt de Europese Data Act een kader voor het overstappen tussen aanbieders van dataverwerkingsdiensten. De Europese Commissie noemt het eenvoudig kunnen overzetten van data en wisselen van cloudaanbieder als een van de doelen van die verordening. Dat helpt, maar vervangt geen eigen voorbereiding. Oefen een verhuizing daarom eenmaal op een testomgeving: herbouw de omgeving bij een tweede aanbieder vanuit de code en zet een recente back-up terug. Pas dan weet u dat de exit werkt. Welke exit-eisen in het contract horen, staat bij vendor lock-in en exitstrategie.

1. Inventarisatie. Wat draait er, waar, met welke versies en wie heeft toegang? Bij een nieuwe omgeving vervangen de eisen van de toepassing deze stap.
2. Ontwerp. Een korte architectuurbeschrijving met componenten, netwerk, back-upstrategie en de verdeling van verantwoordelijkheden uit de tabel hierboven.
3. Bouw als code. De omgeving wordt vanuit de repository opgebouwd, eerst als test, daarna als productie.
4. Hersteltest. We zetten een back-up terug op een lege omgeving en leggen vast hoe lang dat duurde en wat er misging.
5. Overdracht of beheer. U krijgt de repository, een beheerhandleiding en de afspraken over monitoring, patches en meldingen. Beheer kan bij TechinFlow blijven of naar uw eigen team of een andere partij gaan.

Elke stap levert iets op dat u ook zonder vervolg kunt gebruiken. Een inventarisatie is bruikbaar voor een aanbesteding, een ontwerp voor een andere bouwer, en een hersteltest voor uw verantwoording. Wilt u een bestaande omgeving laten doorlichten, neem dan contact op met een korte beschrijving van wat er draait.

Twijfelt u eerst over de architectuur zelf, bijvoorbeeld tussen een eigen cluster en een beheerde clouddienst, dan is technologie- en softwareadvies een logische eerste stap.