Two capital programs in the same period, the same architecture function, the same authority. One produced requirements. The other produced findings. The difference was when it was called.
Called before: requirements
On the fire apparatus mobile gateway program the named role in the project structure was advisor on technical configurations, with separate people co-managing acquisition and implementation. A solution architecture review sat in the schedule before the solicitation closed.
The output was requirements — things the thing being bought had to do, written while it was still possible for them to shape what arrived.
Called after: findings
On an enterprise platform upgrade running at the same time, the review board’s acceptance criteria template was issued to the project manager at kickoff in November 2021, with infrastructure and security asked for at the start. That is the process working as designed.
By March 2022 the server team had already built every server, and architecture had not been on a project call since roughly November — the subsequent meetings having been cancelled. Architecture was consulted only because somebody followed a process, and the environment was already standing when it was.
The findings raised in writing while the project was still running: a shared administrative account used across all environments, with the password not held in a vault, so no action could be attributed to a person. A separation of duty concern was raised alongside them and accepted — the team building the environment was also the team assuring it.
The interesting thing about those findings is not that they were correct. It is that they were written down, routed through a review board with an acceptance-criteria artifact, and put to the project in writing by a function that had been cut out of its meetings. That is the difference between having a process and having one that holds when it is inconvenient.
Identical function, identical authority, one year apart. The variable was not the architecture. It was whether the project called it before or after the build.
Stopping a requirement that had no owner
During the 2022 upgrade of the traffic management platform, a hardware security module and a federal cryptographic validation requirement appeared in the conversation. The architecture question was simply whose requirement it was.
The existing licensing showed no sign of such a requirement, and the installed hardware plausibly could not have supported it. The manufacturer confirmed the initialization was not required for the upgrade.
Requirements arrive in upgrade conversations without provenance all the time, usually carried along by whoever repeated them last. Asking who owns one costs a single email, against the price of the hardware it would otherwise have justified.
Holding the procurement line from both sides of it, fifteen years apart
In June 2007 an objection went in writing when a carrier approached a colleague in a way that cut across the procurement process. The benchmark it was measured against was the vehicle location request for proposal then in flight.
In October 2022 the person scoring a public safety solicitation, personally, on a funded capital program, was the same one who had raised that objection.
The standard held against somebody else became the standard being applied. That is the only way a procurement rule survives in an organization: the people who invoke it have to be willing to be bound by it later, in front of vendors who remember.
Outcome
A documented demonstration that review timing, not review authority, is what decides whether governance produces a design or a complaint.