Seven of every ten IT dollars went on keeping systems alive
Why does modernising anything cost so much and take so long?
Figures and rules on this page apply to
United States
Working somewhere else? The shape of the problem usually travels. The deadlines do not.
What this looks like
The programme is approved and funded, and then it waits. It waits for an interface to a system whose owner has retired. It waits for a data format nobody wrote down, and for an approval that cannot start until both are settled. None of that is the new system. All of it is the cost of the old one.
The numbers
Every figure here is someone else’s. Check them.
- $6.4Bthe value of that operating and maintenance share
- $2.7Bthe remaining 30 percent, spent on development and modernisation
- 13 of 21programmes reported cost increases, with a median rise of $163.3 million
- 24 momedian schedule delay among the seven programmes that reported one
Why it happens
It is not a people problem.
An old system is expensive not because it runs badly but because everything new has to negotiate with it. Each negotiation is bespoke, undocumented and owned by whoever remembers. That cost is charged to the new programme, which makes modernising look expensive when what is expensive is the thing being replaced.
Why your current software has not fixed it
Because it was never built to.
The platform vendors are correct about their own systems and have no duty to the seam between them. Integration suites assume both ends are willing and documented, and one end here is a system from an earlier decade with no owner. The work that remains is reading, mapping and proving, and it is specific to your estate.
Intelligence, plumbed in
An undocumented format is still readable. Somebody just has to read it, and that part can be machine work.
The build is a stable layer over the legacy estate and formats mapped and maintained. Evidence is generated as it runs, and we make hardware where none can be bought. Underneath it: a connector, one agreed meaning per field, and a test set scored on your own records.
How we make AI survive real data-
Connectors -
A semantic layer -
Evals you can check
However hard, whatever it is
Legacy integration is one example. Bring the requirement you were told cannot be met.
We wrote this up because the oversight reports are public. If yours is logistics, readiness or a supply record, we break it down the same way.
-
01 We sit with you
Days where the work happens, not a workshop in a meeting room. We watch the job get done and write down the shortcuts nobody wrote down.
-
02 We read everything
Your data, your rules, your vendors and their documentation, and the published research on your sector. We report what is actually in there.
-
03 We break it to first principles
Not which tool fixes this. What is actually causing it, taken apart until we reach the piece that cannot be divided further.
-
04 Then we build
Weeks, not quarters. By this point we are not guessing what to build, and guessing is the thing that makes projects long.
What we build
Specific enough to argue with.
Four mechanisms, not four features. Each one is a thing that happens on its own, every day, whether or not anyone remembers to run it.
-
A read-only layer over the older system, so new work talks to a stable interface instead of to a fragile one.
-
Undocumented formats mapped and the mapping held as a maintained artefact rather than in a script nobody owns.
-
Evidence for accreditation generated as the system runs, rather than assembled by people ahead of a review.
-
Hardware we design and build where nothing suitable can be procured, which on constrained estates is often the fastest route.
How you would know it worked
Numbers in your own reporting, not ours.
- Share of programme cost spent on integration rather than on the capability itself.
- Time from a requirement being agreed to a working interface existing.
- Days of staff effort spent assembling evidence for an accreditation review.
Straight answers
Where a model is involved, it is scored against your own records first. Accuracy per source, not one flattering average.
The questions this raises
-
Our environment is classified and air-gapped.
That is an ordinary constraint for this kind of work. We design for disconnected operation and for review of every artefact before it crosses any boundary.
-
Can anything be delivered without touching the legacy system?
Usually yes, and it is normally the right first step. Reading a nightly export proves the idea while the deeper interface is still being negotiated.
-
Accreditation is what actually delays us.
Then it belongs in the design rather than at the end. Evidence produced by the system as it runs is the difference between a review and a project.
-
Are these figures about our programme?
No. They are published oversight figures for a set of defence IT programmes and we say so. Your own split is the first thing we would measure.
Where the figures come from
We did not make these up, and you should not take our word for them.
An old system with no documented way in
The old system is what costs money, and the new one gets the bill.
It runs, it is correct, and the person who knew how it worked has retired. Everything new has to negotiate with it, and each negotiation is bespoke. The cost is charged to whatever is being built, rather than to the thing causing it.
Two estates here, and the pattern is not limited to the public sector. Any system old enough to be load-bearing qualifies.Name the system nobody will touch.
The old system is what costs money, and the bill arrives inside the new programme.
The build is a stable layer over the legacy estate and formats mapped and maintained. Evidence is generated as it runs, and we make hardware where none can be bought.
See everything we build-
Software -
Hardware -
Ways of working -
Whole ventures
Is this happening to you? Tell us the size of it.
Twenty minutes. We will tell you honestly whether the numbers justify doing anything about it.