Interoperability isn’t “we exposed an API”.

In enterprise systems, especially in Public Administration (PA), interoperability means exchanging information that stays correct, interpretable, and auditable over time. That “over time” part is where most projects break: models drift, regulations evolve, suppliers change, legacy systems stay put, and the same business concept ends up represented in five different ways across five different databases.

This is a pragmatic walkthrough of what actually works in that environment. We’ll cover Anti-Corruption Layers, Integration Layers, message brokers, normalization, and a few reliability patterns that keep integrations from collapsing under real-world conditions. No vendor talk, no “just adopt microservices”, and no pretending that legacy doesn’t exist.

Interoperability is not integration

Integration is the act of connecting systems: sending requests, receiving responses, delivering messages, moving files. Interoperability is what happens after that connection exists: whether both parties understand the same data in the same way, whether they can evolve without breaking each other, and whether you can reconstruct the truth when something goes wrong.

In PA this gets harder because integrations are institutional. You’re not linking one “service” to another; you’re linking organizations with different standards, responsibilities, and timelines. And traceability is not negotiable. When a citizen’s case is impacted, “the system replied 200 OK” is rarely a meaningful answer. You need to know what changed, why, and which source triggered it.

A simple way to frame interoperability is this: it’s not about connectivity, it’s about shared meaning + controlled evolution + auditability.

The legacy reality check: why naive approaches fail

Most interoperability failures are predictable because the same shortcuts keep happening. Point-to-point growth is the classic one. It starts as “just one integration”, then becomes six, then becomes thirty. Each endpoint carries slightly different assumptions, each transformation is implemented differently, and eventually nobody can explain what the system really believes about a piece of data. Another shortcut is extracting analytics directly from operational databases. The first report works fine, then volumes grow, queries get heavier, indexes get tuned for reporting instead of operations, and the transactional workload slows down. At that point you choose between degrading operational performance or killing analytics that stakeholders now depend on. Then there’s the retry trap. It’s easy to implement “retry on error” and call it resilience. But blind retries can re-apply a command that no longer matches the current state. In legacy-heavy environments this is common: downstream systems aren’t idempotent, upstream systems don’t know the real state, and you introduce subtle misalignments that appear weeks later. Finally, investigations often fail because history is missing. If you can’t reconstruct “what exactly happened to this record”, every incident becomes guesswork. In PA, that’s not only operational pain, it’s also governance pain.

Here are the shortcuts that usually show up together:

  • Point-to-point sprawl and inconsistent transformations
  • Operational DB used for analytics, causing performance regressions
  • Blind retries that ignore current state and create silent inconsistencies
  • Missing history/audit, making root cause analysis nearly impossible

These failures aren’t caused by bad tools. They happen when interoperability is treated as wiring rather than architecture.

Integration Layer vs Anti-Corruption Layer (ACL): two different responsibilities

Two concepts are frequently confused: the Integration Layer and the Anti-Corruption Layer (ACL). They both sit between systems, but their goals are not the same.

The Integration Layer is about mechanics. It standardizes how you connect: protocols, authentication, routing, throttling, canonical headers, consistent error handling. It’s where you centralize the boring but essential concerns that otherwise get re-implemented everywhere.

The ACL is about meaning. It protects your internal model from external chaos. Legacy systems and external organizations often encode business concepts in ways that are convenient for them, not for you. Status codes like 7 or 9 might make sense historically, but they’re not a stable language for your domain. An ACL translates external representations into internal concepts and enforces your invariants. This is where teams often underestimate the work. They implement DTO mapping and call it an ACL. But real ACL work is semantic. It’s deciding what an external field actually means in your domain, how to handle missing or contradictory information, and how to evolve without letting external changes ripple into your core services. A useful rule of thumb is simple: your core domain should never “speak legacy”. If you find yourself introducing external codes, external lifecycle states, or external quirks inside your core model, you’re skipping the ACL and you’ll pay for it later.

A practical mental model:

  • Integration Layer: “How do we connect?”
  • ACL: “What does this mean in our domain?”

Normalization: fix meaning, not just formats

Normalization is often treated as “format cleanup”: date formats, trimming strings, validating identifiers, ensuring encoding consistency. That’s necessary, but it’s not sufficient. In interoperability projects, the harder part is semantic normalization. The same field can represent different meanings depending on the source, the time period, or the business process that generated it. Two systems may both expose a concept called “status”, but one encodes operational status while the other encodes legal eligibility. You can normalize formats all day and still exchange wrong information. That’s why interoperability needs data contracts, not just endpoints. A contract makes expectations explicit: schema, semantics, versioning, validation rules, and compatibility commitments. In long-lived PA ecosystems, contracts are the difference between stable evolution and perpetual firefighting because they let you change one side without breaking the other, and they give you a shared reference when disputes arise.

What good contracts typically include:

  • A clear schema (even a simple one is better than none)
  • Semantic notes (what fields mean, not just their type)
  • Versioning rules and backward compatibility expectations
  • Validation rules and error semantics (what is rejected, what is tolerated)

Treat contracts as products: documented, versioned, tested, and owned. Otherwise interoperability becomes folklore.

The message broker: boring, but it saves projects

