concept

Technology Architecture

The platforms, infrastructure and runtimes the estate depends on — where the recurring architectural problem is obsolescence rather than choice.

technologyinfrastructurestandardslifecycleobsolescence

Definition

Technology architecture covers the compute, storage, network, runtimes, databases, middleware and tooling on which applications run, plus the standards governing their use.

The recurring problem: obsolescence

The interesting work here is rarely choosing a new technology. It is managing the estate's ageing:

  • Versions falling out of support, creating security exposure that cannot be remediated.
  • Vendor end-of-life announcements with migration deadlines.
  • Skills evaporating. A technology whose expertise is retiring from the workforce becomes an operational risk regardless of its technical merit.
  • Hardware and licence renewal points, which are the natural decision moments and are frequently missed.

An estate with no obsolescence view accumulates risk silently until an unsupported component blocks a compliance certification or a vulnerability cannot be patched.

What to maintain

A technology lifecycle register: for each significant technology, its current version, its supported-until date, its adoption stage, and who owns the upgrade path. Reviewed on a cadence.

Adoption stages worth using: adopt (default for new work), trial (evaluating), contain (no new use), retire (with a date). The same classification as applications, for the same reason.

The standards question

Technology standards reduce the estate's variety, which reduces operational cost, patching burden and the number of things the organisation must be good at. That is genuinely valuable — every technology consumes a share of a finite capacity for operational novelty.

The failure is standards without exceptions. A standard with no waiver path is broken quietly rather than formally, and the exceptions become invisible — which is worse than granting them.

The workable position: a small standard set, a paved road that makes the standard the easiest choice, and a fast, credible exception process that records the reason.

Failure scenarios

  • No obsolescence view, so unsupported components are discovered during an audit.
  • Standards enforced without a waiver path, producing invisible exceptions.
  • Standards that never change, so the estate is frozen on decisions made a decade ago.
  • Variety accumulating without limit, so the platform team cannot support anything well.
  • Upgrade paths unowned, so a version stays until it becomes a crisis.

Interview question

"How would you decide which technologies in an estate need attention first?"