Department of Defense Architecture Framework

From Wikipedia, the free encyclopedia

 The external links in this article may not follow Wikipedia's content policies or guidelines.
Please improve this article by removing excessive or inappropriate external links.

The Department of Defense Architecture Framework (DoDAF) defines a standard way to organize an enterprise architecture (EA) or systems architecture into complementary and consistent views. All major U.S. Government Department of Defense (DoD) weapons and information technology system procurements are required to develop and document an EA using the views prescribed in the DoDAF. While it is clearly aimed at military systems, DoDAF has broad applicability across the private, public and voluntary sectors around the world, and represents only one of a large number of systems architecture frameworks.[1] It is especially suited to large systems with complex integration and interoperability challenges, and is apparently unique in its use of "operational views" detailing the external customer's operating domain in which the developing system will operate (reference: Zachman framework).

Contents

[edit] DoDAF overview

DoDAF is the standard framework chosen by the United States Department of Defense to comply with the Clinger-Cohen Act and United States Office of Management and Budget Circulars A-11 and A-130. It is administered by the Office of the DoD Deputy CIO Enterprise Architecture & Standards Directorate. DoDAF was formerly named C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) AF. Other derivative frameworks based on DoDAF include the NATO Architecture Framework (NAF) and Ministry of Defence (United Kingdom) Architecture Framework (MODAF).

Like other EA approaches, for example The Open Group Architecture Framework (TOGAF), DoDAF is organized around a shared repository to hold work products. The repository is defined by the Core Architecture Data Model 2.0 (CADM -- essentially a common database schema) and the DoD Architecture Repository System (DARS). A key feature of DoDAF is interoperability, which is organized as a series of levels, called Levels of Information System Interoperability (LISI). The developing system must not only meet its internal data needs but also those of the operational framework into which it is set.

[edit] Artifact Views

DoDAF views are organized into four basic view sets: overarching All View (AV), Operational View (OV), Systems View (SV), and the Technical Standards View (TV). Only a subset of the full DoDAF viewset is usually created for each system development.

[edit] All View (AV)

AV products provide overarching descriptions of the entire architecture and define the scope and context of the architecture. The AV products are defined as:

  • AV-1 Overview and Summary Information - Scope, purpose, intended users, environment depicted, analytical findings (if applicable)
  • AV-2 Integrated Dictionary - Definitions of all terms used in all products.

[edit] Operational View (OV)

OV products provide descriptions of the tasks and activities, operational elements, and information exchanges required to accomplish DoD missions. The OV provides textual and graphical representations of operational nodes and elements, assigned tasks and activities, and information flows between nodes. It defines the type of information exchanged, the frequency of exchanges, the tasks and activities supported by these exchanges and the nature of the exchanges. The OV products are defined as:

  • OV-1 High Level Operational Concept Graphic - High level graphical and textual description of operational concept (high level organizations, missions, geographic configuration, connectivity, etc).
  • OV-2 Operational Node Connectivity Description - Operational nodes, activities performed at each node, and connectivites and information flow between nodes.
  • OV-3 Operational Information Exchange Matrix - Information exchanged between nodes and the relevant attributes of that exchange such as media, quality, quantity, and the level of interoperability required.
  • OV-4 Organizational Relationships Chart - Command, control, coordination, and other relationships among organizations.
  • OV-5 Operational Activity Model - Activities, relationships among activities, inputs and outputs. In addition, overlays can show cost, performing nodes, or other pertinent information.
  • OV-6a Operational Rules Model - One of the three products used to describe operational activity sequence and timing that identifies the business rules that constrain the operation.
  • OV-6b Operational State Transition Description - One of the three products used to describe operational activity sequence and timing that identifies responses of a business process to events.
  • OV-6c Operational Event-Trace Description - One of the three products used to describe operational activity sequence and timing that traces the actions in a scenario or critical sequence of events.
  • OV-7 Logical Data Model - Documentation of the data requirements and structural business process rules of the Operational View.

[edit] Systems and Services View (SV)

SV is a set of graphical and textual products that describe systems and services and interconnections providing for, or supporting, DoD functions. SV products focus on specific physical systems with specific physical (geographical) locations. The relationship between architecture data elements across the SV to the OV can be exemplified as systems are procured and fielded to support organizations and their operations.The SV products are:

  • SV-1 Systems/Services Interface Description - Depicts systems nodes and the systems resident at these nodes to support organizations/human roles represented by operational nodes of the OV-2. SV-1 also identifies the interfaces between systems and systems nodes.
  • SV-2 Systems/Services 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 implements 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, Services-Systems, Services-Services Matrices - provides detail on the interface characteristics described in SV-1 for the architecture, arranged in matrix form.
  • SV-4a/SV-4b Systems/Services Functionality Description - The SV-4a documents system functional hierarchies and system functions, and the system data flows between them. The SV-4 from DoDAF v1.0 is designated as 'SV-4a' in DoDAF v1.5. Although there is a correlation between OV-5 or business-process hierarchies and the system functional hierarchy of SV-4a, it need not be a one-to-one mapping, hence, the need for the Operational Activity to Systems Function Traceability Matrix (SV-5a), which provides that mapping.
  • SV-5a, SV-5b, SV-5c Operational Activity to Systems Function, Operational Activity to Systems and Services Traceability Matrices - Operational Activity to SV-5a and SV-5b is a specification of the relationships between the set of operational activities applicable to an architecture and the set of system functions applicable to that architecture. The SV-5 and extension to the SV-5 from DoDAF v1.0 is designated as 'SV-5a' and ‘SV-5b’ in DoDAF v1.5 respectively.
  • SV-6 Systems/Services 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/Services Performance Parameters Matrix - 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. Performance parameters include all technical performance characteristics of systems for which requirements can be developed and specification defined. The complete set of performance parameters may not be known at the early stages of architecture definition, so it should be expected that this product will be updated throughout the system’s specification, design, development, testing, and possibly even its deployment and operations life-cycle phases.
  • SV-8 Systems/Services 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/Services Technology Forecast - Defines the underlying current and expected supporting technologies that have been targeted using standard forecasting methods. 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/Services Rules Model - Describes the rules under which the architecture or its systems behave under specified conditions.
  • SV-10b Systems/Services State Transition Description - 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/Services 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 and Services View may reflect system-specific aspects or refinements of critical sequences of events described in the Operational View.
  • SV-11 Physical Schema - 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.

