According to Gartner, Enterprise Architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating, and improving the key principles and models that describe the enterprise's future state and enable its evolution10 . DoDAF defines it as a set of abstractions and models that simplify and communicate complex structures, processes, rules, and constraints to improve understanding, implementation, forecasting, and resourcing

Why does DoDAF has an architecture framework?

DoDAF has an architecture framework because the US Department of Defense (DoD) recognised the need for a structured approach to manage its complex structures and information.

Here's a breakdown of why DoDAF has an architecture framework:

The **TOGAF Standard, Version 1, was originally based on the US Department of Defense Technical Architecture Framework for Information Management (TAFIM)**1 .... This indicates that the DoD, the entity behind what we now know as DoDAF, saw the value in having a technical architecture framework as early as 1995.

TAFIM was the result of significant development effort and investment by the US Government. This foundational work highlights the DoD's early understanding of the importance of a structured approach to architecture.

An overview of TOGAF

Think of TOGAF as a comprehensive and open framework for Enterprise Architecture (EA) it's a standard way of developing, approving, using, and looking after your Enterprise Architecture, it can be used across all sorts of EA work

Here's a quick rundown of the key bits:

• Framework for EA: At its heart, TOGAF provides the structure, methods, and tools you need to build and manage an effective Enterprise Architecture

• Standard Approach: It offers a consistent and repeatable way to tackle EA, ensuring that everyone's on the same page when it comes to development, approval, and ongoing maintenance

• Open and Consensus-Driven: TOGAF is an open standard, meaning it's publicly available and has been developed through the collaboration of industry experts within The Open Group

  Universally Applicable: It's designed to be relevant no matter the industry, size, or how fast things are changing in your organisation. Whether you're dealing with strategy, projects, digital transformation, or legacy systems, TOGAF's got you covered

Work in progress

Enterprise Architecture

Is needed to manage complexity when change involves multiple systems with multiple inter-dependencies.

Often key people identify areas of change required in order for new business goals to be met. Such people are commonly referred to as the "stakeholders" in the change. The role of the architect is to address their concerns by:

1 Identifying and refining the requirements of the stakeholders

2 Developing views of the architecture that show how the concerns and requirements are going to be addressed

3 Showing the trade-offs that are going to be made in reconciling the potentially conflicting concerns of different stakeholders

what's the role of an architect with vendors? #pending

Glossary of the TOGAF Nomenclature

Abstraction – The technique of providing summarised or generalised descriptions of detailed and complex content. It can also mean providing a focus for analysis concerned with a consistent and common level of detail or abstraction, which is useful for managing large and complex architectures by identifying relevant issues before detailing further [4.1, 579]. Architecture effort can be divided into four distinct abstraction levels: Contextual (why the architecture is needed, scope, motivation), Conceptual (what is needed to address the problem, often modelled using service models), Logical (how an architecture can be organised and structured in an implementation-independent way, identifying kinds of components), and Physical (with what physical components logical-level components can be realised, managing allocation and implementation of physical components) [3.7, 541-545].

Actor – A person, organisation, or system that has one or more roles that initiates or interacts with activities [4.2, 580]. Actors can be internal or external to an organisation [4.2, 580].

Agile – Refers to the ability to move/change quickly and easily, often to provide value-generating outcomes [1].

Agile Architecture – The "act" of developing architecture that reacts quickly and easily to changes through the delivery of iterative architectures that provide incremental value-generating outcomes. It also refers to the "thing" – an architecture that is flexible; i.e., easy to change or adapt [1, 2].

Agile Product Owner – A member of an Agile Product team responsible for defining user stories and prioritising the backlog, ensuring these are understood by other team members while maintaining the conceptual integrity of the features or components for the Delivery team [2].

Application Architecture – A description of the structure and interaction of the applications that provide key business capabilities and manage the data assets [4.3, 417, 580]. It provides a blueprint for individual applications, their interactions, and relationships to core business processes [3.3, 527].

Application Component – An encapsulation of application functionality aligned to implementation structure, which is modular and replaceable. It encapsulates its behavior and data, provides services, and makes them available through interfaces [4.4, 581].

Application Platform – The collection of technology components of hardware and software that provide the services used to support applications [4.5, 582].

Application Service – A discrete behavior requestable from an application; an automated element supporting or delivering part or all of one or more business services [4.6, 582].

Architect – A key role whose purpose is to identify and refine stakeholder requirements, develop views of the architecture to address concerns, and show trade-offs in reconciling conflicting concerns [3].

Architectural Style – The combination of distinctive features related to the specific context within which architecture is performed or expressed; a collection of principles and characteristics that steer or constrain how an architecture is formed [4.7, 582]. Styles differ in focus, form, techniques, materials, subject, and time period [4, 5].

Architecture –

1. The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution [4.8, 417, 525]. (Source: ISO/IEC/IEEE 42010:2011) [4.8, 525].

2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time [4.8, 417, 526].

Architecture Board – A decision-making framework responsible for operational items and for making decisions in situations of possible conflict. It typically comprises executives responsible for review and maintenance of the overall architecture, covering architecture, business, and program management areas [6-8].

