Mastering TOGAF Architecture Capability and Governance: A Practical Guide

1. Architecture Capability Building and Governance

To ensure that architecture functions are successfully applied within an enterprise, the organization must establish appropriate structures, processes, roles, responsibilities, and skills to develop its own enterprise architecture capability. This is the focus of TOGAF’s Architecture Capability Framework, which provides reference material for building such capability. However, the framework is not yet a complete template for applying architecture capability; it offers guidelines and recommendations for key activities during capability construction and use.

The diagram below shows that an enterprise’s architecture capability operates at a certain maturity level. Governance bodies oversee, assess, and guide the operation of all architecture functions. The central part of the diagram lists the elements required for successful architecture function execution:

Skilled Resource Pool – the pool of roles, responsibilities, and skills needed to implement and maintain architecture functions.

Projects/Portfolios – architecture functions must be realized through projects or portfolios, which remain under architecture governance throughout their lifecycle to ensure alignment with architectural definitions. Contracts are used to communicate and constrain these projects and their governance.

The Skilled Resource Pool defines participation roles and responsibilities for projects and their governance, and specifies the skills required for professionals, supported by training to develop or enhance those skills. Governance bodies not only guide the development of the skill pool but also set priorities and focus for project governance, and evaluate its effectiveness. Because the enterprise’s internal and external environment constantly changes, daily business operations reflect these changes and provide a reference for prioritising and focusing architecture project governance, while architecture implementation projects deliver suitable solutions for business operations.

All architecture artefacts are stored in an Architecture Repository, which preserves and maintains work products generated by projects and classifies them using the Enterprise Continuum.

In summary, the Architecture Capability Framework provides guidance for building architecture capability within an enterprise. Architecture capability refers to the enterprise’s ability to successfully build and use architecture. This is achieved by establishing appropriate organisational structures and processes, defining and allocating required roles, responsibilities, and skills, and providing the environment and resources for architecture delivery and governance. TOGAF offers guidelines and recommendations in the following areas:

Architecture Capability Building – guidance on how enterprises can develop architecture capability by introducing architecture development methods.

Architecture Governance – the goal of architecture capability is to ensure smooth construction and operation of enterprise architecture through proper governance, with detailed descriptions of architecture contracts and compliance.

Architecture Maturity Models – to help enterprises understand their architecture maturity level and identify weak areas for improvement.

Architecture Skills Framework – defines roles, required skills, and proficiency levels for participants in architecture projects and governance, providing reference and guidance.

1. Architecture Capability Construction

Enterprises can apply the Architecture Development Method (ADM) to build various business capabilities. In a broader view, ADM can be applied to any capability development, including architecture capability. Successful use of ADM in capability construction enables a sustainable, customer‑centric, value‑adding architecture practice that helps achieve business goals, maximise investment value, and identify opportunities for business benefits and risk management. Architecture practice construction is a continuous process that provides an environment and resources for other architecture deliveries within the organisation.

According to TOGAF, any enterprise capability construction requires design in four domains, including architecture capability:

Business Architecture: focuses on architecture governance, processes, organisational structure, information needs, and architecture products.

Data Architecture: defines the structure of the Enterprise Continuum and Architecture Repository.

Application Architecture: describes the functions and/or application services that support the sustainable architecture practice.

Technology Architecture: describes the infrastructure requirements and deployment methods that support architecture applications and the Enterprise Continuum.

TOGAF provides more detailed guidance for building a sustainable architecture practice, which will be explored in the following sections based on the phases of the Architecture Development Method.

1) Architecture Vision Phase

The purpose of this phase is to define or review the vision, stakeholders, and principles of the architecture practice. Specific steps include:

Establish the project – identify all stakeholders involved in the architecture practice, including roles and organisational units that will benefit from the deliverables.

Clarify stakeholders, concerns, business needs, and architecture vision – produce a high‑level definition of baseline and target environments from both business and technical perspectives.

Identify business gaps and drivers – understand business objectives and drivers to align the architecture practice with business.

Define scope – create a high‑level project plan outlining problems to be addressed in the upcoming time frame.

Define constraints – capture enterprise‑wide constraints that affect all architecture projects.

Review architecture principles (including business principles) – define principles that govern and guide the practice, distinct from typical architecture principles that govern artefacts.

Develop architecture work statements and security certification.

