Practice area

The seams between systems are where the cost actually lives.

Most platforms are not slow or fragile because a service is badly written. They are slow and fragile because the contracts between services were never stated, so every integration is a negotiation and every change is a surprise.

I design the substrate that makes the next integration boring: canonical data contracts, event streams other teams can build against, and a capability model that turns new vendors into data rather than into a release.

  • 22s → 0.4s

    report resolution, by collapsing roughly 1,500 sequential queries into about seven batched

  • 285+

    device capabilities across 57 vendors, under a 1,279-test conformance suite

  • 20+

    partner integrations shipped and maintained, not prototyped

What I do here

Sequential round-trips versus batched Before: one report fans out into roughly fifteen hundred sequential round-trips to the data store and resolves in twenty-two seconds. After: the same report issues about seven batched round-trips and resolves in four tenths of a second. BEFORE Report Data ~1,500 sequential round-trips 22s to resolve AFTER Report Data ~7 batched round-trips 0.4s to resolve
The seam, drawn. Nothing about the query got faster — the number of times the system crossed the boundary changed, and that is where the 22 seconds were living.

Event-driven and event-sourced systems

Kafka, Debezium change data capture, Kubernetes, AWS. The decision that matters is rarely which broker — it is whether the events you publish are a contract other teams can build against, or an implementation detail you will regret exposing.

Partner integration fabrics

Twenty-plus integrations, each with a partner who versions on their own schedule and reads the spec differently than you do. The work is canonical data contracts and an anti-corruption layer, so one partner’s idea of a unit does not leak into your domain model.

IoT control planes

A capability catalogue that describes what a device can actually do, rather than a switch statement per vendor. That is what makes 57 vendors tractable: new hardware becomes data, not a release.

On the record

2026

Five radios on one microcontroller

LoRaWAN, BLE, Z-Wave, NFC and Wi-Fi in a single Zephyr RTOS image with secure boot and signed over-the-air updates — at 73% flash and 27% RAM. The budget was assumed to be exceeded; I disproved that with measured builds rather than argument, which is usually the cheaper way to win an architecture disagreement.

2026

A user interface that writes itself

A server-driven UI where the interface is a projection of a machine-readable capability catalogue: add a device capability and its controls appear for entitled users with no renderer changes. One contract drives a web runtime plus generated Android and iOS native code, verified by real compiler runs.

2025 – 2026

An event-sourced IoT control plane

Built inside a governed multi-agent delivery programme, alongside a greenfield twelve-service platform and shipping firmware — the integration substrate the device work above depends on.

“One of their standout achievements was taking our multi-vendor integrations service, previously unreliable and difficult to use, and rebuilding it from the ground up into a robust solution that dramatically improved our customer satisfaction.”
Sampath Pagolu · Cloud Specialist — AWS, Kubernetes, CI/CD

This is one of four practices.

The architecture is only half of it. What decides whether a platform can be trusted is the governance layer on top of it, and how the work gets delivered.

Start a conversation See the whole practice How I work