Gemeenten: Houd regie over je integratieplatform, voorkom afhankelijkheid door lagen te scheiden

Steeds meer gemeenten willen hun IT-landschap vereenvoudigen en laten beheren door één partij. Logisch. Het scheelt tijd, mensen en zorgen.

Maar in de praktijk zien we dat dit gemak vaak omslaat in afhankelijkheid. De oorzaak? Het gehele integratieplatform wordt in één keer aanbesteed. Een paar jaar later moet alles opnieuw: nieuwe aanbesteding, nieuwe leverancier, nieuwe migratie.

Het probleem: je zit vast na de aanbesteding

Na een aantal jaar moet je opnieuw aanbesteden. Dat is het moment van de waarheid.

"Die ene leverancier is de enige die ons systeem kent"

Herkenbaar? Natuurlijk kent alleen die leverancier het systeem. Zij hebben het gebouwd. Het resultaat: je kunt niet wisselen zonder opnieuw te beginnen. 

Dit patroon herhaalt zich bij veel gemeenten. Een klassiek voorbeeld van de vendor lock-in, waar iedereen het over heeft.

Waarom gebeurt dit steeds weer?

Het probleem zit in hoe integratieplatformen worden opgebouwd. Alles zit verweven:

• De infrastructuur (servers/cloud)
• De software die systemen laat praten
• De specifieke koppelingen met beheer en onderhoud

Één geheel. Onlosmakelijk verbonden. Dus bij een nieuwe aanbesteding heb je twee keuzes:

Optie 1: Blijven bij dezelfde leverancier (vaak duurder)
Optie 2: Compleet opnieuw beginnen (nog duurder)

De oplossing: denk in 3 gescheiden lagen

Een integratieplatform zou moeten bestaan uit drie componenten. Deze moeten technisch én contractueel onafhankelijk blijven:

Laag 1: Infrastructuur

Waar draait alles op? Haven, Azure, AWS, on-premises of de Frank!Cloud.

Laag 2: Integratiesoftware

De motor die systemen laat communiceren. Denk aan Frank!Framework, MuleSoft, Adeptia of Boomi. Vaak gecombineerd met een API Gateway zoals de Frank!Gateway of Layer7.

Laag 3: Koppelingen & beheer

Low-code integraties: koppelingen tussen gemeentelijke systemen en/of landelijke voorzieningen. Met dagelijks beheer, monitoring, incidentafhandeling en kleine wijzigingen.

Elke laag moet vervangbaar zijn zonder de andere te raken

Wat betekent dit bij een nieuwe aanbesteding?

Zonder gescheiden lagen: "We willen een andere cloudleverancier" → Alles opnieuw bouwen

Met gescheiden lagen: "We willen een andere cloudleverancier" → Alleen één laag vervangen, terwijl de rest intact blijft.

Maar jullie bieden toch ook een ‘alles-in-een’ oplossing?

Wij bieden ook oplossingen met complete ontzorging. Het verschil? We houden de drie lagen altijd gescheiden. Zo kun je bij de volgende aanbesteding gewoon verder. Of je nu wilt wisselen van cloud, een ander beheerteam wilt, of helemaal wilt overstappen, het kan zonder alles opnieuw te bouwen.

Je koppelingen blijven van jou. De documentatie is altijd toegankelijk. Open standaarden zorgen voor overdraagbaarheid.

"Echte ontzorging betekent: de vrijheid om te kiezen"

Conclusie

Door bewust te kiezen voor gescheiden lagen, bouw je aan een platform dat meebeweegt met de toekomst.
Je voorkomt hoge migratiekosten, behoudt de regie en voldoet automatisch aan de principes van Common Ground en NDS.

Gemeenten die dit goed inrichten, hoeven nooit meer opnieuw te beginnen. Ze bouwen stap voor stap verder op wat er al staat.

Twijfel je of jouw huidige architectuur toekomstbestendig is?

We helpen gemeenten inzicht te krijgen in de opbouw van hun integratieplatform, waar de afhankelijkheden zitten en hoe je die kunt beperken.

Plan een gesprek en ontdek hoe je jouw integratiearchitectuur flexibel en open houdt.