Architecture Governance: Capturing What and How

In my previous article, I argued that Architecture Decision Records capture the “why” behind architectural choices - the context and reasoning that led to specific decisions. But knowing why past decisions were made doesn't tell engineers what rules to follow for new decisions.

Teams make architectural choices in isolation. One squad picks REST, another chooses gRPC. Services use different authentication patterns, logging formats, and deployment strategies. Each choice is locally reasonable. Collectively, the architecture fragments into incompatible pieces.

Architecture governance provides exactly that - a documented set of principles, standards, and conventions that guide architectural decisions across the organization.

Why It Matters

Without explicit governance, every architectural decision becomes a fresh debate every time. Engineers reinvent solutions to solved problems. Teams make incompatible choices that create integration friction later. The architecture drifts as each decision optimizes locally without considering global coherence.

Governance answers critical questions before they become debates:

• What communication patterns are allowed?

• Which technology stacks are supported?

• How should services handle authentication?

• What observability standards must components meet?

These aren't restrictions for the sake of control - they're shared agreements that reduce cognitive load and enable interoperability.

The “Three Layers”

Architecture governance operates at three levels of specificity:

Principles → Standards → Conventions

Principles are the fundamental beliefs that guide architectural thinking - the “why” behind the rules.

• Services should be independently deployable

• Data ownership must be clear and explicit

• Security is non-negotiable at every layer

Standards are the concrete requirements that enforce principles - the “what” teams must do.

• All services must expose health check endpoints

• Authentication must use OAuth 2.0 with the company SSO

• APIs must use semantic versioning

Conventions are the recommended practices that create consistency - the “how” that makes integration easier.

• Use kebab-case for service names

• Structure repositories with /src, /docs, /tests

• Log OTEL Format to stdout

This hierarchy provides flexibility within boundaries. Principles are mandatory. Standards are enforced. Conventions are strongly encouraged, but teams can deviate with justification.

Living Governance

Governance isn’t static. As the organization learns, standards evolve.

ADRs document past decisions. Governance documents current rules. Together, they create a complete picture: why we made specific choices, and what principles guide future ones. The hardest part of governance isn’t defining standards - it’s making them discoverable and actionable.

Standards become checkable assertions. CI/CD pipelines validate compliance. Dashboards show conformance across services. Engineers discover governance through tooling, not documentation archaeology.

Summary

Architecture governance is a foundational decision-making primitive.

• Reduces decision fatigue - provides default answers to common questions

• Enables autonomous teams - clear boundaries allow independent movement

• Creates interoperability - shared standards make integration predictable

• Accelerates onboarding - new engineers learn “how we do things” explicitly

Without governance, every architectural decision is negotiated from first principles. With it, teams move faster within well-defined guardrails.