Jump to content

Department of Defense Architecture Framework

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Deemery (talk | contribs) at 14:38, 31 May 2007 (Added reference to ISO/IEC 42010 as 'synonym' of IEEE 1471. (Also created ISO/IEC 42010 page and pointed it back to IEEE 1471)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

The Department of Defense Architecture Framework (DoDAF) is a framework for development of a systems architecture or enterprise architecture (EA). All major U.S. Government Department of Defense (DoD) weapons and information technology system procurements are required to develop an EA and document that architecture using the set of views prescribed in the DoDAF. While it is clearly aimed at military systems, it 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. 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 (ref. Zachman framework).

DoDAF overview

DoDAF is the implementation chosen by the United States Department of Defense to gain compliance with the Clinger-Cohen Act and United States Office of Management and Budget Circulars A-11 and A-130. It is administered by the Undersecretary of Defense for Business Transformation's DoDAF Working Group. 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.

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.

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.

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.

Systems View (SV)

SV products provide graphical and textual descriptions of systems and system interconnections that provide or support DoD functions. Interconnections between systems defined in the OV are described in the SVs. The SV products are:

  • SV-1 System Interface Description - Identification of systems and system components and their interfaces, within and between nodes.
  • SV-2 Systems Communications Description - Physical nodes and their related communications lay downs.
  • SV-3 Systems-Systems Matrix - Relationships among systems in a given architecture. It can be designed to show relationships of interest, e.g., system-type interfaces, planned existing interfaces, etc.
  • SV-4 Systems Functionality Description - Functions performed by systems and the information flow among system functions.
  • SV-5 Operational Activity to Systems Functionality Traceability Matrix - Mapping of system functions back to operational activities.
  • SV-6 Systems Data Exchange Matrix - Detailing of data exchanges among system elements and applications allocated to system elements.
  • SV-7 Systems Performance Parameters Matrix - Performance Characteristics of each system's hardware and software elements, for the appropriate timframes.
  • SV-8 Systems Evolution Description - Planned incremental steps toward migrating a suite of systems to a more efficient suite, or toward evolving a current system to a future implementation.
  • SV-9 Systems Technology Forecast - Emerging technologies and software and hardware products that are expected to be available in a given set of timeframes, and that will affect future development of the architecture.
  • SV-10a Systems Rules Model - One of three products used to describe systems activity sequence and timing -- Constraints that are imposed on systems functionality due to some aspect of systems design or implementation.
  • SV-10b Systems State Transition Description - One of three products used to describe systems activity sequence and timing -- Responses of a system to events.
  • SV-10c Systems Event-Trace Description - One of three products used to describe systems activity sequence and timing -- System specific refinements of critical sequences of events described in the operational view.
  • SV-11 Physical Schema - Physical implementation of the information of the Logical Data Model, e.g., message formats, file structures, and physical schema.

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.

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
  • AV-2
  • OV-1
  • OV-5
  • OV-2
  • OV-3
  • SV-1
  • TV-1

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.

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.

Versions and timeline

  • October 2003. Version 1.0 was released, DODAF supplanting C4ISR.
  • February 2004. Release of 'Definitions and Guidelines' (87 pages) and 'Product Descriptions' (254 pages)

Harmonization between national architecture frameworks

There is an OMG effort to standardise a UML Profile for military architecture frameworks UPDM (UML Profile for DoDAF and MODAF). In addition, the IDEAS Group is a four nation (Australia, Canada, UK, USA + NATO as observers) effort to standardise a conceptual model for military architecture frameworks.

See also


Tools

A number of development tools help enterprise architects create the artifacts; some of these are listed below.

Other tools provide full repositories of these artifacts.

Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Department_of_Defense_Architecture_Framework&oldid=134818895"