An architecture description is a representation of a defined domain, as of a current or future point in time, in terms of its component parts, what those parts do, how the parts relate to each other, and the rules and constraints under which the parts function. What constitutes each of the elements of this definition depends on the degree of detail of interest. For example, domains can be at any level, from DoD as a whole down to individual functional areas or groups of functional areas. Component parts can be anything from “U.S. Air Force” as a component of DoD, down to a “satellite ground station” as a component part of a communications network, or “workstation A” as a component part of system “x.” What those parts do can be as general as their high- level operational concept or as specific as the lowest- level action they perform. How the parts relate to each other can be as general as how organizations fit into a very high-level command structure or as specific as what frequency one unit uses in communicating with another. The rules and constraints under which they work can be as general as high- level doctrine or as specific as the e-mail standard they must use. The term architecture is generally used both to refer to an architecture description and an architecture implementation. Hereafter in this document, the term architecture will be used as a shortened reference to architecture description. Occasionally the term architecture description is used for emphasis. References to architecture implementations will use the term architecture implementation. An architecture description is a representation of a current or postulated “real-world” configuration of resources, rules, and relationships. Once the representation enters the design, development, and acquisition portion of the system development life-cycle process, the architecture description is transformed into a real implementation of capabilities and assets in the field. The Framework itself does not address this representation-to-implementation transformation process but references policies that are relevant to that process.
Replaced/Superseded by document(s)
|File||MIME type||Size (KB)||Language||Download|
|DoD Architecture Framework Vol. 1 Definitions and Guidelines.pdf||application/pdf||1.03 MB||English||DOWNLOAD!|
The Department of Defense (DoD) Architecture Framework (DoDAF), Version 1.0, defines a common approach for DoD architecture description development, presentation, and integration for both warfighting operations and business operations and processes. The Framework is intended to ensure that architecture descriptions can be compared and related across organizational boundaries, including Joint and multinational boundaries.
This document applies to architectures developed by and for the Office of the Secretary of Defense (OSD), the Military Departments, the Chairman of the Joint Chiefs of Staff (CJCS), the Combatant Commands, the Office of the Inspector General of the Department of Defense, the Defense Agencies, DoD Field Activities, and all other organizational entities within the Department of Defense (hereafter referred to collectively as “the DoD Components”). The Framework supports the development of interoperating and interacting architectures as referenced in DoD issuances. It defines three related views of architecture: Operational View (OV), Systems View (SV), and Technical Standards View (TV) as depicted in Figure ES-1. Each view is composed of sets of architecture data elements that are depicted via graphic, tabular, or textual products. The All-DoD Core Architecture Data Model (CADM) defines the entities and relationships for architecture data elements.
The Framework is partitioned into two volumes and a deskbook:
· Volume I provides definitions, guidelines, and related background material.
· Volume II contains descriptions for each product.
· The DoDAF Deskbook provides supplementary information to Framework users.