The DoDAF Architecture Design Process has 6-step. These steps provide guidance and guiding rules to the architect and Architectural Description development team. The process is data-centric rather than product-centric and ensures synchronization between views while ensuring that all essential data relationships are captured to support a wide variety of analysis tasks. The views created as a result of the architecture development process provide visual renderings of the underlying architectural data and convey information of interest needed by a specific user and/or decision-makers.
The Six (6) Step are:
- Step 1: Determine Intended Use of Architecture
- Step 2: Determine Scope of Architecture
- Step 3: Determine Data Required to Support Architecture Development
- Step 4: Collect, Organize, Correlate, and Store Architectural Data
- Step 5: Conduct Analyses in Support of Architecture Objectives
- Step 6: Document Results in Accordance with Decision-Maker Needs
Step 1: Determine Intended Use of Architecture
Defines the purpose and intended use of the architecture (“Fit-for-Purpose”); how the Architectural Description effort will be conducted; the methods to be used in architecture development; the data categories needed; the potential impact on others; and the process by which success of the effort will be measured in terms of performance and customer satisfaction. This information is generally provided by the process owner to support architecture development describing some aspect of their area of responsibility (process, activity, etc.).
Step 2: Determine Scope of Architecture
The scope defines the boundaries that establish the depth and breadth of the Architectural Description and establish the architecture’s problem set, helps define its context and defines the level of detail required for the architectural content.
Step 3: Determine Data Required to Support Architecture Development Determines
The required level of detail to be captured for each of the data entities and attributes. This includes the data identified as needed for the execution of the process, and other data required to effect change in the current process. The initial type of architectural data content to be collected is determined by the established scope of the Architectural Description and recorded as attributes, associations, and concepts as described in the DoDAF Meta Model (DM2). This step is normally completed in conjunction with Step 4, a bottom-up approach to organized data collection and Architectural Description development typically iterates over these two steps.
Step 4: Collect, Organize, Correlate, and Store Architectural Data
Architects typically collect and organize data through the use of architecture techniques designed to use views for presentation and decision-making purposes. The architectural data should be stored in a recognized commercial or government architecture tool. Terms and definitions recorded are related to elements of the (DM2).
Step 5: Conduct Analyses in Support of Architecture Objectives
Architectural data analysis determines the level of adherence to process owner requirements. This step may also identify additional process steps and data collection requirements needed to complete the Architectural Description and better facilitate its intended use. Validation applies the guiding principles, goals, and objectives to the process requirement, as defined by the process owner, along with the published performance measures (metrics), to determine the achieved level of success in the Architectural Description effort. Completion of this step prepares the Architectural Description for approval by the process owner.
Step 6: Document Results in Accordance with Decision-Maker Needs
The final step in the architecture development process involves the creation of architectural views based on queries of the underlying data. Presenting the architectural data to varied audiences requires transforming the architectural data into meaningful presentations for decision-makers. This is facilitated by the data requirements determined in Step 3, and the data collection methods employed during Step 4.
DoDAF provides for models and views. DoDAF-described Models are those models that enable an architect and development team whose data has already been defined and described consistent with the DM2. The models become views when they are populated with architectural data.
- The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
- DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.
AcqLinks and References:
-  DoDAF Architecture Framework Version 2.02
- (Old) DoD Architecture Framework Working Group Version 1.0, Volume 1: Definition and Guideline, 9 Feb 04
- (Old) DoD Architecture Framework Version 1.0, Volume 2: Product Description, 9 Feb 04
- Website: DoDAF Architecture Framework Version 2.02