Modern IT infrastructure, in five pillars

Modern IT isn’t a product you buy. It’s how hardware, software and the cloud interact to carry a business mission, and the interaction is exactly where the mess lives. Users, suppliers, devices, services and data all touch each other in ways no single product diagram ever shows.

So I stopped modelling products and started modelling relationships. One rule sits underneath everything: treat every component as a CI (configuration item), and the moment it exists it must link to at least one other CI. A login isn’t a login. It’s an identity, on a directory, on an operating system, on a virtual machine, on a hypervisor, on hardware. Nothing floats. That gives you a map instead of an inventory, and every CI on that map lands in one of five pillars.

Five pillars, four foundations

The frame is a literal one. A miya-daiku — the carpenter who raises a Japanese temple — joins the whole structure from interlocking timber and almost no nails, so the strength lives in the joinery rather than the fasteners, and a good joint binds tighter the harder the building is pushed. Upright posts, penetrating tie-beams, and the joints where they cross: that’s the honest shape of an IT estate, so it’s the shape I build the model on.

Picture a timber frame. The business mission is the ridge beam it all holds up. Five posts carry it — the pillars. Four beams run straight through every post — the foundations. The strength isn’t in nails; it’s in the joints.

The pillars are what you build with:

• Identities — who or what is acting: users, service accounts, devices, AI agents. Your access-control plane.
• Compute — where workloads actually run: servers, VMs, containers, endpoints.
• Networking — how any of it reaches anything else: switching, routing, firewalls, segmentation.
• Software — what delivers the function: apps, APIs, SaaS, platform services.
• Data — the reason the rest exists: databases, files, backups, logs as assets.

The foundations are how you keep each pillar honest, and they run through all five:

• Operations runs it — provisioning, patching, incidents, SLAs.
• Security protects it — hardening, least privilege, detection, evidence.
• Governance proves it — ownership, change control, audit trails.
• Finance sizes it — cost, budget, right-sizing, run-rate. You can’t frame bigger than your lumber.

Miss a foundation and the pillar leans. A perfectly operated server with no governance is an orphan nobody will own at 2 a.m.; a well-governed one nobody patched is a breach with paperwork; a flawless one nobody costed is next year’s budget surprise.

Nothing stands alone

The pillars are how I sort things; the links between them are where the real engineering is. Take one boring corporate login. The identity lives in an IdP, which is software, running on a server, which is compute, reachable only through a network path, granting access to data — and every step wants operations, security, governance and finance wrapped around it. One trivial action, five pillars, four foundations.

That’s the whole point of drawing the links: it’s the only way to see blast radius before it sees you. Change your identity tiering model and you’ve just changed which compute tiers exist, which network segments you need, and what your apps are allowed to assume. If the CIs aren’t linked, you find that out in the incident review instead of the design review.

It’s also where the vendor question lives. Keep a pillar on an open standard and the vendor underneath is swappable; fuse your design into one product’s private features and the pillar becomes a hostage. That’s the whole argument in build like you’ll have to leave.

The loop that keeps it honest

A pillar isn’t a purchase, it’s a lifecycle. Every framework I build runs the same closed loop: design it for security and scale up front, evaluate and adopt it with the operational and lock-in cost weighed honestly, operate it through the long boring middle where the value actually is, and audit it to prove reality still matches intent, then feed what you learned back into the next design. Not a waterfall. A loop, and each turn is tighter than the last.

Sort every component into a pillar, thread the four foundations through all of them, and link every CI to the next. The architecture is in the joints, not the boxes.

The full model — the 5 × 4 matrix, a maturity score, and the euro each gap is worth — lives on the pillar model reference page. This post is the scaffolding I hang the rest on: when I write about giving an AI agent the keys safely, or why my homelab lives behind VLANs, that’s one pillar in close-up, resting on the same four foundations and wired to the other four. Start thinking in pillars and the whole thing stops being a pile of products and becomes a system you can actually reason about.