Architecture Building Block (ABB) – An architectural component that specifies the required Solution Building Blocks (SBBs) at a more logical (or supplier-independent) level [4.9, 418, 583]. They capture architecture requirements (business, data, application, technology) and direct and guide the development and procurement of SBBs [7.13, 398].

Architecture Capability – The ability to develop, use, and maintain the architecture of a particular enterprise, and use the architecture to govern change [3.2, 40, 175]. It is conceptually similar to operating any function in the organisation and consists of both Enterprise Architecture-specific and general business activities [9].

Architecture Capability Iteration – A type of iteration within the ADM that supports the creation and evolution of the required Architecture Capability [10, 11]. This includes initial mobilisation by establishing or adjusting the architecture approach, principles, scope, vision, and governance [10-12].

Architecture Compliance – Guidelines for ensuring project compliance to the architecture [13]. Compliance assessments are periodic reviews of implementation projects to ensure design and implementation align with strategic and architectural objectives [14].

Architecture Content – A document describing the TOGAF Content Framework, a structured metamodel for architectural artifacts, and an overview of typical architecture deliverables, artifacts within deliverables, and the ABBs that artifacts represent [15-17].

Architecture Contracts – Joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture [7.18, 406]. They may occur at various stages of the ADM, such as Phase G: Implementation Governance [7.18, 406].

Architecture Continuum – A categorisation mechanism, with increasing detail and specialisation, for the components and artifacts stored in the Architecture Landscape or Reference Library (part of the Architecture Repository) [4.10, 418, 584]. It classifies architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures [18-20].

Architecture Definition Document – The deliverable container for the core architectural artifacts created during a project and for important related information [7.10, 381]. It spans all architecture domains (Business, Data, Application, Technology) and all relevant states (Baseline, Transition, Target) [7.10, 381]. It provides a qualitative view of the solution [7.10, 383].

Architecture Definition Increments Table – Used by the architect to plan a series of Transition Architectures outlining the status of the Enterprise Architecture at specified times, listing projects and their incremental deliverables across Transition Architectures [5.3.3.3, 43, 269].

Architecture Deliverables – Contractually specified work products that are formally reviewed, agreed upon, and signed off by stakeholders [21-23]. They often represent the output of projects and are typically archived or transitioned into an Architecture Repository as reference models, standards, or snapshots of the Architecture Landscape [21-23].

Architecture Development Iteration – A type of iteration within the ADM where projects may operate multiple ADM phases concurrently or cycle between phases to converge on a detailed Target Architecture [24-27].

Architecture Development Method (ADM) – The core of the TOGAF framework; an iterative, multi-phase approach to develop and use an Enterprise Architecture to shape and govern business transformation and implementation projects [28-34]. It provides a tested and repeatable process for developing architectures [31, 33, 35-37].

Architecture Domain – The architectural area being considered. TOGAF typically divides Enterprise Architecture into four primary domains: Business, Data, Application, and Technology [4.12, 43, 585].

Architecture Framework – A conceptual structure used to plan, develop, implement, govern, and sustain an architecture [4.13, 43, 459, 586]. It should include a method for describing baseline and target states, building blocks, and planning evolution [38].

Architecture Governance – The practice of monitoring and directing architecture-related work to deliver desired outcomes and adhere to relevant principles, standards, and roadmaps [4.14, 43, 301, 586]. It involves controlling and monitoring architecture components and activities at an enterprise-wide level [13, 39, 40].

Architecture Landscape – The architectural representation of assets in use, or planned, by the enterprise at particular points in time [4.15, 43, 419, 586]. It is likely to exist at multiple levels of abstraction [41].

Architecture Level – A framework for dividing the Architecture Landscape into levels of granularity, such as Strategic, Segment, and Capability Architecture [4.16, 44, 66, 287, 586].

Architecture Maturity Models – Techniques for evaluating and quantifying an organisation’s maturity in Enterprise Architecture [42]. They describe practices for process improvement, provide a yardstick for measurement, and offer a framework for managing improvement efforts [43].

Architecture Metamodel – Describes the organisationally tailored application of an architecture framework, including a metamodel for architecture content [41]. It defines the types of entities that appear in the models that describe the architecture, and the relationships between these entities [44-46].

Architecture Model – A representation of a subject of interest [4.17, 44, 587]. It provides a smaller scale, simplified, and/or abstract representation [4.17, 587].

Architecture Partitioning – The use of partitions to simplify the development and management of the Enterprise Architecture [5.4.4, 64, 97, 288]. Architectures are partitioned because organisational unit architectures conflict, different teams need to work concurrently, and effective re-use requires modular segments [47-49].

Architecture Principles – General rules and guidelines that relate to architecture work [7.3, 136, 363, 419, 547, 588]. They are intended to be enduring and seldom amended, influencing how an organisation fulfills its mission [50].

Architecture Project – An endeavour undertaken to define and describe the Enterprise Architecture to be implemented, encompassing all activities within ADM Phases A to F, and Requirements Management for these phases [51].

Architecture Project Management – Guidelines for TOGAF architects on how to manage an Architecture Project using an approach that supplements the TOGAF ADM with selected project management techniques [52].

Architecture Requirements Repository – A component of the Architecture Repository that provides a view of all authorised architecture requirements agreed with the Architecture Board [53].

