Every list of platform principles contains the same items, and most organisations fail at roughly the same three. That's not a criticism of the lists. It's evidence that the hard part was never knowing what to do.

Matthew Liste, Global Head of Infrastructure at American Express, sets out twelve core principles for building scalable, reliable infrastructure platforms in a QCon San Francisco talk published on InfoQ — avoiding technical debt, managing deprecation, building engineering culture, reducing complexity for the developers who consume the platform. This piece responds to the themes the talk names rather than reviewing the full presentation. They are the themes that get cut first when a programme goes amber.

Technical debt is a budgeting problem wearing an engineering costume

Nobody accrues technical debt by accident. It gets accrued by a delivery date, a steering committee, and a conversation that goes "we'll come back and fix it in the next phase."

What actually changes outcomes isn't a maturity model. It's making the debt visible in the same register as everything else — same risk log, same owner, same review cadence as a security finding or a supplier issue. Once an unpatched legacy file server with a 2012 OS sits on the same page as a late third-party integration, the conversation stops being technical and starts being commercial. That's the conversation you need. An architect arguing for refactoring loses. A risk owner explaining that an unsupported platform carries no vendor patch path wins, because somebody has to sign their name next to it.

What tends not to work: debt sprints, debt budgets expressed as a percentage of capacity, and the perennial "20% of engineering time" rule. Each of those gets eaten the first time a major release slips. The percentage is a promise. The risk register is a record.

Deprecation is the discipline nobody funds

Of the twelve principles, this is the one I'd argue is most consistently absent from real enterprise practice. We are extremely good at standing things up. We are terrible at taking them down.

Count the systems in your estate that are still running solely because nobody can produce a list of who depends on them. In most mid-sized organisations that's a meaningful fraction of the server footprint — a reporting box, two file shares, a Server 2012 R2 application that one finance team swears they need at quarter-end. Each one is a patching obligation, a backup line item, an identity surface, and an audit finding waiting to happen.

The pattern that works is unglamorous: every new platform gets a named end-of-life owner and a decommission trigger written down at go-live, not at end of life. Not a date — dates slip and everyone knows it — but a trigger condition. "When the successor hits 90% of transaction volume, this one enters a 60-day shutdown window." It converts deprecation from a judgement call into an operational event. It also means the person who argued hardest for the new system owns the cost of removing the old one, which does wonders for honesty during business cases.

Microsoft's own cadence forces the issue whether you plan for it or not. Exchange 2016 and 2019 both went out of support in October 2025. Windows 10 the same month. If you weren't running a deprecation discipline, you now have an unplanned programme. If you were, you had a scheduled one. Same work, very different budget conversation.

Complexity reduction is a product decision, not an architecture one

The framing of the talk — platforms that streamline developer workflows — is the right one, and it's the shift that has taken hold properly in recent years. Infrastructure stops being a set of assets and becomes a product with internal customers who can, increasingly, go elsewhere.

That "go elsewhere" bit is the forcing function. If provisioning a test environment through the official channel takes four weeks and a change advisory board slot, somebody's expensing an Azure subscription on a departmental card. The shadow IT isn't a governance failure in the first instance; it's a symptom of a platform that lost to the alternative on user experience. The governance failure is only what happens next.

So the measurement that matters isn't uptime. Uptime is table stakes and everybody reports it green. The measurements I'd actually put on a platform scorecard:

  • Time from request to working environment, measured end to end including approvals — not from when the ticket reaches your team
  • Percentage of deployments that need a human from the platform team to intervene
  • Number of distinct ways to do the same thing (authentication, logging, secrets) still live in the estate
  • Age of the oldest component still in production, and who owns its retirement

Culture is the one you can't procure

Liste puts engineering culture alongside the technical principles, and that ordering is right. The uncomfortable part is that culture is the only item on the list with no purchase order attached. You cannot buy it, and the consultancies that claim to install it are selling you a workshop.

What builds it is narrower than the word suggests: engineers who are allowed to say no to a date and are backed when they do; post-incident reviews that produce a changed control rather than a named individual; and senior people who run the same deployment pipeline as everyone else. The third one does more than the first two combined. Nothing improves a platform faster than the person who approved it having to use it.

What to take from it

The principles in this talk aren't new, and I doubt the author would claim they are. Their value is as a checklist you can hold your own estate against on a Tuesday afternoon. Pick deprecation. Ask your team for the list of systems with a named retirement owner. If the list is short, you've found your next quarter's work — and you've found it before an auditor or an attacker does.

Source: Building Resilient Platforms: Insights from 20+ Years in Mission-Critical Infrastructure