Architecture bends around what you won't change
Designing around components you can't control means picking which side holds the workaround. The one you refuse to change shapes everything else.
Friction doesn't disappear when you design around it. It moves.
Every system has components you govern and components you don't. When they disagree, one side has to carry the extra work. Try to make the ungoverned side comply, and the work comes back as a config pushed to another device, a workaround shipped for another partner, due again on the other side's schedule.
The design decision is which component absorbs the friction. Once you decide one component costs too much to change, every other component has to bend around it.
The side you don't govern sets the rate
The other side can add the workaround. You can't require it or check that it survived the last update. The only fix you can rely on is the one you maintain.
When every instance carries the workaround, the bill grows with three things: the cost of each change, the size of the population, and how quickly that population turns over. You control the first. The other side sets the population and churn, which is why the total can grow even while each fix remains small.
A self-signed certificate can secure a connection with the same keys and ciphers as a publicly trusted one. The client rejects the identity, not the encryption. The refusal is correct, and it doesn't bend for a private network. To fight it, you distribute a custom root to every device, and again to every device that arrives after. The alternative is a wildcard certificate from a public authority the clients already trust. One certificate covered 20 to 30 internal services; clients required no configuration, and renewal ran from a single governed point.
When the workaround is smoother than the intended path, the friction sits on a side that can't absorb it. A warning that gets clicked through every day has already lost the argument. The design is overruled on a per-instance basis, and nothing records the verdict.
Put the fix where one owner can keep it working
Put the workaround behind one control point, and the population stops multiplying it. The certificate still expires, and the proxy still needs monitoring, but you maintain both on your schedule and watch them in one place.
The component that hurts and the component that can fix it are usually different components. Warnings appear on clients. The fix lives on the proxy.
Scatter the workaround and stale copies fail one by one, each discovered only when it breaks something. Put it behind a single control point, and the whole system can fail at once. That trade only works when someone owns the logs and the uptime target.
Someone has to operate the control point. It becomes infrastructure the moment the first client depends on it. The maintenance once scattered across the population lands on one team. In return, failures appear alongside the logs, and a single fix reaches every client.
The boundary doesn't need to be one you can touch. If a partner controls the export format, keep the adapter on your side. Their format can change on their schedule without forcing every consumer to change with it.
"Can't change" usually means "costs too much to change"
A few components are immovable: another company's systems, a protocol frozen by everyone who already speaks it. The rest are movable at a price, and the price is usually distribution. The change is one line, and that line has to apply to every instance of a population that churns. Even where a custom certificate authority is technically available, its root still has to reach every device, forever. The component you "can't change" is usually the component you've priced and declined to pay for.
You can control it and still leave it alone
You can control both components and still have only one worth changing. Control answers what you may change. Price answers what you should.
A workload that needs a fast-moving kernel can't run a backup agent built for a stable one. A small container exposes the data through read-only mounts over an interface the backup system already speaks, so no backup agent runs on the host. The kernel can move while the backup interface stays put.
When the same fix keeps coming back, redo the math
First try to delete the mismatch. When both sides can adopt the same standard, or the requirement that created the conflict can be dropped, the friction stops existing, and that is the cheapest it will ever be. Absorb what survives that attempt.
The same fix keeps coming back: one more device configured, one more exception added, one more warning clicked through. The bill scales with whichever side carries it. The first estimate may have counted a single fix, even though the system keeps buying it for every device. Run the numbers again. Count how many places carry the workaround and how often those places change. Keeping it there may still be cheaper. The decision no longer rests on the old price.
The warning appears on the client. The architecture decision lives at the proxy.
