Two Clocks in Every Programme

Acquisition · June 24, 2026 · 6 min read

Every major acquisition runs two clocks at once, and they are not merely different speeds — they are governed by different things entirely.

The first clock belongs to the platform. Its pace is set by structural design, qualification testing, safety certification, production ramp and the working life of an expensive object that will be maintained for decades. This clock is slow because the consequences of getting it wrong are physical and irreversible, and no amount of urgency compresses a fatigue test.

The second clock belongs to the components inside it: processors, sensors, communications equipment, displays, the software that ties them together. Its pace is set by a commercial market that neither knows nor cares that a particular part ended up inside a thirty-year article. Parts on this clock are discontinued for reasons that have nothing to do with their fitness — a fab retooling, a product line rationalisation, a change of ownership.

Almost every recurring complaint about defence acquisition is a symptom of these two clocks being pretended into one.

Why the requirement is the wrong place to fight this

The instinct is to fix the problem at the requirement, and there are only two ways to write a requirement, both of which fail here.

Write it specifically — name the performance, the interfaces, the parts — and you have frozen a snapshot of what was available when the document was drafted. By the time the article is fielded, the snapshot describes a generation that has passed. The specification is met and the capability is dated, which is the outcome everyone finds most infuriating because nobody broke any rules.

Write it loosely — “state of the art at delivery”, “open and upgradeable” — and you have written something nobody can verify, price or contest. A requirement that cannot be failed cannot be enforced, so what actually gets built is whatever the supplier’s engineering organisation was going to build anyway, and the loose wording becomes a defence against criticism rather than a constraint on design.

The requirement is the wrong instrument because it is a statement about the product, and the problem is a mismatch of rates. Rates are not fixed by sharpening a noun.

What actually decouples the clocks

The only mechanism that reliably separates a slow platform from fast components is an interface that is specified independently of what sits behind it. Fix the physical envelope, the power and cooling budget, the data contract and the timing, and the box inside the envelope becomes replaceable without touching the platform’s qualification basis. This is the whole of the modular-architecture argument, and it is correct.

It is also routinely misapplied, in two ways.

First, an interface is only real when more than one implementation has ever sat behind it. If a single supplier’s unit has occupied the slot since first flight, the document does not describe an interface — it describes that unit. Every undocumented assumption the unit relies on is invisible precisely because nothing has ever tested it. The cost of finding out is paid later, by whoever attempts the second implementation, and it is usually paid in schedule.

Second, an interface has an owner, and ownership is not a clause. Maintaining an interface means running a change process, arbitrating between suppliers who want it moved in different directions, funding the verification that keeps it honest, and retaining people who understand why each constraint is there. That is a standing engineering capability inside the buying organisation. Where the buyer has no such capability, interface control migrates to the integrator by default, and an integrator that owns the interface has no commercial reason to make the box behind it easy to replace. Openness then survives as a word in the contract and nowhere in the hardware.

Obsolescence is a budgeting problem wearing an engineering costume

Consider the arithmetic. If the interval from requirement to fielding exceeds the interval at which a component generation turns over, then the article enters service already carrying at least one generation of obsolescence, by construction. Nothing has gone wrong. That is simply what the two intervals imply, and it will be true of the next programme as well.

The consequence is that a refresh is not a contingency. It is a scheduled event whose date is knowable at the start, and the only real question is which budget pays for it. Here the two clocks reappear as two funding lines: acquisition money buys the article, sustainment money keeps it working. A refresh driven by part obsolescence lands on sustainment, where it competes with spares, depot work and training, and where it has no advocate because it is not a new capability and nobody’s programme depends on it.

That is why obsolescence tends to be handled by the most expensive available method: a lifetime buy. Purchase enough of the discontinued part to last, put it in a store, and defer the redesign. It is a rational local decision. It also converts an engineering problem into an inventory problem, adds storage and counterfeit-screening risk, and — most importantly — guarantees that the redesign happens anyway, later, when the store runs out, when the original design team has dispersed, and when the cost is higher than it would have been.

A lifetime buy is a loan taken out against the sustainment budget at a poor rate of interest.

What a programme can honestly do

It cannot make the platform clock fast. Structural qualification, safety certification and production learning take the time they take, and the pressure to compress them lands on the parts that were protecting somebody.

It can do three other things. It can shorten the parts of the programme that are not assurance — the approvals, the re-competitions, the waiting for a decision — which frequently occupy more calendar time than the engineering does. It can build the article around interfaces the buyer owns and has proven with a second implementation, accepting that this costs more on the first unit and pays back on the third refresh. And it can schedule and fund the first technology refresh in the original business case, at the point when everyone still agrees it will be necessary, rather than discovering it as a surprise a decade later.

None of that closes the gap between the two clocks. Nothing closes it. The distinction worth drawing is between programmes that are built in full knowledge of the gap and programmes that were priced as though only one clock existed.