Architecture Requirements Specification – A document providing a set of quantitative statements that outline what an implementation project must do to comply with the architecture [7.11, 391]. It offers a quantitative view of the solution, stating measurable criteria for compliance [7.10, 383].

Architecture Roadmap – Lists individual work packages that will realise the Target Architecture and lays them out on a timeline, showing progression from Baseline to Target Architecture [7.12, 396]. It is incrementally developed throughout Phases E and F [7.12, 396].

Architecture Repository – A structural framework for an Architecture Repository that allows an enterprise to distinguish between different types of architectural assets that exist at different levels of abstraction [18, 54-58]. It is used to store different classes of architectural output created by the ADM [58].

Architecture Skills Framework – Provides a set of role, skill, and experience norms for staff undertaking Enterprise Architecture work [52, 59].

Architecture Vision – Provides a high-level summary of the changes to the enterprise that will follow from the successful deployment of the Target Architecture [7.7, 140, 375]. Its purpose is to agree on the desired outcome at the outset [7.7, 375].

Architecture View – A representation of a system from the perspective of a related set of concerns [4.20, 44, 420, 575, 588].

Architecture Viewpoint – A specification of the conventions for a particular kind of architecture view [4.21, 44, 420, 575, 589]. It acts as a schema for that view, establishing conventions for its construction, interpretation, and use [4.21, 589].

Artifact – An architectural work product that describes an aspect of the architecture [60-64]. Artifacts are generally classified as catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things) [60, 61, 65].

Backlog – An ever-evolving list of requirements, prioritised by stakeholders, that conveys to an Agile team which requirements to handle first [62].

Baseline – A specification that has been formally reviewed and agreed upon, serving as the basis for further development or change, and which can only be changed through formal change control procedures [64, 66].

BDUF (Big Design Up Front) – A concept in architecture planning, generally to be avoided, where too much detail is explored too soon without the benefit of feedback from delivery sprints [67].

Boundaryless Information Flow™ – A shorthand for "access to integrated information to support business process improvements", representing a desired state of an enterprise’s infrastructure specific to its business needs [4.25, 45, 591].

Building Block – A potentially re-usable component of business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions [60, 61, 65, 66, 68]. They can be defined at various levels of detail [60, 65].

Business Architecture – A representation of holistic, multi-dimensional business views of capabilities, end-to-end value delivery, information, and organisational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders [4.27, 46, 421, 593].

Business Capability – A particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome [4.28, 50, 194, 422, 594]. It delineates what a business does without explaining how, why, or where [69].

Business Capability Model – Represents the currently active, stable set of business capabilities (and their defining characteristics) that cover the business, enterprise, or organisational unit [70]. The end product is typically a Business Capability Map [71].

Business Change Backlog – The top-level backlog typically employed in business change design and development [62].

Business Function – A collection of business behavior based on a chosen set of criteria, closely aligned to an organisation [4.29, 46, 594].

Business Governance – Concerned with ensuring that the business processes and policies (and their operation) deliver the business outcomes and adhere to relevant business regulation [4.30, 46, 594].

Business Model – A description of the rationale for how an organisation creates, delivers, and captures value [4.31, 50, 192, 46, 594]. They provide a basis for establishing common understanding and discussions around business innovation and strategy planning [72].

Business Principles, Goals, and Drivers – Usually defined elsewhere in the enterprise, these are re-stated as an output of the Preliminary Phase and reviewed in Phase A: Architecture Vision, ensuring correctness and clarity [7.4, 138, 371].

Business Scenarios – A technique to help identify and understand the business requirements that an architecture must address [73, 74]. A good business scenario represents a significant business need or problem and enables understanding of the solution's value [74].

Business Service – Supports the business by encapsulating a unique "element of business behavior" [4.32, 46, 595]. A service offered externally may be supported by business services [75].

Business System – Hardware, software, policy statements, processes, activities, standards, and people which together implement a business capability [B.3, 61, 625].

Business Transformation Readiness Assessment (BTRA) – A technique for identifying business transformation issues [76]. It provides a quantifiable measurement for an organisation's preparedness for Digital Transformation and identifies gaps [77, 78].

Business Value Assessment Matrix – A matrix based on a value index dimension and a risk index dimension, used to assess the business value of a project [5.3.3.5, 47, 89, 271].

Capability – An ability that an organisation, person, or system possesses [4.33, 46, 422, 595].

Capability Architecture – A highly detailed description of the architectural approach to realise a particular solution or solution aspect [4.34, 47, 422, 595]. It provides an organising framework for change activity and effective architecture roadmaps realising capability increments [16, 48].

Capability Increment – A discrete portion of a capability architecture that delivers specific value [4.35, 47, 422, 596]. When all increments are completed, the capability is realised [4.35, 422].

Capability Assessment – An assessment, first carried out in Phase A and updated in Phase E, to understand the baseline and target capability level of the enterprise [7.9, 141, 378]. It typically includes Business, IT, Architecture Maturity, and Business Transformation Readiness Assessments [7.9, 378-381].

Catalog – A structured list of architectural outputs of a similar kind, used for reference [B.4, 61, 625]. Examples include a requirements catalog or an application portfolio [B.4, 625].

