• DODAF Home 
• Background 
• Architectural Development 
• Meta Model 
  • Conceptual 
  • Logical 
  • PES 
  • IDEAS Foundation Ontology 
• 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 
• Presentation Techniques
  • Composite Views 
  • Fusion Views 
  • Reference Models 
• DODAF-DM2 Configuration Management
• IDEAS 
• Related Links 
• Acronyms List and Glossary of Terms 
• Site Map 
• Archives

Resource Flows

Resource Flows are used to model the flow of Resources - Materiel, Information (and Data), Geo-Spatial Extents, Performers, or any combination thereof. Resource Flows are key modeling techniques used in the definition of Interfaces and assurance of Interoperability between Activities and their associated Performers (e.g., Systems and Personnel.) Resource Flow models and associated analysis techniques reveal behavior such as:

• The connectivity between resources. 
• Resource Flow modeling provides an explicit means to describe the behavior of activities, systems, organizations and their composite effects on the overall enterprise.
• The content of the information flowing between resources (e.g., interface definition).
• The order or sequential behavior (parallel or serial) of the resources in relation to one another (e.g., project task execution and critical path). 
• The behavior of Resource Flow between or within organizations (e.g., work flow, information flow, etc.).
• The changes in state during the spatial and/or temporal existence of the resource.
• The rules that modify the behavior of the Resource Flow (e.g., business rules, controls, decisions, etc.).
• The measures that define the quality, constraints, timing, etc. of the Resource Flow (e.g., Quality of Service (QoS), measures of performance, measures of effectiveness, etc.).
• The flow of control orchestrating the behavior of the Resource Flow.

Data Group Description

The DoDAF Meta Model for the data comprising Resource Flows is shown in the figure below. The following should be noted:

1. Whereas prior versions of DoDAF modeled only information and data exchanges and flows, this version also allows modeling of other flows, such as:
   1. Materiel flows such as ammunition, fuel, etc. important for modeling the fire rate, logistics, etc., aspects of a Capability solution so it can be compared with other alternative solutions.
   2. Personnel Types such as Military Occupational Specialty (MOS) that allow representation of the Training and Education pipeline aspects of Doctrine, Organization, Training, Material, Leadership and Education, Personnel, and Facilities (DOTMLPF).
   3. Performers such as Services, Systems, or Organizations that might be the output or result of a Project’s design and production process (activities). This allows modeling of, for instance, an acquisition project.
2. Another difference from prior versions of DoDAF is that all exchanges and flows are by virtue of a producing or consuming Activity. Resource Flows are Activity-based, not Performer based since a Performer cannot produce or consume a resource other than by conduct of a production or consumption activity. That is, a Performer can only provide or consume by conducting an activity of production or consumption. For instance, publication and subscription are modeled as an interaction between the publishing Activity, the subscribing Activity, and the information or data Resource. Note that publication is typically not at the same time as subscription but the subscriber does have to go to the publication place to retrieve the Resource. For example, data might be published at 2:00 GMT on a server located at some URL and the subscriber may not overlap until 10:00 GMT. Also note in the diagram the overlap is a triple - the producing Activity, the Consuming Activity, and the Resource.
3. The exchange or flow triple may have standards (Rules) associated with it such as Information Assurance (IA)/Security rules or, for data publication or subscription, data COI and web services standards.
4. Rules and Measures are applied to specific Activities and their Performers. Activities, Systems and Personnel can be assigned to Locations and further can be assigned Conditions and Constraints.
5. The term flow implies that something (e.g., materiel, information) is moving from point A to point B, hence the use of the foundation concept of "overlap".
6. The exchange or flow triple may have Measures associated with it such as timeliness, throughput, reliability, or QoS.
7. Resource Flow modeling can be performed at varying levels of detail and fidelity depending on the areas of concern being analyzed and the solutions being sought. The upper-level aggregations have been termed need lines in previous versions DoDAF. Other terminology expressing levels of aggregation are used depending on the community of interest (e.g., The SysML modeling standard uses lifeline).
8. It should be noted that information inputs and outputs between resources for some levels of decomposition may be at a higher-level of abstraction than the information characteristics represented in the matrix. This is commonly done to simplify graphical representations of information flow or in the initial definition stages where the characteristics are still unknown. In this case, multiple information exchanges will map to a single resource input or output. Similarly, the information inputs and outputs between resources at a low-level of decomposition may be at a higher-level of detail than the information exchanges in the matrix, and multiple information inputs and outputs may map to a single information exchange. In these cases, to provide the necessary clarity and precision, an ontological or taxonomic structure of information aggregation should be developed for use in each level of decomposition of the Resource Flow models (e.g., The Navy Common Information Exchange List [CIEL] represents initiatives showing taxonomic structure or levels of aggregation).

