Department of Defense Architecture Framework
Encyclopedia
The Department of Defense Architecture Framework (DoDAF) is an architecture framework
Architecture framework
An enterprise architecture framework is a framework for an enterprise architecture which defines how to organize the structure and views associated with an enterprise architecture.- Overview :...

 for the United States Department of Defense
United States Department of Defense
The United States Department of Defense is the U.S...

, that provides structure for a specific stakeholder concern through viewpoints organized by various views
View model
A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation...

.

DoDAF defines a set of views
View model
A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation...

 that act as mechanisms for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular
Table (information)
A table is a means of arranging data in rows and columns.Production % of goalNorth 4087102%South 4093110% The use of tables is pervasive throughout all communication, research and data analysis. Tables appear in print media, handwritten notes, computer software, architectural...

, structural, behavioral, ontological, pictorial
Image
An image is an artifact, for example a two-dimensional picture, that has a similar appearance to some subject—usually a physical object or a person.-Characteristics:...

, temporal
Timeline
A timeline is a way of displaying a list of events in chronological order, sometimes described as a project artifact . It is typically a graphic design showing a long bar labeled with dates alongside itself and events labeled on points where they would have happened.-Uses of timelines:Timelines...

 or graphical
Graphical model
A graphical model is a probabilistic model for which a graph denotes the conditional independence structure between random variables. They are commonly used in probability theory, statistics—particularly Bayesian statistics—and machine learning....

 means.

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.

Overview

The Department of Defense Architecture Framework (DoDAF) provides a foundational framework for developing and representing architecture descriptions that ensure a common denominator for understanding, comparing, and integrating architectures across organizational, Joint, and multinational boundaries. It establishes data element definitions, rules, and relationships and a baseline set of products for consistent development of systems, integrated, or federated architectures. These architecture descriptions may include Families of Systems (FoS), Systems of Systems (SoS), and net-centric capabilities for interoperating and interacting in the NCE.

All major U.S.
United States
The United States of America is a federal constitutional republic comprising fifty states and a federal district...

 Government Department of Defense
United States Department of Defense
The United States Department of Defense is the U.S...

 (DoD) weapons and information technology system acquisitions 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 one of a large number of systems architecture frameworks.
The purpose of DoDAF is to define concepts and models usable in DoD’s six core processes:
  1. Capabilities Integration and Development (JCIDS)
  2. Planning, Programming, Budgeting, and Execution (PPBE)
  3. Acquisition System (DAS)
  4. Systems Engineering (SE)
  5. Operations Planning
  6. Capabilities Portfolio Management (CPM)


In addition, DoDAF 2.0’s specific goals were to:
  1. Establish guidance for architecture content as a function of purpose – “fit for purpose”
  2. Increase utility and effectiveness of architectures via a rigorous data model – the DoDAF Meta Model (DM2) -- so the architectures can be integrated, analyzed, and evaluated to mathematical precision.


History

Note, where the diagram states TBD, the DoDAF V2.0 was promulgated on May 28, 2009.
The first version of the development DoDAF was developed in the 1990s under the name C4ISR
C4ISR
C4ISR may refer to:* the C4ISR concept of Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance, the U.S. term for C4ISTAR* C4ISR Journal, a journal published by the Defense News Media Group...

 architectural Architecture Framework. C4ISR stand for The Command, Control, Communications, Computers, and Intelligence, Surveillance, and Reconnaissance. In the same period the reference model TAFIM
TAFIM
Technical Architecture Framework for Information Management is a 1990s reference model for enterprise architecture development, defined by the United States Department of Defense in 1986....

, which was initiated in 1986, was further developed. The first C4ISR Architecture Framework v1.0, released 7 June 1996, was created in response to the passage of the Clinger-Cohen Act
Clinger-Cohen Act
The Clinger–Cohen Act , formerly the Information Technology Management Reform Act of 1996 , is a 1996 United States federal law, designed to improve the way the federal government acquires, uses and disposes information technology ....

. It addressed the 1995 Deputy Secretary of Defense directive that a DoD-wide effort be undertaken to define and develop a better means and process for ensuring that C4ISR capabilities were interoperable and met the needs of the warfighter. Continued development effort resulted in December 1997 in the second version, C4ISR Architecture Framework v2.0.

