Architecture is full of constraints.

We think about CPU, memory, network bandwidth, database connections, latency budgets, availability targets, regulatory boundaries, and cost. Good architects learn to respect those limits because ignoring them eventually produces a system that fails.

But there is another constraint that rarely appears on an architecture diagram.

How much of the system can the people responsible for it actually understand?

Modern software has become remarkably good at moving technical complexity around. We hide infrastructure behind cloud services. We hide deployment behind pipelines. We hide distributed systems behind frameworks. We add security scanners, observability platforms, service meshes, feature flags, policy engines, developer portals, and now AI tools.

Each addition may be individually reasonable. The problem appears when the team operating the system has to understand the interactions among all of them.

At that point, cognitive load stops being a developer experience complaint.

It becomes an architecture constraint.

The System in Production Is Larger Than the Application

Consider what a developer may need to understand to make what sounds like a small production change.

There is the application code, of course. But there may also be a CI pipeline, infrastructure as code repository, Kubernetes configuration, secrets management, IAM roles, API gateway policies, observability dashboards, feature flags, vulnerability findings, deployment rules, data contracts, runtime configuration, incident procedures, and several internal standards.

None of these is unnecessary by definition. Many exist precisely because the organization learned an important lesson about security, reliability, or scale.

But complexity is cumulative.

A system can be technically elegant at every individual layer and still be operationally incomprehensible as a whole.

This is why I think architecture reviews should ask not only whether a design can run, but whether a team can realistically own it.

We Have Been Shifting Left for Years

One of the dominant ideas in modern engineering has been to shift responsibilities left.

Security should happen earlier. Testing should happen earlier. Infrastructure should be defined by developers. Observability should be built into the application. Teams should own what they run.

These are good ideas. I would not reverse them.

But there is a hidden assumption inside shift left thinking: that the receiving team has enough cognitive capacity to absorb what is being shifted.

Eventually a stream aligned application team can become responsible for application logic, cloud infrastructure, security controls, compliance evidence, telemetry, deployment automation, cost management, production support, and a growing collection of enterprise tools.

We call that ownership.

Sometimes it is. Sometimes it is simply overload with a better name.

Google Cloud describes platform engineering as a way to combine shift left with shift down: important concerns remain integrated into the software lifecycle, while unnecessary underlying complexity is absorbed by a platform rather than repeatedly pushed onto every application team.

That distinction matters.

Abstraction Is a Cognitive Load Decision

Architects usually discuss abstraction in technical terms. An abstraction hides implementation details behind an interface.

But a useful abstraction does something else: it decides what a team should have to think about.

A developer deploying a routine web service should probably care about its availability requirement, resource profile, data sensitivity, and scaling behavior. They may not need to understand every subnet rule, certificate renewal mechanism, logging agent, admission policy, or container runtime setting underneath it.

If the organization has already made those decisions safely and repeatedly, exposing all of them to every developer is not necessarily empowerment.

It may be a failure to create the right abstraction.

This is one reason golden paths can be powerful. A good golden path is not merely a template that generates YAML. It is an architectural opinion about which decisions should be standardized, which should remain visible, and where teams genuinely need choice.

The best abstraction removes accidental complexity without hiding essential behavior.

A Concrete Architecture Example

Imagine two organizations offering developers the same basic capability: deploy a production web service safely.

Architecture A: the implementation is the interface

A developer may need to understand and coordinate:

  • application configuration
  • Kubernetes manifests and Helm values
  • Terraform modules and cloud networking
  • IAM roles and secrets integration
  • service mesh and ingress configuration
  • CI and deployment workflow details
  • logging, metrics, tracing, and alert configuration
  • security and policy requirements enforced by several tools

The architecture may be automated, standardized, and technically sophisticated. But the application team still carries much of the implementation model in its head.

Architecture B: the platform contract is the interface

The developer declares the service characteristics that are actually specific to the product: runtime, resource profile, availability target, data sensitivity, scaling behavior, and any legitimate exceptions.