[edit] Technical Standards View (TV)

TV products define technical standards, implementation conventions, business rules and criteria that govern the architecture. The TV products are as follows:

  • TV-1 Technical Standards Profile - Extraction of standards that applies to the given architecture.
  • TV-2 Technical Standards Forecast - Description of emerging standards that are expected to apply to the given architecture, within an appropriate set of timeframes.

[edit] Creating an integrated architecture using DoDAF

DoDAF v1.0 listed the following products as the “minimum set of products required to satisfy the definition of an OV, SV and TV.” One note: while the DoDAF does not list the OV-1 artifact as a core product, its development is strongly encouraged. The sequence of the artifacts listed below gives a suggested order in which the artifacts could be developed. The actual sequence of view generation and their potential customization is a function of the application domain and the specific needs of the effort.

  • AV-1 Overview and Summary Information
  • AV-2 Integrated Dictionary
  • OV-1 High Level Operational Concept Graphic
  • OV-5 Operational Activity Model
  • OV-2 Operational Node Connectivity Description
  • OV-3 Operational Informational Exchange Matrix
  • SV-1 System Interface Description
  • TV-1 Technical Standards Profile

One concern about the DoDAF is how well these products meet actual stakeholder concerns for any given system of interest. One can view DoDAF products, or at least the 3 views, as ANSI/IEEE 1471-2000 or ISO/IEC 42010 viewpoints. But to build an architecture description that corresponds to ANSI/IEEE 1471-2000 or ISO/IEC 42010, it is necessary to clearly identify the stakeholders and their concerns that map to each selected DoDAF product. Otherwise there is the risk (seen in at least some DoDAF architecture efforts) of producing products with no customers.

[edit] Representation

Representations for the DoDAF products may be drawn from many diagramming techniques including: tables, ICAM Definition Language, Entity-Relationship Diagrams (ERDs), UML/ SysML, and other custom techniques depending on the product, tool used, and contractor/customer preferences. There is a UPDM (UML Profile for DoDAF and MODAF) effort within the OMG to standardize the representation of DoDAF products when UML is used. DoDAF generically describes in the representation of the artifacts to be generated, but allows considerable flexibility regarding the specific formats and modeling techniques. The DoDAF deskbook provides examples in using traditional systems engineering and data engineering techniques, and secondly, UML format. DoDAF proclaims latitude in work product format, without professing one diagramming technique over another.

In addition to graphical representation, there is typically a requirement to provide metadata to the Defense Information Technology Portfolio Repository (DITPR) or other architectural repositories.

[edit] Versions and timeline

  • October 2003: Version 1.0 was released, DODAF supplanting C4ISR.
  • February 9, 2004: Version 1.0 was released, 'Volume I: Definitions and Guidelines' (87 pages), 'Volume II: Product Descriptions' (254 pages), and 'Deskbook' (296 pages)
  • April 23, 2007: Version 1.5 was released, 'Volume I: Definitions and Guidelines' (46 pages), 'Volume II: Product Descriptions' (284 pages), and 'Volume III: Architecture Data Description' (223 pages)

[edit] Relationship to other architecture frameworks

The UPDM (UML Profile for DoDAF and MODAF) is an OMG initiative to standardize UML and SysML usage for USA and UK defense architecture frameworks. In addition, the multi-national IDEAS Group, which is supported by Australia, Canada, UK, USA, with NATO observers, has launched an initiative to develop a formal ontology for enterprise architectures.

[edit] See also

[edit] References

  1. ^ Architecture Framework FAQ. Retrieved on 2007-08-07.

[edit] External links

  • DoDAF Promulgation Memo Feb 9, 2004 - The DODAF Policy Directive which mandates that all DoD architectures approved after 12/01/03 must be DODAF compliant.
  • DoDAF 1.5 Volume 1 - Provides definitions, guidelines, background material.
  • DoDAF 1.5 Volume 2 - Describes each architecture product.
  • DoDAF 1.5 Volume 3 - Provides the architecture data description.
  • DoDAF 1.0 Deskbook - Provides supplementary "how to" information relating to architectures. The DODAF architecture documents were updated on April 23, 2007 to version 1.5. Currently the Deskbook, which is from February 9, 2004, has not been updated. This link is only to the Final Draft version August 30, 2003 - not the Feb 9, '04 version
  • DoDAF section of Architecture Framework Forum Information resource dedicated to DoDAF as it relates to other architecture frameworks (e.g., MODAF, TOGAF, Zachman).
  • DoD BEA v5.0 - DoD Business Enterprise Architecture BEA 5.0 (March 2008)
Languages