Content is Pre-Decisional Material
     24 Dec 08                                                                         ...
Content is Pre-Decisional Material
     24 Dec 08                                            Spiral 4


24
25
26




     ...
Content is Pre-Decisional Material
     24 Dec 08                                                                         ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                            Spiral 4


165              ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
Content is Pre-Decisional Material
      24 Dec 08                                                                        ...
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
DoD Architecture Framework
Upcoming SlideShare
Loading in...5
×

DoD Architecture Framework

6,139
-1

Published on

Published in: Technology, News & Politics
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
6,139
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
173
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

DoD Architecture Framework

  1. 1. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1 wre ath stars Text 2 3 4 5 6 7 8 DoD Architecture Framework 9 Version 2.0 10 Draft 11 12 13 14 15 16 17 Volume 1: Introduction, Overview, and Concepts 18 19 Management Volume 20 21 24 December 2008 22 This content is pre-decisional material. No part of this publication maybe released, transmitted, or copied 23 without prior permission of Deputy CIO (EA&S) i DRAFT Content is Pre-Decisional Material
  2. 2. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 24 25 26 ii DRAFT Content is Pre-Decisional Material
  3. 3. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 27 TABLE OF CONTENTS 28 TABLE OF CONTENTS ............................................................................................................ iii 29 TABLE OF FIGURES................................................................................................................ vii 30 To be provided............................................................................................................................. vii 31 DOD ARCHITECTURE FRAMEWORK VERSION 2.0 ........................................................ 1 32 EXECUTIVE SUMMARY .......................................................................................................... 1 33 VOLUME 1 – INTRODUCTION, OVERVIEW, AND CONCEPTS ..................................... 6 34 1. INTRODUCTION............................................................................................................. 6 35 1.1 Vision for DoDAF 2.0 ............................................................................................................. 7 36 1.2 DoDAF 2.0 Organization and Intended Audience ............................................................... 7 37 1.3 Purpose and Scope ............................................................................................................ 9 38 1.3.1 Developing Architectures. .......................................................................................... 10 39 1.3.2 Maintaining and Managing Architectures ............................................................... 11 40 1.3.3 Using Architectures .................................................................................................... 11 41 1.3.4 DoDAF Conformance ........................................................................................................ 12 42 1.4 What’s New in Volume 1...................................................................................................... 12 43 1.5 What Managers and Executives Need to Know about DoDAF. ...................................... 13 44 2. SCOPING ARCHITECTURES TO BE “FIT FOR PURPOSE” .............................. 15 45 3. DoDAF VOLUMES AND JOURNAL OVERVIEW .................................................. 18 46 3.1 DoDAF Overview ............................................................................................................ 18 47 3.2 DoDAF Background ....................................................................................................... 19 48 3.2.1 Authority: Law, Policy, and Historic Perspective.................................................... 19 49 3.2.2 Historical Evolution of DoDAF......................................................................................... 20 50 3.2.3 DoDAF Version 2.0 – The Need for Change............................................................. 21 51 3.2.3.1 Architecture Focus...................................................................................................... 22 52 3.2.3.2 Shifting from Product-Centric to Data-Centric Focus............................................ 22 53 3.3 Assumptions..................................................................................................................... 22 54 3.4 DoDAF Structure and Views ............................................................................................... 23 55 3.5 DoDAF Development Guidelines................................................................................... 26 56 3.5.2 Multiple Techniques and Toolsets, including Structured and Object Oriented 57 Analysis. 28 58 3.6 Architecture Resources .................................................................................................. 28 59 4. ENTERPRISE ARCHITECTURE ............................................................................... 32 60 4.1 Introduction and Overview............................................................................................ 32 61 4.2 Transition Planning ........................................................................................................ 34 62 4.3 Federated Approach to DoD Architecture Management............................................ 35 63 4.4 Tiered Accountability. .................................................................................................... 35 64 4.5 DoD Architecture Enterprise Services.......................................................................... 36 65 4.6 Alignment to the Federal Enterprise Architecture (FEA) .......................................... 37 66 4.7 Addressing Security Issues in DoDAF-conformant Architecture Development............. 40 67 5. ARCHITECTURE PLANNING ................................................................................... 40 68 5.1 Defining the Enterprise .................................................................................................. 40 69 5.2 The Enterprise-level Architecture....................................................................................... 40 70 5.3 The Solution-Level Architecture ......................................................................................... 41 71 5.4 Architecture Management ............................................................................................. 41 iii DRAFT Content is Pre-Decisional Material
  4. 4. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 72 5.4.1 Architecture Development ......................................................................................... 41 73 5.4.2 Architecture Utilization.............................................................................................. 41 74 5.4.3 Architecture Maintenance.......................................................................................... 42 75 5.4.4 Architecture Utilization.............................................................................................. 42 76 5.4.5 Architecture Compliance Reviews ................................................................................. 42 77 5.4.5.1 OMB Architecture Assessment.............................................................................. 43 78 5.4.5.2 GAO Architecture Assessment .................................................................................. 43 79 5.4.6 User Support................................................................................................................ 44 80 5.4.7 Training ....................................................................................................................... 44 81 5.4.8 Communications Planning ......................................................................................... 44 82 5.4.9 Quality Planning ......................................................................................................... 45 83 5.4.10 Risk Management ....................................................................................................... 45 84 6. CUSTOMER REQUIREMENTS.................................................................................. 46 85 6.1 Tailoring Architecture to Customers’ Needs ............................................................... 46 86 6.2 Key Decision Support Processes .................................................................................... 47 87 6.2.1 Joint Capability Integration and Development System .......................................... 47 88 6.2.2 Defense Acquisition System ....................................................................................... 47 89 6.2.3 Systems Engineering (SE) .......................................................................................... 48 90 6.2.4 Planning, Programming, Budgeting, and Execution (PPBE) ................................. 49 91 6.2.5 Portfolio Management ................................................................................................ 49 92 6.2.6 Operations ................................................................................................................... 49 93 6.3 Information Sharing ............................................................................................................. 50 94 7. METHODOLOGIES...................................................................................................... 51 95 7.1 Methodology Based Approach to Architecture............................................................ 51 96 7.1.1 6-Step Architecture Development Process................................................................ 52 97 7.1.1.1 Step 1: Determine Intended Use of Architecture ..................................................... 53 98 7.1.1.2 Step 2: Determine Scope of Architecture.................................................................. 53 99 7.1.1.3 Step 3: Determine Data Required to Support Architecture Development............ 54 100 7.1.1.4 Step 4: Collect, Organize, Correlate, and Store Architecture Data ................... 55 101 7.1.1.5 Step 5: Conduct analyses in support of architecture objectives ............................. 56 102 7.1.1.6 Step 6: Document Results in Accordance with Architecture Framework............. 56 103 7.1.2 Accommodating Multiple Methods for Implementation......................................... 57 104 7.1.3 Architecture Life Cycle & Architecture Governance..................................................... 57 105 7.1.4 Planning for Architecture Development................................................................... 58 106 7.1.5 Approaches to Architecture Development................................................................ 59 107 7.1.5.1 Structured Technique Overview ............................................................................... 59 108 7.1.5.1.1 Process Data Flow ................................................................................................... 59 109 7.1.5.1.2 Process Task-Dependency Diagram...................................................................... 60 110 7.1.5.1.3 Entity-Relation Model ............................................................................................ 60 111 7.1.5.2 Object-Oriented Technique Overview...................................................................... 60 112 7.1.5.2.1 Process – Activity Diagram, Object-Sequence Diagram ..................................... 60 113 7.1.5.2.2 Data – Object Class Diagram................................................................................. 61 114 7.2 System (Component, Package, Deployment) Diagram................................................ 61 115 7.2.1 Component Model and Package Diagram................................................................ 61 116 7.2.2 Deployment/Operational Model ................................................................................ 61 iv DRAFT Content is Pre-Decisional Material
  5. 5. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 117 8. ARCHITECTURE PRESENTATION TECHNIQUES.............................................. 63 118 8.1 Overview ................................................................................................................................ 63 119 8.2 Choosing an Appropriate Presentation Technique ........................................................... 65 120 8.3 Composite Views ............................................................................................................. 67 121 8.3.1 Purpose and Audience ................................................................................................ 67 122 8.3.2 Examples............................................................................................................................. 67 123 8.4 Dashboard Views ............................................................................................................ 68 124 8.4.1 Purpose and Audience ................................................................................................ 69 125 8.4.2 Examples............................................................................................................................. 69 126 8.5 Fusion Views.......................................................................................................................... 71 127 8.5.1 Purpose and Audience ....................................................................................................... 71 128 8.5.2 Examples............................................................................................................................. 71 129 8.6 Graphics Views...................................................................................................................... 73 130 8.6.1 Purpose and Audience ................................................................................................ 73 131 8.6.2 Examples............................................................................................................................. 74 132 8.7.1 Purpose and Audience ................................................................................................ 76 133 8.7.2 Examples...................................................................................................................... 76 134 9. DODAF META-MODEL............................................................................................... 79 135 a. 9.1 The DoDAF Conceptual Data Model ...................................................................... 79 136 10. ARCHITECTURE-BASED ANALYTICS................................................................... 82 137 10.1 Analytics Context ............................................................................................................ 82 138 10.2 Architecture Analytics.................................................................................................... 83 139 10.3 Types of Architecture Analysis...................................................................................... 83 140 10.4 Examples of Analytics..................................................................................................... 84 141 10.5 Principles of Architecture Analytics ............................................................................. 84 142 10.5.1 Information Consistency ............................................................................................ 84 143 10.5.2 Data Completeness...................................................................................................... 85 144 10.5.3 Transformation ........................................................................................................... 85 145 10.5.4 Iteration ....................................................................................................................... 85 146 10.5.5 Lack of Ambiguity ...................................................................................................... 85 147 11. CONFIGURATION MANAGEMENT OF THE DODAF ARCHITECTURE 148 FRAMEWORK........................................................................................................................... 86 149 11.1 Configuration Management Authority ......................................................................... 86 150 11.2 Configuration Management Guidance for Program Managers................................. 86 151 11.2.1 Configuration Management Implementation........................................................... 87 152 11.2.3 The DARS Registration Process ................................................................................ 88 153 11.3 Configuration Control Board (CCB................................................................................. 88 154 11.4 Technical Working Groups (TWGs)................................................................................ 88 155 12. RELATIONSHIPS TO OTHER ARCHITECTURE FRAMEWORKS/ 156 REFERENCE DOCUMENTS................................................................................................... 89 157 12.1 Frameworks......................................................................................................................... 89 158 12.1.1 Federal Enterprise Architecture (FEA) Program ................................................... 89 159 12.1.2 The Zachman Framework ......................................................................................... 89 160 12.1.3 The Open Group Architecture Framework (TOGAF) ........................................... 89 161 12.1.4 The Ministry of Defense Architecture Framework (MODAF)............................... 90 v DRAFT Content is Pre-Decisional Material
  6. 6. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 162 12.1.5 NATO Architecture Framework (NAF) ................................................................... 90 163 12.2 Other Reference Documents ............................................................................................. 90 164 APPENDIX A ACRONYMS ...................................................................................................... 1 vi DRAFT Content is Pre-Decisional Material
  7. 7. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 165 TABLE OF FIGURES 166 167 168 To be provided vii DRAFT Content is Pre-Decisional Material
  8. 8. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 169 DOD ARCHITECTURE FRAMEWORK VERSION 2.0 170 171 EXECUTIVE SUMMARY 172 173 The DoD Architecture Framework (DoDAF), Version 2.0 serves as the overarching, 174 comprehensive framework and conceptual model enabling DoD managers at all levels to make 175 key decisions more effectively through organized information sharing across Department, Joint 176 Capability Areas (JCAs), Mission, Components and Program boundaries. DoDAF serves as one 177 of the pillars that support the responsibilities of the Department of Defense Chief Information 178 Officer (DoD CIO) in development and maintenance of architectures required under the Clinger- 179 Cohen Act. It also reflects guidance from OMB Circular A-130, and other Departmental 180 directives and instructions. This version of the Framework provides extensive guidance on 181 development of architectures supporting the adoption and execution of Net-centric services 182 within the Department. 183 184 DoD managers, as process owners, specify the requirements, and control the development of 185 architectures, as described in this volume, within their areas of authority and responsibility. In 186 that role, they select an architect, and an architecture development team to create the architecture 187 in accordance with the requirements defined by the manager (process owner). As described in 188 Volume 1, architecture concentrates on those data that correspond to architecture requirements. 189 190 The duties of the architect, and the architecture team that create the architecture, are further 191 described in Volume 2 of DoDAF. The architect supervises development of the architecture, and 192 ensures that the requirements and visual representations of the architecture meet process owner 193 requirements. 194 195 DoDAF 2.0 focuses on architecture data, rather than on developing individual products. Data 196 can be collected, organized, and stored by a wide range of architecture tools developed by 197 commercial sources and organized using the DoDAF Meta-model (DM2)... A 'Data Capture 198 Method' for each data group of the DM2 is provided in Volume 2 to guide architects in collecting 199 and organizing the necessary architecture data. 200 201 1 DRAFT Content is Pre-Decisional Material
  9. 9. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 DoDAF conformance is achieved when: - The data in a described architecture is defined according to the DoDAF Meta-model concepts, associations, and attributes. Appendix B, "DoDAF View Support" - Architecture Data is registered in the DoD Metadata Registry (DMR); The Architecture Overview and Summary Information Document (AV-1) is registered in DARS, and - The architecture data capable of transfer in accordance with the PES. -The mapping of the DoDAF Meta-model Concepts, Associations, and Attributes to each DoDAF View is listed in Table B-2, " DM2 Concepts (Classes, Aliases, and Composite Terms) Mapping to DoDAF Views" in Volume 2, 202 203 The framework enables architecture content to be built that is “Fit for Purpose”, defined and 204 described in Volume 1 as architecture, which is consistent with specific project or mission 205 objectives. Because architecture can be applied at myriad levels of an enterprise, the purpose or 206 use of architecture at each level will be different in content, structure, and level of detail. In 207 order to ensure that architecture meets program and mission objectives, the approach to 208 architecture development must be tailored to address a specific, well-articulated, and understood 209 purpose. This will help to ensure that necessary data collection, to an appropriate level of detail, 210 is undertaken, completed, and supportive of specific decisions or objectives. 211 212 DoDAF also serves as the principal guide for development of integrated architectures as defined 213 in DoD Instruction 4630.81, which defines an integrated architecture as “An architecture 214 consisting of multiples views or perspectives facilitating integration and promoting 215 interoperability across capabilities and among integrated architectures”. The term integrated 216 means that data required in more than one instance in architectural views is commonly 217 understood across those views. 218 219 The DoDAF Meta-model provides information needed to collect, organize, and store data in an 220 easily understandable way, and the presentation description of various types of views in Volumes 221 1 & 2 provide the guidance on how to develop graphical representations of that data that will be 222 useful in defining acquisition requirements under the DOD Instruction 5000-series. 1 Department of Defense Instruction 4630.8, Procedures for Interoperability and Supportability of Information Technology (IT) and National Security Systems (NSS) 30 June 2004. Office of the Assistant Secretary of Defense (Networks & Information Integration) (NII)/ DoD Chief Information Officer (DoD CIO). The current version is found at: www.dtic.mil/whs/directives/corres/pdf/463008p.pdf 2 DRAFT Content is Pre-Decisional Material
  10. 10. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 The DoDAF Meta-model (DM2) replaces the Core Architecture Data Model (CADM) which supported previous versions of the DoDAF. DM2 is a data construct that facilitates reader understanding of the use of data within an architecture document. CADM can continue to be used in support of architectures created in previous versions of DODAF. 223 224 DoDAF 2.0 is a marked change from earlier versions of either C4ISR or DoDAF, in that 225 architects now have the freedom to create enterprise architectures to meet the demands of their 226 customer requirements. The central core of DoDAF v2.0 is a data-centric approach where the 227 creation of architectures to support decision-making is secondary to the collection, storage, and 228 maintenance of data needed for efficient and effective decisions. The architect and stakeholders 229 select views to ensure that architectures will explain current and future states of the process or 230 activity under review. Selecting architecture views carefully ensures that the views adequately 231 explain the requirement and proposed solution in ways that will enhance audience understanding. 232 DoDAF 2.0 provides two types of views. DoDAF-described Views are created from the subset 233 of data for a particular purpose and are fully explained in DoDAF. These views are useful as 234 examples for presentation purposes, and can be used as described or modified as needed. Fit- 235 for-Purpose Views are user-defined views of a subset of architecture data created for some 236 specific purpose. While these views are not described or defined in DoDAF, they can be created, 237 as needed, to ensure that presentation of architecture data is easily understood within an agency. 238 This enables agencies to use their own established presentation preferences in their deliberations. 239 240 The Views described in DoDAF, including those that are legacy views from previous versions of the Framework, are provided as pre-defined examples that can be used when developing presentations of architecture data. DoDAF does not prescribe any particular views, but instead concentrates on data as the necessary ingredient for architecture development. However, other regulations and instructions from both DoD and CJCS have particular presentation view requirements. These views are supported by DoDAF 2.0, and should be consulted for specific view requirements. 241 242 DoDAF 2.0 provides, but does not require, a particular methodology in architecture 243 development. Volume 1 contains numerous examples of how to utilize the DoDAF methodology 244 either alone, or in conjunction with other methods. Volume 1 provides guidance and suggestions 245 on how to ensure that other proposed methods can be adapted as needed to meet the DoD 246 requirements for data collection and storage. Similarly, the views presented in DoDAF are 247 examples, intended to serve as a possible visualization of a particular view. DoDAF 2.0 also 248 continues to provide support for views (i.e. ‘products’) developed in previous versions of the 249 Framework. These views do not require any particular graphical design by toolset vendors. 250 3 DRAFT Content is Pre-Decisional Material
  11. 11. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 251 DoDAF 2.0 is composed of three volumes, along with an electronic DoDAF Journal hosted on 252 Defense Knowledge Online, https://www.us.army.mil/suite/page/454707. Together, these 253 volumes provide a resource that enables users to access the DoD’s entire body of knowledge 254 associated with architecture. 255 256 • Volume 1 provides general guidance for development, use, and management of DoD 257 architectures. This volume is designed to help non-technical users understand the role of 258 architecture in support of major decision support processes. Volume 1 provides a six- 259 step methodology (Section 7) that can be used to develop architectures at all levels of the 260 Department, and a Conceptual Data Model (CDM) (Section 9) for organizing data 261 collected by an architecture effort. 262 • Volume 2 describes the construct of architectures, data descriptions, data exchange 263 requirements, and examples of their use in developing architectural views in technical 264 detail, to include the development and use of service-oriented architectures in support of 265 Net-centric operations. Volume 2 provides a Logical Data Model (LDM), based on the 266 CDM, which describes and defines architecture data; further describes the methods used 267 to populate architecture views, and describes how to use the architecture data in DoDAF- 268 described views, or in developing Fit-for-purpose Views that support decision-making. 269 270 • Volume 3 relates the CDM structure with the LDM relationships, associations, along 271 business rules described in Volume 2 to introduce a Physical Exchange Specification 272 (PES), which provides the constructs needed to enable exchange of data among users 273 and COIs. NOTE: DoDAF 2.0 does NOT prescribe a Physical Data Model (PDM), 274 leaving that task to software developers who will implement the principles and practices 275 of DoDAF in their own software offerings. 276 277 • The DoDAF Journal, https://www.us.army.mil/suite/page/454707, is the electronic 278 interface for DoDAF support. The DoDAF Journal provides a place for submitting future 279 change requests to DoDAF or the DM2 (Section 9); provides examples referenced in the 280 various DoDAF volumes, and includes descriptions of other best practices, lessons 281 learned, and reference documents that supplement the information contained in the three 282 volumes of DoDAF V2.0, including: 283 284 • DoDAF Architecture Development Process for the Models 285 • DoDAF Product Development Questionnaire Analysis Report 286 • DoDAF V2.0 Meta-model Data Dictionary 287 288 289 In DoDAF 2.0, examples provided lean heavily on the major areas of change within the 290 Department, including the Joint Capabilities Integration and Development System (JCIDS), the 291 Defense Acquisition System (DAS), Systems Engineering (SE), the Planning Programming, 292 Budgeting, and Execution (PPBE) Process, and Portfolio Management (PfM). These major 293 processes produce far-reaching change across all Military Departments, Agencies, The Joint 294 Staff, and other Departmental functions. Architectures developed utilizing the guidance in 4 DRAFT Content is Pre-Decisional Material
  12. 12. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 295 DoDAF demonstrate how change is documented and executed through an architecturally based 296 approach that: 297 298 • Establishes and documents scope and boundaries. 299 • Documents best practices. 300 • Defines and describes generic performance metrics. 301 • Documents and describes potential solutions for management review and approval. 302 303 DoDAF 2.0 is organized to facilitate the organization, and maintenance of data collected in an 304 architectural development effort. This approach responds to Departmental programs, such as 305 BTA, JCIDS, and other major functions with significant impact throughout the Department that 306 have developed requirements for multiple, custom views beyond the customary operational, 307 systems, and technical views contained in previous versions of DoDAF, and is also consistent 308 with DODI 4630.8 requirements for integrated architectures. These customized views, and the 309 models that utilize the data, enable the architecture information to be communicated to, and 310 understood by, stakeholders in diverse functional organizations. Products developed under 311 previous versions of DoDAF continue to be supported, as described in Volume 2. 312 DoDAF data can be collected, organized, and stored by a wide range of architecture tools developed by commercial sources. Visualization of views in DoDAF 2.0 is for illustration purposes only. There may be multiple techniques that can be employed create architectural models in differing views. 313 5 DRAFT Content is Pre-Decisional Material
  13. 13. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 314 VOLUME 1 – INTRODUCTION, OVERVIEW, AND CONCEPTS 315 316 317 1. INTRODUCTION 318 319 DoDAF Version 2.0 is the overarching, comprehensive framework and conceptual model 320 enabling DoD managers at all levels to make key decisions more effectively through organized 321 information sharing across Department, Joint Capability Areas (JCAs), Components and 322 Program boundaries. DoDAF 2.0 focuses on architecture data as information required by key 323 DoD decision makers, rather than on developing individual products. The framework also 324 enables architecture content to be built that is 'Fit for Purpose', as defined and described in 325 Section 1.4. DoDAF is one of the pillars that support the responsibilities of the Department of 326 Defense Chief Information Officer (DoD CIO) in development and maintenance of architectures 327 required under the Clinger-Cohen Act. it also includes guidance from OMB Circular A-130, and 328 appropriate Departmental directives and instructions; This version of the Framework also 329 provides guidance on the development of architectures supporting the development of Net- 330 centric services within the Department. 331 332 DoDAF also serves as the principal guide for development of integrated architectures, as defined 333 in DoD Instruction 4630.82, which states: “An architecture consisting of multiples views or 334 perspectives facilitating integration and promoting interoperability across capabilities and 335 among integrated architectures”. The term integrated means that data utilized in more than one 336 instance in the architectural views is commonly understood across those views. 337 338 The Office of Management and Budget (OMB) annually evaluates agency efforts to improve 339 performance in strengthening the quality and usefulness of information technology investments 340 requested by agencies through well-organized strategic decisions relating to investments and 341 portfolio management. This process evaluates the use of enterprise and segment architectures, 342 discussed in Section 3 of this document, as a principal means of ensuring that mission 343 requirements are met, while savings and cost avoidance goals are achieved. Each agency is 344 required to adopt an architecture framework—either existing or created within the agency for 345 that purpose. DoDAF is the designated architecture framework with the DoD for architecture 346 development. 347 348 The DoDAF Meta-model (DM2) is a data model that provides information needed to collect, 349 organize, and store data or derived information in an easily understandable way. The 350 descriptions of DoDAF-described Views in Volumes 1 & 2 provide guidance on how to develop 351 graphical representations of that data and derived information that will be useful in defining 352 acquisition requirements under the DoD Instruction 5000-X series. 353 2 Department of Defense Instruction 4630.8, Procedures for Interoperability and Supportability of Information Technology (IT) and National Security Systems (NSS) 30 June 2004. Office of the Assistant Secretary of Defense (Networks & Information Integration) (NII)/ DoD Chief Information Officer (DoD CIO). The current version is found at: www.dtic.mil/whs/directives/corres/pdf/463008p.pdf 6 DRAFT Content is Pre-Decisional Material
  14. 14. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 354 355 DoD managers, as process owners and/or decision-makers, specify the requirements, and control 356 the development of architectures, as described in this volume, within their areas of authority and 357 responsibility. In that role, they select an architect, and an architecture development team to 358 create the architecture in accordance with the requirements defined by the manager (process 359 owner). As described in Volume 1, the architecture concentrates on those data that correspond to 360 architecture requirements. 361 362 The duties of the architect and the architecture team that create the architecture are supported 363 through Volume 2 of DoDAF. The architect supervises development of the architecture, and 364 ensures that the requirements and visual representations of the architecture meet process owner 365 requirements. 366 367 368 1.1 Vision for DoDAF 2.0. The vision for utilization of DoDAF is to: 369 • 370 • Provide an overarching set of architecture concepts, guidance, best practices, and 371 methods to enable and facilitate architecture development in support of major decision 372 support processes across all major Departmental programs, Military components, and 373 Capability areas that is consistent and complementary to Federal Enterprise Architecture 374 Guidance, as provide by OMB.. 375 376 • Support the DoD CIO in defining and institutionalizing the Net-Centric Strategy of the 377 Department, to include the definition, description, development, and execution of Net- 378 Centric Directory Services (NCDS) and Net-Centric Support Services (NCSS) through 379 introduction of Service-oriented Architecture Development. 380 381 • Focus on architecture data as information required for making critical decisions rather 382 than emphasizing individual architecture products. Enable architects to provide 383 visualizations of the derived information through combinations of DoDAF-described 384 Views, and Fit-for-purpose Views commonly used by decision-makers, enabling 385 flexibility to develop those views consistent with the culture and preferences of the 386 organization. 387 388 • Provide methods and suggest techniques through which information architects and other 389 developers can create architectures responsive to and supporting Departmental 390 management practices. 391 392 1.2 DoDAF 2.0 Organization and Intended Audience 393 394 DoDAF 2.0 is presented in three volumes, along with an electronic DoDAF Journal, 395 https://www.us.army.mil/suite/page/454707. Together, these volumes provide a resource that 396 enables users to understand and access DoD’s entire body of knowledge associated with 397 architecture. 398 7 DRAFT Content is Pre-Decisional Material
  15. 15. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 399 DoDAF Volume 1 – Introduction, Overview, and Concepts. [Primary audience: 400 Executives, Project Directors, & Managers] Volume 1 introduces DoD architecture concepts 401 and provides general guidance for development, use, and management of DoD architectures. 402 This volume is intended to help non-technical users understand the role of architecture in support 403 of major decision support processes. Volume 1 provides a six-step methodology (Section 7) that 404 can be used to develop architectures at all levels of the Department, and a Conceptual Data 405 Model (CDM) (Section 9) for organizing data and derived information collected by an 406 architecture effort. 407 Volume 1 contains the following resources: 408 • An Overview and Vision for DoDAF (Section 1) 409 • Defining ‘Fit for Purpose” Architectures (Section 2) 410 • An overview of the Framework, DoDAF-based architecture development guidelines, and 411 the historical background for DoDAF (Section 3) 412 • An Introduction to Enterprise Architecture, Federated Architecting, and Architecture 413 enterprise Services, and an introduction to the Federal Enterprise Architecture published 414 by the Office of Management and Budget (OMB) (Section 4) 415 • An overview for architecture planning (Section 5) 416 • Addressing Customer requirements in architecture development (Section 6) 417 • Methodology for architecture development (Section 7) 418 • Presentation methods and graphical views (Section 8) 419 • The DoDAF Meta-model Conceptual View (Section 9) 420 • Analytics in support of architecture-based management analysis (Section 10) 421 • Guidance on configuration management of architectures, and the CM process for DoDAF 422 (Section 11) 423 • Inter-relationships among DODAF and other architecture frameworks (Section 12) 424 425 DoDAF Volume 2 – Architecture Data & Views. [Primary Audience: architects, program 426 managers, portfolio managers, and other technically oriented architecture users] Volume 2 427 describes the Meta-model data groups, and their associated views, introduced in Volume 1, from 428 a technical viewpoint. 429 430 Volume 2 is organized as follows: 431 • Introduction (Section 1) 432 • Meta-model Data Groups (Section 2). Twelve data groups are described in Volume 2, 433 and each is defined by the following attributes: 434 435 o Associated Data 436 o Data Collection Method 437 oUse 438 • DoD Architecture Framework Viewpoints and Views (Section 3) 439 8 DRAFT Content is Pre-Decisional Material
  16. 16. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 440 Appendices contain acronyms, DoDAF Model Support, and references. Volume 2 references the 441 DoDAF Journal for the “DoDAF V2.0 Meta-model Data Dictionary” which describes the 442 DoDAF Logical Data Model (LDM), and the “DoDAF Architecture Development Process for 443 the Models”. The LDM provided introduces the relationships and associations needed by data 444 modelers and technical designers. 445 446 DoDAF Volume 3 – DoDAF Meta-model Physical Exchange Specification. Volume 3 relates 447 the CDM structure, LDM relationships, associations, and business rules as described in Volume 448 2 to introduce a Physical Exchange Specification (PES), which provides the constructs needed 449 to enable exchange of data and derived information among users and COIs. 450 NOTE: DoDAF 2.0 does NOT prescribe a Physical Data Model (PDM), leaving that task to the software developers who will implement the principles and practices of DoDAF in their own software offerings. 451 452 DoDAF Journal. The DoDAF Journal, https://www.us.army.mil/suite/page/454707, is the 453 electronic interface for DoDAF support, provides a place for submitting future change requests 454 to DoDAF or the DoDAF Meta-model, and provides the examples referenced in the various 455 DoDAF volumes. The Journal also includes descriptions of other best practices, lessons 456 learned, and reference documents that supplement the information contained in the three 457 volumes of DoDAF 2.0. The Journal has two parts: 458 459 • Part 1 describes the DoDAF Configuration Management Process, and provides the 460 means to submit, review, and comment on the adjudication of formal changes to DoDAF. 461 This part is intended to apply to all audiences who would like to propose changes to and 462 keep up to date with the details of the DoDAF. 463 464 • Part 2 is a reference of best practices, examples, and templates, which can be used in 465 projects where DoDAF is used to develop and execute process change through 466 architecture development. This part is geared to architects, developers, program 467 managers, and portfolio managers. Part 2 is organized in the same structure as the 468 Volumes of DoDAF. 469 470 A quick reference guide and tutorial on the use of DoDAF and the DoDAF Journal is also under 471 development. 472 473 1.3 Purpose and Scope 474 The DoDAF provides the guidance needed to establish a common vocabulary for architecture 475 development, for the exchange of architecture information, and for facilitating interoperability 476 between architecture descriptions.” Architectures are created for a number of reasons. From a 477 compliance perspective, DoD development of architectures is compelled by law and policy (i.e., 478 Clinger-Cohen Act, Office of Management, and Budget (OMB) Circular A-130). From a 479 practical perspective, the management of large organizations employing sophisticated systems, 480 technologies, and services in pursuit of often complex joint missions demands a structured, 9 DRAFT Content is Pre-Decisional Material
  17. 17. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 481 repeatable method for evaluating investments and investment alternatives, as well as the ability 482 to implement organizational change effectively, create new systems, deploy new technologies, 483 and offer services which add value to management decisions and practices. 484 485 Guidance provided by DoDAF 2.0 applies to all architectures developed, maintained, and used 486 within the DoD. The DoDAF also provides the foundational constructs to support the concept of 487 architecture federation at each tier, and enables the sharing of all pertinent architecture 488 information. This in turn permits creation of the federated version of the DoD Enterprise 489 Architecture. DoDAF 2.0 provides guidance in all areas of architecture lifecycle, consistent with 490 both DoD and OMB Guidance (i.e. Development, Maintenance, and Use of Architectures)3. 491 492 DoDAF 2.0 also supports the concept of Service-oriented Architecture (SOA) development. 493 Volume 1 provides management guidance on development of architecture views, based on 494 service requirements. Volume 2 provides technical information needed, data views, and other 495 supporting resources for development of SOA-based architectures. 496 497 1.3.1 Developing Architectures. Careful scoping and organization of the architecture 498 development effort focuses on areas of change desired by executives and managers in support of 499 their stated goals and objectives. A data-centric, rather than product-centric, architecture 500 framework ensures concordance across architecture views (i.e. architecture integration), enables 501 the federation of all pertinent architecture information, and provides full referential integrity 502 through the underlying data to support a wide variety of analysis tasks. Architecture integration 503 thus becomes a critical ‘property’ of architectures of all types as described more fully below, and 504 must be included in architecture planning and development actions. 505 506 DoDAF 2.0 describes several types of architectures that contribute to the DoD Enterprise 507 Architecture. Each of these architectures serves a specific purpose, as described briefly below, 508 and in more detail in Section 4 of Volume 1. Architecture types correspond to the tiers defined 509 in the DoD Architecture Federation Strategy. 510 511 Department-level Architecture is that type of architecture that describes processes applicable to 512 the Department and Joint Staff as a whole. These architectures include the Global Information 513 grid Architecture (GIG), the DoD Information Enterprise Architecture (DOD IEA). 514 515 Capability Architectures are those types of architectures that define and describe specific 516 capabilities required by the Department for business, procurement, and tactical operations. The 517 capability architecture is considered segment architecture, as defined in OMB Circular A-130. 518 519 Component Architectures are that type of architecture that describe and define the military 520 services and their internal business and operational functions. 3 Office of Management and Budget (OMB) Circular-A-130, Management of Federal Information Resources, February 8, 1996. Executive Office of the President., Office of Management and Budget. The current version can be found at: http://www.whitehouse.gov/omb/circulars/a130/a130trans4.html#2 10 DRAFT Content is Pre-Decisional Material
  18. 18. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 521 522 Solutions Architectures are those type of architecture that define a particular project o create, 523 update, revise, or delete established activities in the Department. Solution architecture may 524 transcend one or more of the other architecture types. A Solution Architecture is the most 525 common type of architecture developed in the Department. Solution architectures include those 526 service-oriented architectures (SOA) developed in support of specific data and other services 527 solutions. 528 529 Architecture data and derived information can be collected, organized, and stored by a wide 530 range of tools developed by commercial sources. Creation of various views using these 531 architecture tools is the typical way an enterprise architect initially captures and represents 532 important architecture data. Both DoDAF-described views, and Fit-for-purpose views (e.g. 533 dashboards, composite, or fusion presentations) created as a part of the architecture development 534 process, which visually render the underlying architecture data, act to facilitate management 535 decisions. 536 The Views described in DoDAF, including those that are legacy views from previous versions of the Framework, are provided as pre-defined examples that can be used when developing presentations of architecture data. DoDAF does not prescribe any particular views, but instead concentrates on data as the necessary ingredient for architecture development. However, other regulations and instructions from both DoD and CJCS have particular presentation view requirements. These views are supported by DoDAF 2.0, and should be consulted for specific view requirements. 537 538 1.3.2 Maintaining and Managing Architectures. Embedding the architecture 539 development process in routine planning and decision-making institutionalizes the practice and 540 makes its maintenance more automatic. Architectures are maintained and managed within the 541 Department through tiered accountability. Tiered accountability is the distribution of authority 542 and responsibility for development, maintenance, configuration management, and reporting of 543 architectures, architecture policy, tools, and related architecture artifacts to all four distinct tiers 544 within the DoD. DoDAF 2.0 supports four tiers: Department, Joint Capability Area (JCA), 545 Component, and Solution. These tiers support the federated approach to architecture 546 development and maintenance descried more fully in the DoD Architecture Federation Manual4. 547 548 1.3.3 Using Architectures. Architectures are used to support DoD decision-making 549 processes including JCIDS, DAS, PPBE, SE, and PfM processes. Other major Departmental 550 processes supported are business process reengineering, organizational development, research 551 and development, operations support, and service-oriented solutions. Architecture data and other 4 Department of Defense Manual 8210-11-M, DoD Architecture Federation Manual, dated (DRAFT) XX-XX-200X Office of the Assistant Secretary of Defense (Networks and Information Integration) (NII)/ DoD Chief Information Officer (DoD CIO).. 11 DRAFT Content is Pre-Decisional Material
  19. 19. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 552 derived information, based on process-owner or stakeholder input and review, provides decision 553 makers with information necessary to support specific decisions in those processes. 554 555 1.3.4 DoDAF Conformance. DoDAF conformance is achieved when the content of a 556 described architecture is defined according to the DM2 Concepts, Associations, and Attributes 557 for the appropriate DoDAF Views. The mapping of the DM2 Concepts, Associations, and 558 Attributes to each DoDAF View is listed in Table B-2, " DM2 Concepts (Classes, Aliases, and 559 Composite Terms) Mapping to DoDAF Views" in Volume 2, Appendix B, "DoDAF View 560 Support" 561 562 563 1.4 What is New in Volume 1. 564 565 The major changes for DoDAF Version 2.0 Volume 1 are: 566 • The major emphasis on architecture development has changed from a product-centric 567 process to an information-centric process designed to provide decision-making data 568 organized as information for the manager 569 • The three major views of architecture described in previous version (e.g. Operational, 570 technical, and System) have been changed to more specific views that relate to the 571 collection of architecture-related data that can be organized as useful information for the 572 manager in decision-making. 573 • ‘Products’ have been replaced by ‘views’ that represent specific types of presentation for 574 architecture data and derived information. 575 • The Department initiatives for Architecture Federation and Tiered Responsibility have 576 been incorporated into Version 2.0. 577 • Requirements for sharing of data and derived information in a Federated environment are 578 described. 579 • Specific tiers of architecture within the Department have been identified and described 580 (e.g. Department, Segment/Capability, Component and Solution) 581 • The DoD Enterprise Architecture is defined and described. 582 • Linkages to the Federal Enterprise Architecture are defined and described. 583 • Architecture constructs originally described in the Ministry of Defense (UK) Architecture 584 Framework (MODAF), the NATO Architecture Framework (NAF), and the Open Group 585 Architecture Framework (TOGAF) are adopted for use within DoDAF. 586 • A New DoDAF Meta-model (DM2), containing a Conceptual Data Model, a Logical 587 Data Model, and a Physical Exchange Specification has been created. 588 • Examples of graphical representations (DoDAF-described Views) have been provided as 589 examples to assist managers in determining how architecture data and other derived 590 information can be utilized in decision-making. Information is also provided on 591 development of Fit-for-purpose Views, which are user-defined views representing 592 specific desired presentations. 593 • Approaches to service-oriented architecture development are described and discussed. 594 12 DRAFT Content is Pre-Decisional Material
  20. 20. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 595 1.5 What DoD Managers and Executives Need to Know about DoDAF. 596 597 Architecture development is a management tool that supports the decision-making process. 598 A Process owner (An executive responsible for a specific process or program) has the direct 599 responsibility for ensuring that a particular process or program works efficiently, in 600 compliance with legal and departmental requirements, and serves the purpose for which it 601 was created. Periodically this means that review and evaluation of the efficiency of the 602 program or process is required. Those requirements for review, to include those detailed 603 in legislation such as the Clinger-Cohen Act and OMB Directive A-130, include the need to 604 create or update an information architecture supporting any budget requests for funding 605 of those projects and processes. 606 607 While a manager or executive may delegate the responsibility for creation of the 608 architecture to an architect with the professional qualifications needed, along with an 609 architecture development team. However, that delegation of authority does not alter the 610 continuing responsibility of the executive or manager As described throughout this volume, 611 the decision-maker needs to be actively involved in the architecture development process and 612 support architecture description development. Active Involvement means that the decision- 613 maker: 614 • Identifies the Purpose and Scope for the Architecture. The 6-Step Architecture 615 Development Process (depicted in Section 7.1.1. "6-Step Architecture Development 616 Process") provides a structure for development of scope and purpose. 617 • Transmits to the Architect and Development Team the scope and purpose of the 618 architecture effort, along with those goals and objectives that support the need. 619 • In conjunction with the Architect, identifies the general data categories needed for 620 architecture development; assist in data collection and validation 621 • Determines desired views and presentation methods for the completed architecture 622 • Meets frequently with the Architect and Development Team to ensure that the 623 development effort is on target (i.e. is ‘Fit for Purpose’) and provides new direction, as 624 required to ensure that the development effort meets established requirements. 625 Figure 1.5-1 is a more detailed view of the 6-Step Architecture Process, and depicts the sub-steps that the decision-maker needs to perform in coordination with the Architect within the Six-Step Architecture Development Process described in Section 7. In each step, the 'Meta-model Groups' referred to by the step is that data in the Meta-model Groups in DM2 described in this volume, and more technically in Volume 2. 626 627 628 Figure 1.5-1: What the decision-maker needs to do 13 DRAFT Content is Pre-Decisional Material
  21. 21. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 Figure 1.5-1: What the DoD manager needs to do 629 630 The detailed steps for the decision-maker are: 631 632 • Step 1: Review the Purpose and Scope with the Architect. In order for the architecture to 633 be “Fit-for-purpose”, the decision-maker needs to provide the list of data needed and the 634 usage of the data (use-cases) to the Architect. The decision-maker, not the Architect, is 635 the subject matter expert for the problem to be solved, the decision to be made, or the 636 information to be captured and analyzed. The architect is the technical expert who 637 translates the decision-maker’s requirements into views representing proposed solutions. 638 Determining the data needed and the use-cases (requirements) to be applied is an 639 important responsibility for the decision-maker and cannot be delegated to the Architect. 640 641 • Step 2: Review the Views, Concepts, Associations, and Attributes the Architect has 642 determined that meets the data requirements and use-cases. The Models, Concepts, 643 Associations, and Attributes required are determined in the Architect’s detailed process 644 (Step 3.2) described in Section 1.6 of Volume 2. 14 DRAFT Content is Pre-Decisional Material
  22. 22. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 645 646 • Step 3: Assist with data collection, or provide the data needed using the architecture 647 collection method described in the Architect’s detailed process (Step 3.5) found in 648 Section 1.6 of Volume 2 In that step, the Architect determined the appropriate collection 649 methods for the “Fit-for-Purpose” needs. Section 2 of Volume 2 contains a “Method” 650 subsection for each of the Meta-model groups, which provides potential collection 651 methods.. Step 3 includes those actions taken to ensure that data integration occurs 652 across all views created as a part of the architecture development effort. 653 654 • Step 4: Verify that the data collected meets the need described in use-cases to support the 655 analysis that will be performed in Step 5 of the 6-Step Architecture Development Process 656 The Architect has collected the architecture data that will meet the decision-maker’s 657 purpose (“Fit-for-Purpose”) and support the decision review processes. Section 2 of 658 Volume 2 contains a “Use” subsection for each of the Meta-model groups, which 659 provides example uses. . 660 661 • Step 5: Determine the appropriate views for the “Fit-for-Purpose” needs and support to 662 decision deliberations. Volume 2, Section 3 contains a “DoD Architecture Framework 663 Viewpoints & Views” subsection which describes each of the DoDAF-described Views. 664 This step results in presentation creation in Step 6 of the 6-Step Architecture 665 Development Process. 666 667 Working with the Architect and team, the decision-maker has a critical role in ensuring that the 668 architecture not only supports the creation of executable requirements that will achieve the 669 desired outcome, but also that senior executives and managers can view the desired solution in 670 an understandable and logical manner. 671 672 673 2. SCOPING ARCHITECTURES TO BE “FIT FOR PURPOSE” 674 675 Establishing the scope of an architecture is critical to ensuring that its purpose and use are 676 consistent with specific project goals and objectives. The term “Fit for Purpose” is used in 677 DoDAF to describe an architecture (and its views) that is appropriately focused (i.e. responds to 678 the stated goals and objectives of process owner, is useful in the decision-making process, and 679 responds to internal and external stakeholder concerns. Meeting intended objectives means those 680 actions that either directly support customer needs or improve the overall process undergoing 681 change. At each tier of the DoD, goals and objectives, along with corresponding issues that may 682 exist should be addressed according to the established scope and purpose, (e.g. Departmental, 683 Capability, Systems Engineering, and Operational), as shown in the notional diagram in Figure 684 2-1. 685 15 DRAFT Content is Pre-Decisional Material
  23. 23. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 DoD Decision-Making Direction, Guidance Architecture & Engineering Activities Impact, Results Scope and Focus Strategic Strategic Plans Enterprise Architecture Planning GIG Arch Vision NC Data Strategy Department NC Services Strategy Level NC IA Strategy Joint Ops Concepts CONOPS Requirements, … Capability JCIDS DOTMLPF changes Level (supports PfM) Enterprise-wide System Engineering Enterprise-wide System Engineering 8115 JDF/Planning Guidance CPMs ICPs Portfolios, PPBE Increments - - POM Systems Programs Architecting (supports DAS PEOs/PMs) Operational Systems Operational Mission Warfighter Mission Effectiveness Operations and other users and Support 686 687 Figure 2-1: Establishing the scope for architecture development 688 689 Establishing a scope for an architecture effort at any tier is similarly critical in determining the 690 architecture boundaries (Purpose and Use expected), along with establishing the data categories 691 needed for analysis and management decision-making. Scope also defines the key players whose 692 input, advice, and consensus is needed to successfully architect and implement change (i.e. 693 Stakeholders, both internal and external). Importantly, scope also determines the goals and 694 objectives of the effort, consistent with both boundaries and stakeholders; since goals and 695 objectives define both the purpose for architecture creation and the level of the architecture. 696 Establishing the scope of an effort also determines the level of complexity for data collection and 697 information presentation. 698 699 Architecture development also requires an understanding of external requirements that may 700 influence architecture creation. An architecture may be developed for an internal agency 701 purpose, and be consistent with and mappable to the DoD EA. To do so, consideration must be 702 given in data collection and graphical presentation to satisfaction of other external requirements, 703 such as upward reporting and submission of architecture data and models for program review, 704 funding approval, or budget review due to the sensitivity or dollar value of the proposed solution. 705 Volume 2 contains guidance on data collection for specific views required by instruction, 706 regulation, or other regulatory guidance (i.e. Exhibit 43/53, or 300 submission; interoperability 707 requirements, etc.). 708 16 DRAFT Content is Pre-Decisional Material
  24. 24. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 709 Architecture scoping must facilitate alignment with, and support the decision-making process 710 and ultimately mission outcomes and objectives (Figure 2-2). Architecture data and supporting 711 views created from organizing raw data into useful information should enable domain experts, 712 program managers, and decision makers to utilize these architectures to locate, identify, and 713 resolve definitions, properties, facts, constraints, inferences, and issues both within and across 714 architectural boundaries that are redundant, conflicting, missing, and/or obsolete. DoDAF 2.0 715 provides the either flexibility to develop Fit-for-Purpose Views (User-developed Views) or 716 DoDAF-described Views to maximize the capability for decision-making at all levels. 717 718 Analysis also uncovers the effect and impact of change (“what if”) when something is redefined, 719 redeployed, deleted, moved, delayed, accelerated, or no longer funded. Having a disciplined 720 process for architecture development in support of analytics will produce quality results, not be 721 prone to misinterpretations, and therefore, be of high value to decision makers and mission 722 outcomes. 723 724 725 726 Figure 2-2: Mission Outcomes Supported by Architectures 727 728 729 17 DRAFT Content is Pre-Decisional Material
  25. 25. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 730 3. DoDAF VOLUMES AND JOURNAL OVERVIEW 731 Section 3 provides an overview of DoDAF 2.0,both the volumes, and the electronic Journal, and 732 describes the primary reasons for developing and publishing a new version, while addressing 733 fundamental principles and guidelines that should be followed when an architecture development 734 effort is initiated. A graphical representation of the breadth and depth of information, users, 735 concepts, and artifacts that can assist in describing an architecture for executives, managers, and 736 other non-technical reviewers and users is also provided. 737 738 3.1 DoDAF Overview 739 740 DoDAF is the structure for organizing architecture concepts, principles, assumptions, and 741 terminology about operations and solutions into meaningful patterns to satisfy specific DoD 742 purposes. DoDAF offers guidance, principles and direction on communicating business, mission 743 needs and capabilities to managers, architects, analysts, and developers who are responsible for 744 developing and building the necessary services, applications and infrastructure to meet 745 stakeholder needs and to manage their expectations. 746 747 Architecture frameworks support change in organizations through building and utilization of 748 architectures that: 749 • Enhance decision making processes by leveraging knowledge and opportunities for reusing 750 existing information assets 751 • Respond to stakeholder, customer, and client needs for effective and efficient processes, 752 systems, services, and resource allocation 753 • Provide mechanisms to manage configuration of the current state of the enterprise and 754 maintain validity of the expected performance 755 • Facilitate the design of future states of the enterprise 756 757 In DoDAF 2.0, examples provided lean heavily on the major areas of change within the 758 Department, including the Joint Capabilities Integration and Development System (JCIDS), the 759 Defense Acquisition System (DAS), Systems Engineering (SE), the Planning Programming, 760 Budgeting, and Execution (PPBE) Process, and Portfolio Management (PfM). These ‘key’ 761 processes produce far-reaching change across all Military Departments, Agencies, The Joint 762 Staff, and other Departmental functions. Architectures developed utilizing the guidance in 763 DoDAF demonstrates how change is documented, and executed through an architecturally based 764 approach that: 765 766 • Establishes and documents scope and boundaries. 767 • Documents best practices. 768 • Defines and describes generic performance metrics. 769 • Documents and describes potential solutions for management review and approval. 770 771 Data, organized as information, is the critical element of architecture development. DoDAF 2.0 772 provides conceptual and logical data models, along with a Physical Exchange Specification for 773 use by data managers, tool vendors, and others to facilitate: 18 DRAFT Content is Pre-Decisional Material
  26. 26. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 774 775 • Establishment of areas of discourse and a shared vocabulary. 776 • Support for data overlap analysis. 777 • Define and encourage the use of shared information. 778 • Provide a target for architecture data integration. 779 780 The framework is consistent with, and supports DoD policy directives that require programs and 781 components (a) to ensure that their architectures meet stated objectives and Departmental 782 requirements, and, (b) provide the information necessary to support defined decisions at higher 783 tiers. These policies also require consistency across horizontal architecture boundaries within a 784 tier. The guidance and information contained in these volumes also ensures that, when followed, 785 architecture development is consistent with OMB Enterprise Architecture Guidance. 786 787 This version of the DoDAF is written to support the Departmental preference for federated 788 architecture development in a tiered environment (Section 4.3). To enable federation and 789 facilitate tiered responsibility and accountability, the framework provides data structures to 790 ensure appropriate touch-points can be compared for consistency across architecture boundaries. 791 Utilization of these data structures ensures that higher tiers have access to data from lower tiers 792 in a form that supports their decision needs. The Framework also includes aids to architects in 793 supporting net-centricity in their architectures and structures that define the management of net- 794 centric architectures (Volume 2). 795 796 DoDAF 2.0 also facilitates creation of Service-oriented Architectures (SOA) that define 797 solutions specifically in terms of services that can be discovered, subscribed to, and utilized, as 798 appropriate, in executing departmental or joint functions and requirements. 799 800 3.2 DoDAF Background 801 802 3.2.1 Authority: Law, Policy, and Historic Perspective. The Federal Government has 803 established the importance of using architecture through law, policy, and guidance. Federal law 804 and policies (Table 3.2.1-1), such as the Clinger-Cohen Act of 1996, the E-Government Act of 805 2002, and OMB Circular A-130, along with other guidance, have expressed the need for 806 architectures in support of business decisions. 807 808 Table 3.2.1-1: Federal Law and Policy Policy/Guidance Description Recognizes the need for Federal Agencies to improve the way they select and manage IT resources and states, “information technology architecture, with respect to an executive agency, means an integrated framework for Clinger-Cohen Act of evolving or maintaining IT and acquiring new IT to achieve the agency’s 1996 strategic goals and information resources management goals.” Chief Information Officers are assigned the responsibility for “developing, maintaining, and facilitating the implementation of a sound and integrated IT architecture for the executive agency”. E-Government Act of Calls for the development of Enterprise Architecture to aid in enhancing the 2002 management and promotion of electronic government services and 19 DRAFT Content is Pre-Decisional Material
  27. 27. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 processes. Office of “Establishes policy for the management of Federal information resources”5 Management and and calls for the use of Enterprise Architectures to support capital planning Budget and investment control processes. Includes implementation principles and Circular A-130 guidelines for creating and maintaining Enterprise Architectures. Facilitates cross-agency analysis and the identification of duplicative OMB investments, gaps, and opportunities for collaboration within and across Federal Enterprise Federal Agencies.6 Alignment with the reference models ensures that Architecture important elements of the FEA are described in a common and consistent Reference Models way.7 The DoD Enterprise Architecture Reference Models are aligned with (FEA RM) the FEA RM. OMB Serves as the basis for enterprise architecture maturity assessments. Enterprise Compliance with the EAAF ensures that enterprise architectures are Architecture advanced and appropriately developed to improve the performance of Assessment information resource management and IT investment decision making. Framework (EAAF) General Accounting Office Enterprise “Outlines the steps toward achieving a stable and mature process for Architecture managing the development, maintenance, and implementation of enterprise Management architecture.” Using the EAMMF allows managers to determine what steps Maturity Framework are needed for improving architecture management. (EAMMF) 809 810 3.2.2 Historical Evolution of DoDAF. The Command, Control, Communications, Computers, 811 and Intelligence, Surveillance, and Reconnaissance (C4ISR) Architecture Framework v1.0, dated 812 7 June 1996, was created in response to the passage of the Clinger-Cohen Act. It replaced the 813 Technical Architecture for Information Management (TAFIM) and ensured that a DoD-wide 814 effort to develop a better means and process for ensuring that C4ISR capabilities were 815 interoperable and met the needs of the war-fighter. Version 2.0 of the C4ISR Framework was 816 published on 18 December 1997. 817 818 The DoD Architecture Framework (DoDAF) v1.0 30 August 2003 restructured the C4ISR 819 Framework v2.0 and broadened the applicability of architecture tenets and practices to all Joint 820 Capability Areas (JCAs) rather than just the C4ISR community. DoDAF v1.0 addressed usage, 821 integrated architectures, DoD and Federal policies, value of architectures, architecture metrics, 822 DoD decision support processes, development techniques, analytical techniques, and moved 823 towards a repository-based approach by placing emphasis on architecture data elements that 5 Office of Management and Budget (OMB) Circular-A-130, Management of Federal Information Resources, February 8, 1996. Executive Office of the President., Office of Management and Budget. The current version can be found at: http://www.whitehouse.gov/omb/circulars/a130/a130trans4.html#2 6 Federal Enterprise Architecture (FEA). Executive Office of the President, Office of Management and Budget E-Gov Initiative. The current version of the FEA, and its associated reference models can be found at: http://www.whitehouse.gov/omb/egov/a-2-EAModelsNEW2.html 7 Federal Enterprise Architecture Consolidated Reference Model Version 2.0. Executive office of the President, Office of Management and Budget (OMB). A current version can be found at: http://www.whitehouse.gov/omb/egov/documents/FEA_CRM_v20_Final_June_2006.pdf 20 DRAFT Content is Pre-Decisional Material
  28. 28. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 824 comprise architecture products. DoDAF v1.0 was supported by a Core Architecture Data Model 825 (CADM) which provided for data organization and sharing. 826 827 DoDAF v1.5, 23 April 2007, was a transitional evolution of the DoDAF v1.0, provided 828 additional guidance on how to reflect net-centric concepts within architecture descriptions, 829 included information on architecture data management and federating architectures through the 830 Department, and incorporated the pre-release CADM v1.5, a simplified model of previous 831 CADM. DoDAF 1.5 provided support for net-centricity concepts within the context of the 832 existing set of architecture views and architecture products. 833 834 DoDAF 2.0 expands the framework to capture architecture information about net-centricity, 835 support Departmental net-centric strategies, and describe service-oriented solutions that facilitate 836 the creation and maintenance of a net-centric environment. DoDAF 2.0 will continue to be 837 updated in the future as it improves its support for the increasing uses of architecture data and its 838 derived information to meet the growing needs of decision makers in a Net-Centric Environment 839 (NCE). 840 841 3.2.3 DoDAF Version 2.0 – The Need for Change. Over time, and as experience with 842 architecture has grown within the Department, it has become obvious that there are two types of 843 architectures. The first and most traditional type is the Program Level Architecture. This 844 architecture has been required, defined, and supported by major Departmental processes for 845 solution evaluation, interoperability, and resource allocation. Enterprise Architecture, the 846 second type of architecture, provides a roadmap for change as well as a context and reference for 847 how and where programs “fit” within a larger ‘enterprise’ picture. Because of the complex 848 structure and function of the DoD, an enterprise can be defined at the Department level, the JCA 849 level, and the Component level. These ‘tiers’ need architecture content at their level to guide and 850 direct their lower level mission requirements. The JCA and Component tiers are critical to 851 address the high-level capabilities and semantics of a specific JCA or Component within the 852 enterprise so that federation of individual architecture data is possible. 853 854 An architecture can represent either a current (i.e. ‘as-is’ or ‘baseline’) viewpoint, or a future, 855 desired (i.e. ‘to-be’) viewpoint. When the architecture is a baseline viewpoint, it should illustrate 856 the enterprise, or a portion of it, as it exists. The future state architecture depicts the changes that 857 are desired (whether operational, system/service-centric, or technology-driven), and the 858 strategies, programs and projects that are employed to achieve the desired transformation8. The 859 future view extends beyond details or summaries of operational and systems solutions, and 860 includes program plans, programmatic status reporting, financial and budget relationships, and 861 risk management assessments, along with a transition plan. 862 863 DoDAF v2.0 supports the development and use of both program and enterprise-wide 864 architectures to illustrate the context for solutions at the capability and component level, and/or 865 the interdependencies among the components. Future updates and revisions to DoDAF will 8 Derived from OMB Circular A-130 that an enterprise architecture consists of a baseline architecture, a target architecture, and a transition strategy. 21 DRAFT Content is Pre-Decisional Material
  29. 29. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 866 extend beyond the solution space to provide standard mechanisms for communicating program 867 plans, financial information, and project status. These future updates will more fully support the 868 ability of managers and executives to evaluate and direct their programs. Without such 869 standards, interdependent programs and projects will continue to be evaluated separately, and 870 managed as individual budgets and consequently as stovepipe solutions. Such an advance in 871 enterprise architecture would facilitate portfolio management as a whole, help ensure that 872 program direction is coordinated and accountable, and address impact and alternative analysis 873 across programmatic boundaries. 874 875 3.2.3.1 Architecture Focus. DoDAF 2.0 focuses on the use of architecture throughout the 876 various tiers of the department as they relate to operational and transformational decision-making 877 processes. Working directly with process owners, through a set of comprehensive workshops, to 878 validate and extend architecture data content, and provide meaningful and useful architecture 879 views for their decision-making, DoDAF 2.0 provides better harmonization of architecture 880 content and process requirements. Additionally, these tailored architectures can be shared and 881 provide insight into best practices that benefit programs, architects, and process owners. 882 Architecture data content also includes data defining generic performance metrics, capabilities, 883 and the relevant portfolio management data, all of which are analytically useful to process 884 owners and systems engineers. 885 886 3.2.3.2 Shifting from Product-Centric to Data-Centric Focus. Both the C4ISR and earlier 887 DoD versions of the Architecture Framework have emphasized reusable and interoperable data. 888 DoDAF 2.0 places maximum emphasis on utilizing architecture data to support analysis and 889 decision-making. With appropriate architecture data, it is possible to support innovative and 890 flexible presentation of the architecture data in a meaningful, useful, and understandable manner 891 through the views described in Volumes 1 and 2. 892 893 894 3.3 Assumptions. Development of DoDAF 2.0 is guided by several assumptions. These are: 895 • The DoDAF will continue to evolve to meet the growing needs of decision makers in a Net- 896 Centric Environment (NCE). 897 • As capability development continues, and Infrastructure continues to mature, architectures 898 will increasingly be a factor in evaluating investments, development, and performance at the 899 various portfolio levels. 900 • As the DoD increases its use of architecture data and its derived information for decision- 901 making processes, architects will need to understand how to aggregate the data as useful 902 information for presentation purposes at the enterprise level. 903 • The DoDAF plays a critical role in the development and federation of architectures. It will 904 continue to improve its support for the increasing uses of semantically linked and aligned 905 architecture data. 906 • Architecture data described in DoDAF is not all-inclusive. Architectures may require 907 additional data, and it is expected that architecture developers at all levels will extend the set 908 of architecture data as necessary. 22 DRAFT Content is Pre-Decisional Material
  30. 30. Content is Pre-Decisional Material 24 Dec 08 Spiral 4 909 • Prescription of required architect data sets or views to be included in an architecture is a 910 decision made by process owners based on the purpose of the architecture. Some specific 911 minimum architecture data will be described in DoDAF for the exchange of architecture data 912 in the federated environment, and will be included in the architect data set supporting 913 products required by the process owners. 914 915 3.4 DoDAF Structure and Views 916 917 DoDAF 2.0 is organized around data and views. This approach responds to Departmental 918 programs, such as Business Transformation (BT), JCIDS, and other major functions with 919 significant impact throughout the Department that have developed requirements for multiple, 920 custom views. These views use information based on authoritative data, beyond the operational, 921 systems, and technical views of previous versions of DoDAF, and is consistent with DoD 922 Instruction (DODI) 4630.8 requirements for integrated architectures. These customized views 923 enable the information contained in an architecture to be communicated to, and understood by, 924 stakeholders in diverse functional organizations. The products developed under previous 925 versions of DoDAF continue to be supported, as described in Volume 2. 926 927 A view is a representation of a related set of information. A viewpoint describes data drawn 928 from one or more perspectives and organized in a particular way useful to management 929 decision-making. More specifically, a viewpoint definition includes the information that should 930 appear in individual views; how to construct and use the views (by means of an appropriate 931 schema or template); the modeling techniques for expressing and analyzing the information; and 932 a rationale for these choices (e.g., by describing the purpose and intended audience of the 933 view).9 934 935 3.4.1 Architecture Data. Architecture data provides for more efficient and flexible use and 936 reuse of the architecture, enabling broader utility for decision makers and process owners. This 937 version of DoDAF emphasizes the collection, organization, and maintenance of architecture data 938 and derived information, as opposed to development of products in previous versions. A 939 technical description of the underlying data can be found in DoDAF Volume 2. 940 9 The Open Group Architecture Framework (TOGAF), Version 8.11 The current version can be found at: http://www.opengroup.org/architecture/togaf/ 23 DRAFT Content is Pre-Decisional Material

×