What Gregor Hohpe's Enterprise Integration Patterns Taught Our Connector Agent
Twenty years of cataloguing how real systems exchange data across enterprise boundaries — and the four ideas from that body of work that we encoded into our connector agent
By The Data Workers Team
In 2004, Gregor Hohpe published a short essay about Starbucks. Not about coffee. About distributed systems. The argument was that Starbucks serves thousands of customers a day without ever using a two-phase commit protocol — and that this tells you something important about how enterprise software should handle scale, failure, and asynchrony. The essay became one of the most-linked pieces in software architecture.
Hohpe has been doing that for twenty years. His 2003 book Enterprise Integration Patterns, co-authored with Bobby Woolf, catalogued 65 patterns for building asynchronous messaging solutions. It has sold more than 90,000 copies.
What Is Actually Worth Learning
Four ideas do the most work for connector design.
First: asynchrony is the natural state. 'A two-phase-commit can make life a lot simpler but it can also hurt the free flow of messages and therefore the scalability.' Message channels let each side operate at its own pace.
Second: coupling has multiple dimensions. Hohpe identifies coupling dimensions including temporal, topology, data format, semantic, and conversation. 'Most of the decoupling properties of EDAs derive from the use of Publish-Subscribe Channels, not event semantics.' Taking advantage of one dimension exposes you more to another.
Third: use conversation identifiers. Tracking a message through a ten-step workflow that crosses four systems requires a single ID that travels with every message from start to finish, independent of the message IDs individual systems assign.
Fourth: name the error handling strategy. Hohpe catalogued three: write-off (accept the loss), retry (reattempt), and compensating action (undo upstream steps). Choosing one explicitly prevents silent data loss.
- •Classify interaction style before choosing a channel — async is the default
- •Name coupling dimensions explicitly, not just directionally
- •Propagate a Conversation Identifier through every step and every alert
- •Choose write-off, retry, or compensating action before the pipeline runs
How a Method Becomes a Skill
The async-message-pattern-design skill runs in six steps. The agent first classifies the interaction style. It then names the coupling dimensions before designing the message contract. It assigns a Conversation Identifier at entry and propagates it through every downstream call. It selects an error-handling strategy per stage before touching a single pipeline. And when it reports back, it names the coupling trade-offs it made.
One of More Than 400
The async-message-pattern-design skill is one of more than 400 method-named skills we have built across 19 agents.
A note on this post: This is independent commentary and homage. It distills publicly available writing and talks by Gregor Hohpe to illustrate a working method, and every quote is drawn from and verified against the primary sources linked above. The skill it describes is named for the method, not the person, and contains no marketing claims attributed to them. Data Workers is not affiliated with, sponsored by, or endorsed by Gregor Hohpe. If you are Gregor Hohpe and would like anything adjusted or removed, email hello@dataworkers.io and we will respond promptly.
Related Posts
What Ralph Kimball's Dimensional Modeling Taught Our Pipelines Agent
Ralph Kimball's four-step dimensional design process is one of the most durable ideas in data engineering — here is what it taught our pipelines agent.
What Jay Kreps's Log-Centric Architecture Taught Our Streaming Agent
Jay Kreps's core insight is deceptively simple: an append-only, totally-ordered log is not just a message bus — it is the single source of truth that eliminates N² integration pipelines and makes reprocessing routine. We studied his published writing and built a reusable streaming skill around the method.
What W. Edwards Deming's Plan-Do-Study-Act Taught Our Data Quality Agent
W. Edwards Deming spent a career arguing that quality comes from improving the process, not inspecting for defects. His Plan-Do-Study-Act cycle is the most rigorous improvement loop in the field. Here is how we encoded it into our data quality agent.