BizTalk Server may feel like a relic from a previous era of enterprise computing, and in some ways it is. But the patterns it enforces are not. The problems BizTalk was designed to solve (reliable message delivery, schema transformation, protocol mediation, orchestration of multi-step business processes) are the same problems that Azure Service Bus, MuleSoft, and Apache Kafka are solving today, with different technology and better user interfaces.
My early work as a BizTalk developer gave me a foundation in enterprise integration thinking that has shaped how I approach product architecture ever since. I integrated 16 systems for a US insurance ERP transformation and migrated data across two complex ERPs for energy sector clients using BizTalk Server 2013.
The Patterns That Carry Forward
Message Routing
Content-based routing, directing a message to different downstream systems based on the content of the message itself, is as relevant in a microservices architecture as it was in BizTalk orchestrations. The implementation is different (event bus versus orchestration engine), but the design decision is the same: where does the routing logic live, who owns it, and how does it behave when the routing rules change?
Schema Transformation
System A sends data in one format. System B expects another. Between them is a transformation layer that converts, enriches, and validates. In BizTalk, this was handled by maps and pipelines. In modern integration, it's handled by transformation functions in an iPaaS platform or by a dedicated schema registry. The concept is identical. The product questions it raises are the same ones: who owns the canonical data model? How do we handle versioning when the schema changes?
Guaranteed Message Delivery
In financial systems, a lost transaction is not an acceptable failure mode. BizTalk's message box and retry logic enforced guaranteed delivery at the platform level. In cloud-native integration, you achieve the same guarantee through message queues with dead-letter handling, idempotent consumers, and exactly-once semantics. The pattern is the same: assume the network will fail, design for recovery.
Orchestration vs Choreography
One of the most important architectural decisions in any integration programme is whether to use centralised orchestration (one component knows the sequence of steps and directs the others) or choreography (each component knows what to do when it receives a message, with no central coordinator). BizTalk was explicitly an orchestration engine. Modern event-driven architectures often prefer choreography for its loose coupling. The trade-off between visibility and control on one side, and resilience and independence on the other, is a genuine design decision that still deserves explicit attention. Not a default.
The PM Dimension
Why does this matter for a product manager? Because integration failures in finance are often not technology failures. They're governance failures. The question of who owns an integration, who is alerted when it fails, and who is responsible for the business impact of an outage are product and organisational design questions. Getting the answers right requires understanding the patterns well enough to ask the right questions, even if you're not the one writing the orchestration logic.