In August 2003 the DoDAF v1.0 was released, which restructured the C4ISR Framework v2.0 to offer guidance, product descriptions, and supplementary information in two volumes and a Desk Book. It broadened the applicability of architecture tenets and practices to all Mission Areas rather than just the C4ISR community. This document addressed usage, integrated architectures, DoD and Federal policies, value of architectures, architecture measures, DoD decision support processes, development techniques, analytical techniques, and the CADM v1.01, and moved towards a repository-based approach by placing emphasis on architecture data elements that comprise architecture products.

In February 2004 the documentation of Version 1.0 was released with volume "I: Definitions and Guidelines", "II: Product Descriptions" and a "Deskbook". In April 2007 the Version 1.5 was released with a documentation of "Definitions and Guidelines", "Product Descriptions" and "Architecture Data Description".

On May 28, 2009 DoDAF v2.0 was approved by the Department of Defense.
DoDAF V2.0 is published on a public website.

Other derivative frameworks based on DoDAF include the NATO Architecture Framework
NATO Architecture Framework
The NATO Architecture Framework is an Enterprise Architecture framework by the NATO derived from the DoDAF Enterprise architecture.The current NATO C3 System Architecture Framework v2 , issued by NATO in September 2004 provides guidance on describing communication and information systems...

 (NAF) and Ministry of Defence (United Kingdom)
Ministry of Defence (United Kingdom)
The Ministry of Defence is the United Kingdom government department responsible for implementation of government defence policy and is the headquarters of the British Armed Forces....

 Architecture Framework (MODAF
MODAF
The British Ministry of Defence Architecture Framework is an Architecture Framework which defines a standardised way of conducting Enterprise Architecture, originally developed by the UK Ministry of Defence....

). Like other EA approaches, for example The Open Group Architecture Framework (TOGAF
TOGAF
The Open Group Architecture Framework is a framework for enterprise architecture which provides a comprehensive approach for designing, planning, implementation, and governance of an enterprise information architecture...

), DoDAF is organized around a shared repository to hold work products. The repository is defined by the Core Architecture Data Model
Core Architecture Data Model
Core architecture data model in enterprise architecture is a logical data model of information used to describe and build architectures....

 2.0 (CADM -- essentially a common database schema) and the DoD Architecture Registry 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.

DoDAF V1.5 Views

The DoDAF V1.5 defines a set of products, a view model
View model
A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation...

, that act as mechanisms for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through graphic, tabular, or textual means. These products are organized under four views:
  • overarching All View (AV)
  • Operational View
    Operational View
    Operational View is one of the basic views, defined in the enterprise architecture of the Department of Defense Architecture Framework V1.5 . Under DODAF 2, which became operational in 2009, the collections of views are now termed 'viewpoints' and no longer views.Other enterprise architecture...

     (OV)
  • Systems View (SV)
  • Technical Standards View (TV)

Each view depicts certain perspectives of an architecture as described below. Only a subset of the full DoDAF viewset is usually created for each system development. The figure represents the information that links the operational view, systems and services view, and technical standards view. The three views and their interrelationships – driven by common architecture data elements – provide the basis for
deriving measures such as interoperability or performance, and for measuring the impact of the values of these metrics on operational mission and task effectiveness.

All View (AV)

AV products provide overarching descriptions of the entire architecture and define the scope and context of the architecture. The DoDAF V1.5 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)

Operational View
Operational View
Operational View is one of the basic views, defined in the enterprise architecture of the Department of Defense Architecture Framework V1.5 . Under DODAF 2, which became operational in 2009, the collections of views are now termed 'viewpoints' and no longer views.Other enterprise architecture...

 (OV) products provide descriptions of the tasks and activities, operational elements, and information exchanges required to accomplish DoD
United States Department of Defense
The United States Department of Defense is the U.S...

 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 DoDAF V1.5 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 connectivities 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. (In DoDAF V1.5. This corresponds to DIV-2 in DoDAF V2.0.)

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
United States Department of Defense
The United States Department of Defense is the U.S...

 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 DoDAF V1.5 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. (In DoDAF V1.5. This corresponds to DIV-3 in DoDAF V2.0.)

