Technology Architecture and Infrastructure

Technology Architecture is the EA domain that defines the infrastructure and platforms on which applications run — compute, storage, networking, and the cloud and edge platforms that deliver them. It is the most rapidly evolving domain, with cloud-native, edge, and sustainable infrastructure reshaping the foundation every few years.

In 2026, the defining characteristics of technology architecture are cloud-native by default, hybrid and multi-cloud by necessity, platform-engineered for developer experience, and increasingly carbon- and cost-aware by board mandate. The architect's job is no longer to pick a data centre; it is to model a multi-constraint placement problem and provide golden paths that let teams move fast without breaking the foundation.

This page covers the cloud-native substrate, container orchestration, hybrid and edge patterns, platform engineering, and the rising disciplines of FinOps and GreenOps in technology architecture.

Cloud-native is no longer a style choice; it is the default substrate for new enterprise platforms. The CNCF defines cloud-native around containers, service meshes, microservices, immutable infrastructure, and declarative APIs. The payoff is elasticity, resilience, and portability; the cost is operational complexity that must be absorbed by platform engineering.

Kubernetes has become the de facto container orchestration standard, providing declarative management of containerised workloads with scaling, self-healing, and rolling updates. Around it sits an ecosystem — service mesh (Istio, Linkerd), GitOps (ArgoCD, Flux), observability (Prometheus, Grafana), and package management (Helm) — that together form the cloud-native platform.

The architect's decision is less whether to adopt cloud-native and more how much to build versus consume as managed services. The trend is strongly toward managed Kubernetes and platform-as-a-service to reduce operational burden, with bespoke platform engineering reserved for genuine differentiators.

The notion of a single cloud is fading. Enterprises run hybrid by necessity (legacy systems that cannot move), multi-cloud by strategy (best-of-breed services, vendor leverage, sovereignty), and edge by demand (latency, data residency, autonomy). Technology architecture must model placement as a multi-constraint problem: latency, cost, sovereignty, carbon, and resilience.

Multi-cloud is powerful but hard. Without an abstraction layer (containers, IaC, platform engineering), multi-cloud becomes N-clouds-worth of operational complexity. The pragmatic pattern is a primary cloud for most workloads, with selective use of others for specific capabilities or sovereignty — not symmetrical deployment everywhere.

Edge has matured into a genuine tier: 5G and edge runtimes let latency-sensitive and data-sovereign workloads run at the edge, with the cloud as control and training plane. The pattern is hybrid by default: manage centrally, execute at the appropriate tier. Architects must model which workloads belong where based on the constraint set, not on ideology.

Platform engineering is the response to cloud-native complexity. Rather than leaving every team to assemble its own Kubernetes, observability, and delivery stack, the platform team builds an internal developer platform (IDP) that provides golden paths — opinionated, supported routes to production that encode best practices by default.

The shift from DevOps (every team owns everything) to platform engineering (a platform team provides a product to developers) reflects the realisation that cognitive load is the enemy of velocity. A good IDP lets a developer go from code to production in minutes, with security, observability, and compliance built in, not bolted on.

The architecture of the IDP itself is a technology-architecture concern: what capabilities it exposes (environments, databases, messaging, observability), how it is delivered (self-service APIs, Backstage-style portals), and how it evolves. A well-designed IDP is the single biggest multiplier of developer productivity in the cloud-native era.

Beneath the cloud-native abstractions sit concrete compute, storage, and network decisions. Compute choices span VMs, containers, and serverless (functions, FaaS) — each with a cost, latency, and operational profile. Storage spans block, object, file, and specialised stores (relational, document, vector). Networking spans VPC design, connectivity (VPN, Direct Connect, peering), and service-to-service patterns.

Serverless and FaaS (functions-as-a-service) suit event-driven, bursty, short-lived workloads and remove operational burden, but introduce cold-start latency, execution limits, and vendor coupling. The architect matches the compute model to the workload profile rather than imposing one model everywhere.

Network architecture has become more important, not less, in the cloud era — microsegmentation, zero-trust connectivity, service mesh, and hybrid connectivity all live here. The default pattern is a hub-and-spoke or mesh network topology with private connectivity to on-premises and edge, and zero-trust controls between services.

Cost and carbon have moved from operational concerns to architectural ones. FinOps — managing cloud cost as a shared engineering responsibility — is embedded in technology architecture through right-sizing, autoscaling, reserved capacity, and budget-aware routing. An unguarded workload can waste more in a month than a well-architected one saves in a year.

GreenOps extends the same discipline to carbon. Infrastructure placement, workload scheduling, and model-size decisions now carry measurable carbon consequences. Carbon-aware platforms schedule workloads in lower-carbon regions or off-peak hours where flexibility allows. These are architectural decisions made at design time.

The convergence is carbon-and-cost-aware architecture: the architect who can quantify, at design time, the cost and carbon impact of a compute, storage, or placement choice — and trade it off against latency and resilience — is delivering what 2026 boards demand. Technology architecture reference models now include cost and carbon budgets as first-class NFRs.

Resilience is a technology-architecture responsibility. Multi-AZ deployment, regional failover, chaos engineering, and well-defined RTO/RPO targets are designed in, not added later. The pattern is defence in depth: no single component is assumed reliable; the architecture absorbs failure through redundancy, isolation, and graceful degradation.

Disaster recovery is being reframed as continuous resilience — multi-region active-active where economics allow, pilot-light or warm standby where they do not. The architect matches the DR pattern to the business's tolerance for downtime and data loss, making the trade-off explicit.

Sustainability is the newest resilience dimension. Energy-efficient architectures, carbon-aware scheduling, and lifecycle-aware hardware choices are becoming part of the architect's brief as boards and regulators track scope-2 emissions. The sustainable technology architecture is not a sacrifice of performance for planet; it is a reframing that treats carbon as a resource to be governed like cost.