DoDAF V2.0 Models
Models / One Liner Description / Comments, Inputs, and Discussion / Core Process Used In / Governance RequirementAV-1: Architecture Executive Summary / The definition and scoping document[dm1]for the architecture effort. / AV-1: The Architecture Overview and Summary Description (not model) provides executive-level summary information about the architecture project in a consistent format. AV-1 includes the architectural description project name, the architect's name, and the organization developing the architectural description; it provides summary information concerning the scope of the subject architecture, and a listing of viewpoints and views covered by the architectural description needed to adequately cover this scope. AV-1 also includes the list of assumptions, constraints, and limitations that may affect high-level decision processes involving the subject architecture. The last section (to be completed once the architectural description and analysis process has completed) states the findings and recommendations that have been developed based on the architectural description effort. Examples of findings include identification of capability shortfalls, recommended system implementations, and opportunities for technology insertion. / Contains purpose, scope, listing of viewpoints and views, assumptions, constraints, limitations, architecture description project plan, keywords, architecture deployment timeframe, and, upon completion and findings, recommendations.
AV-2: Architecture Dictionary / An architectural data repository with definitions of all terms used throughout the architectural data and presentations. and taxonomic and compositional informationThe names of key objects and their definitions, with associated taxonomic and compositional information.The terms, definitions, and their associations that are needed to understandthe architecture and its description. / AV-2: The Architecture Integrated Dictionary contains definitions of terms used in the subject architecture. It consists of textual definitions in the form of a glossary, a repository (e.g. an xml file) of architecture data, their taxonomies, and their metadata (i.e., data about architecture data), including metadata for tailored views and models, associated with the architecture models developed. Metadata are the architecture data types, possibly expressed in the form of a physical schema. / Remember the authoritative data reference in the short description. Purposes: alignment of multiple / federation, analysis, ….
CV-1: Capability Vision / The overall desired effectsfor transformational endeavors, which provides a strategic context for a setccapabilities. / CV-1: The Capability Vision Model provides a high level description of the CONOPS[dm2] that is the scope of the subject architecture. It consists of a description of a set of capabilities necessary to achieve a desired effect or a particular strategic vision for a specific scenario.
Several CV-1s may be needed to cover all scenarios that are in scope of the subject architecture. / Note: in all capability views, the capability is described in terms of the activities, conditions, desired effects, rules complied with, resource consumption and production, and measures, without regard to the performer and location solutions.
CV-2: Capability Taxonomy and Composition / Meronymy / The hierarchy of capabilities indicating the type of hierarchical relationships between elements.which specifies all the capabilities that are referenced throughout one or more Architectural Descriptions. / CV-2: Capability Taxonomy and Composition / Mereonomy Model: A hierarchy of capabilities indicating the type of hierarchy. / Purpose: e.g., JCA’s, we need this since JCAs are a hierarchy and so are most other capabilities for Mil services, etc. Solution level arch. What about other relationships? Could be multiple diagrams.
CV-3: Capability Phasing / The timelinenedfor the deployment of capabilities. The CV-3 shows the capability phasing in terms of the activities, conditions, desired effects, rules complied with, resource consumption and production, and measures, without regard to the performer and location solutions. / CV-3: Capability Phasing Model: The schedule to achieve capabilities at different points in time or during specific periods of time. The schedule can be used to highlight capability gaps or overlaps (e.g., redundant capability across projects) / E.g., Time line for the deployment of (the ability to achieve desired effects for Maritime Maneuver to Engage to perform TA 1.6 Operate from Afloat Forward Staging Base (AFSB) under specified conditions – all DOTMLPF.)
CV-4: Capability Dependencies / The dependencies between planned capabilities desired effects of capabilties.and the definition of logical groupings of capabilities. / CV-4: Capability Dependencies Model: The dependencies between capabilities / Resource flows?
CV-5: Capability to Organizational Development of CapabilitiesMapping / The fulfillment of capability requirements shows the planned capability deployment and interconnection for a particular Capability Phase. The CV-5 sThows the planned solution for athecapability, group of capabilities, and / or their phase(s) in terms of performers and locations, the plans for their development and deployment, and the organizations responsible for the development, deployment, and operation.and their associated concepts. / CV-5: Organizational Deployment of Capabilities Mapping: The deployment schedule/allocation for a capability, or group of capabilities, and / or their phase(s) in terms of Organizations and Locations.
NOTE: A related CV-5(b) may be developed to show the same set of capabilities and the organizations responsible for their development, deployment, and operation[D3].
CV-6: Activities of Capabilitiesy to Operational Activities Mapping / A mapping between the capabilities required and Tthe operational aactivities that thoseare performed as part ofcapabilities capabilities, the conditions under which they are performed, and measures associated with the activities and conditionssupport. / CV-6: Operational Activities to Capability Mapping: is a table report that shows the operational activities that are performed to provide capabilities.
CV-7: Capabilities of y to Services PerformerMapping / A mapping Associations between the capabilities capabilities and the services performers (systems, services, organizations, types of organizations, types of person roles, and any aggregate thereof) that these act to achieve of the capabilities capabilities.enable. / CV-7: Capabilities of Performer Mapping: is a table report that shows the performers (systems, services, organizations, types of organizations, types of person roles, and any aggregate thereof) that act to achieve capabilities.
DIV-1:Conceptual Information / Data Model / The required hHigh-level data concepts and their inter-relationships. / DIV-1: Conceptual Information / Data Model: High-level data concepts and their inter-relationships. Data concepts are represented in OVs as resources produced and consumed by operational activities.
DIV-2: Logical Information / DataData Model / The documentation of the data requirements andDetailed data concepts and their inter-relationships, attributes, and structural business process (activity) rules associated with those relationships and attributes. In DoDAF V1.5, this was the OV-7. / DIV-2: Logical Information / Data Model: Detailed data concepts and their inter-relationships, attributes, and rules associated with those relationships and attributes. DIV-2 is the data model developed by an authoritative Community of Interest for the domain covered by the subject architecture.
DIV-3: Physical Information / Data Model / TThe physical implementation format of the Logical Data Model entities, of the detailed data concepts (e.g., message formats, data products models, file structures, physical schema. In DoDAF V1.5, this was the SV-11). / DIV-3: Physical Information / Data Model: The physical implementation of the detailed data concepts (e.g., message formats, data products models, file structures, physical schema. DIV-3 is the physical schema developed by an authoritative Community of Interest for the domain covered by the subject architecture.
OV-1: High-Level Operational Concept Graphic / The high-level graphical/textual description of the operational concept of the conceived architecture.. / OV-1: High-Level Operational Concept Model: A high-level graphical depiction of the operational concept of the subject architecture. OV-1 depicts how a system(s) will be used from the viewpoints of the various stakeholders. The objective is to 1) get stakeholder agreement on who is responsible for what (what operational requirements and systems are within scope); 2) what the lines of communication are; and 3) define the environment in which the system will operate.
OV-2: Operational Organizational Resource FlowsIdentificationDescription / The identification of resource flows between organizations, types of organizations, and/or types of person roles.A description of the Resource Flows exchanged between operational activities. / OV-2: Operational Resource Flows Specification Model: The identification of resource flows between performers.
OV-3: Operational Organizational and Activity Resource Flows Matrix / Resource flows among organizations, types of organizations, and/or types of person roles; the activities performed; the resources exchanged; and the attributes (rules and measures) associated with these exchanges.A description of the resources exchanged and the relevant attributes of the exchanges. / OV-3: Operational and Activity Resource Flows Mapping: is a table report that shows the Resource flows among performers; the activities performed; the resources exchanged; and the attributes (rules and measures) associated with these exchanges.
OV-4: Organizational Relationships Chart / The organizational context, role or other relationships Composition and / or relationships among organizations (or types of organizations) specified in guidance, rules, and / or agreements and, optionally, types of person roles associated with those organizations. / OV-4: Organizational Relationships Model: Composition and / or organizational relationships among organizations (or types of organizations) specified and, optionally, types of person roles associated with those organizations.
OV-5a: Operational Activity Decomposition Tree / The capabilities and aThe hierarchical structurectivities (operational activities) organized in a hierarchal structure of organizational activities. / OV-5a: Operational Activity Hierarchy Model: The hierarchical structure of operational activities.
OV-5b: Operational Activity Resource FlowsModel / The context of capabilities and activities (operational activities) and their relationships among activities, inputs, and outputs; Resource flows between organizational activities with associated mAdditional data can show costeasures, pperformers, and / or other pertinent informationrules. / OV-5b: Operational Activity Resource Flows Model: Resource and optionally control flows between operational activities with associated measures and / or rules.
OV-6a: Operational Organizational and Activity Ruless Model / One of three models used to describe activity (operational activity). It identifiesThe b business rules that constrain operationsorganizations and / or organizational activities. / OV-6a: Operational Rules Model: The business rules that constrain operations by constraining performers, operational activities, and/or resources and resource flows.
OV-6b: Organizational and Activity State Transitions Description / One of three models used to describe operational activity (activity). It identifies business process (activity)Organizational state transitions and activity performance in responses to events, other activities, and / or other organizational state transitions.(usually, very short activities). / OV-6b: Operational State Transition Model: depicts the sets of states a performer can have in response to events. Each event triggers an action to move to a new state. Each transition (between states) specifies the event and the action.
OV-6c: Event-Trace SequencesDescription / SOne of three models used to describe activity (operational activity). It traces actions in a scenario or sequences of organizational events and activities.. / OV-6c: Operational Event-Trace Model: describes various Operational scenarios as a sequence of interactions among performers.
PV-1: Project Portfolio Relationships / TIt describes the dependencies amongyrelationships between the organizations and projects and the organizational structures needed to manage a portfolio of projects. / PV-1: Project Portfolio Relationships Model: shows the dependencies among organizations (project owner) and projects (programs) and the organizational structures needed to manage a portfolio of projects.
NOTE: Must relate to CV-5(b) which shows the set of capabilities and the organizations responsible for their development, deployment, and operation, and the project (PV-2) and capabilities (CV-3) time phases.
PV-2: Project Timelines and Dependencies / A tThe timelinesperspective onofprograms or pprojects, their with the key milestones, and /or their es and interdependencies. / PV-2: Project Phasing Model: The schedule to complete projects at different points in time or during specific periods of time. The schedule can be used to highlight project gaps or overlaps.
PV-3: Project Dependencies Model: The dependencies between projects.
PV-3 : Project to Capabilities Achived by Projectsy Mapping / A mapping of Associations among programs and pprojects andtocapabilities capabilitiestothat show how the specific projects and program elements help to achieve a capability. / PV-4 Capabilities delivered by Projects Mapping: a table report that lists capabilities and the projects that are responsible for providing them
NOTE: lists in table format the links established in the subject architecture between CV-5(b) and PV-2 elements.
SvcV-1 Services Composition and Context Interface DescriptionIdentification / The identification of services , resource flows, composition, service items, and their interconnectionsand the resources they provide access to.. / SvcV-1 Services Composition Mereonomy Model: A hierarchy of services indicating the type of hierarchy.
SvcV-2 Services Interface MeansResource Flow Description / The means by which resource flows between services occur.A description of Resource Flows exchanged between services. / SvcV-2 Services Interface Specification Model: Defines the interfaces for services. A service interface is defined by specifying the type of an interface (required or provided ) and the resource accessible via that interface.
SvcV-3a SystemsResources Accessed by -Services Matrix / The relationships among or between systems and services in a given Architectural Description.The resources services provide access to. / Delete (already covered in SvcV-2)
SvcV-3b Services-Services MatrixService Dependencies / The relationshipsS among services that depend on other services to be performed.in a given Architectural Description. It can be designed to show relationships of interest, (e.g., service-type interfaces, planned vs. existing interfaces). / Delete (services are supposed to provide well encapsulated functionality. That is, each service’s functionality (what is provided) must be well defined, self-contained, and loosely coupled from other functionality/services. if a service is dependent on other services, then it is not very well designed.
SvcV-4 Services Functionality Description / The hierarchical structure of service activities. Resource flows between service activities with associated measures, performers, and / or rules.The functions performed by services and the service data flows among service functions (activities). / SvcV-4 Services Functionality Model: Defines the internal behavior of a service in terms of the functions it is expected to perform, the internal resource and optionally control flows between service functions with associated measures and / or rules.
SvcV-5 Operational Organizational Activitiesyto Supported by Services Traceability Matrix / A mapping of sAssociations between services (activities) back to operational activities (activities).and the organizational activities they support. / SvcV-5 Operational Activities Supported by Services Mapping: a table report that shows Operational Activities and the service(s) that are necessary to support them.
SvcV-6 Services Resource FlowsMatrix / The details of resource flows among services; the activities performed; the resources exchanged; and the attributes (rules and measures) associated with these exchanges.It provides details of service Resource Flow elements being exchanged between services and the attributes of that exchange. / Delete already covered in SvcV-2
SvcV-7 Services Measures Matrix / The mMeasures (metrics) of sServices, activities performed by services, and resources accessed by services Model elements for the appropriate time frame(s). / Delete AS A SERVICE MEASURES MODEL, every thing in DODAF v2 has measures, there is no need for a separate model to list those. we did not add one for performers, operational activities, etc.
SvcV-8 Services Evolution Description / The planned incremental steps toward migrating a suite of services to a more efficient suite or toward evolving current services to a future implementation. / Delete.
SvcV-9 Services Technology & Skills Forecast / The emerging technologies, software/hardware products, and skills that are expected to be available in a given set of time frames and that will affect future service development. / Delete
SvcV-10a Services Ruless Model / The business rules that constrain services and / or services activitiesOne of three models used to describe service functionality. It identifies constraints that are imposed on systems functionality due to some aspect of servicesystem design or implementation. / SvcV-10a Services Rules Model: Specifies constraints (policy and SLAs) that bind providers and consumers of a service.
SvcV-10b Services State Transition Description / Service state transitions and activity performance in responses to events, other activities, and / or other service state transitions. One of three models used to describe service functionality. It identifies responses of services to events. / Delete. Services are supposed to be stateless (they do not change their internal state after providing the service)
SvcV-10c Services Event-Trace Description / Sequences of service events and activities.One of three models used to describe service functionality. It identifies service-specific refinements of critical sequences of events described in the Operational Viewpoint. / Delete. Covered in SvcV-4
StdV-1 Standards Profile / The listing of standards that apply to solution elements.The standards that currently apply to an architecture. / StdV-1 Standards Profile: a table report listing the standards that currently apply to the elements defined for the subject architecture.
StdV-2 Standards Forecast / The description of emerging standards and potential impact on current solution elements, within a set of time framesThe standards that apply to an architecture in the future. / StdV-2 Standards Forecast: a table report listing the standards that are projected to apply to the elements defined for the subject architecture.
SV-1 Systems Interface DescriptionSV-1 Systems Composition and Interface Identification / The identification of system resource flows and their composition.The identification of systems, system items, and their interconnections. / SV-1 Systems Composition and Interface Specification Model: shows systems, organizations, types of organizations, and/or types of person roles, and their interfaces, where an interface is denoted by the type of the resource accessible via that interface.
SV-2 Systems Resource FlowInterface MeansDescription / A description of The Resource Flows exchanged between systemsmeans by which resource flows between systems occur. / SV-2 Systems Interface Means Model: The means (physical communications protocols and communications systems) by which resources flow between systems, organizations, types of organizations, and/or types of person roles.
SV-3 Systems Interfaces-Systems Matrix / The identification of system resource flowsThe relationships among systems in a given Architectural Description. It can be designed to show relationships of interest, (e.g., system-type interfaces, planned vs. existing interfaces).. / SV-3 Systems Interface Matrix: a table report that lists characteristics of systems, organizations, types of organizations, and/or types of person roles interfaces such as Classification level (e.g., SECRET, TS/SCI), Means (e.g., JWICS, SIPRNET), Standard, designation as a Key Interface, etc.
SV-4 Systems Functionality Description / The hierarchical structure of system activities. Resource flows between system activities with associated measures, performers, and / or rules.The functions (activities) performed by systems and the system data flows among system functions (activities). / SV-4a: Systems Activity Hierarchy Model: The hierarchical structure of systems activities and the type of the hierarchy. (organizational hierarchies were described in OV-4)
SV-4b: Systems Activity Resource Flows Model: Resource and optionally control flows between systems, organizations, types of organizations, and/or types of person roles activities with associated measures and / or rules.
SV-5a Operational Organizational ActivitiesySupported byto Systems Functionsn Traceability Matrix / A mapping of system functions (activities) back to operational activities (activities)The association of organizational activities to those activities that are currently or planned to be performed by systems.. / SV-5 Services Supported by Systems Activities Mapping: a table report that shows services and the systems, organizations, types of organizations, and/or types of person roles and their activities that implement them.
SV-5b Organizational Operational Activities Supported byy to Systems Traceability Matrix / A mapping of Ssystems back to capabilities Capabilities whose achievement they contribute toward or operational a Activities (activities)supported by the Systems. / Delete, we already have operational activities mapped to services, and services mapped to systems activities, as well as system activities associated with systems.
SV-6 Systems Resource Flows Matrix / The details of resource flows among systems; the activities performed; the resources exchanged; and the attributes (rules and measures) associated with these exchanges.Provides details of system resource flow elements being exchanged between systems and the attributes of that exchange. / SV-6 Systems Resource Flow Mapping: a table report that shows Resource flows among systems, organizations, types of organizations, and/or types of person roles, the activities performed; the resources exchanged; and the attributes (rules and measures) associated with these exchanges.
SV-7 System s Measures Matrix / The measures (metrics) of Systems Model elements for the appropriate timeframe(s). / delete
SV-8 Systems Evolution Description / The planned incremental steps toward migrating a suite of systems to a more efficient suite, or toward evolving a current systemSystem or Systems to a future implementation. / Delete, can be incorporated in project phasing.
SV-9 Systems Technology & Skills Forecast / The emerging technologies, software/hardware products, and skills that are expected to be available in a given set of time frames and that will affect future system development. / delete
SV-10a System s Rules Model / The business rules that constrain systems and / or system activities due to some aspect of service design or implementation.One of three models used to describe system functionality. It identifies constraints that are imposed on systems functionality due to some aspect of system design or implementation. / SV-10a System Rules Model: The rules that constrain systems, organizations, types of organizations, and/or types of person roles, their activities, and/or resources and resource flows due to some aspect of system design or implementation; law, doctrine, or policy that governs organizational behavior.
SV-10b Systems State Transition Description / System state transitions and activity performance in responses to events, other activities, and / or other system state transitions. One of three models used to describe system functionality. It identifies responses of systems to events. / SV-10b Systems State Transition Model: The model depicts the sets of states a system, organization, type of organization, and/or type of person role can have in response to events. Each event triggers an action to move to a new state. Each transition (between states) specifies the event and the action.
SV-10c Systems Event-Trace Description / Sequences of system events and activities.One of three models used to describe system functionality. It identifies system-specific refinements of critical sequences of events described in the Operational Viewpoint. / SV-10c Systems Event-Trace Model: Describes various scenarios as a sequence of interactions among systems, organizations, types of organizations, and/or types of person roles,
[dm1]Make sure the Document def in DoDAF is broad enough to cover any media.