Technical Standards View (TV)

TV products define technical standards, implementation conventions, business rules and criteria that govern the architecture. The DoDAF V1.5 TV products are as follows:
  • TV-1 Technical Standards Profile - Extraction of standards that applies to the given architecture. (In DoDAF V1.5. Renamed to StdV-1 in DoDAF V2.0.)
  • TV-2 Technical Standards Forecast - Description of emerging standards that are expected to apply to the given architecture, within an appropriate set of timeframes. (In DoDAF V1.5. Renamed to StdV-2 in DoDAF V2.0.)

DoDAF V2.0 Viewpoints

In DoDAF V2.0 architectural viewpoints are composed of data that has been organized to facilitate understanding. To align with ISO Standards, where appropriate, the terminology has changed from Views to Viewpoint (e.g., the Operational View is now the Operational Viewpoint).
  • All Viewpoint (AV) - Describes the overarching aspects of architecture context that relate to all viewpoints.

  • Capability Viewpoint (CV) (New in DoDAF V2.0) - Articulates the capability requirements, the delivery timing, and the deployed capability.

  • Data and Information Viewpoint (DIV) (New in DoDAF V2.0) - Articulates the data relationships and alignment structures in the architecture content for the capability and operational requirements, system engineering processes, and systems and services.

  • Operational Viewpoint (OV) - Includes the operational scenarios, activities, and requirements that support capabilities.

  • Project Viewpoint (PV) (New in DoDAF V2.0) - Describes the relationships between operational and capability requirements and the various projects being implemented. The Project Viewpoint also details dependencies among capability and operational requirements, system engineering processes, systems design, and services design within the Defense Acquisition System process.

  • Services Viewpoint (SvcV) (New in DoDAF V2.0) - Presents the design for solutions articulating the Performers, Activities, Services, and their Exchanges, providing for or supporting operational and capability functions.

  • Standards Viewpoint (StdV) (Renamed from Technical Standards View TV) - Articulates the applicable operational, business, technical, and industry policies, standards, guidance, constraints, and forecasts that apply to capability and operational requirements, system engineering processes, and systems and services.

  • Systems Viewpoint (SV) - Articulates, for Legacy support, the design for solutions articulating the systems, their composition, interconnectivity, and context providing for or supporting operational and capability functions.

Note, System has changed in DoDAF V2.0 from DoDAF V1.5: System is not just computer hardware and
computer software. System is now defined in the general sense of an assemblage of components - machine, human - that perform activities (since they are subtypes of Performer) and are interacting or interdependent. This could be anything, i.e., anything from small pieces of equipment that have interacting or interdependent elements, to Family of Systems (FoS) and System of Systems (SoS). Note that Systems are made up of Materiel (e.g., equipment, aircraft, and vessels) and Personnel Types.

Relationship of DoDAF V1.5 Views with DoDAF V2.0 Viewpoints

The first figure shows the overall evolution of DoDAF V1.5 Views to DoDAF V2.0 Viewpoints.
The second figure shows the specific mapping of individual DoDAF V1.5 Views to the corresponding DoDAF V2.0 Viewpoints.

DoDAF V1.5 Support. The architectures for DoDAF V1.0 and DoDAF V1.5 may continue to be used. When appropriate (usually indicated by policy or by the decision-maker), DoDAF V1.0 and V1.5 architectures will need to update their architecture. When pre-DoDAF V2.0 architecture is compared with DoDAF V2.0 architecture, concept differences (such as Node) must be defined or explained for the newer architecture.

In regard to DoDAF V1.5 products, they have been transformed into parts of the DoDAF V2.0 models. In most cases, the DoDAF V2.0 Meta-model supports the DoDAF V1.5 data concepts, with one notable exception: Node. Node is a complex, logical concept that is represented with more concrete concepts. The table below indicates the mapping of DoDAF V1.5 products to DoDAF V2.0 models.

Creating an integrated architecture using DoDAF

