Route design & lifecycle
Message routes treated as versioned artefacts rather than console changes: validate, dry-run, deploy, roll back. A canonical route format means a route reads the same in review as it behaves at runtime.
Braidner · building integrations since 2012
Integration Systems Architect 14 years
Systems that were never designed to talk to each other. I make them do it — reliably, at volume, and without a maintenance window.
Integration is the work of making independent systems agree — on format, on ordering, on what failure means. Four things carry most of it.
Message routes treated as versioned artefacts rather than console changes: validate, dry-run, deploy, roll back. A canonical route format means a route reads the same in review as it behaves at runtime.
XSLT and Groovy transformations with namespace behaviour pinned down, so a payload that leaves one system arrives intact at the next — including the edge cases that only surface under production volume.
Per-route tracing wired in at deploy time. A failed exchange becomes a tree you can read end to end, instead of a log you grep at two in the morning.
Programmatic route management, and an assistant that builds routes through exactly the pipeline a human uses — same validation, same dry run, no privileged shortcut.
Enterprise service bus — architecture and core
An integration platform on Apache Camel carrying traffic between systems that cannot be taken offline. I own the route lifecycle: the validate → dry-run → save pipeline, the canonical route format, and the broker-side trace subsystem that makes a running exchange inspectable.
A language model inside the platform
An assistant that lives inside the ESB and creates routes through the product's own API. The hard part is not the model: it is a tool loop with real blocking points, a prompt token budget measured rather than estimated, provider-specific reasoning wire formats, and gateway-level limits that keep cost bounded.
Self-hosted automation platform
A private platform automating a household of services — job queue, media pipeline, notifications, a React front end — running on my own hardware behind my own CI. Everything in it is something I had to operate, not merely ship.
Infrastructure, end to end
braidner.org runs on a server configured by hand: a single public HTTPS port, TLS from Let's Encrypt with renewal automated and verified, every other service bound to loopback behind a default-deny firewall. The page you are reading is the artefact.
What I reach for, roughly in order of how much of my life it has taken.
Telegram is the fastest way through. Email works just as well, and the code is public either way.