Consider architecture maturity assessment.

2) Business Architecture Phase

The goal of this phase is to establish or refine the business architecture of the practice, focusing on key areas:

Architecture Ontology – defines terminology and definitions to build consensus.

Architecture Process – customises the ADM to the organisation’s needs and integrates required governance processes.

Architecture Viewpoints and Views – enumerates all viewpoints and views, guided by identified stakeholders.

Architecture Framework – describes deliverables, their interactions, dependencies, and the rules governing them.

Architecture Accountability Matrix – defines roles and responsibilities for architecture deliverables and processes.

Architecture Performance Metrics – defines metrics to monitor and compare practice performance against vision and goals.

Architecture Governance Framework – a specific view related to the previously defined processes and accountability matrix.

3) Information Systems Architecture Phase (Data)

The data architecture of the practice describes and governs the Enterprise Continuum and Architecture Repository. Data architecture definitions are based on the chosen architecture framework and may be referenced as the practice’s meta‑model.

4) Information Systems Architecture Phase (Application)

The application architecture defines the functions used to create, maintain, publish, distribute, and govern architecture deliverables, with modelling tools being a key component.

5) Technology Architecture Phase

The technology architecture defines the technical infrastructure that supports the architecture practice.

6) Opportunities and Solutions Phase

In this planning phase, enterprises must carefully consider required organisational changes and the methods to achieve them.

7) Migration Planning Phase

This phase focuses not only on information‑system components but also includes business architecture. The adoption of architecture processes and frameworks significantly impacts overall practice construction.

8) Implementation Governance Phase

The focus here is the implementation of the business architecture. Transforming practice activities into a more structured and disciplined approach requires appropriate organisational change techniques.

9) Architecture Change Management Phase

This phase manages changes to various architectures that are typically triggered during project execution. A typical change may generate a new architecture deliverable and affect all architecture domains.

10) Requirements Management

Understanding and managing the practice’s requirements is critical; they must be clearly described and aligned with the architecture vision.

2. Architecture Governance

Simply put, enterprise architecture capability refers to the ability to build various architectures, and this capability must be delivered in a transparent and controlled environment. Architecture governance is the core part of architecture capability that ensures such controlled delivery.

All enterprises have governance needs, even those without architecture functions. Therefore, architecture governance cannot exist in isolation; it must be part of a hierarchical governance structure. TOGAF divides this structure into four layers, each with its own rules and processes, which can exist across global, regional, and local levels:

Corporate Governance

Technology Governance

IT Governance

Architecture Governance

These governance layers overlap in activities but differ in scope, rules, processes, and activities. TOGAF focuses primarily on Architecture Governance while briefly describing the commonalities and specifics of technology and IT governance.

1) Governance Commonalities

Governance is not merely strict rule enforcement; it provides guidelines for effective and fair resource use to ensure sustainable achievement of strategic goals. OECD outlines common principles such as stakeholder rights, transparency, strategic guidance, effective committee management, accountability, and fairness.

TOGAF also identifies governance characteristics: Discipline, Transparency, Independence, Accountability, Responsibility, and Fairness.

2) Characteristics of Different Governance Domains

Technical Governance controls how an organisation applies technology to research, development, and production. It closely relates to IT Governance, which provides a framework linking IT resources and information to business goals, defining best practices for planning, procurement, implementation, and performance monitoring.

Architecture Governance manages and controls enterprise architecture across the organisation, ensuring creation, supervision, compliance, and accountability of architecture artefacts.

3) Architecture Governance Framework

The framework consists of two parts: a conceptual structure that summarises processes and related content, and an organisational structure suggested by TOGAF.

Conceptual Structure

The conceptual structure separates processes, their content, and background elements, allowing new governance material to be introduced without heavily impacting existing processes, ensuring flexibility.

The diagram illustrates the concepts within the Architecture Governance Framework, highlighting governance processes that identify, manage, audit, and disseminate information related to architecture management, contracts, and implementation, ensuring continuous supervision of artefacts, contracts, principles, and operational‑level agreements, with decisions being auditable.

Policy Management and Take‑On – registers, validates, approves, manages, and publishes new or updated content, ensuring orderly integration with existing governance material.

Compliance – continuous assessment of SLAs, OLAs, standards, and regulatory requirements to ensure stability, consistency, and performance.

