When I join a new program, I start with the current design. Then I find out who made the original decisions, and whether they're still around.
That sounds like a people question. I treat it as an architecture question.
In the long-running programs I've worked on, inherited architecture has been the source of the most expensive problems I've found. The original decisions usually made sense at the time, given the constraints. The trouble is that constraints change, and the decisions don't get re-tested against them.
What inherited architecture actually is
Every architecture is a snapshot of the moment it was designed. It reflects the threat model, the budget, the technology available, the requirements as they were understood, and the preferences of the people in the room.
Run a program long enough and those conditions become history. Requirements grow. The threat landscape shifts. Technology arrives that didn't exist when the design was approved. People leave, and the reasoning behind their decisions leaves with them.
What remains is a set of constraints that present as facts: how the system works, what it depends on, and what would have to change to do it differently.
Some of those constraints are real. Others are assumptions that haven't been tested in years. The work is telling them apart.
Why programs don't revisit inherited decisions
The reasons compound.
The original decision-makers have moved on. Documentation, where it exists, records what was built, not why. Engineers have learned to work within the system's limits rather than question them. Program leaders inherit the architecture and the mindset that came with it.
The risk calculus works against revisiting, too. Changing something that has been stable for three years feels riskier than leaving it alone, even when it's costing money. The risks of change are visible and immediate. The costs of standing still are slow and diffuse. And unless someone is given an explicit mandate, and the political cover, to question an old decision, the decision stands.
The $1M question
The most expensive inherited decision I've dealt with was a platform choice made before I joined the program. The original design locked in a vendor and a deployment model that fit the contract at the time. By the time I reviewed it, the requirements had grown and the vendor's licensing had changed. The deployment also depended on hardware that was aging and oversized for the actual need.
It hadn't been questioned because it worked. A working system doesn't generate the pressure that triggers a review.
My review wasn't a technology evaluation. It was a comparison of the original decision against today's requirements. Once I mapped what the program actually needed against what the platform delivered, and what it cost to sustain, the gap was obvious. The redesign cut over $1M from procurement while meeting every technical, security, and mission requirement.
The decisive move wasn't technical. It was deciding to look.
How to audit an inherited architecture
I open every architecture review with three questions.
What problem was this built to solve? Not the broad mission, but the specific technical problem the original architect faced. If no one can answer, the institutional memory is gone. Treat every constraint as an assumption until proven otherwise.
What has changed since the design was finalized? Look at requirements, threat model, budget, staffing, technology options, vendor relationships, and the certification baseline. Anything that shaped the original decision gets re-tested against current conditions.
What would we build if we started today? This isn't a commitment to redesign. It's a diagnostic. The distance between that answer and what exists is the size of your inherited architecture problem.
When to overturn versus work within
Once you see the gap, the temptation is to redesign. Resist it until the case is made.
Some constraints are real. Security boundaries and certification commitments can't move mid-program. Some dependencies would cost more to unwind than to keep. And delivery teams already carry full backlogs, so a redesign competes for the same capacity.
Overturn an inherited decision only when two conditions hold:
The current design is clearly worse than the alternative on cost, security, or mission performance.
The cost and risk of changing it are lower than the cost and risk of keeping it.
Working within inherited architecture is often the right call. It should still be a call. In the programs I've reviewed, budget cycles fund what already exists by default, and that default gets mistaken for a decision.
The bottom line
Every architecture decision carries an expiration date that isn't written on it. Threats, budgets, priorities, and technology all move, and the assessment of a design has to move with them.
The seven-figure savings I've found didn't come from better original design. They came from asking whether the original design still fit.
If your program is running on decisions that haven't been re-tested since they were made, that's where an independent architecture review starts.