DoDAF Viewpoints and Models
Data and Information Viewpoint
DoDAF-described Models within the Data and Information Viewpoint provide a means of portraying the operational and business information requirements and rules that are managed within and used as constraints on the organizations business activities. Experience gained from many enterprise architecture efforts within the DoD led to the identification of several levels of abstraction necessary to accurately communicate the information needs of an organization or enterprise. The appropriate level or levels of abstraction for a given architecture are dependent on the use and the intended users of the architecture. Where appropriate, the data captured in this viewpoint needs to be considered by COIs.
DoDAF V2.0 incorporates three levels of abstraction that correlate to the different levels associated with most data models developed in support of the operations or business. These levels are:
- Conceptual.
- Logical.
- Physical.
Data and Information Model Descriptions
| Model |
Description |
| DIV-1: Conceptual Data Model |
The required high-level data concepts and their relationships. |
| DIV-2: Logical Data Model |
The documentation of the data requirements and structural business process (activity) rules. In DoDAF V1.5, this was the OV-7. |
| DIV-3: Physical Data Model |
The physical implementation format of the Logical Data Model entities, e.g., message formats, file structures, physical schema. In DoDAF V1.5, this was the SV-11. |
Mappings of the Data and Information Viewpoint DoDAF-described Models to the DM2 Concepts, Associations, and Attributes are in DM2 Concepts, Associations, and Attributes Mapping to DoDAF-described Models. There is traceability between the DIV-1 to the DIV-2 to the DIV3 as follows:
- The information representations in the DIV-1 are same, decomposed into, or factored into the data representations in the DIV-2. The DIV-1 information representations can range in detail from concept lists to structured lists (i.e., whole-part, super-subtype), to inter-related concepts. At the DIV-1 level, any relationships are simply declared and then at the DIV-2 level they are made explicit and attributed. Similarly, attributes (or additional relationships) are added at the DIV-2 level.
- The DIV-3's performance and implementation considerations usually result in standard modifications of the DIV-2 and so it traces quite directly. That is, no new semantics are introduced going from the DIV-2 to the DIV-3.
The DM2 Concepts, Associations, and Attributes are described in the DoDAF Meta-model Data Dictionary.
Uses of Data and Information Viewpoint DoDAF-described Models. The DIV DoDAF-described Models provide means of ensuring that only those information items that are important to the organization's operations and business are managed as part of the enterprise. They are also useful foundations for discussion with the various stakeholders of the architecture (e.g., decision-makers, architects, developers). These stakeholders require varying levels of detail to support their roles within the enterprise.
When building an architecture using a structured analysis approach, the items captured as part of the data model can be derived from the inputs and outputs associated to the organizations activities. Building the data model in this manner ties the data being managed within the architecture to the activities that necessitate that data. This provides a valuable construct enabling the information to be traceable to the strategic drivers of the architecture. This also enables the data to be used to map services and systems to the business operations. The conceptual data model would be a good tool to use when discussing this traceability with executive decision-makers and persons at that level.
The logical data model bridges the gap between the conceptual and physical-levels. The logical data model introduces attributes and structural rules that form the data structure. As evidenced by the content, this model provides more detail than the conceptual model and communicates more to the architects and systems analysts types of stakeholders. This is one model that helps bridge the gap between architecture and system development. It provides a valuable tool for generating requirements and test scripts against which services and systems can be tested.
Lastly, the physical data model is the actual data schema representative of the database that provides data to the services and applications using the data. This schema is usually a de-normalized data structure optimized to meet performance parameters. The physical data model usually can be generated from a well-defined logical data model then used by database developers and system developers or it can be developed separately from the logical data model (not the optimum method of development) and optimized by the database and system developers. This model can be used to develop XML message sets and other physical exchange specifications enabling the exchange of architecture information.
Metadata Groups Used to Create Data and Information Models. The previous DoDAF-described Models focused on particular areas within the DoDAF Meta-model from which the majority of the information within the models can be extracted. For example, the Capability Viewpoint DoDAF-described Models are in large part made up of data extracted from the Capability Metadata groups. The same is true for Project, Services and the like. The Data and Information DoDAF-described Models are somewhat different.
The Data and Information DoDAF-described Models contain information extracted from all of the metadata groups. Therefore, any information that an organization is managing using its enterprise architecture, should be captured within the Data and Information Models. As previously stated, there are levels of detail that are not included in all models (e.g., the conceptual data model is usually not fully attributed like the logical and physical) but the information item itself (e.g., capability, activity, service) should be represented in all models. Together, the three types of models help bridge the gap between architecture being used as requirements and architecture being used to support system engineering.
DIV-1: Conceptual Data Model
DIV-2: Logical Data Model
DIV-3: Physical Data Model