What BizTalk Taught Me About Enterprise Integration
Pattern thinking from the pre-cloud era that still governs how modern cloud integrations fail.
I spent years building BizTalk integrations. Accenture, Avanade, Tim Hortons, Canada Post. More than sixty interfaces across SAP, Lotus Notes, mainframes, and legacy web services, most under timelines with no room for comfort. What that work left me with wasn’t a set of technical skills that aged out when Azure arrived. It was a way of thinking about integration that still explains most of the failures I see in Power Automate and Azure Integration Services today.
The platforms changed completely. The failure modes didn’t.
The boundary is where the risk lives
The most important thing BizTalk made concrete was the boundary. Every integration crosses one: between systems, between organisations, between trust domains. Every integration failure traces back to a boundary that wasn’t handled correctly.
In BizTalk terms this meant schema validation at the receive port. Before a message entered the pipeline, it was validated against a known schema. Non-conforming messages got rejected at the boundary, not processed halfway and then failed. The failure was clean, early, logged. System state stayed consistent.
Today I see Power Automate flows receiving JSON from external systems with no schema validation at all. The flow assumes the payload matches expectations. Then a field comes in null, or a data type changes, or the source system adds a property that breaks a downstream expression, and the flow dies midway through a process that has already written to a database, sent an email, or created a Dataverse record. Cleanup is manual. Damage is real.
Nobody asks for schema validation in requirements. It’s the work that makes every other part of the integration defensible anyway.
Idempotency is not optional
BizTalk had guaranteed delivery, paired with an equally important obligation: the receiving system had to tolerate duplicate messages. On a network, retry means the same message may arrive twice. An integration that can’t handle duplicate delivery will eventually corrupt state. Not might. Will.
The problem hasn’t gone anywhere. Power Automate flows triggered by HTTP requests or message queues can fire on the same trigger more than once in retry scenarios. Azure Service Bus ships with a dead-letter queue, but most integrations built on it never implement idempotency at the processing layer. The working assumption is that each trigger fires once and succeeds. Run it in production long enough and that assumption fails.
Serious BizTalk work enforced idempotency, designing every write so it can apply multiple times with the same result, because the cost of skipping it was immediate and visible. Modern cloud integration defers that cost to a production incident nobody can diagnose cleanly.
Message tracking is not optional either
In BizTalk you could see every message that entered the system, at every pipeline stage, with its payload and routing decisions. This wasn’t optional instrumentation; the platform built it in and production deployments expected it. When something failed, you reconstructed exactly what happened, in order, with the actual data.
Power Automate run history is a reasonable start, and Azure Monitor plus Application Insights go further. Yet I regularly find production integrations on Power Automate or Logic Apps with no structured logging, no correlation IDs, no record of which items were processed in which run, no alerting on failure rates. The integration works until it doesn’t, and then diagnosis starts from zero.
The instrumentation capability exists. What BizTalk enforced structurally, and modern platforms leave optional, is the discipline of using it. Leave it optional and you build integrations that can’t be operated.
Orchestration hides complexity; it does not remove it
BizTalk orchestrations were visual workflow designers for complex integration logic. They made the happy path legible and the exception paths invisible. The failure modes lived in branches the diagram never showed: step three succeeds but step four times out, the rollback fails, the correlation set doesn’t match.
Power Automate is the same pattern at a different layer of abstraction. Clean canvas, easy happy path, and error handling (where it exists at all) buried in scope actions and run-after configurations most builders never wire correctly.
Orchestration tools give you expressive power. They don’t give you correctness. Correctness means knowing the failure modes and deciding what to do about each one, and that work is identical whether the engine is a BizTalk server from 2009 or a Power Automate cloud flow from 2024.
What this means in practice
When I review a Power Platform or Azure integration architecture, my questions come straight from what BizTalk enforced structurally. Where does schema validation happen? How does the system behave on retry? What does the run history tell you, and is anyone reading it? What’s the designed behaviour when step three succeeds and step four fails?
These aren’t cloud-native questions. They’re integration questions. They were the right ones on BizTalk Server 2006 and they’re the right ones now. Enterprises that answer them build integrations that run. Enterprises that skip them build integrations that work in demos.