Don't Panic — Technology Architecture

Technology architecture is the platform layer of a solution — the bit that decides which compute, network, identity, data, integration, and operations capabilities a workload actually needs, and how they fit together. It is not a vendor inventory, however much the vendor catalogs would like it to be. It is a selection discipline, and the selection starts with the workload, not the product list.

Before this was framed as architecture, the default was whatever the team had used last time, or whatever the loudest stakeholder preferred. The cure is to write down the workload's users, data classification, latency and availability targets, residency, contracts, operating model, and budget, and only then go looking for capabilities that fit. Without that list, every choice is a preference wearing a defensible-looking label.

The idea everything else hangs off: the platform is connected domains, not a list of independent services. A choice in one constrains another — an isolated network design changes connectivity, identity, deployment, support, and cost work; a data service's consistency model shapes what compute and integration can do. Reading the domains one at a time is how platforms end up with services that do not fit together.

The surprise, for people who met this as a checklist job: a quoted service limit is not evidence about your workload. The selection loop is requirements, alternatives, trade-offs, evidence, approved pattern — and the evidence step is the one teams skip. Prototype the uncertain behavior, test the failure and recovery paths, measure representative load. Benchmarks are inputs; running your patterns against the capability is evidence.

The warning worth carrying: a standard with no exception path is a control that gets bypassed under deadline pressure and leaves no record. Keep the exception path explicit — affected standard, reason, compensating control, owner, expiry — and revisit decisions when the driver changes, the platform shifts, or the bypasses accumulate. A three-year-old platform decision never revisited is just stale architecture pretending to be policy.

Read the Intro for the connected-domains model and the selection loop. The Cheatsheet keeps the per-capability selection criteria and the Well-Architected lenses at hand. The Reference Links take you to the Azure technology-choices guidance and the AWS Well-Architected Framework that settle the details.