When organizations integrate, availability and timing rarely align. That’s why async-first architectures are so effective in PA and legacy landscapes. A message broker introduces decoupling: producers don’t need consumers to be online right now, and consumers can process at their own pace. But a broker doesn’t magically solve reliability. It forces you to be explicit about things synchronous calls often hide: retry strategies, poison messages, ordering assumptions, and what at least once delivery means for your business operations. This is also where the classic “blind retry” problem shows up again. If a failed transaction is retried without considering the current state, you can create contradictions. The same command that was correct yesterday might be incorrect today because new information arrived or the citizen’s case changed. Resilience that ignores state is just chaos with better logging. A broker helps because it enables a controlled approach: dead-letter queues, delayed retries, backpressure, replay, and fan-out patterns. It turns integrations into pipelines rather than fragile call chains.

A few broker-related concerns you should always decide upfront (explicitly):

  • How retries work (transient vs permanent failures)
  • How you handle poison messages (DLQ)
  • How you achieve idempotency and deduplication downstream
  • Whether you require ordering, and how you enforce it

Reliability patterns that keep integrations survivable

Once you accept that distributed systems fail in annoying ways, a few patterns become non-negotiable.

Transactional Outbox is the first. If a service updates its database and must publish an event, you want both actions to be consistent. Writing state to the DB and sending a message in the same “logical transaction” is harder than it looks. Without an outbox, you’ll eventually hit scenarios where the DB commit succeeds but message publishing fails (or vice versa). The outbox approach writes the outgoing event into a table in the same DB transaction and publishes it asynchronously. Not glamorous, but one of the best reliability trades you can make.

Idempotency and deduplication are the second. Duplicates happen. Replays happen. Recovery produces duplicates by design. Consumers must safely process the same message multiple times without breaking state. This usually means idempotency keys, dedup stores, and “upsert-like” semantics. It also means designing commands/events so that replaying them is safe.

Finally, for long-lived cross-system workflows you often need a Saga or process manager. PA workflows can span multiple domains and last days or weeks. Modeling them as a chain of synchronous calls is fragile and makes recovery painful. A process manager maintains state, correlates events, handles timeouts, and defines compensations. It’s the difference between a controlled workflow and a pile of retries.

If you want a quick checklist, these are the patterns most often missing in broken integrations:

  • Transactional Outbox (reliable publishing)
  • Idempotency + dedup (safe consumption)
  • DLQ strategy (controlled failure handling)
  • Correlation IDs (end-to-end traceability)
  • Process manager for long workflows (controlled orchestration)

Observability and auditability: the PA baseline

In many private contexts, you can survive with basic logging and an incident ticket. In PA contexts, auditability is a baseline requirement. You often need to prove what happened, not just fix it. That means correlation IDs across boundaries, structured logs, and distributed tracing for integration paths. It also means designing an audit trail that answers uncomfortable questions: who changed what, when, why, and based on which source. This becomes critical when the same “record” is influenced by multiple inbound integrations. At the same time, auditability must respect privacy. You can’t just log everything. You need tokenization, masking, and retention policies. The goal is to keep integrations observable and reconstructable without turning logs into a liability.

Analytics: stop querying operational databases

One of the most consistent anti-patterns in enterprise systems is “analytics on production databases”. It usually starts with good intentions and ends with performance problems and fragile tuning. When volumes grow, operational and analytical workloads compete, and tuning becomes a zero-sum game. A healthier approach is workload isolation. Build read models, projections, marts, or any other dedicated layer for analytics. Populate it incrementally, ideally near-real-time, and let it evolve independently from the operational model. This is where “Data-as-a-Product” becomes practical: curated datasets with ownership, documentation, and expectations. Near-real-time analytics isn’t about buying a platform. It’s about not mixing responsibilities. When operations and analytics are separated, both become more reliable.

A pragmatic playbook (no big-bang needed)

Interoperability improvements don’t require rewriting everything. They require choosing the right battles and sequencing changes. Start by identifying the critical exchange flows: high volume, high failure impact, or high business sensitivity. Formalize contracts for those flows and introduce an ACL where semantics are unstable. Move heavy exchange toward asynchronous messaging where coupling and availability are hurting you, and add idempotency and recovery mechanisms before you scale. If you publish events, introduce an outbox. If reporting is killing the operational DB, isolate analytics with projections. Then instrument the whole thing with correlation IDs and audit trails so you can operate it with confidence.

A simple sequence that works surprisingly often is:

  • Stabilize semantics with contracts and ACLs
  • Stabilize reliability with outbox, idempotency, and DLQ
  • Stabilize performance by isolating analytics workloads
  • Stabilize operations with observability and audit trails

Small steps. Measurable wins. Repeat.

Conclusion

Interoperability is semantic stability over time, not a simply connection. In PA and legacy landscapes, architecture must assume drift, partial failure, and long-lived processes. The Integration Layer standardizes mechanics; the ACL protects meaning. Brokers, idempotency, and outboxes make integrations resilient and evolvable. Normalization must include semantics, not just formats. Analytics belongs outside operational databases. Observability and auditability are first-class requirements, not optional extras.

If you treat interoperability as an architecture discipline rather than wiring, you stop fighting fires and start shipping reliable change.

<
Previous Post
Benchmarking in .NET: Measuring What Really Matters
>
Blog Archive
Archive of all previous blog posts