What 40+ Multi-Vendor Deployments Taught Me About Boundry Ownership

On a typical deployment I was coordinating a dozen people who had never met and mostly never would: a building automation programmer (Crestron, Lutron, or Savant), a managed-network engineer, a certified lighting tech, a US firmware shop, a platform development vendor in India, an HVAC contractor, an electrician, a general contractor, and the customer’s own staff. None of them worked for me, and most of them didn’t work for each other. More importantly, the system we were installing in projects didn’t work unless every one of their layers did.

The product was a building wellness platform called DARWIN, which I deployed and commissioned into more than forty projects. The setting happened to be high-end residential, but the architecture will look familiar to anyone who has fielded an industrial system: an edge fleet of twenty-plus IoT air-quality sensors publishing MQTT to an on-prem gateway every minute, a control algorithm on the gateway, commands going out to a supervisory system we didn’t build — Crestron, Lutron, or Savant — which actuated HVAC and lighting, all of it on a managed network owned by somebody else. The integration was complicated: sensors to gateway for data, gateway to controller for visualization, and gateway to controller to thermostat for actuation. That’s three data paths, four companies, and one customer.

The assumption on every project was that the systems integrator would handle integration. That’s what the title says, after all. In practice, the Crestron programmer could see Crestron, the network engineer could see the network, the firmware shop could see the interface they’d built, and the platform vendor could see their own code and nothing else. Every one of them was competent in their layer, and not one of them could trace a failure across any two layers. That was the actual job, and at first it belonged to nobody until I had to claimed it.

Most of the work was translation. The network engineer didn’t need to hear about product features; he needed to know that twenty devices would publish over MQTT every sixty seconds, that the gateway needed a static IP and firewall exceptions, and that if he put the sensors on their own subnet he’d need explicit routes back to the gateway or the fleet would go quiet. The Crestron programmer needed interface specs. The HVAC contractor needed to know what our algorithm was going to do to his airflow before he would sign off on anything. And the customer needed a plain answer to a plain question: what could break and how to fix it? This was a single system, but you needed five languages to bridge the communication gap and make it work. If you speak only one of them, you can install your own layer, but you can’t field the system.

The night that taught me the most started with a late phone call. A $35M property we had just finished — every test passed — but the lights were turning themselves on with no way to shut them off. I made two decisions before any debugging happened. I pulled our gateway out of the loop, so that we stopped being a variable. And I gave the customer direct access to the lighting system’s native software, so the customer had control of their own building back. Then I sequenced the diagnosis the only way a multi-vendor failure can be sequenced: one layer at a time, with each layer’s owner on the phone. The Crestron programmer found a bug in scene execution. We fixed it; but the problem persisted. The firmware shop confirmed no bug in their module. The platform vendor never produced a root cause, and the issue eventually stopped on its own. I took that nobody was lying to me; they were telling the truth about their ownn layer. The failure lived in a seam, and seams don’t have vendors.

A quieter problem turned out to be better evidence of what the bridging work really is. Our algorithm detected particulate spikes and ran the HVAC fan through HEPA filtration — and in doing so, it overrode the thermostat. The software saw a clean control action. But the reality of the field conditions disagreed: a heating cycle that ended two minutes earlier leaves hot coils in the ductwork, our fan pushed air across them, the room drifted out of its temperature band, and the thermostat started a fresh cycle. Note that these are two systems, each behaving correctly, producing a loop neither of them could see. Catching it required knowing how thermostats actually behave, which is contractor knowledge, and knowing what our code assumed, which is developer knowledge. Fixing it required real-time thermostate state flowing from the controller to our gateway — an interface that did not exist until I scoped it and drove the firmware shop to build it.

None of that is product or system specific knowledge. What those forty-odd commissionings taught me is that every fielded system crosses organizational boundaries. Most importantly, the failures concentrate at the boundaries, and boundary ownership is unassigned by default. The hardware changes from site to site and sector to sector; the seams don’t. So before any deployment mobilizes, I do four things. I map the whole system on paper — every device, every data path, every port and protocol, and which organization owns each piece — because the ownership map tells you where it will break. I put written interface and network requirements in front of whoever owns the site’s infrastructure before I arrive, instead of negotiating access on the ground. I make sure someone on site can safely isolate my system without calling me, because degraded-mode control belongs to the customer, not the vendor. And I don’t command any system whose state I can’t read back. I built that list the hard way — for years I treated every site as a surprise, and paid for it.

DARWIN was eventually retired, and the cost of commissioning and supporting it was part of that math. But the role it forced me to invent — the person who owns the seams — is the role every multi-vendor deployment needs, whether the edge devices sit in a residence, a factory, or a base. It doesn’t appear on any org chart and someone has to do it anyway.