There are many different approaches for creating an integrated architecture using DoDAF, and for determining which products are required. The approach depends on the requirements and the expected results; i.e., what the resulting architecture will be used for.
As one example, the 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
Stakeholder analysis
Stakeholder analysis in conflict resolution, project management, and business administration, is the process of identifying the individuals or groups that are likely to affect or be affected by a proposed action, and sorting them according to their impact on the action and the impact the action...

 concerns for any given system of interest. One can view DoDAF products, or at least the 3 views, as ANSI/IEEE 1471-2000
IEEE 1471
IEEE 1471 is an IEEE Standard for describing the architecture of a software-intensive system, also known as software architecture.- Overview :...

 or ISO/IEC 42010
ISO/IEC 42010
ISO/IEC/IEEE 42010 Systems and software engineering — Architecture description is an international standard for architecture descriptions of systems and software.-Overview:...

 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.
The figure "DoDAF V1.5 Products Matrix" shows how the DoD Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 6212.01E specifies which DoDAF V1.5 products are required for each type of analysis, in the context of the Net-Ready Key Performance Parameter (NR-KPP):
  • Initial Capabilities Document (ICD). Documents the need for a materiel solution to a specific capability gap derived from an initial analysis of alternatives executed by the operational user and, as required, an independent analysis of alternatives. It defines the capability gap in terms of the functional area, the relevant range of military operations, desired effects, and time.
  • Capability Development Document (CDD). A document that captures the information necessary to develop a proposed program(s), normally using an evolutionary acquisition strategy. The CDD outlines an affordable increment of militarily useful, logistically supportable and technically mature capability.
  • Capability Production Document (CPD). A document that addresses the production elements specific to a single increment of an acquisition program.
  • Information Support Plan (ISP). The identification and documentation of information needs, infrastructure support, IT and NSS interface requirements and dependencies focusing on net-centric, interoperability, supportability and sufficiency concerns (DODI 4630.8).
  • Tailored Information Support Plan (TISP). The purpose of the TISP process is to provide a dynamic and efficient vehicle for certain programs (ACAT II and below) to produce requirements necessary for I&S Certification. Select program managers may request to tailor the content of their ISP (ref ss). For programs not designated OSD special interest by ASD (NII)/DOD CIO, the component will make final decision on details of the tailored plan subject to minimums specified in the TISP procedures linked from the CJCSI 6212 resource page and any special needs identified by the J-6 for the I&S certification process.

Representation

Representations for the DoDAF products may be drawn from many diagramming techniques including:
  • tables
    Table (database)
    In relational databases and flat file databases, a table is a set of data elements that is organized using a model of vertical columns and horizontal rows. A table has a specified number of columns, but can have any number of rows...

    ,
  • IDEF
    IDEF
    IDEF, an abbreviation of Integration Definition, refers to a family of modeling languages in the field of systems and software engineering. They cover a wide range of uses, from functional modeling to data, simulation, object-oriented analysis/design and knowledge acquisition. These "definition...

    ,
  • Entity-Relationship Diagrams
    Entity-relationship model
    In software engineering, an entity-relationship model is an abstract and conceptual representation of data. Entity-relationship modeling is a database modeling method, used to produce a type of conceptual schema or semantic data model of a system, often a relational database, and its requirements...

     (ERDs),
  • UML
    Unified Modeling Language
    Unified Modeling Language is a standardized general-purpose modeling language in the field of object-oriented software engineering. The standard is managed, and was created, by the Object Management Group...

    ,
  • SysML,

and other custom techniques depending on the product, tool used, and contractor/customer preferences. There is a UPDM
UPDM
The Unified Profile for DoDAF/MODAF is the product of an Object Management Group ] initiative to develop a modeling standard that supports both the USA Department of Defense Architecture Framework and the UK Ministry of Defence Architecture Framework...

 (Unified Profile for DoDAF and MODAF) effort within the OMG
Object Management Group
Object Management Group is a consortium, originally aimed at setting standards for distributed object-oriented systems, and is now focused on modeling and model-based standards.- Overview :...

 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
Systems engineering
Systems engineering is an interdisciplinary field of engineering that focuses on how complex engineering projects should be designed and managed over the life cycle of the project. Issues such as logistics, the coordination of different teams, and automatic control of machinery become more...

 and data engineering
