DoD Architecture Framework: Vol. I- Definitions and Guidelines

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.