Change Request – A request submitted to kick-start a further cycle of architecture work when original architecture definition/requirements are unsuitable, or when external factors create new opportunities [7.19, 410]. Considered in Phase H: Architecture Change Management [7.19, 410].

Client – An application component which requests services from a server [B.5, 61, 625].

C-MDM (Customer Master Data Management) – An approach for implementing Customer Master Data Management in an organisation, covering people, processes, organisations, and systems to manage customer master data as an asset [4.3.2, 64, 217-218]. Its purpose is to increase the value of customer information shared across the organisation [79].

CMM (Capability Maturity Model) – More formally known as Architecture Maturity Models, these provide an effective method for an organisation to gradually gain control over and improve its change processes [43, 80].

COBIT – An acronym for Control OBjectives for Information and related Technology, providing a set of recommended best practices for the governance/management of information systems and technology [B.6, 61, 625].

Commercial Aviation Reference Architecture – Reference material developed by The Open Group and included in the TOGAF Library, which organisations can adopt or use as examples [81, 82].

Communications and Stakeholder Management – The management of needs of stakeholders of the Enterprise Architecture practice, and the execution of communication between the practice and stakeholders/consumers [4.36, 34, 596].

Communications Plan – A deliverable developed in Phase A that allows for effective communication of targeted information to stakeholders within a planned and managed process [7.8, 141, 376].

Compliance Assessment – A deliverable in Phase G, where periodic reviews of implementation projects ensure design and implementation align with strategic and architectural objectives and feed lessons learned back into the architecture process [7.20, 156, 412].

Concern – An interest in a system relevant to one or more of its stakeholders [4.37, 47, 597]. Concerns may pertain to any aspect of the system’s functioning, development, or operation [4.37, 597].

Configuration Management – A discipline applying technical and administrative direction and surveillance to identify, document, control, and report changes to functional and physical characteristics of a configuration item [B.7, 626]. It also covers managing intellectual property assets and baselines of the Enterprise Architecture practice [B.7, 626].

Consolidated Gaps, Solutions, and Dependencies Matrix – Used by the architect to group identified gaps from domain architecture gap analysis results and assess potential solutions and dependencies [5.3.3.2, 42, 87, 268].

Content Framework – A categorisation framework used to structure the Architecture Description and the models that describe an architecture [83, 84]. It defines how building blocks and artifacts reflect decisions in creating architecture deliverables [84]. The TOGAF Content Framework is intended to provide a detailed model of architectural work products, drive consistency, offer a checklist, reduce gaps, and help mandate standard concepts [85-88].

Contextual Abstraction Level – Focuses on understanding the environment in which an enterprise operates and the context for architecture work. It answers why architecture is needed, its scope, and motivations [3.7.1, 542].

Conceptual Abstraction Level – Centred on decomposing requirements to understand the problem and what is needed, without focusing on how it will be realised. Usually modelled using service models [3.7.2, 543].

Course of Action – Direction and focus provided by strategic goals and objectives, often to deliver the value proposition characterised in the business model [4.38, 597].

CSF (Critical Success Factor) – A way to quantify factors crucial for success [422, B.14, 639].

CFO – Chief Financial Officer [B.8, 626].

CIO – Chief Information Officer [B.8, 626].

COTS (Commercial Off-The-Shelf) – Refers to commercially available products that are purchased rather than custom-developed [89].

CxO – The chief officer within a particular function of the business; e.g., Chief Executive Officer, Chief Financial Officer, Chief Information Officer, Chief Technology Officer [B.8, 626].

Data Architecture – A description of the structure of the enterprise’s major types and sources of data, logical data assets, physical data assets, and data management resources [4.39, 47, 422, 588].

Data Dictionary – A specialised type of database containing metadata; a repository of information describing the characteristics of data [B.9, 627].

Database – A structured or organised collection of data entities, to be accessed by a computer [B.11, 627].

Database Management System – A computer application program that accesses or manipulates the database [B.12, 628].

Data Element – A basic unit of information having a meaning and that may have subcategories (data items) of distinct units and values [B.10, 627].

DBRM (Digital Business Reference Model) – An industry-independent outline of common core components that are essential building blocks for the modern digital enterprise [90, 91]. It enables organisations to develop appropriate digital architecture blueprints [90].

Deliverable – An architectural work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders [71, 295, 4.40, 537, 598]. Deliverables represent the output of projects [21, 22].

Digital Architecture – The inclusive architecture focused on a combination of Enterprise Architecture, data science, telecommunications and IoT, security, artificial intelligence, cognitive science, neuroscience, robotics, and social medias to deliver operational services [4.41, 48, 599].

Digital Transformation Readiness Assessment (DTRA) – A technique to assess how ready an enterprise is for changes related to digital technology adoption [77, 91].

DPBoK (Digital Practitioner Body of Knowledge) Standard – A standard from The Open Group that identifies four contexts of organisational evolution of a digital enterprise: Individual/Founder, Team, Team of Teams, and Enduring Enterprise [91-93].

DTRA (Digital Transformation Readiness Assessment) – See Business Transformation Readiness Assessment.

End User – A person who ultimately uses the computer application or output [B.13, 628].