Dispensation – when content is deemed non‑compliant, it may be adjusted or a temporary exemption granted with defined service and operational conditions.

Monitoring and Reporting – performance management to ensure service and operational agreements are supervised, feedback is provided, and results reported.

Business Control – processes that ensure alignment with business strategy.

Environment Management – defines services that support the governance framework, including management of physical and logical resource repositories, access, communication, training, and review.

Organisational Structure

Effective governance requires a dedicated organisational structure. In practice, creating such a structure from scratch is unrealistic; enterprises should combine existing IT governance processes, organisational structures, and capabilities. Typical governance organisational layers include:

Global Governance Committee

Local Governance Committee

Design Department

Working Group

TOGAF proposes the following governance organisational model, which enterprises can adapt:

The model divides responsibilities into three focus areas—Develop, Implement, and Deploy—each representing a stage of the architecture lifecycle and associated responsibilities.

Develop: The Architecture Board appoints chief architects and collaborates to guide design, refining enterprise architecture into domain‑specific solutions.

Implement: The Program Management Office, authorised by the Architecture Board, controls implementation projects for domain architectures.

Deploy: The Service Management Organisation, delegated by the Management Office, monitors operational systems, identifies new issues and requirements, and initiates the next architecture development cycle.

The Enterprise Continuum also plays a crucial role, providing a repository for architecture work products and governance materials.

4) Architecture Governance Practice Guidelines

To achieve successful architecture governance and manage architecture contracts effectively, enterprises should consider:

Best practices related to architecture strategy, processes, roles, skills, organisational structure, and support services.

Processes and organisational structures that support governance and reporting requirements.

Integration of tools and processes to facilitate cultural and procedural execution.

Metrics related to governance processes, exemptions, compliance reviews, SLAs, and OLAs.

Requirements for confidentiality, integrity, availability, compliance, and reliability of governance information and services.

TOGAF also identifies three strategic elements for successful architecture governance:

Establish a cross‑organisational Architecture Board with senior‑management support to oversee IT governance strategy implementation.

Develop a comprehensive set of architecture principles to guide the use of information technology.

Adopt an architecture compliance strategy that includes impact assessments, formal compliance reviews, and possible involvement in product procurement.

3. Architecture Committee

A cross‑organisational Architecture Board, sponsored by senior management, supervises the implementation of architecture governance strategies. The board represents major stakeholder interests and typically holds responsibilities such as ensuring sub‑architecture consistency, identifying reusable components, maintaining enterprise architecture flexibility, enforcing compliance, improving governance maturity, adopting architecture‑based development processes, providing decision foundations for architecture changes, and offering escalation capabilities.

From an execution perspective, the committee’s duties include overseeing architecture contracts, holding regular meetings, ensuring consistent and effective architecture management, resolving ambiguities and escalated conflicts, providing advice and guidance, granting exemptions aligned with technical strategy, validating service‑level and cost‑saving reports, and more.

From a governance perspective, responsibilities involve producing governance artefacts, enabling consensus‑based acceptance and approval of architecture, providing basic control mechanisms for effective implementation, linking architecture strategy and objectives with business strategy, and clarifying differences between architecture and planned activities for adjustments.

1) Establishing the Architecture Committee

Triggers for establishing a committee include new CIO appointment, mergers/acquisitions, adoption of new computing models, poor IT‑business alignment, desire for competitive advantage, creation of an enterprise architecture solution, major business changes, rapid business growth, or the need for complex, cross‑functional solutions.

Typically, the CIO sponsors the committee, but a broader sponsorship organisation is preferred for wider support. The committee should be small (four to five members, not exceeding ten) and use a rotation system to maintain representation and continuity.

2) Operating the Architecture Committee

The committee operates through scheduled meetings with clear objectives, agenda items, and defined actions. Meetings support high‑quality governance material creation, consensus‑based acceptance, basic control mechanisms, alignment of architecture implementation with business strategy, and clarification of differences for exemptions or policy updates.

Participants receive agenda descriptions and supporting documents beforehand, must review them, report progress on assigned activities, and confirm attendance.

TOGAF recommends the meeting agenda include:

Previous meeting minutes.

Change requests (e.g., architecture or principle revisions, contract controls).

Exemptions (temporary allowances with defined service and operational conditions).

