More architecture won't move the objection

An inherited requirement makes a stubborn objection.

Somebody has to be able to get to it. That one came off a plant floor, where an outage runs as long as somebody's walk to the machine. A machine stops, a person goes over, and every hour in between is visible to everyone waiting. On that floor, the requirement was right every time it was applied.

Point it at a system in a data center and one word stops working. The word is *get*. The rest holds because a system generating revenue does need somebody awake to the problem. But on that floor, awake and present always arrived together. Every repair anyone there had seen came with a person standing next to it, so the two never had to be told apart.

So the objection is that a reading from an instrument that has never been wrong was pointed at a system it was never built to measure. More architecture won't move a reading. Take the same measurement somewhere else, and it moves.

The evidence is already in the room

Take the objection in the words it was said in, and ask it of whatever is running now.

Somebody has to be able to get to it. Ask that, and the answer comes back fine. The operations lead can reach it, and always could. Then ask what actually saved it the last time something went wrong, and the answer is a copy restored from somewhere else, or a second one already running.

The requirement passes, and passing protected nothing. Presence was only ever standing next to repair.

That answer is architectural. Whether a copy exists somewhere else is a statement about how a system is built. It lands because the operations lead already held every piece of it before anyone walked in. The question is all the proposal supplies. The evidence was theirs.

Which is why they have to be the one who says it out loud. The same facts, coming from the side that wants a yes, are a claim about the operations lead's own system.

Keep the wording. Narrow the question, and it stops being the same question, and everyone in the room can tell.

Then expect it to come back the other way. Sometimes reaching it is exactly what saved the thing, because a person walked over and the work started again when they did. Then the requirement holds, and the design problem belongs to the proposal. A question that can only go one way is a trick, and this one goes both ways.

What it does is smaller than it looks. The objection stops being the deciding factor, though asking a second time uses up what's left of the room's patience.

Name the word in the objection that carries the weight, then name what that word always came with where the requirement was learned. A system that delivers one without the other is being measured on the half that stopped predicting anything.

That leaves the objection that was never learned anywhere. A requirement that arrived as written policy has no floor to revisit and no companion word to name.

Let the other side run the check

The operations lead cannot verify failover behavior, backup frequency, or restore time without access to the proposed system. Until that access exists, every fact arrives as a description from the side that wants a yes. Ten more descriptions are ten more of the same.

Change the kind of claim instead. Once there is something to restore from, run the restore while the operations lead holds the clock, and let them go looking for their own numbers in what comes back. Or leave the old system running with a way back and a date on it. Both put the claim somewhere the operations lead can score it alone.

Standing works the same way. Read the system you want to change, report what's in it, and stop there. A finding they can confirm from their own monitoring is free to accept, and after enough of those, the question arrives from someone who has already shown they understand what they are asking about. The first time they bring a problem over unprompted is the signal it worked.

The operations lead adopts the standard only after watching it rule against you once. Concede a point on your own evidence and the next check gets run honestly. Skip that, and they price the question as rigged, which it usually is.

Skip all of it and the change still ships, over an unanswered objection. Then a dependency outside the system fails, or a fix has to wait for a window, and recovery takes four hours. From the floor that produced the objection, the visible facts are that it broke, that nobody came, and that it stayed broken until the afternoon. The event matches every term the objection predicted. Nothing in it tests *get*, because being there wouldn't have shortened a queue somewhere else. Whoever holds the requirement reads it as confirmation anyway, and the next proposal comes up against a stronger reading.

The same standard rules against the proposal

Hand the standard over, and it can't be taken back when the answer is no.

The changes that are hardest to lose are the ones an engineer wants most. A rewrite onto a supported framework results in lower maintenance costs the next time the system has to change. Until then, the system it would replace produces evidence every working day. What the rewrite already cost its author has nothing to do with the verdict.

The current system can still fail the same test. A stack that only one team can maintain forces the operations lead to wait in that team's queue. Watch who gets called, then count how long the queue is.

A system that keeps running accumulates the argument against touching it at a rate of one day per day.