Enterprise – Any collection of organisations that have common goals [449, 4.42, 495, 599]. It typically represents the highest level of description of an organisation and can span multiple organisations, including partners, suppliers, and customers [450, 4.42, 496, 599].

Enterprise Agility – Refers to an enterprise's ability to better react to change by being more customer and product-centric, more efficient, and better able to ensure regulatory compliance [47, 94].

Enterprise Architecture – The process of translating business vision and strategy into effective enterprise change by creating, communicating, and improving the key principles and models that describe the enterprise’s future state and enable its evolution [91]. It provides a strategic context for the evolution and reach of digital capability [95, 96].

Enterprise Architecture Capability and Governance – A document providing resources, guidelines, templates, and background information to help establish an architecture practice and governance framework within an organisation [97, 98].

Enterprise Architecture Service – An encapsulated element of Enterprise Architecture capability that delivers specific Enterprise Architecture functionality [4.43, 49, 599]. These services are often provided through a service delivery model and address specific needs independent of an organisation’s operating model [3.5, 532]. Categories include Enterprise Support, Design Support, Development Support, Requirements Elicitation and Understanding, Architecture Planning, and EA Practice Development Support Services [3.5, 532-535].

Enterprise Continuum – A categorisation mechanism for classifying architecture and Solution Building Blocks (SBBs) as they evolve from generic to specific applicability (or vice versa) [4.44, 49, 424, 551, 600]. It comprises the Architecture Continuum and the Solutions Continuum [18-20].

Enterprise Principles – Provide a basis for decision-making throughout an enterprise, and inform how the organisation sets about fulfilling its mission [99].

Enterprise Resource Planning (ERP) System – A complete suite of integrated applications that support the major business support functions of an organisation [B.14, 639].

Enterprise Risk Management (ERM) – Aids decision-making by taking account of uncertainty and the possibility of future events or circumstances (intended or unintended) and their effects on agreed objectives [100-102].

ERD (Entity Relationship Diagram) – A type of diagram that can be used to formally model information maps [102, 103].

Framework – A structure for content or process that can be used as a tool to structure thinking, ensuring consistency and completeness [4.46, 49, 425, 600].

Foundation Architecture – Generic building blocks, their inter-relationships with other building blocks, combined with the principles and guidelines that provide a foundation on which more specific architectures can be built [4.45, 49, 424, 600].

Gap – A statement of difference between two states [4.47, 49, 425, 601]. Used in gap analysis to highlight shortfalls between Baseline and Target Architectures [5.3.2, 85, 263, 4.47, 601].

Gap Analysis – A technique typically used as the final step within an ADM phase, to highlight a shortfall between the Baseline Architecture and the Target Architecture [5.3.2, 85, 263].

Governance – The discipline of monitoring, managing, and steering a business (or Information Systems/Information Technology (IS/IT) landscape) to deliver the business outcome required [4.48, 49, 425, 601].

Government Reference Model (GRM) – A standard reference model template that can be used to describe any business in the public sector [42, 104]. It gives public sector organisations a common way to view themselves for planning and executing transformational change [42, 105].

Hardware – The physical infrastructure needed to run software; e.g., servers, workstations, network equipment [B.15, 639].

Implementation and Migration Plan – A deliverable developed in Phases E and F, providing a schedule of projects for implementing the Target Architecture [7.15, 151, 402]. It includes executable projects grouped into portfolios and programs [7.15, 402].

Implementation Factor Catalog – Used to document factors impacting the architecture Implementation and Migration Plan [5.3.3.1, 40, 86, 266]. Typical factors include risks, issues, assumptions, dependencies, actions, and impacts [5.3.3.1, 266].

Implementation Governance Model – Produced as an output of Phase F, ensuring that a project transitioning into implementation also smoothly transitions into appropriate Architecture Governance (for Phase G) [7.17, 153, 406].

Information – Any communication or representation of facts, data, or opinions, in any medium or form [4.49, 601-602].

Information Architecture – A domain within Enterprise Architecture that could be defined by combining appropriate views of Business, Data, Application, and Technology domains [33].

Information Domain – Grouping of information (or data entities) by a set of criteria such as security classification, ownership, location [B.16, 630].

Information Map – A collection of information concepts and their relationships to one another [106]. It provides a means to articulate, characterise, and visually represent information critical to the business [106].

Information Mapping – A TOGAF Series Guide that describes how to develop an information map that articulates, characterises, and visually represents information critical to the business [107].

Information Security Management (ISM) – A process that defines security objectives, assigns ownership of information security risks, and supports the implementation of security measures [108-110].

Information System (IS) – The computer (or IT)-based portion of a business system [B.17, 630].

Information Systems Architectures – Developed in Phase C, this section covers both Data and Application Architectures, including their Baseline and Target states [7.10.2, 388].

Information Technology (IT) – The lifecycle management of information and related technology used by an organisation [4.50, 602].

Integration Architecture – An architectural style that can be described using TOGAF [111].

Intentional Architecture – Specifies a set of purposeful, planned architectural strategies and initiatives to enhance solution design, performance, and usability, and providing guidance for inter-team design and implementation synchronisation [112, 113].

