TOGAF Architecture Principles and Governance Basics

Every organization that runs a TOGAF-based architecture practice eventually confronts the same challenge: how do you make sure that hundreds of decisions made by dozens of teams across many projects all move in the same direction?

The answer is principles and governance.

Architecture principles define the fundamental beliefs that guide every decision. Governance creates the structure that ensures those beliefs are respected in practice. Together, they are what separate a mature, consistent architecture function from a collection of uncoordinated projects.

This post explains how TOGAF defines and applies these two concepts, with practical examples drawn from real organizational scenarios.

What Are Architecture Principles?

An Architecture Principle is a general rule or guideline that represents a fundamental belief about how an organization should approach technology and architecture decisions.

Principles are not policies. A policy is a rule that must be followed. A principle is a belief that guides judgment. When architects face a decision without a clear right answer, they apply the relevant principles to decide which direction best serves the organization.

Good principles are stable over time. They do not change with every project. A single well-formed set of principles can guide an organization for years, even as technology evolves rapidly around it.

Why Good Principles Matter

Without principles, different teams make different assumptions. One team builds data in proprietary formats. Another team creates a system that cannot integrate with anything else. A third team makes a platform decision that contradicts the organization's security strategy.

Principles create shared understanding. When everyone holds the same foundational beliefs, technical decisions become easier to make, easier to justify, and easier to align across the enterprise.

The Structure of a Well-Formed Principle

TOGAF defines a very specific structure for architecture principles. Every principle should have four components.

1. Name

The name should be a short, memorable phrase that communicates the essence of the principle. It should be something people can reference in conversation without confusion.

Examples: "Data Is a Shared Asset", "Build Once, Use Many Times", "Technology Independence", "Single Point of Truth".

2. Statement

The statement expresses the principle clearly in one or two sentences. It should be unambiguous and actionable.

For example, the statement for "Data Is a Shared Asset" might be: "All data held by the organization is accessible to any person or process with a legitimate business need, subject to security and privacy controls."

3. Rationale

The rationale explains why this principle exists and what organizational benefit it delivers. It connects the principle to business strategy.

For the same example: "Treating data as a shared asset eliminates duplication, reduces costs, improves data quality, and enables faster decision-making across the enterprise. It positions the organization to respond more effectively to regulatory and analytical demands."

4. Implications

Implications describe the practical consequences of adopting the principle. These are often the hardest part to define because they reveal what needs to change.

For "Data Is a Shared Asset": "Data silos will not be created or tolerated. All new systems must expose their data through agreed integration interfaces. A data governance function must be established to manage access and quality. Legacy systems that maintain proprietary data formats must be included in modernization roadmaps."

Keep Principles Manageable

TOGAF recommends keeping the total number of architecture principles to a manageable set, typically between 5 and 20. Too few principles leave gaps. Too many create confusion and become impossible to remember or apply consistently.

Categories of Architecture Principles

TOGAF organizes principles into five primary categories, each addressing a different dimension of the enterprise.

Business Principles

These address how the organization conducts its work at a strategic level.

Examples:

Primacy of Principles: Architecture principles take priority over exceptions
Maximize Benefit to the Enterprise: Individual decisions should serve the whole organization, not just the team making them
Business Continuity: Enterprise operations must be maintained in all circumstances

Data Principles

These address how data is treated across the organization.

Examples:

Data Is an Asset: Data has real business value and must be managed accordingly
Data Is Shared: The same data should not be held in multiple disconnected stores
Data Trustee: Each data element has a designated owner responsible for its quality

Application Principles

These address how software applications are designed and managed.

Examples:

Technology Independence: Applications should not be tied to a single platform or vendor
Ease of Use: Applications should be simple and intuitive for their intended users
Common Use Applications: Shared services should be preferred over custom builds

Technology Principles

These address infrastructure and platform decisions.

Examples:

Requirements-Based Change: No change to infrastructure is made without a clear business requirement
Responsive Change Management: Changes are managed in a timely and controlled way
Control Technical Diversity: Limit the variety of technologies to reduce complexity and cost

Principles Require Enforcement

Documenting principles is only the first step. Without a governance structure to audit compliance and handle exceptions, principles become aspirational statements that teams ignore under project pressure.

What Is Architecture Governance?

Architecture Governance is the practice and set of processes by which enterprise architectures and the policies that guide them are controlled, managed, and made accountable.

In straightforward terms, governance is the system that makes sure the architecture actually happens the way it was designed.

Without governance, architects produce documents that sit on a shelf. Projects deliver systems that contradict the agreed architecture. Technical debt builds silently. Standards erode.

With governance, the architecture becomes a living, enforced framework that actively shapes how technology evolves across the organization.

What Governance Addresses

Good architecture governance handles four core questions:

Who decides? — Which body or individual has the authority to approve architecture decisions at different levels?
What standards apply? — Which technology platforms, data formats, and design patterns are approved for use?
How is compliance checked? — At what points are projects reviewed against the architecture?
How are exceptions handled? — What happens when a project cannot comply with the agreed architecture?

The Architecture Board

The Architecture Board is the central governance body in most TOGAF implementations. It is a group of senior architects and business representatives responsible for making architectural decisions and approving architecture work.

The Architecture Board typically performs the following functions:

Reviewing and approving architecture principles
Approving the Architecture Vision and Statement of Architecture Work for new projects
Conducting Architecture Compliance Reviews at agreed milestones
Handling requests for exceptions or waivers from approved standards
Resolving architectural disputes between teams
Monitoring the implementation of major architectural changes

In large organizations, there may be multiple architecture boards operating at different levels. A corporate board sets enterprise-wide standards. Divisional boards handle segment-level decisions within those standards. Project boards handle implementation-level governance.

Architecture Compliance Reviews

An Architecture Compliance Review is a formal examination of a project or solution against the agreed architecture. It is one of the primary tools that governance uses to maintain architectural integrity.

Compliance reviews typically happen at key delivery milestones, such as at the end of the design phase or before a system moves into production.

TOGAF defines six possible outcomes from a compliance review:

Conformant: The project fully meets all architecture requirements
Accommodated: The project mostly conforms, with minor gaps acknowledged and managed
Delineated: The project intentionally departs from the architecture, with the departure formally documented and accepted
Irrelevant: Architecture standards do not apply to this project
Consistent: The project is broadly aligned but has not been formally evaluated in full detail
Non-conformant: The project fails to meet architecture requirements with no agreed remediation plan

Non-conformant projects are flagged back to the Architecture Board for escalation and remediation planning.

Architecture Contracts

An Architecture Contract is a joint agreement between the development team and the architecture body on what will be delivered, to what quality, and under what constraints.

It is essentially the governance mechanism that makes the architecture binding on delivery teams. Without an Architecture Contract, teams can claim they were unaware of architectural requirements or interpret them differently.

A good Architecture Contract covers:

The specific architecture standards and principles the project must comply with
Agreed quality criteria for the delivered system
A schedule of Architecture Compliance Reviews
How exceptions and deviations will be managed
Sign-off requirements from both the development team and the architecture governance body

Governance Enables, Not Just Constrains

A well-run architecture governance function actually helps projects move faster. It gives teams pre-approved standards to work with rather than making decisions from scratch. It reduces rework by catching architectural misalignment early rather than after delivery.

Governance in the ADM Cycle

Architecture governance is established during the Preliminary Phase of the ADM and actively operates throughout every subsequent phase.

Key governance touchpoints in the ADM include:

Preliminary Phase: Governance structures, tools, and principles are defined
Phase A: Architecture Vision: The Statement of Architecture Work is approved by the Architecture Board
Phases B-D: Architecture decisions are reviewed and signed off by governance
Phase G: Implementation Governance: Active oversight of delivery ensures implementation aligns with the design
Phase H: Change Management: Governance manages how changes to the approved architecture are assessed and approved

Phase G deserves special mention. It is the phase entirely dedicated to implementation governance. It is where architects stop designing and start actively monitoring whether what is being built matches what was agreed. This is often skipped in practice, which is one of the primary reasons architecture documents diverge from reality.

Practical Example: Governance in a Financial Services Firm

Consider a large bank running a cloud migration programme. The architecture governance structure might look like this:

A Group Architecture Board sets the cloud strategy and approved platforms (for example, AWS and Azure only, no other providers)
A Technology Standards Catalogue in the Architecture Repository lists approved services on each platform
Each migration project signs an Architecture Contract agreeing to use only approved services
A Compliance Review is conducted before each system goes live to check that no unapproved services were introduced
A team that needs an exception to use an unapproved tool must submit a formal request to the Architecture Board with a business justification

This structure means the bank can run fifty simultaneous migration projects without losing control of its architectural standards. Each project operates independently within a bounded, governed framework.

Summary

Architecture Principles are the fundamental beliefs that guide every architecture decision. Each principle needs a name, statement, rationale, and implications to be effective.

Architecture Governance is the system that ensures those principles are followed in practice. It operates through an Architecture Board, Architecture Contracts, and Compliance Reviews at key points in every project.

Together, principles and governance are what give TOGAF its teeth. Without them, the ADM produces documents. With them, it produces lasting architectural change.

In the next post, we will step into the ADM itself and begin with the Preliminary Phase, where an organization sets up its architecture capability and prepares everything needed before the first architecture project begins.

If you are new to this series, start with What is TOGAF 9.2? and progress through The Four Architecture Domains and Core Concepts and Terminology before this post.