The platform owns the repeated mechanics underneath that contract: networking, baseline identity, certificates, telemetry, deployment policy, health checks, common security controls, and standard operational metadata.

The underlying technology may still include Kubernetes, Terraform, IAM, policy engines, observability agents, and deployment automation. The difference is that knowing all of those mechanisms is no longer a prerequisite for making a routine application change.

Both architectures may have similar technical capability. They do not have the same cognitive surface.

That is an architectural difference, not merely a developer experience difference.

But Abstraction Can Also Make Things Worse

There is an easy mistake here.

Once an organization decides developers have too much complexity, it builds a portal.

Now the developer has Kubernetes, Terraform, Jenkins, cloud consoles, security tools, and a portal.

Nothing disappeared. We simply added another interface.

A platform reduces cognitive load only when it actually takes responsibility for complexity. A button that triggers the same confusing process is not an abstraction. A catalog that links to fifteen other tools is not self service. A template that generates infrastructure the application team must later reverse engineer may make onboarding faster while making ownership harder.

This is why platform engineering is fundamentally an architecture and product discipline, not a portal project.

DORA's platform engineering guidance makes the same point from another direction: internal platforms should be treated as products, designed around developer journeys, with complexity deliberately shifted into reusable platform capabilities. DORA reports that internal platforms are now widespread, so the interesting question is no longer whether an organization has one. It is whether the platform genuinely reduces friction and cognitive load.

Architecture Boundaries Should Fit Team Boundaries

Cognitive load also changes how I think about service boundaries.

We often decompose systems around business domains, scalability, deployment independence, or data ownership. Those are important dimensions.

But a boundary also determines what a team must understand to make a safe change.

If a team owns twelve microservices, three event pipelines, two databases, several shared libraries, and a complicated set of cross team dependencies, calling each service "small" does not make the team's cognitive surface small.

The meaningful unit is not lines of code per service.

It is the amount of context required to reason about an outcome.

This is where organizational design and software architecture begin to converge. Team Topologies popularized the idea that team cognitive load should influence system and team boundaries. AWS DevOps Guidance goes far enough to include balanced cognitive load as an explicit organizational capability, alongside recommendations such as reducing toil, limiting work in progress, clarifying escalation paths, preserving autonomy, and sizing teams around cognitive capacity.

Those may sound like management practices, but they have architectural consequences.

If five teams must coordinate for a routine change, the dependency graph is part of the architecture whether or not it appears in the C4 diagram.

Shared Platforms Should Own Decisions, Not Just Technology

One of the hardest questions in enterprise architecture is deciding what should be centralized.

Centralize too much and every team waits for a platform group. Decentralize too much and every team independently learns cloud networking, identity, observability, resilience, security, and deployment engineering.

The better question may be:

Which decisions benefit from being made once?

If every application team is debating how to collect standard telemetry, rotate common credentials, expose health endpoints, configure baseline security policies, or publish the same deployment metadata, the organization is spending cognitive capacity on problems it has already solved.

A mature platform does not merely centralize infrastructure. It centralizes repeated decisions and turns them into safe defaults.

That leaves application teams with more attention for the decisions that are actually specific to their product.

AI Will Increase the Importance of Cognitive Architecture

AI changes this problem in an interesting way.

At first glance, coding assistants appear to increase cognitive capacity. They can explain unfamiliar code, generate configuration, search documentation, and help developers navigate systems they do not fully know.

That is useful.

But it can also allow organizations to tolerate more complexity rather than remove it.

AI increases our ability to produce complexity faster than it increases our ability to understand complexity.

Agents can create repositories, services, infrastructure, policies, tests, dashboards, and integrations at a cost and speed that were previously impossible. That means the bottleneck can move. Producing software becomes easier while comprehending the resulting system becomes harder.