Interaction – A relationship between architectural building blocks (i.e., services or components) that embodies communication or usage [B.18, 630].

Interaction Model – An architectural view, catalog, or matrix that shows a particular type of interaction [B.19, 630].

Interface – Interconnection and inter-relationships between, for example, people, systems, devices, applications, or the user and an application or device [B.20, 630].

Interoperability – The ability to share information and services [4.51, 25, 49, 548, 602]. It can be categorised as Operational/Business, Information, or Technical Interoperability [114].

Interoperability Requirements – Requirements for determining interoperability are present throughout the ADM cycle, from initial revelation in Phase A to logical implementation in Phase F [89, 115].

Iteration – A key concept used to manage the complexity of developing an Enterprise Architecture and managing its lifecycle, along with levels [116, 117]. The ADM supports iteration to develop a comprehensive Architecture Landscape, within an ADM cycle, and to manage the Architecture Capability [118-120].

IT4IT™ Reference Architecture – A reference architecture developed by The Open Group and included in the TOGAF Library, which organisations can adopt or use as examples [81, 82, 121].

Key Performance Indicator (KPI) – A way of quantifying the performance of the business or project [B.21, 630].

Lifecycle – The period of time that begins when a system is conceived and ends when the system is no longer available for use [B.22, 630].

Logical Abstraction Level – Focuses on identifying the kinds of business, data, application, and technology components needed to achieve services, and how an architecture can be organised and structured in an implementation-independent fashion [3.7.3, 544].

Managing Successful Programs (MSP) – A best practice methodology for program management, developed by the UK Office of Government Commerce (OGC) [B.23, 631].

Matrix – A format for showing the relationship between two (or more) architectural elements in a grid format [B.24, 64, 631].

Metadata – Data about data, of any sort in any media, that describes the characteristics of an entity [4.53, 603].

Metamodel – A model that describes the entities used in building an Architecture Description, their characteristics, and the key relationships between those entities [4.54, 49, 603].

Metaview – A pattern or template of the view, from which to develop individual views [B.25, 64, 631]. It establishes the purposes and audience for a view, how it's documented, and how it's used [B.25, 631].

Method – A defined, repeatable approach to address a particular type of problem [4.55, 603].

Migration Planning Techniques – A collection of techniques defined in the TOGAF Standard to support migration planning in Phases E and F of the ADM [5.3.3, 40, 86, 266].

Minimum Viable Architecture (MVA) – The minimum (Enterprise) Architecture that is realisable and adds business value [110]. An architecture that enables the delivery of product features with just enough content to be deployed and satisfy known requirements [110].

Minimum Viable Business Development (MVBD) – The minimum set of business change that delivers significant value to the stakeholders [122].

Minimum Viable Product (MVP) – An output that satisfies a minimum set of functional and non-functional requirements and can be realised when implemented in a live operational environment [122].

Modeling – A technique through construction of models which enables a subject to be represented in a form that enables reasoning, insight, and clarity concerning the essence of the subject matter [4.56, 604].

Model Kind – Conventions for a type of modeling [4.57, 604]. An architecture viewpoint references one or more model kinds; an architecture view incorporates one or more models [4.57, 604].

Objective – An organisational aim that is declared in a Specific, Measurable, Actionable, Realistic, and Timebound (SMART) way [4.58, 604].

Open System – A system that implements sufficient open specifications for interfaces, services, and supporting formats to enable properly engineered application software to be portable, interoperate, and interact with users in a way that facilitates user portability [B.26, 64, 632].

O-PAS™ Standard – A standard developed by The Open Group and included in the TOGAF Library, presented as a reference architecture [81, 82].

Operational Governance – The operational performance of systems against contracted performance levels, the definition of operational performance levels, and the implementation of systems that ensure effective operation of systems [B.27, 64, 632].

Organisation Map – A Business Architecture blueprint that shows the main organisational units, partners, and stakeholder groups that comprise an enterprise's ecosystem, and the working relationships between them [123].

Organisation Mapping – A TOGAF Series Guide that shows how organisation mapping provides the organisational context to an Enterprise Architecture [107].

Organisational Model for Enterprise Architecture – An important deliverable produced in the Preliminary Phase, defining the organisation, roles, and responsibilities needed for an architecture framework to be used successfully [7.2, 161-162, 361].

Packaged Services – Services that are acquired from the market from a Commercial Off-The-Shelf (COTS) vendor, rather than being constructed via code build [B.28, 633].

Pattern – A technique for putting building blocks into context; for example, to describe a re-usable solution to a problem [4.60, 605].

Physical Abstraction Level – Manages the allocation and implementation of physical components to meet identified logical components. It determines with what physical components logical-level components can be realised [3.7.4, 545].

Portability – The ease with which a system, component, data, or user can be transferred from one hardware or software environment to another [B.29, 633]. Also, the capability to grow to accommodate increased work loads [B.35, 635].

Portfolio – A collection of programs, projects, and/or operations managed as a group to achieve strategic objectives [B.30, 65, 634].

Practitioner – The person tasked to develop, maintain, and use an Enterprise Architecture [122].

PRINCE2 – An acronym for PRojects IN Controlled Environments, which is a standard project management method [B.31, 65, 634].

