Page Operations
Browse Space
Appendix A. DoDAF Architecture Views and Products
A.1 DoDAF Architecture Views and Products
The Department of Defense (DoD) Architecture Framework (DoDAF), Version 1.5 [DoDAF], defines a common approach for DoD architecture description development, presentation, and integration for both operations and processes.
A.1.1 Views and Products Developed
Figure A.1.1 DoDAF views, comprising All Views (AV), - Operational Views (OV), System and Services Views (SV) and Technical Standards Views (TV)
In the following tables, a coarse overview of the content of each of the views defined by DoDAF is presented:
Table A.1.1 Definition of DoDAF Architecture Framework Views
| View | Definition |
|---|---|
| All-Views (AV) | There are some overarching aspects of an architecture that relate to all three views. These overarching aspects are captured in the All-Views (AV) products. The AV products give information pertinent to the entire architecture but do not represent a distinct view of it. AV products set the scope and context of the architecture. The scope includes the subject area and time frame. The setting in which the architecture exists comprises the interrelated conditions that compose the context for the architecture. These conditions include doctrine; tactics, techniques, and procedures; relevant goals and vision statements; concepts of operations (ConOps); scenarios; and environmental conditions. |
| Operational View (OV) | The OV is a description of the tasks and activities, operational elements, and information exchanges required to accomplish DoD business processes. The OV contains graphical and textual products that comprise an identification of the operational nodes and elements, assigned tasks and activities, and information flows required between nodes. It defines the types of information exchanged, the frequency of exchange, which tasks and activities are supported by the information exchanges, and the nature of information exchanges. |
| Systems and Services View (SV) | The SV is a set of graphical and textual products that describes systems and interconnections providing for, or supporting, DoD functions, including business functions. The SV associates system resources with the OV. These system resources support the operational activities and facilitate the exchange of information among operational nodes. |
| Technical Standards View (TV) | The TV is the minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements. Its purpose is to ensure that a system satisfies a specified set of operational requirements. The TV provides the technical systems implementation guidelines upon which engineering specifications are based; common building blocks are established, and product lines are developed. The TV includes a collection of the technical standards, implementation conventions, standards options, rules, and criteria organized into profile(s) that govern systems and system elements for a given architecture. |
A.1.2 Architecture Products
Table A.1.2-1 lists the products defined by DoDAF version 1.5 together with an expected content summary. Table A.1.2-1 Architecture Products defined in the DoD Architecture Framework
| Product | Name | Summary |
|---|---|---|
| AV-1 | Overview and Summary Information | The Overview and Summary Information provides executive- level summary information in a consistent form that allows quick reference and comparison among architectures. AV-1 includes assumptions, constraints, and limitations that may affect high-level decision processes involving the architecture. |
| AV-2 | Integrated Dictionary |
The Integrated Dictionary contains definitions of terms used in the given architecture. It consists of textual definitions in the form of a glossary, a repository of architecture data, their taxonomies, and their metadata (i.e., data about architecture data), including metadata for tailored products, associated with the architecture products developed. Metadata are the architecture data types, possibly expressed in the form of a physical schema. In this document, architecture data types are referred to as architecture data elements. |
| OV-1 | High Level Operational Concept Graphic |
The High- Level Operational Concept Graphic describes a mission and highlights main operational nodes (see OV-2 definition) and interesting or unique aspects of operations. It provides a description of the interactions between the subject architecture and its environment, and between the architecture and external systems. A textual description accompanying the graphic is crucial. Graphics alone are not sufficient for capturing the necessary architecture data. |
| OV-2 | Operational Node Connectivity Description | The Operational Node Connectivity Description graphically depicts the operational nodes (or organizations) with needlines between those nodes that indicate a need to exchange information. The graphic includes internal operational nodes (internal to the architecture) as well as external nodes. |
| OV-3 | Operational Information Exchange Matrix |
The Operational Information Exchange Matrix details information exchanges and identifies "who exchanges what information, with whom, why the information is necessary, and how the information exchange must occur". There isn't a one-to-one mapping of OV-3 information exchanges to OV-2 needlines; rather, many individual information exchanges may be associated with one needline. |
| OV-4 | Organizational Relationships Chart |
The Organizational Relationships Chart illustrates the command structure or relationships (as opposed to relationships with respect to a business process flow) among human roles, organizations, or organization types that are the key players in architecture. |
| OV-5 | Operational Activity Model |
The Operational Activity Model describes the operations that are normally conducted in the course of achieving a mission or a business goal. It describes capabilities, operational activities (or tasks), input and output (I/O) flows between activities, and I/O flows to/from activities that are outside the scope of the architecture. High- level operational activities should trace to (are decompositions of) a Business Area, an Internal Line of Business, and/or a Business Sub-Function as published in OMB's Business Reference Model. |
| OV-6a | Operational Rule Model |
The Operational Rules Model specifies operational or business rules that are constraints on an enterprise, a mission, operation, business or architecture. |
| OV-6b | Operational State Transition Description | The Operational State Transition Description is a graphical method of describing how an operational node or activity responds to various events by changing its state. The diagram represents the sets of events to which the architecture will respond (by taking an action to move to a new state) as a function of its current state. Each transition specifies an event and an action. |
| OV-6c | Operational Event Trace Description | The Operational Event-Trace Description provides a time-ordered examination of the information exchanges between participating operational nodes as a result of a particular scenario. Each event-trace diagram should have an accompanying description that defines the particular scenario or situation. |
| OV-7 | Logical Data Model | The Logical Data Model describes the structure of an architecture domain's system data types and the structural business process rules (defined in the architecture's Operational View) that govern the system data. It provides a definition of architecture domain data types, their attributes or characteristics, and their interrelationships. |
| SV-1 | Systems Interface Description | The Systems Interface Description depicts systems nodes and the systems resident at these nodes to support organization/human roles represented by operational nodes of the Operational Node Connectivity Description (OV-2). SV-1 also identifies the interfaces between systems and system nodes. |
| SV-2 | Systems Communication Description | The Systems Communications Description depicts pertinent information about communications systems, communications links, and communications networks. SV-2 documents the kinds of communications media that support the systems and implement their interfaces as described in SV-1. Thus, SV-2 shows the communications details of SV-1 interfaces that automate aspects of the needlines represented in OV-2. |
| SV-3 | Systems-Systems Matrix | The Systems-Systems Matrix provides detail on the interface characteristics described in SV-1 for the architecture, arranged in a matrix form. |
| SV-4 | Systems Functionalities Description | The Systems Functionality Description documents system functional hierarchies and system functions, and the system data flows between them. Although there is a correlation between Operational Activity Model (OV-5) or business-process hierarchies and the system functional hierarchy of SV-4, it need not be a one-to-one mapping, hence, the need for the Operational Activity to Systems Function Traceability Matrix (SV-5), which provides that mapping. |
| SV-5 | Operational Activities to System Functionalities Traceability Matrix | Operational Activity to Systems Function Traceability Matrix is a specification of the relationships between the set of operational activities applicable to architecture and the set of system functions applicable to that architecture. |
| SV-6 | Systems Data Exchange Matrix | The Systems Data Exchange Matrix specifies the characteristics of the system data exchanged between systems. This product focuses on automated information exchanges (from OV-3) that are implemented in systems. Non-automated information exchanges, such as verbal orders, are captured in the OV products only. |
| SV-7 | Systems Performance Parameters Matrix | The Systems Performance Parameters Matrix product specifies the quantitative characteristics of systems and system hardware/software items, their interfaces (system data carried by the interface as well as communications link details that implement the interface) and their functions. It specifies the current performance parameters of each system, interface, or system function and the expected or required performance parameters at specified times in the future. |
| SV-8 | Systems Evolution Description | The Systems Evolution Description captures evolution plans that describe how the system or the architecture, in which the system is embedded, will evolve over a lengthy period of time. Generally, the timeline milestones are critical for a successful understanding of the evolution timeline. |
| SV-9 | Systems Technology Forecasts | The Systems Technology Forecast defines the underlying current and expected supporting technologies. It is not expected to include predictions of technologies as with a crystal ball. Expected supporting technologies are those that can be reasonably forecast given the current state of technology and expected improvements. New technologies should be tied to specific time periods, which can correlate against the time periods used in SV-8 milestones. |
| SV-10a | Systems Rules Model | Systems rules are constraints on architecture, on a system(s), or system hardware/software item(s), and/or on a system function(s). While other SV products (e.g., SV-1, SV-2, SV-4, SV-11) describe the static structure of the Systems View (i.e., what the systems can do), they do not describe, for the most part, what the systems must do, or what it cannot do. |
| SV-10b | Systems State Transitions Description | The Systems State Transition Description is a graphical method of describing a system (or system function) response to various events by changing its state. The diagram basically represents the sets of events to which the systems in the architecture will respond (by taking an action to move to a new state) as a function of its current state. Each transition specifies an event and an action. |
| SV-10c | Systems Event-Trace Description | The Systems Event-Trace Description provides a time-ordered examination of the system data elements exchanged between participating systems (external and internal), system functions or human roles as a result of a particular scenario. Each event-trace diagram should have an accompanying description that defines the particular scenario or situation. SV-10c in the Systems View may reflect system-specific aspects or refinements of critical sequences of events described in the Operational View. |
| SV-11 | Physical Schema | The Physical Schema product is one of the architecture products closest to actual system design in the Framework. The product defines the structure of the various kinds of system data that are utilized by the systems in the architecture. |
| TV-1 | Technical Standards Profile | The Technical Standards Profile collects the various systems standards rules that implement and sometimes constrain the choices that can be made in the design and implementation of architecture. |
| TV-2 | Technical Standards Forecast | The Technical Standards Forecast contains expected changes in technology-related standards and conventions, which are documented in the TV-1 product. The forecast for evolutionary changes in the standards should be correlated against the time periods as mentioned in the SV-8 and SV-9 products. |