Information engineering
Information engineering or information engineering methodology in software engineering is an approach to designing and developing information systems.-Overview:...

 techniques, and secondly, UML
Unified Modeling Language
Unified Modeling Language is a standardized general-purpose modeling language in the field of object-oriented software engineering. The standard is managed, and was created, by the Object Management Group...

 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
Metadata
The term metadata is an ambiguous term which is used for two fundamentally different concepts . Although the expression "data about data" is often used, it does not apply to both in the same way. Structural metadata, the design and specification of data structures, cannot be about data, because at...

 to the Defense Information Technology Portfolio Repository (DITPR) or other architectural repositories.

Meta-Model

DoDAF has always had some form of Meta-Model underpinning the framework. The meta-model defines the types of modelling elements that can be used in each view and the relationships between them.

DoDAF versions 1.0 thru 1.5 used the CADM meta-model, which was defined in IDEF1X
IDEF1X
IDEF1X is a data modeling language for the developing of semantic data models. IDEF1X is used to produce a graphical information model which represents the structure and semantics of information within an environment or system.IDEF1X permits the construction of semantic data models which may serve...

 (then later in UML
Unified Modeling Language
Unified Modeling Language is a standardized general-purpose modeling language in the field of object-oriented software engineering. The standard is managed, and was created, by the Object Management Group...

) with an XML Schema
XML Schema
XML Schema, published as a W3C recommendation in May 2001, is one of several XML schema languages. It was the first separate schema language for XML to achieve Recommendation status by the W3C...

 derived from the resulting relational database.

From version 2.0, DoDAF has adopted the IDEAS Group
IDEAS Group
The IDEAS Group is the International Defence Enterprise Architecture Specification for exchange Group. The deliverable of the project is a data exchange format for military Enterprise Architectures. The scope is four nation and covers MODAF , DoDAF , and the Australian Defence Architecture...

 foundation ontology as the basis for its new meta-model. This new meta-model is called "DM2"; an acronym for "Defense Meta-Model".

Diagram of DoDAF V2.0 Meta Model DM2's Three Levels.

Each of these three levels of the DM2 is important to a particular viewer of Departmental processes:
  1. The conceptual level or Conceptual Data Model (CDM) defines the high-level data constructs from which Architectural Descriptions are created in non-technical terms, so that executives and managers at all levels can understand the data basis of Architectural Description. Represented in the DoDAF V2.0 DIV-1 Viewpoint.
  2. The Logical Data Model (LDM) adds technical information, such as attributes to the CDM and, when necessary, clarifies relationships into an unambiguous usage definition. Represented in the DoDAF V2.0 DIV-2 Viewpoint.
  3. The Physical Exchange Specification (PES) consists of the LDM with general data types specified and implementation attributes (e.g., source, date) added, and then generated as an XSD. Represented in the DoDAF V2.0 DIV-3 Viewpoint.


The purposes of the DM2 are:
  1. Establish and define the constrained vocabulary for description and discourse about DoDAF models (formerly “products”) and their usage in the 6 core processes
  2. Specify the semantics and format for federated EA data exchange between:architecture development and analysis tools and architecture databases across the DoD Enterprise Architecture (EA) Community of Interest (COI) and with other authoritative data sources
  3. Support discovery and understandability of EA data:
    1. Discovery of EA data using DM2 categories of information
    2. Understandability of EA data using DM2’s precise semantics augmented with linguistic traceability (aliases)
  4. Provide a basis for semantic precision in architectural descriptions to support heterogeneous architectural description integration and analysis in support of core process decision making.


The 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. In this manner, the DM2 supports the exchange and reuse of architectural information among JCAs, Components, and Federal and Coalition partners, thus facilitating the understanding and implementation of interoperability of processes and systems. As the DM2 matures to meet the ongoing data requirements of process owners, decision makers, architects, and new technologies, it will to a resource that more completely supports the requirements for architectural data, published in a consistently understandable way, and will enable greater ease for discovering, sharing, and reusing architectural data across organizational boundaries.

