Every few months I get pulled into a war room where an insurance carrier or a bank is trying to figure out why their policy data, claims feed, or commission calculation is wrong. The integration platform is always shiny — some combination of Logic Apps, MuleSoft, Boomi, or a homegrown Kafka pipeline with Python glue. And the root cause is almost always the same: nobody enforced a contract at the boundary, nobody guaranteed delivery, and nobody can tell you with certainty which message produced which downstream record.
I spent a meaningful chunk of my career building BizTalk solutions for Turkish banks and insurers. I am not nostalgic about it. The tooling was painful, the learning curve brutal, and debugging an orchestration at 2 AM with DTA queries was a special kind of suffering. But BizTalk forced you to do things correctly in ways that modern iPaaS platforms make optional — and optional, in enterprise integration, means skipped.
The Three Disciplines BizTalk Enforced
BizTalk was opinionated to the point of being obnoxious. You could not build a half-baked integration without the platform fighting you. Three disciplines in particular:
- Schema validation at the boundary. Every message entering the MessageBox had to conform to a published XSD. If a partner sent you a malformed EDI 837 or a broken policy XML, it failed at the receive port — not three hops downstream in a stored procedure.
- Guaranteed, durable message delivery. The MessageBox was a transactional store. Once a message was persisted, it was delivered exactly once, with retries, suspension, and resumption built in. You did not write this logic. You inherited it.
- Explicit orchestration contracts. An orchestration had typed inputs, typed outputs, and a visible flow. Correlation sets were declared. Compensation logic was explicit. You could read an orchestration and know what it did.
None of this was glamorous. All of it was load-bearing.
What Modern iPaaS Made Optional
Look at a typical Logic Apps or Boomi implementation in a mid-sized insurer. A REST endpoint receives JSON. The JSON is passed through a series of transformation steps. Maybe there's a JSON schema check, maybe not. Usually not, because the schema lives in a Confluence page that hasn't been updated since 2022.
When the upstream system adds a new field, or changes policyHolderId from int to string, the integration keeps running. The transformation silently coerces or drops the field. Downstream, the data warehouse gets a NULL where it expected an identifier. Three weeks later, a reinsurance report comes out wrong, and someone calls me.
The pattern repeats:
- No schema enforcement. JSON is treated as forgiving, which means errors are deferred, not prevented. A malformed claim payload becomes a malformed claim record.
- At-least-once delivery dressed up as exactly-once. Most iPaaS connectors retry on failure but have no idempotency contract. I have seen the same premium payment posted three times because the acknowledgment timed out.
- Implicit orchestration. A flow with 40 steps, dynamic content references, and inline expressions is not an orchestration. It's a script. Nobody can review it, nobody can reason about its failure modes, and the moment the original developer leaves, it becomes archaeology.
A Concrete Example: Policy Issuance
A Turkish life insurer I worked with replaced their BizTalk policy issuance pipeline with a modern event-driven architecture. Kafka, microservices, the full stack. Six months in, finance flagged that roughly 0.4% of issued policies had premium amounts that did not match the underwriting decision.
The old BizTalk flow validated the underwriting message against a schema that required grossPremium, netPremium, and commissionAmount as decimals with explicit precision. The orchestration had a correlation set on quoteId and persisted every state transition.
The new flow accepted JSON events. Somewhere upstream, a service started emitting grossPremium as a string in locale-formatted form — "1.234,56" — when a specific product was quoted. The consumer parsed it with parseFloat, got 1.234, and wrote that to the policy record. No error, no alert, no schema rejection. Just quietly wrong premiums for one product line for six months.
In BizTalk, this would have failed at the receive port the first time it happened. In the new system, it failed at the audit committee.
What to Steal From BizTalk Without Bringing BizTalk Back
I am not arguing for a BizTalk revival. The platform deserved its retirement. But the discipline it enforced should not have retired with it. If you are building integrations on modern iPaaS, steal these habits:
- Validate every inbound payload against a versioned schema. JSON Schema, Avro, Protobuf — pick one, store it in a registry, reject non-conforming messages at the edge. Not in the transformation step. At the edge.
- Make idempotency a contract, not a hope. Every message needs a stable identifier. Every consumer needs to handle replays. Write this down. Test it.
- Persist before you process. If you cannot replay every message that entered your platform in the last 30 days, you do not have guaranteed delivery. You have optimistic delivery with extra steps.
- Make orchestration explicit and reviewable. If your integration logic is spread across visual designer expressions, inline scripts, and connector configurations, nobody is reviewing it. Move complex flows to code that goes through pull requests.
- Treat schema changes as breaking changes by default. Backward compatibility is a property you prove, not assume.
The Real Lesson
The iPaaS vendors sold a story that integration could be drag-and-drop, low-code, accessible to citizen developers. For simple flows, fine. But the moment money, policies, or regulatory data are involved, the absence of enforced contracts becomes a liability that compounds quietly until an auditor or a customer finds it.
BizTalk made the right things mandatory because it knew the wrong things were too easy. Modern platforms made the right things optional and called it flexibility. The data quality problems I get paid to fix are the bill for that flexibility, arriving with interest.