Product – An outcome generated by the business to be offered to customers; products include materials and/or services [4.62, 46, 428, 605].

Program – A co-ordinated set of change projects that deliver business benefit to the organisation [B.32, 65, 634].

Project – A single change project which delivers business benefit to the organisation [B.33, 65, 634].

Project Management – The planning, delegating, monitoring, and control of all aspects of the project, and the motivation of those involved to achieve objectives within expected performance targets [124].

Reference Library – A component of the Architecture Repository that provides guidelines, templates, patterns, and other forms of reference material that can be leveraged to accelerate the creation of new architectures [53]. The TOGAF Library is an example of such a library [125].

Reference Model (RM) – An abstract framework for understanding significant relationships among entities and for the development of consistent standards or specifications [4.63, 606]. It is based on unifying concepts and can be used for education and explaining standards [4.63, 606].

Repository – A system that manages all of the data of an enterprise, including data and process models and other enterprise information [124].

Request for Architecture Work – A document sent from the sponsoring organisation to the architecture organisation to trigger the start of an architecture development cycle [7.5, 139, 372].

Requirement – A statement of need, which is unambiguous, testable or measurable, and necessary for acceptability [4.64, 51, 607].

Requirements Impact Assessment – Assesses current architecture requirements and specifications to identify changes that should be made and the implications of those changes [7.21, 157, 413-414].

Requirements Management – The process of managing architecture requirements throughout the ADM, applying to all phases of the ADM cycle [126, 127]. It is central to driving the ADM process [127, 128].

Risk – The "effect of uncertainty on objectives" (ISO 31000:2009) [129, 130]. The effect of uncertainty is any deviation from what is expected (positive or negative) [130].

Risk Management – A technique used to mitigate risk when implementing an architecture project [5.3.4, 47, 89, 272]. It includes classification, identification, initial assessment, mitigation, residual assessment, and monitoring [5.3.4, 272-273].

Roadmap – An abstracted plan for business or technology change, typically operating across multiple disciplines over multiple years [4.65, 51, 607].

Role – The usual or expected behavior of an actor, or the part somebody or something plays in a particular process or event [4.66, 51, 607].

Runways – A concept in Agile Enterprise Architecture, similar to guardrails, providing guidance for implementation [44].

Scalability – The ability to use the same application software on many different classes of hardware/software platforms (extends the portability concept) and the capability to grow to accommodate increased work loads [B.35, 65, 635].

Security – Services which protect data, ensuring its confidentiality, availability, and integrity [B.36, 66, 636].

Security Architecture – A structure of organisational, conceptual, logical, and physical components that interact in a coherent fashion to achieve and maintain a state of managed risk and security (or information security) [131]. It is a cross-cutting concern pervasive through the whole Enterprise Architecture [132, 133].

Segment Architecture – A detailed, formal description of areas within an enterprise, used at the program or portfolio level to organise and align change activity [4.67, 51, 66, 287, 430, 608].

Server – An application component which responds to requests from a client [B.37, 66, 636].

Service – An encapsulated element of behavior that provides specific functionality in response to requests from actors or other services [4.68, 52, 608]. It has an interface and description [4.68, 608].

Service-Orientation – Viewing an enterprise, system, or building block in terms of services provided and consumed [4.69, 52, 608].

Service-Oriented Architecture (SOA) – An architectural style that supports service-orientation [4.70, 52, 430, 609].

Service Portfolio – A collection of services, potentially an interface definition [4.71, 52, 609]. It is used in TOGAF to define requirements for a building block or system [4.71, 609].

Service Quality – A preset configuration of non-functional attributes that may be assigned to a service or service contract [B.38, 66, 636].

SLA (Service-Level Agreement) – A formal agreement about the level of service provided [134].

SMART – An acronym for Specific, Measurable, Actionable, Realistic, and Timebound, an approach to ensure targets and objectives are set in a way that can be achieved and measured [B.39, 66, 636].

Solution Architecture – A description of a discrete and focused business operation or activity and how IS/IT supports that operation [4.72, 52, 431, 609].

Solution Building Block (SBB) – A physical or implementation-specific component that realises part or all of one or more logical Architecture Building Blocks (ABBs) [4.73, 52, 431, 610]. They are implementation choices of the architectures [7.14, 400].

Solutions Continuum – A categorisation mechanism, with increasing detail and specialisation, for the components and artifacts stored in the Solutions Landscape or Reference Library (part of the Architecture Repository) [4.74, 52, 431, 610].

Sprint – A short, time-boxed period, at the very heart of Agile methodologies, when an Agile team works to complete a set amount of work supporting the delivery of a working solution [135].

Sprint Backlog – A backlog created by each Agile team working on a sprint [62].

Stakeholder – An individual, team, organisation, or class thereof, having an interest in a system [4.75, 53, 432, 610].

Stakeholder Management – An important discipline that architects use to win support for their projects by identifying key players early, shaping the architecture with their input, and communicating effectively [5.3.1, 84, 261-262].

Standards Library – A component of the Architecture Repository that captures the standards with which new architectures must comply [553, 4.76, 611].

Statement of Architecture Work – A deliverable created in Phase A, effectively a contract between the architecting organisation and the sponsor of the Architecture Project [7.6, 139, 374]. It responds to the Request for Architecture Work [7.6, 374].