DoDAF Meta Model for Resource Flow

(Click to enlarge)

Resource Flow modeling is a fundamental engineering based technique used in Information Technology (IT) Architecture, System Engineering, Process Re-engineering, Resource Planning and many other disciplines.

1. JCIDS
   1. Where are the process bottlenecks?
   2. Are the activities and procedures interoperable?
   3. Identify new and emerging systems interoperability requirements.
   4. Uncover unnecessary or inefficient operational activities and information flows.
   5. Evaluate alternative architectures with different connectivity and Resource Flow to maximize capability and minimize automation complexity.
   6. Identify critical connectivity needs and interfaces (or Key Interface Profiles (KIPs) between activities and their performers (organizations and personnel types).
   7. Critical Interfaces are generally documented in formal interface documentation signed by the responsible authorities (both information supplier and information consumer) in charge of each end of the interface. This type of interface may be annotated as a Key Interface (KI). A KI is defined as an interface where one or more of the following criteria are met:
   8. Support Analysis of Alternatives (AoA) and other Systems Engineering Analysis.
2. DAS
   1. The interface spans organizational boundaries (may be across instances of the same system, but utilized by different organizations).
   2. Support the development of test sequences and procedures.
   3. The Details of Resource Flow (materiel, personnel, or data) are generally documented in Interface Control Documents (ICDs), Interface Requirements Specifications (IRSs) and Interface Description Documents (IDDs). This data is typically provided to DoD Investment Review Board (IRB) registry systems for the purpose of milestone reviews and support of acquisition decisions points.
3. PPBE
   1. Ensure FYDP provides flows needed for operations and missions
   2. Ensure consumption requirements are met by producers
4. SE
   1. Identify new system or service, functions (activities), components and modifications required.
   2. Identify new Resource Flow and system integration requirements.
   3. Identification of the need for Application of new standards.
   4. Clearly identify the relationship and information flow between systems and system/services in an SoS or between services in a Service Oriented Architecture (SOA) including definition of publish or subscribe requirements 
   5. Interface Identification and Definition including interoperability analysis and standardization. 
   6. Support configuration management of interfaces. Interfaces are generally documented in interface documentation representing the agreements of the responsible parties in charge of each end of the interface (both information supplier and information consumer). This, in no way implies a point-to-point interface. Interfaces implemented with an enterprise service bus, for example, are defined with appropriate publish/subscribe documentation formalized, if necessary, with contractual agreements between information supplier and consumer.
   7. Critical interfaces are generally documented in formal interface documentation signed by the responsible authorities (both information supplier and information consumer) in charge of each end of the interface. For legacy point-to-point interfaces this may be in the form of Interface Control Drawings (ICDs), Interface Requirement Documents (IRSs), Interface Design Documents (IDDs), etc. In multiple access or common connectivity (radio communications or bus type connectivity) implementations may be in the form of formal agreements (defined herein as a consent among parties regarding the terms and conditions of activities that said parties participate in) detailing the specific set of implementations (e.g., Tactical Digital Information Links [TADILs]) data elements implementation tables or in the case of a SOA, a publish/subscribe implementation document. These agreements are, in general, managed and controlled by the SoS or System Project manager. In new systems, and where possible the interface should be managed and configuration controlled using a common precision data model. Figure 4 illustrates the evolution from configuration control of legacy point-to-point interfaces to a net-centric, distributed processing means of connectivity using carefully managed publish and subscribe agreements and documentation based on formally documented logical and physical data models.

Migrating from Legacy to Data Focused Configuration Management
(Click to enlarge)

5. Ops Planning
   1. Operations utilizing information flows should be technology independent. However, operations and their relationships may be influenced by new technologies. There may be some cases in which it is necessary to document the way activities are performed to examine ways in which new systems could facilitate streamlining the activities
   2. Mission Planning including simulation and training.
   3. Logistics planning.
   4. Provide a necessary foundation for depicting information needs and task sequencing to assist in producing procedures, operational plans and facilitate associated personnel training.
   5. Identify critical mission threads and operational Resource Flow exchanges by annotating which activities are critical (i.e., identify the activities in the DoDAF-described Model that are critical e.g., Critical Path).
6. CPM
   1. Resource flows can be used to represent the structural and behavioral relationships between the Activities and Performers within the portfolio including interfaces and interdependencies.

Presentation

Resource Flows are generally depicted as Structural, Behavioral and Tree models with amplifying tabular information. A generic Resource Flow presentation is shown in the figure below.

Migrating from Legacy to Data Focused Configuration Management