Enterprise standards & governance

The portfolio runs on AWS as the primary plane, GCP for specific workloads where the platform fit was stronger, and on-prem for systems with data-residency or latency constraints that have not yet been re-evaluated. The standard names the primary plane, names the legitimate exceptions, and forces every new workload to declare which it is and why. The forcing function matters more than the answer; sprawl is what happens when the question is never asked.

Account topology is decided once. Workloads land in accounts segmented by environment, by domain, and by sensitivity tier. Cross-account access is mediated by AWS Organizations / Resource Manager — no long-lived credentials cross account boundaries. The control plane (billing, IAM root, audit) is isolated from the workloads that consume it. This is invisible when it works; the cost of getting it wrong is the kind of incident that ends careers.

APIs are the contracts between teams. The standard mandates contract-first design — OpenAPI for REST, schemas for GraphQL, defined event shapes for asynchronous flows — reviewed in code review independent of the implementation. Backwards compatibility is enforced at the contract layer; consumers do not learn about breaking changes from a production incident.

Integration patterns favor async over sync at boundaries that cross teams. Tight RPC coupling between domains is a coupling that scales until it doesn’t; events flowing through a shared bus give the consumer team room to evolve without coordinating every release with the producer. The exception is intra-domain calls within a team, where the synchronous coupling is acceptable because the change cadence is unified.

External integrations always go through an anti-corruption layer. The portfolio does not let a third-party API’s shape leak into domain code; an adapter translates and the domain stays clean. When the third party deprecates an endpoint or changes a field semantics, one component changes — not twelve.

Data classification comes before data architecture. Every dataset has a tier — public, internal, confidential, regulated — and the tier dictates where it can live, who can access it, how long it is retained, and what level of audit applies. Architecture decisions follow the classification, not the other way around.

Identity is one system, not many. Workforce identity through the corporate IdP; customer identity through the customer-facing IdP; service identity through workload identity. No application maintains its own user store; no cross-system identity resolution happens at the application layer. Tokens are short-lived; long-lived credentials are an audit finding by default.

Regulated data — PII, payment, health where applicable — is handled with explicit scope. The architecture pattern is to minimize blast radius (isolate the systems that hold it, encrypt at rest and in transit, log every access) and to make the access surface visible and auditable. The hardest standard to maintain is "don’t let regulated data into systems that aren’t designed to handle it"; eternal vigilance is the unfortunate price.

Architectural review is not a tollbooth. The standard tiers reviews by risk — a small change to an existing pattern needs lightweight peer review; a new system that introduces a new tier of data sensitivity, a new vendor relationship, or a new identity surface needs a structured review with documented decisions, alternatives considered, and trade-offs surfaced.

The review artifacts are short and structured: context, options, recommendation, decision, consequences. The artifact is reviewable in code review; the conversation happens around the document, not in a meeting that nobody documented. Decisions are versioned; revisions reference the prior decision and explain what changed. This is what turns "we decided X two years ago" into "here is the document and the rationale."

The review process is itself reviewed. Quarterly retrospectives surface where reviews added value, where they were ceremony, and where they missed a finding that surfaced later. The process evolves; ceremony gets pruned.

Standards that allow no exceptions become irrelevant; standards with informal exceptions become a fiction. The exception process is the standard that holds all the others up. Every exception is named, justified, time-boxed, and reviewed. The justification is documented in the same artifact format as the original decision, so the next architect can find it.

Time-boxing matters most. An "exception" without an expiration is just a quietly broken standard. The standard process attaches a review date — sometimes "we will reconsider this when X changes," sometimes a literal calendar date — and the exception either expires or is renewed with fresh justification. The list of active exceptions is visible to the architecture practice, not buried in tickets.

The exception process is also the feedback loop on the standards themselves. A standard that generates frequent exceptions is a standard that does not fit reality; the response is to revise the standard, not to keep granting exceptions. This is how the practice stays honest.