Municipalities: keep control of your integration platform by separating your layers

More and more municipalities want to simplify their IT landscape and have it managed by a single party. Makes perfect sense. It saves time, people and headaches.

But in practice, we often see this convenience turn into dependency. The reason? The entire integration platform is procured as one big package. A few years later the cycle starts again: a new tender, a new supplier, a new migration.

The problem: you’re stuck after the tender

After a few years, you need to tender again. That’s the moment of truth.

“Only our current supplier understands our system.”

Sounds familiar? Of course they do. They built it. The result: you can’t switch without starting over.

This pattern repeats across many municipalities. A classic example of the vendor lock-in everyone talks about.

Why does this keep happening?

The issue lies in how integration platforms are structured. Everything is intertwined:

• the infrastructure (servers/cloud)
• the software that lets systems communicate
• the specific integrations with maintenance and support

One single bundle. Technically and contractually entangled. So when the next tender arrives, you’re left with two options:

Option 1: stay with the same supplier (usually more expensive)
Option 2: start from scratch (even more expensive)

The solution: think in three separate layers

An integration platform should consist of three components, each of which must remain separate, both technically and contractually:

Layer 1: infrastructure

Where everything runs: Haven, Azure, AWS, on-premises or the Frank!Cloud.

Layer 2: integration software

The engine that lets systems communicate. Think Frank!Framework, MuleSoft, Adeptia or Boomi. Often combined with an API gateway such as the Frank!Gateway or Layer7.

Layer 3: integrations and operations

Low-code connections between municipal systems and national facilities, plus daily operations: monitoring, incident handling and minor changes.

Each layer must be replaceable without affecting the others

What does that mean for your next tender?

Without separated layers: “We want to switch cloud providers” → you have to rebuild everything.

With separated layers: “We want to switch cloud providers” → you replace one layer, the rest stays intact.

But don’t you also offer an “all-in-one” solution?

We do offer fully managed solutions. The difference?
We always keep the three layers separated. That means that in your next tender you can continue without starting over. Whether you want to switch clouds, change your operations team or migrate entirely, it can be done without rebuilding your integrations.

Your integrations remain yours. Documentation is always accessible. Open standards ensure portability.

“Real peace of mind means having the freedom to choose.”

Conclusion

By intentionally separating layers, you build a platform that can evolve over time.
You avoid high migration costs, keep control and automatically align with the principles of Common Ground and NDS.

Municipalities that set this up well never have to start over again. They can continue building, step by step, on what already exists.

Unsure whether your current architecture is future-proof?

We help municipalities assess the structure of their integration platform, identify where dependencies exist and show how to reduce them.

Schedule a conversation and discover how to keep your integration architecture flexible and open.