To facilitate the use of information at the data layer, the DoDAF describes a set of models for visualizing data through graphic, tabular, or textual means. These views relate to stakeholder requirements for producing an Architectural Description.

Relationship to other architecture frameworks

The UPDM
UPDM
The Unified Profile for DoDAF/MODAF is the product of an Object Management Group ] initiative to develop a modeling standard that supports both the USA Department of Defense Architecture Framework and the UK Ministry of Defence Architecture Framework...

 (Unified Profile for DoDAF and MODAF
MODAF
The British Ministry of Defence Architecture Framework is an Architecture Framework which defines a standardised way of conducting Enterprise Architecture, originally developed by the UK Ministry of Defence....

) is an OMG
Object Management Group
Object Management Group is a consortium, originally aimed at setting standards for distributed object-oriented systems, and is now focused on modeling and model-based standards.- Overview :...

 initiative to standardize UML
Unified Modeling Language
Unified Modeling Language is a standardized general-purpose modeling language in the field of object-oriented software engineering. The standard is managed, and was created, by the Object Management Group...

 and SysML usage for USA and UK defense architecture frameworks. In addition, the multi-national IDEAS Group
IDEAS Group
The IDEAS Group is the International Defence Enterprise Architecture Specification for exchange Group. The deliverable of the project is a data exchange format for military Enterprise Architectures. The scope is four nation and covers MODAF , DoDAF , and the Australian Defence Architecture...

, which is supported by Australia
Australia
Australia , officially the Commonwealth of Australia, is a country in the Southern Hemisphere comprising the mainland of the Australian continent, the island of Tasmania, and numerous smaller islands in the Indian and Pacific Oceans. It is the world's sixth-largest country by total area...

, Canada
Canada
Canada is a North American country consisting of ten provinces and three territories. Located in the northern part of the continent, it extends from the Atlantic Ocean in the east to the Pacific Ocean in the west, and northward into the Arctic Ocean...

, Sweden
Sweden
Sweden , officially the Kingdom of Sweden , is a Nordic country on the Scandinavian Peninsula in Northern Europe. Sweden borders with Norway and Finland and is connected to Denmark by a bridge-tunnel across the Öresund....

, UK, USA, with NATO observers, has launched an initiative to develop a formal ontology for enterprise architectures.

Commercial Products Support

Several commercial products have support for DODAF, including the following.



  • System Architect (software)
    System Architect (software)
    IBM Rational System Architect is an enterprise architecture tool that is used by the business and technology departments of corporations and government agencies to model their business operations and the systems, applications, and databases that support them...



  • IServer
    IServer
    iServer is an enterprise architecture and business process modeling tool, produced by Orbus Software, headquartered in London. The product recently gained interest from the research organization Gartner Group for its use of Microsoft Visio as a platform - Gartner named Orbus as a ‘cool vendor’ for...

     produced by Orbus Software
    Orbus software
    Orbus Software is a London-based enterprise architecture and business process modeling software vendor that was named as a 2009 Cool Vendor by Gartner Group. The main reason for this was the Microsoft Visio-based architecture of their modeling tool product, iServer...

    . Orbus Software

Further reading


  • Architectural Resources cited in DoDAF V2.0. A number of architecture resources exist which serve as sources for guidelines that should be consulted while building architectural views. Some of these architecture resources are briefly listed below, with their architectural uses, and their URLs. Additional information is contained in the individual URLs. Some architecture resources require Secret Internet Protocol Router Network (SIPRNET) access.

DoDAF V2.0 Resources
    • DoD IEA: Department of Defense Information Enterprise Architecture (DoD IEA) Defines the key principles, rules, constraints and best practices to which applicable DoD programs, regardless of Component or portfolio, must adhere in order to enable agile, collaborative net-centric operations. The DoD IEA provides the guidelines and rules that the architect must keep in mind in the architecture development effort.
    • DARS: DoD Architecture Registry System (DARS) DARS is the DoD registry of segment and solution architectures comprising the federated DoD enterprise architecture. To discover architectures that exist, or may be in development. Depending on the purpose and scope, an architect may search and discover Architectures that overlap the scope and purpose of the architecture effort. To register metadata about architectures that are being developed, or currently exist.
    • DITPR: DoD Information Technology Portfolio Repository (DITPR) The official unclassified DoD data source for Federal Information Security Management Act (FISMA), EAuthentication, Portfolio