If creation accelerates without stronger architectural boundaries, the total system can grow faster than the human organization can reason about it. DORA's 2026 analysis of AI assisted development describes a related tension: AI reduces friction in creating work, but some of the saved time moves into auditing and verification, while higher AI adoption can coincide with both greater throughput and greater delivery instability.

So AI should not become our excuse for bad cognitive architecture.

The goal should not be to build systems so complicated that only an AI agent can explain them.

AI can help people navigate necessary complexity. Architecture should still remove unnecessary complexity.

There Is a Cognitive Budget

We routinely establish performance budgets. A page may have a latency budget. A service has an error budget. A workload has a cost envelope.

I think engineering organizations should develop an intuition for a cognitive budget as well.

Not a numeric score pretending we can precisely measure human thought. Something more practical.

A Cognitive Load Review

For a team owning a system, I would review at least these seven dimensions:

  • Technology surface: How many technologies require deep knowledge to make a safe change?
  • Change surface: How many repositories, systems, or configuration layers change during normal feature work?
  • Dependency surface: How many other teams must participate in a routine change?
  • Operational surface: How many dashboards, consoles, and tools are needed to understand a production problem?
  • Decision surface: How many infrastructure and platform decisions are repeatedly exposed to application developers?
  • Exception surface: How much important knowledge exists outside the standard path and must be remembered manually?
  • Learning surface: How long does it take a capable new engineer to become independently effective?

The purpose is not to turn human cognition into a synthetic score. The purpose is to make the hidden cost of a design discussable during architecture review.

These questions reveal something architecture diagrams often miss.

When the answers keep growing, the response should not automatically be more documentation or more training.

Sometimes the system is telling us that the architecture itself needs to become simpler.

Toward Cognitive Architecture

We already evaluate architecture through technical complexity, operational complexity, organizational complexity, and cost. I think cognitive complexity belongs beside them.

An architecture is incomplete if it describes machines, services, and dependencies but ignores the amount of human comprehension required to operate and change the system safely.

This does not mean every system should be simple. Some domains are inherently difficult. The architectural responsibility is to distinguish essential complexity from accidental complexity, and to decide deliberately who must carry each part.

That is what I mean by cognitive architecture: designing not only how software components interact, but how understanding, decisions, and operational responsibility are distributed across the people and teams that own the system.

What Architects Can Do Differently

I would add cognitive load to the normal set of architecture tradeoffs.

When introducing a technology, ask what existing complexity it removes, not only what capability it adds.

When defining a standard, ask whether teams need to understand the mechanism or only the contract.

When creating a platform, measure whether engineers can complete important journeys with fewer decisions, handoffs, and context switches.

When decomposing a system, look at the ownership graph alongside the service graph.

And when a design requires every application developer to become a part time expert in networking, identity, containers, observability, security, compliance, FinOps, and half a dozen internal frameworks, resist calling that "full stack ownership" without examining what it really costs.

Simplicity Is Organizational Capacity

Software architecture has always been partly about managing complexity.

What has changed is the scale of the machinery surrounding modern software. Cloud and DevOps gave teams extraordinary power. Platforms can make that power easier to consume. AI may amplify it again.

But human attention has not scaled at the same rate.

That makes simplicity more than an aesthetic preference.

It is organizational capacity.

A system that a team can understand, operate, change, and recover is not merely nicer to work with. It is more resilient because people can reason about failure. It is faster to change because engineers do not have to reconstruct the world before touching it. It is easier to govern because important decisions are visible rather than buried under accidental complexity.

We would never approve an architecture that requires more memory than the machine possesses.

We should be equally cautious about approving one that requires more context than its team can carry.

Further Reading

DORA. Platform Engineering capability guidance.

DORA. Balancing AI tensions: Moving from AI adoption to effective SDLC use, 2026.

AWS. Well Architected DevOps Guidance: Balanced Cognitive Load.

Google Cloud. Platform Engineering: Shift Left and Shift Down.

Skelton, M. & Pais, M. Team Topologies.

Explore this topic

Part of the Architecture Practice topic collection.