Compliance assessments (SLAs, OLAs, cost targets).

Dispute resolution.

Architecture strategy and direction documents (global committee).

Action allocation – a report tracking assigned actions with details such as reference material, priority, description, owner, start/end dates, status, type, and decision date.

Contract document management – formal approval of updates and changes to architecture documents.

Any Other Business (AOB).

Meeting schedule – publicised timing and content.

4. Architecture Compliance

Architecture compliance reviews are a core part of governance strategy, determining whether projects align with established standards, principles, and business goals. The review aims to detect errors early, apply best practices, provide compliance overviews, identify required standard modifications, highlight services that could become infrastructure components, document collaborative strategies, leverage technology advances, communicate technical readiness, define procurement criteria, and pinpoint significant architectural gaps for supplier communication.

Compliance reviews may also serve political purposes, providing decision‑making support for senior leadership, ensuring alignment between IT projects and business objectives, and offering a mechanism for architecture teams to participate in development projects.

1) Timing of Compliance Reviews

Reviews occur at appropriate project milestones or lifecycle checkpoints, focusing on:

Architecture development compliance – adherence to the ADM.

Architecture implementation compliance – alignment of implementation projects with architecture.

Typical review points include project initiation, preliminary design, major design changes, and other specific moments.

2) Review Scenarios

Small projects – a project architect or lead creates a set of questions, records answers in a report, and manages it within the enterprise‑wide IT governance strategy.

Projects without a dedicated architect – the enterprise architecture function leads, organizes, and executes the review, involving domain experts and possibly a database system for large data volumes.

Large projects – the chief architect coordinates a team of business and technical experts, compiling answers into a report; the review may also be led by the Architecture Committee or a similar enterprise‑wide body.

All scenarios require senior‑management support and are typically enforced as part of the enterprise architecture governance strategy, with CIOs or the Architecture Committee mandating reviews for major projects.

3) Compliance Review Process

TOGAF summarises the process in the diagram below:

Roles and responsibilities involved are illustrated here:

4) Compliance Review Question Lists

TOGAF provides reference question lists for various aspects (hardware/OS, software/services, applications, information management, security, system management, system engineering, tools, etc.). Enterprises should customise these lists to focus on high‑risk areas and expected variances, understand each question’s meaning and underlying principle, seek domain‑expert input, and incorporate Architecture Committee feedback.

Sample Question Categories (selected)

Hardware and OS: Project lifecycle method, current phase, key evaluation questions for hardware/OS, data volume, standard vs. non‑standard choices, lifecycle cost assessment, vendor financial analysis, etc.

Software Services and Middleware: Error condition definition, method patterns, data structures, protocols, stateful vs. stateless components, object pooling, threading, code review, unit testing, interface completeness, cross‑platform handling, etc.

Application: Infrastructure application capabilities, business application support, integration methods, etc.

Information Management: Data value processes, data definition, security/protection, hosting, shared services, access methods, etc.

Security: Security awareness, identification/authentication, authorization, access control, sensitive data protection, audit logging, external access considerations, etc.

System Management: Software update frequency, distribution tools, version support, backup frequency, account management, licensing, service management tools, health monitoring, error reporting, etc.

System Engineering / Overall Architecture: Integration needs, strategic importance, resource requirements, user distribution, lifecycle, performance testing, component organisation, hardware/software requirements, future user expectations, etc.

Tools and Methods: Definition of methods, documentation, training, tool familiarity, reuse promotion, change integration, evaluation metrics, impact analysis, etc.

Guidelines for Tailoring Question Lists

Focus on high‑risk areas and anticipated variances.

Understand each question’s meaning, principle, and required answer content.

Seek domain‑expert advice.

Adapt questions to organisational needs.

Remember to obtain Architecture Committee feedback.

Guidelines for Conducting Compliance Reviews

Understand the review’s objective and stay on track, delivering artefacts that answer the right questions.

Identify emerging issues during discussion and plan follow‑up actions based on importance.

Maintain a scientific attitude; provide evidence‑based recommendations.

Ask open‑ended questions.

Use a non‑personalised approach to bridge hidden agendas or contentious topics.

Respect interviewees; recognise their effort within constraints.

Gain experience through practice.

Ensure detailed evaluation results are stored in the Enterprise Continuum.

Source: https://zhuanlan.zhihu.com/p/84110694