TOGAF 9.1 Series - Architecture Capability Framework

Have you ever heard of TOGAF and never really understood it? In my TOGAF 9.1 series of articles, I will give you summary points what TOGAF is and what you will learn in TOGAF.

I have written the TOGAF exam a while back. I thought that writing this series will let me review the TOGAF content and believe that it would be valuable to others. It is always a good practice to regularly review the contents of a topic that you have learned.

I'm not going to rewrite the official TOGAF books content in my article series. Some sections will only contain bullet points of key terms used in TOGAF. Always reference the official TOGAF book for more details.

Legal Points

TOGAF is a trademark of The Open Group. They maintain the TOGAF standard and release new versions of the framework. I highly recommend that you read the official website and content of TOGAF on the official site:

The contents in my article series are my opinions and in no way reflects the views of The Open Group.

If you are interested in learning all the finer details of TOGAF or want to write the exam then buy the official book:

TOGAF Version 9.1 Official Book

Figure 1: TOGAF Version 9.1 book

Architecture Capability Framework

Architecture Board

  • Providing the basis for all decision-making with regard to the architectures.
  • Consistency between sub-architectures.
  • Establishing targets for re-use of components.
  • Flexibility of enterprise architecture
    • To meet changing business needs.
    • To leverage new technologies
  • Enforcement of Architecture Compliance
  • Improving the maturity level of architecture discipline within the organization.
  • Ensuring that the discipline of architecture-based development is adopted.
  • Supporting a visible escalation capability for out-of-bounds decisions
Setting up Triggers
  • New CIO
  • Merger or acquisition
  • Considerations of a move to newer forms of computing
  • Recognition that IT is poorly aligned to business
  • Desire to achieve competitive advantage via technology
  • Creation of an enterprise architecture program
  • Significant business change or rapid growth
  • Requirement for complex, cross-functional solutions
Board Structure Bodies
  • Global Governance Board
  • Local Governance Board
  • Design Authorities
  • Working Parties
Meeting Agenda Items
  • Minutes of Previous Meeting
  • Request for Change
  • Dispensations
  • Compliance Assessments
  • Dispute Resolution
  • Architecture Strategy and Direction Documentation
  • Actions Assigned
  • Contract Documentation Management
  • Any Other Business (AOB)
  • Schedule of Meetings

Architecture Compliance

The meaning of Architecture Compliance is a key relationship between the architecture and the implementation.

  • Catch errors in the project early and thereby reduce the cost and risk of changes.
  • Ensure the application of best practices to architecture work.
  • Provide an overview of compliance of an architecture to mandated enterprise standards.
  • Identify where the standards themselves may require modification.
  • Identify services that are currently application-specific but might be provided as part of the enterprise infrastructure.
  • Document strategies for collaboration, resource sharing and other synergies across multiple architecture teams.
  • Take advantage of advances in technology.
  • Communicate to management the status of technical readiness of the project.
  • Identify key criteria for procurement activities.
  • Identify and communicate significant architectural gaps to product and service providers.
Levels of Architecture Conformance
  • Irrelevant
    • The implementation has no features in common with the architecture specification.
  • Consistent
    • The implementation has some features in common with the architecture specification and those common features are implemented in accordance with the specifications.
  • Compliant
    • Some features in the architecture specification are not implemented, but all features implemented are covered by the specification and in accordance with it.
  • Conformant
    • All the features in the architecture specification are implemented in accordance with the specification, but some more features are implemented that are not accordance with it.
  • Fully Conformant
    • There is full correspondence between architecture specification and implementation.
  • Non-conformant
    • Any of the above in which some features in the architecture specification are implemented not in accordance with the specification.
Architecture Compliance Reviews
  • Is a scrutiny of the compliance of a specific project against established architectural criteria, spirit and business objectives.
Architecture Compliance Review Process
  1. Architecture Review Request
    • Roles: IT Governance / Architecture Board
  2. Identify Responsible Organization
    • Roles: Architecture Review coordinator
  3. Identify Lead Architect
    • Roles: Architecture Review coordinator
  4. Determine Scope of Review (Discovery)
    • Roles: Architecture Review coordinator
  5. Tailor Checklists
    • Roles: Lead Architect
  6. Schedule Architecture Review Meeting
    • Roles: Architecture Review coordinator
  7. Interview Project Principles
    • Roles: Lead Architect, Project Leader, Customers
  8. Analyze Completed Checklists
    • Roles: Lead Architect
  9. Prepare Architecture Review Report
    • Roles: Lead Architect
  10. Present Review Findings
    • Roles: Lead Architect
  11. Accept, Review and Sign off
    • Roles: Architecture Board, Customers
  12. Assessment Report Summary
    • Roles: Lead Architect, Architecture Review coordinator
Architecture Compliance Checklists
  • Hardware and Operating System Checklist
  • Software Services and Middleware Checklist
  • Applications Checklist
  • Information Management Checklist
  • Security Checklist
    • Security Awareness
    • Identification/Authentication
    • Authorization
    • Access Controls
    • Sensitive Information Protection
    • Audit Trails and Audit Logs
    • External Access Considerations
  • System Management Checklist
  • System Engineering/Overall Architecture Checklist
  • System Engineering/Methods & Tools Checklist
Tailoring the Checklists
  • Focus on:
    • High risk areas
    • Expected (and emergent) differentiators
  • For each question understand:
    • The question itself
    • The principle behind it
    • What to look for in the responses
  • Ask subject experts for their views
  • Fix the checklist questions for your use
  • Bear in mind the need for feedback to the Architecture Board

Architecture Contracts

Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality and fitness-for-purpose of an architecture.

Contract Types
  • Statement of Architecture Work
  • Contract between Architecture Design and Development Partners
  • Contract between Architecting Function and Business Users
