DoDAF Architecting

The System View (SV)-1 “Systems Interface Description” addresses the composition and interaction of Systems. The SV-1 incorporates the human elements as types of Performers – Organizations and Personnel Types. Guide: DoDAF Architecture Framework Version 2.02 – Page 204 The SV-1 links together the operational and systems architecture models by depicting how Resources are structured and […]

DoDAF Services Viewpoint (SvcV) describes services and their interconnections providing or supporting DoD functions. DoD functions include both warfighting and business functions. The Service Models associate service resources to operational and capability requirements. These resources support the operational activities and facilitate the exchange of information. The relationship between architectural data elements across the Services Viewpoint

The Standards Viewpoint (StdV) StdV-2 contains expected changes in technology-related standards, operational standards, or business standards and conventions, which are documented in the StdV-1 model. The forecast for evolutionary changes in the standards need to be correlated against the time periods mentioned in the: SV-8 Systems Evolution Description SvcV-8 Services Evolution Description SV-9 Systems Technology

The Standards Viewpoint (StdV) StdV-1 defines the technical, operational, and business standards, guidance, and policy applicable to the architecture being described. It also documents the policies and standards that apply to the operational or business context. The intended usage of the StdV-1 includes: Application of standards (informing project strategy). Standards compliance. Guide: DoDAF Architecture Framework

The Standards Viewpoint (StdV) is the set of rules governing the arrangement, interaction, and interdependence of parts or elements of the Architectural Description. These sets of rules can be captured at the enterprise level and applied to each solution. Its purpose is to ensure that a solution satisfies a specified set of operational or capability

A Reference Architecture guides and constrains the development of Solution Architectures. There may be multiple Reference Architectures within a subject area where each represents a different emphasis or viewpoint. They can be defined at many levels of detail and abstraction (from specific to generalized) and for many different purposes. They help provide: [1] A common

The PV-3 “Project to Capability Mapping” supports the acquisition and deployment processes, including the management of dependencies between projects and the integration of all relevant project and program elements to achieve a capability. It maps programs, projects, portfolios, or initiatives to capabilities to show how the specific elements help to achieve a capability. Programs, projects,

The PV-1 “Project Portfolio Relationships” represents an organizational perspective on programs, projects, portfolios, or initiatives. It enables the user to model the organizational structures needed to manage programs, projects, portfolios, or initiatives. It shows dependency relationships between the actual organizations that own the programs, projects, portfolios, or initiatives. This model could be used to represent

The PV-2 “Project Timelines” provides a timeline perspective on programs. The PV-2 is intended primarily to support the acquisition and fielding processes including the management of dependencies between projects and the integration of DoD Directive 5000.1 “Defense Acquisition System” policies to achieve a successfully integrated capability. The PV-2 is not limited to the acquisition and

  The physical architecture is the physical layout of a system and its components in a schema.  It refers to some  representation of the structure or organization of the physical elements of the system.  The physical architecture should be part of the Allocated and Product Baselines. SMC Systems Engineering Handbook Example – Page 25 The

The Project Viewpoint (PV) describe how programs, projects, portfolios, or initiatives deliver capabilities and the organizations contributing to them and the dependencies between them. These models expand the usability of the DoDAF by including information about programs, projects, portfolios, or initiatives and relating that information to capabilities and other programs, projects, portfolios, or initiatives. This expands

The OV-6c “Event-Trace Description” provides a time-ordered examination of the Resource Flows as a result of a particular scenario. Each event-trace diagram should have an accompanying description that defines the particular scenario or situation. Operational Event/Trace Descriptions, sometimes called sequence diagrams, event scenarios, or timing diagrams, allow the tracing of actions in a scenario or

The OV-6b “State Transition Description” is a graphical method of describing how an Operational Activity responds to various events by changing its state. The diagram represents the sets of events to which the Activities respond (by taking an action to move to a new state) as a function of its current state. Each transition specifies

The OV-5a “Operational Activity Model” and the OV-5b describe the operations that are normally conducted in the course of achieving a mission or a business goal. It describes operational activities (or tasks); Input/Output flows between activities, and to/from activities that are outside the scope of the Architectural Description. Guide: DoDAF Architecture Framework Version 2.02 –

The OV-5a and the OV-5b “Operational Activity Model” describe the operations that are normally conducted in the course of achieving a mission or a business goal. It describes operational activities (or tasks); Input/Output flows between activities, and to/from activities that are outside the scope of the Architectural Description. Guide: DoDAF Architecture Framework Version 2.02 –

An OV-6a “Operational Rules Model” specifies operational or business rules that are constraints on the way that business is done in the enterprise. At a top-level, rules should at least embody the concepts of operations defined in OV-1 “High Level Operational Concept Graphic” and provide guidelines for the development and definition of more detailed rules

The OV-3 “Operational Resource Flow Matrix” addresses operational Resource Flows exchanged between Operational Activities and locations. Resource Flows provide further detail of the interoperability requirements associated with the operational capability of interest. The focus is on Resource Flows that cross the capability boundary. The intended usage of the OV-3 includes: Definition of interoperability requirements Guide: DoDAF

The OV-4 “Organizational Relationship Chart” shows organizational structures and interactions and may be civil or military. The OV-4 exists in two (2) forms: Role-based (e.g., a typical brigade command structure) and Actual (e.g., an organization chart for a department or agency). Guide: DoDAF Architecture Framework Version 2.02 – Page 150  A role-based OV-4 shows the possible

The OV-2 “Operational Resource Flow Description” applies the context of the operational capability to a community of anticipated users. The primary purpose of the OV-2 is to define capability requirements within an operational context. The OV-2 may also be used to express a capability boundary. Guide: DoDAF Architecture Framework Version 2.02 – Page 144 New

The OV-1 “High Level Operational Concept Graphic” describes a mission, class of mission, or scenario. It shows the main operational concepts and interesting or unique aspects of operations. It describes the interactions between the subject architecture and its environment, and between the architecture and external systems. The OV-1 is the pictorial representation of the written

A Functional Architecture is an architectural model that identifies system functions and their interactions. It defines how the functions will operate together to perform the system mission(s) and is a framework for organizing information, processes, or different solution modules into an enterprise system. A functional architecture depicts a system that emphasizes its functions and how they

An Enterprise Architecture (EA) describes the “current architecture” and “target architecture,” and provides a strategy that will enable an agency to transition from its current state to its target environment. The Office of Management and Budget defines enterprise architecture as the explicit description and documentation of the current and desired relationships among business and management

The DoDAF Meta Model (DM2) defines architectural data elements and enables the integration and federation of Architectural Descriptions. It establishes a basis for semantic (i.e., understanding) consistency within and across Architectural Descriptions. Website: DoDAF Meta Model (DM2) The purposes of the DM2 are: Establish and define the constrained vocabulary for description and discourse about DoDAF

The DIV-2 Logic Data Model allows analysis of an architecture’s data definition aspect, without consideration of implementation specific or product specific issues.  Another purpose is to provide a common dictionary of data definitions to consistently express models wherever logical-level data elements are included in the descriptions. Guide: DoDAF Architecture Framework Version 2.02 – Page 135

The DIV-3 defines the structure of the various kinds of system or service data that are utilized by the systems or services in the Architectural Description. The Physical Schema is one of the models closest to actual system design in DoDAF. It’s used to describe how the information represented in the DIV-2 “Logical Data Model”