Department of Defense Architecture Framework The Department of Defense Architecture Framework ( DoDAF ) is an architecture framework for the United States Department of Defense ( DoD ) that provides visualization infrastructure for specific stakeholders concerns through viewpoints organized by various views . These views are artifacts for visualizing , understanding , and assimilating the broad scope and complexities of an architecture description through tabular , structural , behavioral , ontological , pictorial , temporal , graphical , probabilistic , or alternative conceptual means . This Architecture Framework is especially suited to large systems with complex integration and interoperability challenges , and it is apparently unique in its employment of " operational views " . These views offer overview and details aimed to specific stakeholders within their domain and in interaction with other domains in which the system will operate . Overview . The 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 non - combat environment . All major U . S . DoD weapons and information technology system acquisitions are required to develop and document an enterprise architecture ( 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 framework s . History . The first version of the development DoDAF was developed in the 1990s under the name C4ISR architectural architecture framework . In the same period the reference model TAFIM , 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 . 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 . The current version is DoDAF 2 . 02 DoDAF V2 . 0 is published on a public website . Other derivative frameworks based on DoDAF include the NATO Architecture Framework ( NAF ) and Ministry of Defence Architecture Framework . 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 common database schema Core Architecture Data Model 2 . 0 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 . Capabilities and Mission . See the diagram for a depiction of the Capabilities Emphasis , as tied in with mission / course of action , threads , activities , and architectures . The DoD has moved toward a focus on the delivery of capabilities , which are the reason for creating the system / service . The Capability Models describe capability taxonomy and capability evolution . A capability thread would equate to the specific activities , rules , and systems that are linked to that particular capability . The concept of capability , as defined by its Meta - model Data Group allows one to answer questions such as : The Mission or Course of Action is described by a Concept of Operations ( CONOPS ) , and is organized by Capabilities . Capabilities are described by Threads . Threads are described by Activities executed in serial or parallel . Activities are grouped into Mission Areas . Activities define operations for an Architecture . Architectures are organized by mission areas . Architectures provide proper resourcing of capabilities required by the Mission or Course of Action . Version 1 . 5 views . The DoDAF V1 . 5 defines a set of products , a view model , 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 : 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 . All view ( 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 : Operational view . Operational view ( 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 DoDAF V1 . 5 OV products are defined as : Systems and services view . Systems and services view ( 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 DoDAF V1 . 5 SV products are : Technical standards view . Technical standards view ( TV ) products define technical standards , implementation conventions , business rules and criteria that govern the architecture . The DoDAF V1 . 5 TV products are as follows : Version 2 . 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 ) . 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 . Data and Information Viewpoint ( DIV ) . Note , see Logical data model for discussion of the relationship of these three DIV data models , with comparison of the Conceptual , Logical & Physical Data Models . Creating an integrated architecture using DoDAF . The DODAF 2 . 0 Architects Guide repeated DOD Instruction 4630 . 8 definition of an integrated architecture as " An architecture consisting of multiple views facilitating integration and promoting interoperability across capabilities and among integrated architectures . " For the purposes of architecture development , the term integrated means that data required in more than one of the architectural models is commonly defined and understood across those models . Integrated architectures are a property or design principle for architectures at all levels : Capability , Component , Solution , and Enterprise ( in the context of the DoD Enterprise Architecture ( EA ) being a federation [ of ] architectures ) . In simpler terms , integration is seen in the connection from items common among architecture products , where items shown in one architecture product ( such as sites used or systems interfaced or services provided ) should have the identical number , name , and meaning appear in related architecture product views . 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 . 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 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 ) : Representation . Representations for the DoDAF products may be drawn from many diagramming techniques including : There is a UPDM ( Unified 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 . Meta - model . DoDAF has a meta - model underpinning the framework , defining 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 ( then later in UML ) with an XML Schema derived from the resulting relational database . From version 2 . 0 , DoDAF has adopted the IDEAS Group foundation ontology as the basis for its new meta - model . This new meta - model is called " DM2 " ; an acronym for " DoDAF Meta - Model " . Each of these three levels of the DM2 is important to a particular viewer of Departmental processes : The purposes of the DM2 are : 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 ( Unified 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 , Sweden , UK , USA , with NATO observers , has launched an initiative to develop a formal ontology for enterprise architectures .