Strategic Architecture – A summary formal description of the enterprise, providing an organising framework for operational and change activity, and an executive-level, long-term view for direction setting [4.77, 53, 66, 287, 432, 611].

Structure of the TOGAF Documentation – The TOGAF documentation set is structured to address the transition from common universal concepts to unique organisational configuration, including the formal TOGAF Standard and the TOGAF Library [136, 137]. It is modular with a clear hierarchy from universal concepts (Fundamental Content) to stable best practices (Series Guides) to emerging ideas (Library) [138, 139].

Supplier Management – The management of suppliers of products and services to the Enterprise Architecture practice in concert with larger corporate procurement activities [B.40, 66, 637].

Sustaining Factors – Factors that enable the institutionalisation of the adoption of digital technologies for sustained long-term benefits [140].

System – A combination of interacting elements organised to achieve one or more stated purposes [B.41, 66, 637]. (Source: ISO/IEC/IEEE 15288:2015) [B.41, 637].

TAFIM (Technical Architecture Framework for Information Management) – The US Department of Defense framework that formed the basis for the original development of TOGAF Version 1 in 1995 [28, 141-144].

Tailored Architecture Framework – A deliverable produced in the Preliminary Phase that involves customising the TOGAF framework for integration into the enterprise and for specific Architecture Projects [7.1, 132, 360].

Target Architecture – The description of a future state of the architecture being developed for an organisation [4.78, 53, 432, 611].

Technical Reference Model (TRM) – A structure which allows the components of an information system to be described in a consistent manner [142].

Technology Architecture – A description of the structure and interaction of the technology services and technology components [4.80, 53, 16, 390, 432, 589]. It describes the digital architecture and the logical software and hardware infrastructure capabilities and standards required to support business, data, and application services [3.3, 527].

Technology Component – A technology building block; a generic infrastructure technology that supports and enables application or data components [4.81, 53, 612].

Technology Service – A technical capability required to provide enabling infrastructure that supports the delivery of applications [4.82, 54, 613].

The Open Group – A global consortium that enables the achievement of business objectives through technology standards [145, 146]. Its mission is to drive the creation of Boundaryless Information Flow™ [145, 146].

Time Period – The timeframe over which the potential impact is to be measured [B.42, 66, 637].

TOGAF Content Framework – See Content Framework.

TOGAF Documentation Set – Comprises the formal TOGAF Standard and a broader body of knowledge in the TOGAF Library [136, 137, 147].

TOGAF Framework – Reflects the structure and content of an Architecture Capability within an enterprise [29, 148]. It is based on an iterative process model supported by best practices and reusable architectural assets [28, 149].

TOGAF Fundamental Content – Provides universal concepts of Enterprise Architecture [150-154]. It consists of six documents: Introduction and Core Concepts, Architecture Development Method, ADM Techniques, Applying the ADM, Architecture Content, and Enterprise Architecture Capability and Governance [15, 35, 151, 153-158].

TOGAF Library – A reference library containing additional resources and guidance material such as emerging ideas, guidelines, templates, patterns, and other forms of reference material to accelerate the creation of new architectures for the enterprise [125, 147, 158-162]. It complements the formal TOGAF Standard and is part of the broader TOGAF documentation set [136, 137, 147, 161].

TOGAF Series Guides – Consist of a series of best practice documents that build upon the Fundamental Content by providing extended guidance for specific topics, concerns, and use-cases [154, 163, 164]. They represent proven, stable, best practices [159, 160].

TOGAF Standard – An open, industry consensus framework for Enterprise Architecture [149, 165-167]. It is a standard approach for developing, approving, using, and maintaining Enterprise Architectures [28, 149]. It applies to all Enterprise Architecture practices [28, 36].

Transition Architecture – A formal description of one state of the architecture at an architecturally significant point in time [4.83, 54, 152, 404, 433, 613]. It shows the enterprise at an architecturally significant state between the Baseline and Target Architectures [7.16, 404].

Transition Architecture State Evolution Table – Used by the architect to show the proposed state of the architectures at various levels using the defined taxonomy for the enterprise [5.3.3.4, 45, 88, 269].

Transition Planning Iteration – A type of iteration within the ADM that supports the creation of formal change roadmaps for a defined architecture [12, 168].

Use-Case – A view of organisation, application, or product functionality that illustrates capabilities in context with the user of that capability [B.43, 66, 637].

User – Any person, organisation, or functional unit that uses the services of an information processing system [B.44, 67, 638].

Value Stream – An end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end user [4.84, 54, 55, 200, 433, 614].

Value Stream Stages – The sequential and/or parallel actions within a value stream that incrementally create and add stakeholder value from one stage to the next [169].

View – See Architecture View.

Viewpoint – See Architecture Viewpoint.

Viewpoint Library – A collection of the specifications of architecture viewpoints contained in the Reference Library portion of the Architecture Repository [4.88, 614].

Work Package – A set of actions identified to achieve one or more objectives for the business [170, 171]. A work package can be a part of a project, a complete project, or a program [170, 171].

Glossary

DoDAF: Department of Defense Architecture Framework