Management, Privacy Impact Assessments, the inventory of MC/ME/MS systems, and the registry for systems under DoDI
5000.2. The Systems metadata from the Architecture can be used to populate DITPR with new or updated information. DITPR can also populate the architecture’s Systems metadata, particularly on systems that interface with systems described in the architecture, but are not part of the scope of the architecture.
    • DISR: DoD Information Technology Standards and Profile Registry (DISR) Online repository for a minimal set of primarily commercial IT standards. The DISR can be used to populate the Standards models (StdV-1 and StdV-2) of the Architecture. Conversely, the Standards Models can identify additional or new standards that need to be added to DISR.
    • JCPAT: (SIPRNet) Joint C4I Program Assessment Tool (JCPAT) Formally assess systems and capabilities documents (Initial Capabilities Document, Capability Development Document, and Capability Production Document) for Joint Staff interoperability requirements certification and is the ITS/NSS Lifecycle Repository and the archives. The ICD, CDD, and CPD contain architecture information. As the architecture development progresses, the collected architecture information can be extracted and reported in the ICD, CDD, and the CPD. In addition, the architecture information can be within with the Enhanced-Information Support Plan (E-ISP) tool, a part of the JCPAT toolset.
    • JCSFL: Joint Common System Function List (JCSFL) A common lexicon of

systems/service functionality supporting joint capability. The JCSFL is provided for mapping functions to supported activities and the systems or services that host them. Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 6212.01E prescribes the JCSFL for use in developing a common vocabulary for architecture development. Use the taxonomy to align or extend system functions within the architecture being developed
    • KM/DS: (SIPRNet) Knowledge Management/ Decision Support (KM/DS) The KM/DS tool will be used by DoD components to submit documents and comments for O-6 and flag reviews, search for historical information, and track the status of documents. Supporting the JCIDS approval process, the

documents that are necessary for Milestone Decisions have architecture information. As the architecture development
progresses, the collected architecture information can be extracted and reported in the required documents.
    • DoD MDR: Metadata Registry The DoD Metadata Registry and Clearinghouse provides software developers access to data technologies to support DoD mission applications. Through the Metadata Registry and Clearinghouse, software developers can access registered XML data and metadata components, database segments, and

reference data tables and related metadata information The Resource Flows and Physical Schemas from the Architecture
can be used to populate the Metadata Registry.
concurrence and standardization for an integrated architecture. They comprise the lexicon for the three views of the architecture framework, the operational (OV), system (SV) and technical standards (TV) views. The use of the critical
taxonomies is a step to ensuring integration of systems within a system of systems and alignment of information
technology (IT) functionality to mission and operational needs. The data contained in each element of the
Architecture list shall be used for overall architecture framework development, programmatic research,
development, and acquisition activities, and related integration and interoperability and capability assessments. It will be updated through review periods to support DoN Program Objective Memorandum (POM) efforts and to reflect
changes mandated by DoD, technology improvements, and other factors.
    • Service Registry: Service Registry. Select the “NCES Service Discovery” button The Service Registry provides enterprise-wide insight, control and leverage of an organization's services. It captures service descriptions and makes them discoverable from a centrally managed, reliable, and searchable location. The Services

metadata from the Architecture effort can be used to populate the Service Registry in the process of developing the
solution.
    • UJTL: Universal Joint Task List (UJTL) The Universal Joint Task List from the Chairman of the Joint Chiefs of Staff Manual 3500.04C (CJCSM) serves as a common language and

common reference system for joint force commanders, combat support agencies, operational planners, combat developers, and trainers to communicate mission requirements. It is the basic language for development of a joint mission essential task list (JMETL) or agency mission essential task list (AMETL) that identifies required capabilities for mission success. Use the taxonomy to align or extend operational activities within the architecture being developed.

External links

  • DoDAF V2.02 - This is the official and current version for the Department of Defense Architecture Framework.

The source of this article is wikipedia, the free encyclopedia.  The text of this article is licensed under the GFDL.
 
x
OK