Notes on The DoDAF Architecture Framework Version 2.02
1. Original Spec Links
- DODAF Home
- Background
- Architectural Development
- Meta Model
- Viewpoints & Models
- All Viewpoint
- Capability Viewpoint
- Data and Information Viewpoint
- Operational Viewpoint
- Project Viewpoint
- Services Viewpoint
- Standards Viewpoint
- Systems Viewpoint
- Models
- Model Categories
- Levels of Architecture
- Architecture Interrogatives
- Architecture Modeling Primitives
- Mapping to DM2
- All Viewpoint
- Presentation Techniques
- DODAF-DM2 Configuration Management
- IDEAS
- Related Links
- Acronyms List and Glossary of Terms
- Site Map
- Archives
2. Background
2.1. Introduction
“DoDAF V2.0 focuses on architectural “data”, rather than on developing individual “products” as described in previous versions.”
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_background/#:~:text=DoDAF%20V2.0%20focuses%20on%20architectural%20%22data%22%2C%20rather%20than%20on%20developing%20individual%20%22products%22%20as%20described%20in%20previous%20versions.
“Visualizing architectural data is accomplished through models (e.g., the products described in previous versions of DoDAF). Models can be documents, spreadsheets, dashboards, or other graphical representations and serve as a template for organizing and displaying data in a more easily understood format. When data is collected and presented as a “filled-in” model, the result is called a view. Organized collections of views (often representing processes, systems, services, standards, etc.) are referred to as viewpoints, and with appropriate definitions are collectively called the Architectural Description.”
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_background/#:~:text=Visualizing%20architectural%20data,Architectural%20Description.
“DoDAF V2.0 discusses DoDAF-described Models and Fit-for-Purpose Views:
DoDAF-described Models (also referred to as Models) are created from the subset of data for a particular purpose. Once the DoDAF-described Models are populated with data, these “views” are useful as examples for presentation purposes, and can be used as described, modified, or tailored as needed.
Fit-for-Purpose Views are user-defined views of a subset of architectural data created for some specific purpose (i.e., “Fit-for-Purpose”)”
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_background/#:~:text=DoDAF%20V2.0%20discusses,Fit%2Dfor%2DPurpose%22)
“The DM2 replaces the Core Architecture Data Model (CADM) which supported previous versions of the DoDAF. DM2 is a data construct that facilitates reader understanding of the use of data within an architecture document”
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_background/#:~:text=The%C2%A0DM2%20replaces%20the%20Core%20Architecture%20Data%20Model%20(CADM)%20which%20supported%20previous%20versions%20of%20the%20DoDAF.%C2%A0DM2%20is%20a%20data%20construct%20that%20facilitates%20reader%20understanding%20of%20the%20use%20of%20data%20within%20an%20architecture%20document
“DoDAF V2.0 is a marked change from earlier versions of Command, Control, Communications, Computers, and Intelligence Surveillance Reconnaissance Architecture Framework (C4ISR AF) or DoDAF, in that architects now have the freedom to create enterprise architectures to meet the demands of their customers. The core of DoDAF V2.0 is a data-centric approach where the creation of architectures to support decision-making is secondary to the collection, storage, and maintenance of data needed to make efficient and effective decisions.”
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_background/#:~:text=DoDAF%20V2.0%20is,and%20effective%20decisions.
Architecture views are organized into viewpoints
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_background/#:~:text=Architecture%20views%20are%2C%20in%20turn%2C%20organized%20into%20viewpoints
DoDAF Meta-model (DM2) contains a Conceptual Data Model (CDM), a Logical Data Model (LDM), and a Physical Exchange Specification (PES)”
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_background/#:~:text=DoDAF%20Meta%2Dmodel%20(DM2)%2C%20containing%20a%20Conceptual%20Data%20Model%20(CDM)%2C%20a%20Logical%20Data%20Model%20(LDM)%2C%20and%20a%20Physical%20Exchange%20Specification%20(PES)
2.2. Six Core Processes DoDAF Supports:
JCIDS, the DAS, SE, PPBE, Net-centric Integration, and PfM
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_background/#:~:text=JCIDS%2C%20the%20DAS%2C%20SE%2C%20PPBE%2C%20Net%2Dcentric%20Integration%2C%20and%20PfM
2.2.1. Joint Capability Integration and Development System
The primary objective of the JCIDS process is to ensure warfighters receive the capabilities required to execute their assigned missions successfully. JCIDS defines a collaborative process that utilizes joint concepts and integrated Architectural Descriptions to identify prioritized capability gaps and integrated joint Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel, and Facilities (DOTMLPF) and policy approaches (materiel and non-materiel) to resolve those gaps”
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_background/#:~:text=Joint%20Capability%20Integration,resolve%20those%20gaps
2.2.2. Defense Acquisition System
The DAS exists to manage the nation’s investments in technologies, programs, and product support necessary to achieve the National Security Strategy and support employment and maintenance of the United States Armed Forces”
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_background/#:~:text=Defense%20Acquisition%20System,States%20Armed%20Forces
2.2.3. Systems Engineering
DoD Acquisition policy directs all programs responding to a capabilities or requirements document, regardless of acquisition category, to apply a robust SE approach that balances total system performance and total cost with the family-of-systems, and system-of-systems context. Programs develop a Systems Engineering Plan (SEP) for Milestone Decision Authority (MDA) that describes the program’s overall technical approach, including activities, resources, measures (metrics), and applicable performance incentives”
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_background/#:~:text=Systems%20Engineering,applicable%20performance%20incentives
2.2.4. Planning, Programming, Budgeting, and Execution
The PPBE process allocates resources within the DoD and establishes a framework and process for decision-making on future programs. PPBE is a systematic process that guides DoD’s strategy development, identification of needs for military capabilities, program planning, resource estimation, and allocation, acquisition, and other decision processes. JCIDS is a key supporting process for PPBE, providing prioritization and affordability advice”
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_background/#:~:text=Planning%2C%20Programming%2C%20Budgeting,and%20affordability%20advice
2.2.5. Portfolio Management
DoD policy requires that IT investments be managed as portfolios to ensure IT investments support the Department’s vision, mission, and goals; ensure efficient and effective delivery of capabilities to the Warfighter; and maximize return on investment within the enterprise”
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_background/#:~:text=Portfolio%20Management,within%20the%20enterprise
2.2.6. Operations
In most cases, an enterprise will capture its routine or repeatable business and mission operations as architectural content. However, when the basic structure of an activity is very stable and the activity repeated often, such as military operations planning or project definition and management, the enterprise may choose to include that structure as part of the Architectural Description itself. In this case, the architecture repository may be enhanced to include templates, checklists, and other artifacts commonly used to support the activity”
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_background/#:~:text=capability%20gap%20analysis.-,Operations,templates%2C%20checklists%2C%20and%20other%20artifacts%20commonly%20used%20to%20support%20the%20activity,-.
DoD uses four continuous integrated activities to manage its portfolios – analysis, selection, control, and evaluation”
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_background/#:~:text=DoD%20uses%20four%20continuous%20integrated%20activities%20to%20manage%20its%20portfolios%20%E2%80%93%20analysis%2C%20selection%2C%20control%2C%20and%20evaluation
2.3. DM2 Support for the Six Core Processes DoDAF Supports
The DoDAF V2.0 Meta-model Groups support the viewpoints and DoD Key Processes of JCIDS, DAS, PPBE, System Engineering, Operations, and Portfolio Management (IT and Capability). The table below indicates a non-inclusive mapping of DoDAF Meta-model Groups to the DoDAF Viewpoints and DoD Key Processes.
3. Architecture Development
3.1. Architecture Development
6-Step Architecture Development Process
3.1.1. Step 1 Determine Intended Use of Architecture
Defines the purpose and intended use of the architecture (“Fit-for-Purpose”); how the Architectural Description effort will be conducted; the methods to be used in architecture development; the data categories needed; the potential impact on others; and the process by which success of the effort will be measured in terms of performance and customer satisfaction”
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_arch_development/#:~:text=Step%201%3A%20Determine%20Intended%20Use%20of%20Architecture.,measured%20in%20terms%20of%20performance%20and%20customer%20satisfaction
3.1.2. Step 2 Determine Scope of Architecture
The scope defines the boundaries that establish the depth and breadth of the Architectural Description and establish the architecture’s problem set, helps define its context and defines the level of detail required for the architectural content”
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_arch_development/#:~:text=Step%202%3A%20Determine%20Scope%20of%20Architecture.%20The%20scope%20defines%20the%20boundaries%20that%20establish%20the%20depth%20and%20breadth%20of%20the%20Architectural%20Description%20and%20establish%20the%20architecture%27s%20problem%20set%2C%20helps%20define%20its%20context%20and%20defines%20the%20level%20of%20detail%20required%20for%20the%20architectural%20content
3.1.3. Step 3 Determine Data Required to Support Architecture Development
The required level of detail to be captured for each of the data entities and attributes is determined through the analysis of the process undergoing review conducted during the scoping in Step 2″
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_arch_development/#:~:text=Step%203%3A%20Determine%20Data%20Required%20to%20Support%20Architecture%20Development.%20The%20required%20level%20of%20detail%20to%20be%20captured%20for%20each%20of%20the%20data%20entities%20and%20attributes%20is%20determined%20through%20the%20analysis%20of%20the%20process%20undergoing%20review%20conducted%20during%20the%20scoping%20in%20Step%202
The initial type of architectural data content to be collected is determined by the established scope of the Architectural Description, and recorded as attributes, associations, and concepts as described in the DM2″
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_arch_development/#:~:text=The%20initial%20type%20of%20architectural%20data%20content%20to%20be%20collected%20is%20determined%20by%20the%20established%20scope%20of%20the%20Architectural%20Description%2C%20and%20recorded%20as%20attributes%2C%20associations%2C%20and%20concepts%20as%20described%20in%20the%20DM2
3.1.4. Step 4 Collect, Organize, Correlate, and Store Architectural Data
Architects typically collect and organize data through the use of architecture techniques designed to use views (e.g., activity, process, organization, and data models as views) for presentation and decision-making purposes. The architectural data should be stored in a recognized commercial or government architecture tool”
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_arch_development/#:~:text=Step%204%3A%20Collect%2C%20Organize%2C%20Correlate%2C%20and%20Store%20Architectural%20Data.,be%20stored%20in%20a%20recognized%20commercial%20or%20government%20architecture%20tool
3.1.5. Step 5 Conduct Analyses in Support of Architecture Objectives
Architectural data analysis determines the level of adherence to process owner requirements. This step may also identify additional process steps and data collection requirements needed to complete the Architectural Description and better facilitate its intended use. Validation applies the guiding principles, goals, and objectives to the process requirement, as defined by the process owner, along with the published performance measures (metrics), to determine the achieved level of success in the Architectural Description effort. Completion of this step prepares the Architectural Description for approval by the process owner
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_arch_development/#:~:text=Step%205%3A%20Conduct%20Analyses%20in%20Support%20of%20Architecture%20Objectives.,prepares%20the%20Architectural%20Description%20for%20approval%20by%20the%20process%20owner
3.1.6. Step 6 Document Results in Accordance with Decision-Maker Needs
The final step in the architecture development process involves creation of architectural views based on queries of the underlying data”
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_arch_development/#:~:text=Step%206%3A%20Document%20Results%20in%20Accordance%20with%20Decision%2DMaker%20Needs.%20The%20final%20step%20in%20the%20architecture%20development%20process%20involves%20creation%20of%20architectural%20views%20based%20on%20queries%20of%20the%20underlying%20data
3.2. Scoping Architectures to be “Fit-for-Purpose”
Establishing the scope of an architecture is critical to ensuring that its purpose and use are consistent with specific project goals and objectives. The term “Fit-for-Purpose” is used in DoDAF to describe an architecture (and its views) that is appropriately focused (i.e., responds to the stated goals and objectives of process owner, is useful in the decision-making process, and responds to internal and external stakeholder concerns”
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_arch_development/#:~:text=Scoping%20Architectures%20to,external%20stakeholder%20concerns
The architect is the technical expert who translates the decision-maker’s requirements into a set of data that can be used by engineers to design possible solutions
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_arch_development/#:~:text=The%20architect%20is%20the%20technical%20expert%20who%20translates%20the%20decision%2Dmaker%E2%80%99s%20requirements%20into%20a%20set%20of%20data%20that%20can%20be%20used%20by%20engineers%20to%20design%20possible%20solutions
Architecture scoping must facilitate alignment with, and support the decision-making process and ultimately mission outcomes and objectives as shown in the figure below”
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_arch_development/#:~:text=Architecture%20scoping%20must%20facilitate%20alignment%20with%2C%20and%20support%20the%20decision%2Dmaking%20process%20and%20ultimately%20mission%20outcomes%20and%20objectives%20as%20shown%20in%20the%20figure%20below
3.3. Enterprise Architecture
The DoD EA is a federation of Architectural Descriptions with which Solution Architectural Descriptions must conform. Its content includes but is not limited to rules, standards, services and systems lifecycle information needed to optimize and maintain a process, or part of a process that a self-sufficient organization wants to create and maintain by managing its IT portfolio
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_arch_development/#:~:text=The%20DoD%20EA%20is%20a,by%20managing%20its%20IT%20portfolio
References to Architectural Description Development
4. DoDAF Meta-Model (DM2)
The Purpose of the DoDAF Meta Model (DM2)
The purpose of DoDAF is to define concepts and models usable in DoD’s six core processes:
Capabilities Integration and Development (JCIDS)
Planning, Programming, Budgeting, and Execution (PPBE)
Acquisition System (DAS)
Systems Engineering (SE)
Operations Planning
Capabilities Portfolio Management (CPM)
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_dm2/#:~:text=The%20Purpose%20of,Portfolio%20Management%20(CPM)
The purposes of the DM2 are:
Establish and define the constrained vocabulary for description and discourse about DoDAF models (formerly “products”) and their usage in the 6 core processes
Specify the semantics and format for federated EA data exchange between:architecture development and analysis tools and architecture databases across the DoD Enterprise Architecture (EA) Community of Interest (COI) and with other authoritative data sources
Support discovery and understandability of EA data:
Discovery of EA data using DM2 categories of information
Understandability of EA data using DM2’s precise semantics augmented with linguistic traceability (aliases)
Provide a basis for semantic precision in architectural descriptions to support heterogeneous architectural description integration and analysis in support of core process decision making.
The DM2 defines architectural data elements and enables the integration and federation of Architectural Descriptions.
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_dm2/#:~:text=The%20DM2%20defines%20architectural%20data%20elements%20and%20enables%20the%20integration%20and%20federation%20of%20Architectural%20Descriptions.
4.1. DM2’s Three Levels:
Each of these is important to a particular viewer of Departmental processes.
- The conceptual level or Conceptual Data Model (CDM) defines the high-level data constructs from which Architectural Descriptions are created in non-technical terms, so that executives and managers at all levels can understand the data basis of Architectural Description.
- The Logical Data Model (LDM) adds technical information, such as attributes to the CDM and, when necessary, clarifies relationships into an unambiguous usage definition.
- The Physical Exchange Specification (PES) consists of the LDM with general data types specified and implementation attributes (e.g., source, date) added, and then generated as an XSD.
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_dm2/#:~:text=Each%20of%20these,as%20an%20%C2%A0XSD.
The DM2 consists of the following data items:
4.2. CDM
The CDM defines concepts involving high-level data constructs from which Architectural Descriptions are created, enabling executives and managers at all levels to understand the data basis of Architectural Description. The key concepts are as follows:
Activity: Work, not specific to a single organization, weapon system or individual that transforms inputs (Resources) into outputs (Resources) or changes their state.
Resource: Data, Information, Performers, Materiel, or Personnel Types that are produced or consumed.
Materiel: Equipment, apparatus or supplies that are of interest, without distinction as to its application for administrative or combat purposes.
Information: The state of a something of interest that is materialized – in any medium or form – and communicated or received.
Data: Representation of information in a formalized manner suitable for communication, interpretation, or processing by humans or by automatic means. Examples could be whole models, packages, entities, attributes, classes, domain values, enumeration values, records, tables, rows, columns, and fields.
Architectural Description: Information describing an architecture such as an OV-5b Operational Activity Model.
Performer: Any entity – human, automated, or any aggregation of human and/or automated – that performs an activity and provides a capability.
Organization: A specific real-world assemblage of people and other resources organized for an on-going purpose.
System: A functionally, physically, and/or behaviorally related group of regularly interacting or interdependent elements.
Person Type: A category of persons defined by the role or roles they share that are relevant to an architecture.
Service: A mechanism to enable access to a set of one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. The mechanism is a Performer. The capabilities accessed are Resources – Information, Data, Materiel, Performers, and Geo-political Extents.
Capability: The ability to achieve a Desired Effect under specified (performance) standards and conditions through combinations of ways and means (activities and resources) to perform a set of activities.
Condition: The state of an environment or situation in which a Performer performs.
Desired Effect: A desired state of a Resource.
Measure: The magnitude of some attribute of an individual.
Measure Type: A category of Measures.
Location: A point or extent in space that may be referred to physically or logically.
Guidance: An authoritative statement intended to lead or steer the execution of actions.
Rule: A principle or condition that governs behavior; a prescribed guide for conduct or action.
Agreement: A consent among parties regarding the terms and conditions of activities that said parties participate in.
Standard: A formal agreement documenting generally accepted specifications or criteria for products, processes, procedures, policies, systems, and/or personnel.
Project: A temporary endeavor undertaken to create Resources or Desired Effects.
Vision: An end that describes the future state of the enterprise, without regard to how it is to be achieved; a mental image of what the future will or could be like.
Skill: The ability, coming from one’s knowledge, practice, aptitude, etc., to do something well.
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_conceptual/#:~:text=The%20CDM%20defines,Examples%20could%20be
4.3. DM2 Conceptual Data Model (DIV-1) Diagram
5. DODAF Viewpoints and Models
5.2. DODAF Models – Interrogatives
Interrogatives
A critical part of defining an architecture is answering what is known as, the set of standard interrogatives, which are the set of questions, who, what, when, where, why, and how, that facilitate collection and usage of architecture-related data.
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_interrogatives/#:~:text=Architecture-,Interrogatives,-A%20critical%20part
7. DM2 Configuration Management notes
Purposes of the DoD Architecture Framework (DoDAF)
The purpose of the DoD Architecture Framework (DoDAF) is to support process improvement for the six core processes of DoD:
Joint Capabilities Integration and Development (JCIDS)
Planning, Programming, Budgeting, and Execution (PPBE)
Acquisition System (DAS)
Systems Engineering (SE)
Operations Planning
Capabilities Portfolio Management (CPM)
Purposes of the DoDAF Meta Model (DM2)
The DoDAF Meta Model (DM2) is the core of DoDAF. The purposes of DM2 are:
Provide the vocabulary for description and discourse about DoDAF models (formerly “products”) and core process usage.
Provide the basis for generation of the “physical” exchange specification for exchange of data between architecture tools and databases.
Provide a basis for semantic precision in architectural descriptions to support heterogeneous architectural description integration and analysis in support of core process decision making.
Support discovery and understandability of architecture data assets within the DoD Enterprise Architecture (EA) Community of Interest (COI) and with cross-COIs, discovery using DM2 categories of information, and understandability thru precise semantics augmented with linguistic traceability.
Support information sharing across the DoD Enterprise Architecture COI with precise, universally understood, and commonly interpretable semantics.
Purposes of DoDAF-DM2 Configuration Management (CM)
The purposes of DoDAF-DM2 Configuration Management (CM) are:
Governance. Provide a visible and clearly understood process for DoDAF-DM2 issue resolution and model improvement. Establish change activity that is controlled through a known, organized process so that there is a known basis for making change to architecture model, and a means for evaluating the effectiveness of that change. Establish procedures for interaction with related communities including related COIs, EA tool vendors, and semantic interoperability groups.
Product Improvement. Improve the ability to produce desired models and analyses that reflect customer need through common understanding of the definition and usage of the data. Provide a process for evaluation of present and future impact of proposed changes.
Baselines. Maintain stable DoDAF-DM2 baselines and clearly establish and provide community-wide awareness of DoDAF-DM2 developmental, operational, deprecated, and retired baselines. Ensure that all changes to any baseline can be traced to an approved change proposal and that the implementation status of changes can be verified.
COI. Provide a means to continuously re-assess and improve information sharing within the DoD EA COI and with related COIs, to determine requirements for information sharing, and to monitor and measure progress within the DoD EA COI.
A configuration management program provides an orderly way to facilitate change, based on need, and utilizes best practices and performances standards to ensure that expectations are realized, efficiency is increased, reliability and maintainability is assured, and stability achieved.
Configuration Management (CM): a management discipline that applies technical and administrative direction over the life cycle of an item to:
Identify and document the functional and physical characteristics of configuration items (CIs) (configuration identification)
Control changes to configuration items and their associated documentation (configuration control)
Record and report information needed to manage configuration items effectively, including the status of proposed changes and the implementation status of approved changes (status accounting)
Audit CIs to verify conformance to requirements (configuration audit)
Configuration Item (CI): an aggregation of metadata, and occasionally data on architecture components, processes, or data that is designated for configuration management and treated as a single entity in the configuration management process. (E.g., NetViz net file, Core Systems and Quantities List, etc.) [Adapted from ISO 10007:1995(E)]