Statement of Architecture Work Contract Content
  • Title
  • Architecture project request and background
  • Architecture project description and scope
  • Overview of Architecture Vision
  • Specific change of scope procedures
  • Roles, responsibilities and deliverables
  • Acceptance criteria and procedures
  • Architecture project plan and schedule
  • Approvals
Architecture Design and Development Contract Content
  • Introduction and background
  • The nature of the agreement
  • Scope of the architecture
  • Architecture and strategic principles and requirements
  • Conformance requirements
  • Architecture development and management process and roles
  • Target architecture measures
  • Defined phases of deliverables
  • Prioritized joint work plan
  • Time Window(s)
  • Architecture delivery and business metrics
Business Users’ Architecture Contract Content
  • Introduction and background
  • The nature of the agreement
  • Scope
  • Strategic requirements
  • Architecture deliverables that meet the business requirements
  • Conformance requirements
  • Architecture adopters
  • Time window
  • Architecture business metrics
  • Service architecture (including Service Level Agreement (SLA))
Relationship to Architecture Governance
  • Simple processes
  • People-centered authority
  • Strong communication
  • Timely responses and an effective escalation process
  • Supporting organizational structures
  • Status tracking of architecture implementation

Architecture Governance

Architecture governance is the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level.

  • Implementing a system of controls over the creation and monitoring of all architectural component and activities.
  • Implementing a system to ensure compliance with internal and external standards and regulatory obligations.
  • Establishing processes that support effective management of the above processes within agreed parameters.
  • Developing practices that ensure accountability to a clearly identified stakeholder community, both inside and outside the organization.
Levels of Governance within the Enterprise
  • Corporate Governance
  • Technology Governance
  • IT Governance
  • Architecture Governance
Characteristics of Governance
  • Discipline
    • All involved parties will have a commitment to adhere to procedures, processes and authority structures established by the organization.
  • Transparency
    • All actions implemented and their decision support will be available for inspection by authorized organization and provider parties.
  • Independence
    • All processes, decision-making and mechanisms used will be established so as to minimize or avoid potential conflicts of interest.
  • Accountability
    • Identifiable groups within the organization are authorized and accountable for their actions.
  • Responsibility
    • Each contracted party is required to act responsibly to the organization and it stakeholders.
  • Fairness
    • All decisions taken, processes used and their implementation will not be allowed to create unfair advantage to any one particular party.
Technology Governance
  • Controls how an organization utilizes technology in the research, development and production of its goods and services.
IT Governance
  • Provides the framework and structure that links IT resources and information to enterprise goals and strategies.

Architecture Governance Framework

Conceptual Structure
  • Context
    • Process
      • Policy Management & Take-on
      • Compliance
      • Dispensation
      • Monitoring & Reporting
      • Business Control
      • Environment Management
    • Content
      • Requirements
      • SLAs and OLAs
      • Authority Structures
      • Organizational Standards
      • Solutions
      • Architectures
    • Process Flow Control
    • Repository
Organizational Structure
  • Global Governance Board
  • Local Governance Board
  • Design Authorities
  • Working Parties
Key areas of Architecture Management
  • Develop
  • Implement
  • Deploy
Benefits of Architecture Governance
  • Links IT processes, resources and information to organizational strategies and objectives.
  • Integrates and institutionalizes IT best practices.
  • Aligns with industry frameworks.
  • Enables the organization to take full advantage of its information, infrastructure and hardware and software assets.
  • Protects the underlying digital assets of the organization.
  • Supports regulatory and best practice requirements such as audibility, security, responsibility and accountability.
  • Promotes visible risk management.

Architecture Maturity Models

Capability Maturity Models (CMMs) address this problem by providing an effective and proven method for an organization to gradually gain control over and improve its change processes.

Main Issues Addressed
  • Process implementation and audit
  • Quality measurements
  • People competencies
  • Investment management
Enterprise Architecture Process Levels
  • 0 – None
    • No enterprise architecture program. No enterprise architecture to speak of.
  • 1 – Initial
    • Informal enterprise architecture process underway.
  • 2 – Under Development
    • Enterprise architecture process is under development.
  • 3 – Defined
    • Defined enterprise architecture including detailed written procedures and TRM.
  • 4 – Managed
    • Managed and measured enterprise architecture process.
  • 5 – Optimizing
    • Continues improvement of enterprise architecture process.

Architecture Skills Framework

Categories of Skills
  • Generic Skills
  • Business Skills & Methods
  • Enterprise Architecture Skills
  • Program or Project Management Skills
  • IT General Knowledge Skills
  • Technical IT Skills
  • Legal Environment
Levels of Knowledge
  • 1 – Background
    • Not a required skill, though should be able to define and manage skill if required.
  • 2 – Awareness
    • Understand the background, issues and implications sufficiently to be able to understand how to proceed further and advise client accordingly.
  • 3 – Knowledge
    • Detailed knowledge of subject area and capable of providing professional advice and guidance. Ability to integrate capability into architecture design.
  • 4 – Expert
    • Extensive and substantial practical experience and applied knowledge on the subject.
Role of the Architect
  • Understand and interpret requirements
  • Create a useful model
  • Validate, refine and expand the model
  • Manage the architecture
Key Characteristics of an Enterprise Architect
  • Skills and Experience in Producing Designs
  • Extensive Technical Breadth with Technical Depth in One or a few Disciplines.
  • Method-Driven Approach to Execution
  • Full Project Scope Experience
  • Leadership
  • Personal and Professional Skills
  • Skills and Experience in One or More Industries

Articles in the Series

Table of contents
Article Tags
Getting Started SharePoint Office 365 Azure SQL Server Node.js IoT News Architecture Review Elixir Programming Elm