Architecture Governance and TOGAF
This module keeps a software-architecture focus and uses TOGAF as supporting governance context. If you want the dedicated TOGAF-led path on this site, use the Enterprise Architecture course.
By the end of this module you will be able to:
- Explain the purpose of architecture governance and the Architecture Review Board (ARB)
- Describe the TOGAF Architecture Development Method (ADM) phases and what each produces
- Apply fitness functions to automate architectural compliance checks in CI pipelines
- Design a lightweight governance process appropriate for a mid-sized engineering organisation
Real-world case · 2021-2023
A 200-engineer fintech with 12 teams and 12 different message brokers.
Between 2021 and 2023 a UK fintech grew from 50 to 200 engineers by hiring aggressively and forming new teams every quarter. Each team had autonomy over their technology choices. Three teams chose Apache Kafka because their engineers had prior experience. Four teams chose RabbitMQ because it was simpler to operate. Three teams chose AWS Simple Queue Service (SQS) because it integrated well with their existing AWS infrastructure. Two teams built REST-polling integration because they did not want to manage a broker at all.
By mid-2023 the platform team reported that cross-team event integration required a different client library, a different monitoring approach, and a different operations runbook for each broker. Onboarding a new engineer required learning which broker their team used and how it differed from the broker in the team they had previously worked on. The total operational overhead had become measurable in engineering time per week.
The company formed an Architecture Review Board (ARB) in Q3 2023 and adopted a federated governance model. Within six months, all new event-driven integration used a single approved broker. Migrating existing teams was a longer project. The lesson: governance is cheaper before fragmentation than after it.
When every team makes local technology decisions that are individually reasonable, how does the organisation end up with 12 different message brokers? And what is the cost of resolving that fragmentation once it has happened?
With the learning outcomes established, this module begins by examining architecture governance in depth.
21.1 Architecture governance
Architecture governance is the set of processes, roles, and standards that ensure architectural decisions are made consistently, communicated across teams, and validated against quality attribute requirements. Without governance, architecture is a recommendation, not a constraint. Teams make locally reasonable decisions that collectively produce an incoherent system.
Governance operates on a spectrum. Centralised governance (all architectural decisions approved by a central architecture team) provides consistency but creates a bottleneck that slows delivery. Decentralised governance (teams own their architecture entirely) maximises speed but produces fragmentation. Federated governance sits in the middle: a small architecture function sets standards, approved technology choices, and non-negotiable constraints; teams make decisions within those guardrails.
Most successful engineering organisations use federated governance. The fintech in the opening is an example of decentralised governance producing fragmentation that required expensive remediation. The architecture function that formed in Q3 2023 adopted federated governance.
“Architectural governance is the practice of monitoring and directing architectural decisions to ensure they comply with established principles and goals.”
The Open Group (2022) - Phase A, Architecture Vision
The phrase 'monitoring and directing' distinguishes governance from architecture itself. Architecture produces decisions; governance ensures those decisions are followed and remain appropriate over time. The second part, 'established principles and goals', is where the Architecture Review Board and approved technology lists operate.
The Architecture Review Board (ARB) reviews significant architectural decisions before implementation. It is not a bureaucratic approval gate for every decision. Its scope is decisions that are expensive to reverse, that cross team boundaries, or that affect shared infrastructure. The ARB should review new service or platform introductions, changes to shared APIs or event schemas, major infrastructure technology changes, and decisions affecting security, compliance, or data residency. It should not review technology choices within a team's bounded context, refactoring that does not change external interfaces, or implementation details that do not affect other teams.
With an understanding of architecture governance in place, the discussion can now turn to togaf and the architecture development method, which builds directly on these foundations.
21.2 TOGAF and the Architecture Development Method
TOGAF (The Open Group Architecture Framework) is an enterprise architecture framework providing a structured method for developing, managing, and governing enterprise IT architecture. The 10th edition was published in 2022. TOGAF organises architecture into four domains: Business Architecture (business strategy, processes, and organisational structure), Data Architecture (logical and physical data assets), Application Architecture (individual applications and their interactions), and Technology Architecture (infrastructure and platforms).
The Architecture Development Method (ADM) is the cyclical process TOGAF provides for developing and evolving architecture. It has nine phases. The Preliminary phase sets up governance and defines principles. Phase A (Architecture Vision) defines scope, identifies stakeholders, and produces a high-level vision. Phases B, C, and D develop the business, information systems, and technology architectures respectively. Phases E and F identify solutions and produce a migration roadmap. Phase G oversees implementation. Phase H manages ongoing changes. Requirements Management runs continuously through all phases.
The ADM is a reference cycle, not a mandatory waterfall. Organisations running iterative programmes apply the ADM in shorter cycles, re-entering at Phase A when priorities change. The TOGAF certification programme (Foundation and Practitioner) is one of the most widely held enterprise architecture certifications globally.
Common misconception
“TOGAF must be applied in full to be useful.”
Applying the full TOGAF ADM to a startup's architecture would take longer than building the product. TOGAF is most valuable in large organisations (1,000 or more employees, multiple business units) where cross-domain consistency has material business value. Smaller organisations benefit from adopting TOGAF concepts (architecture domains, governance principles, ADM phases as a vocabulary) without applying the full method. Use what is appropriate to your organisation's scale and maturity.
With an understanding of togaf and the architecture development method in place, the discussion can now turn to fitness functions: automating governance, which builds directly on these foundations.
21.3 Fitness functions: automating governance
An architectural fitness function is an automated test that verifies a system's adherence to an architectural characteristic. The term was coined by Neal Ford, Rebecca Parsons, and Patrick Kua in Building Evolutionary Architectures(2017). Fitness functions shift architecture enforcement from documentation and periodic review to automated, continuous verification in the CI/CD pipeline.
A dependency direction fitness function verifies that the domain layer does not import from the infrastructure layer. In Java, ArchUnit provides a domain-specific language for writing these as JUnit tests. In Python, a custom script that inspects import statements achieves the same result. Both run in the CI pipeline on every commit and block the build if the constraint is violated.
A service coupling fitness function verifies that Service A's database user does not have direct access to Service B's database schema. This enforces the microservices rule that each service owns its own data. A PostgreSQL query against the information schema can verify this. Running it in CI means no deployment will ever introduce a direct cross-service database coupling without being caught automatically.
“Fitness functions provide a mechanism for architects to express architectural constraints that will be checked automatically, continuously, and objectively.”
Ford, N., Parsons, R., Kua, P. (2017) - Building Evolutionary Architectures. O'Reilly Media, Chapter 2
The word 'objectively' is important. A governance document that says 'services must not access each other's databases' relies on code reviewers to catch violations manually. A fitness function that fails the build if Service A's user has access to Service B's schema is objective and automatic. The constraint cannot be ignored or overlooked.
With an understanding of fitness functions: automating governance in place, the discussion can now turn to lightweight governance for engineering organisations, which builds directly on these foundations.
21.4 Lightweight governance for engineering organisations
A 50-engineer organisation does not need a full TOGAF programme. An effective lightweight governance system combines four elements. A technology radar is a quarterly list of technologies in four categories: Adopt (use freely), Trial (experiment with ARB awareness), Assess (watch but do not adopt yet), and Hold (do not use for new work). The ThoughtWorks Technology Radar, published quarterly since 2010, is the model for this approach.
Architecture Decision Records (ADRs) as governance artefacts capture team-level decisions in version-controlled documents reviewed in pull requests. Cross-team decisions are escalated to the architecture channel or ARB. ADRs produce a searchable record of why each decision was made, making future governance decisions better-informed.
Fitness functions in CI automate enforcement of critical architectural rules: dependency direction, API contract compliance, security policies, and service coupling. These replace the most time-consuming manual review activities with automated checks that run on every commit.
Architecture office hours, a weekly 30-minute open session where teams discuss architectural questions without a formal review gate, reduce the friction of seeking architectural input. Engineers who might avoid a formal ARB review will ask a question in a low-stakes open session, catching problems earlier.
A 200-engineer fintech has 12 teams using four different message brokers. Using federated governance, what standards would the architecture function set, what decision-making authority would teams retain, and how would the standard be enforced?
What does the TOGAF Architecture Development Method (ADM) primarily produce?
A team wants to ensure that no code in the domain layer ever imports from the infrastructure layer. Which approach ensures this constraint is enforced continuously rather than only during periodic reviews?
Which decisions should an Architecture Review Board (ARB) review, and which should it not review?
Key takeaways
- Architecture governance coordinates decisions across teams without requiring central approval for every choice. Federated governance balances consistency (central standards) with autonomy (team decision-making within guardrails).
- The ARB reviews decisions that are expensive to reverse or that cross team boundaries. It should not review routine internal decisions. Scoping the ARB correctly prevents it becoming a bottleneck.
- TOGAF provides a structured method (ADM) for developing enterprise architecture across business, data, application, and technology domains. Use the concepts and vocabulary; apply the full method only where organisational scale justifies it.
- Fitness functions automate architectural compliance checks in CI pipelines, making governance continuous rather than point-in-time. Automated enforcement cannot be bypassed or forgotten.
- A technology radar, ADRs, fitness functions, and architecture office hours form a lightweight but effective governance system for mid-sized engineering organisations.
Standards and sources cited in this module
The Open Group, TOGAF Standard 10th Edition
Part VI: Architecture Governance; Part II: ADM
The authoritative TOGAF reference. The ADM phases, four architecture domains, and governance definition in Section 21.1 are drawn from this source.
Ford, N., Parsons, R., Kua, P. (2017). Building Evolutionary Architectures. O'Reilly Media
Chapter 2: Fitness Functions
Introduces fitness functions as the mechanism for automated architectural governance. Quoted in Section 21.3 for the definition and the principle of objective, continuous enforcement.
ThoughtWorks Technology Radar. thoughtworks.com/radar
Quarterly editions, 2010 to present
The model for technology radars referenced in Section 21.4. Quarterly editions are independently valuable for tracking technology trends relevant to the Adopt/Trial/Assess/Hold framework.
ISO/IEC/IEEE 42010:2022. Systems and Software Engineering: Architecture Description
Full standard
The international standard for architecture description and governance frameworks. Provides the formal definition of architectural concerns, viewpoints, and decisions underlying both TOGAF and lighter-weight governance approaches.
What comes next: Governance sets direction. Chaos engineering tests whether the system actually delivers on its promises. Module 22, the final module, covers chaos engineering principles, game days, ATAM-style trade-off analysis, and how to present architecture decisions to non-technical stakeholders.
Module 21 of 22 in Practice and Strategy