DoD Architecture Framework
Upcoming SlideShare
Loading in...5
×
 

DoD Architecture Framework

on

  • 5,920 views

 

Statistics

Views

Total Views
5,920
Views on SlideShare
5,920
Embed Views
0

Actions

Likes
1
Downloads
156
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

DoD Architecture Framework DoD Architecture Framework Document Transcript

  • 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
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 24 25 26 ii DRAFT Content is Pre-Decisional Material
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 NOTE: DoDAF data can be collected, organized and stored by a wide range of architecture tools developed by commercial sources. Visualization of views, as shown in DoDAF 2.0 is for example purposes only. It should be understood, however, that the creation of a limited set of models, using a range of architecture tools developed by commercial sources, is the typical way an enterprise architect initially captures and collects important architecture data. These models are commonly produced by architects. Development of architecture views is accomplished by collecting and organizing architecture data that must be clearly mapped to the underlying DoDAF Conceptual and Logical Data Models in a standard and consistent way, in order to capture interoperable architecture data, and to achieve the goal of a federated approach to architecture management. There is no single, correct way to visualize any view, although the examples present those that are commonly used in the DoD communities. The critical factor in ‘conforming’ to DoDAF practice is that the data represented by the graphical representation is consistent with, or mappable to the DoDAF Conceptual and Logical Data models, and the Physical Exchange Specification described in these volumes. A View, as described in DoDAF 2.0, is a representation of data in any understandable format. Formats can include any of the presentation styles (such as dashboards, spreadsheets, diagrams, data models, etc) that convey the meaning of data. 941 942 943 3.4.2 Architecture Viewpoints. An architecture viewpoint is composed of a selected set of 944 architecture data that has been organized to facilitate visualization in an understandable way. An 945 architecture can be visualized in a number of formats, such as dashboard, fusion, textual, 946 composite, or graphics, which present data and derived information collected in the course of 947 architecture development. A viewpoint is only a presentation of a portion of the architecture 948 data, in the sense that a photograph provides only one view of the object within the picture, not 949 the entire representation of that object. Figure 2.5-1 provides a graphical representation of the 950 architecture viewpoints in DoDAF 2.0. 951 24 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 952 953 Figure 3.4.2-1: Architecture Viewpoints in DoDAF 2.0 954 955 956 3.4.2.1 ALL Viewpoint (AV). Some overarching aspects of an architecture relate to all the 957 views. The AV products provide information pertinent to the entire architecture, such as the 958 scope and context of the architecture. The scope includes the subject area and time frame for the 959 architecture. The setting in which the architecture exists comprises the interrelated conditions 960 that compose the context for the architecture. These conditions include doctrine; tactics, 961 techniques, and procedures; relevant goals and vision statements; concepts of operations 962 (CONOPS); scenarios; and environmental conditions. 963 964 965 3.4.2.2 The Capability Viewpoint (CV). The CV captures the enterprise goals associated 966 with the overall vision for executing a specified course of action, or the ability to achieve a 967 desired effect under specific standards and conditions through combinations of means and ways 968 to perform a set of tasks. It provides a strategic context for the capabilities described by an 969 architecture, and an accompanying high-level scope, more general than the scenario-based scope 970 defined in an operational concept diagram. The views are high-level and describe capabilities 971 using terminology, which is easily understood by decision makers and used for communicating a 972 strategic vision regarding capability evolution. 973 974 3.4.2.3 The Data and Information Viewpoint (DIV). The DIV captures the business 975 information requirements and structural business process rules of the architecture. It describes 25 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 976 the information that is associated with the information exchanges of the architecture, such as 977 attributes, characteristics, and inter-relationships. Data is described fully in Volume 2. 978 979 3.4.2.4 The Operational Viewpoint (OV). The OV captures the organizations, tasks, or 980 activities performed, and information that must be exchanged between them to accomplish DoD 981 missions. It conveys the types of information exchanged the frequency of exchange, which tasks 982 and activities are supported by the information exchanges, and the nature of information 983 exchanges. 984 985 3.4.2.5 The Project Viewpoint (PV). The PV captures how programs are grouped in 986 organizational terms as a coherent portfolio of acquisition programs. It provides a way of 987 describing the organizational relationships between multiple acquisition programs, each of which 988 are responsible for delivering individual systems or capabilities. 989 990 3.4.2.6 The Services Viewpoint (SvcV). The SvcV captures system, service, and 991 interconnection functionality providing for, or supporting, operational activities. DoD processes 992 include warfighting, business, intelligence, and infrastructure functions. The SvcV functions and 993 service resources and components may be linked to the architecture artifacts in the OV. These 994 system functions and service resources support the operational activities and facilitate the 995 exchange of information. 996 997 3.4.2.7 The Standards Viewpoint (StdV). The TV is the minimal set of rules governing the 998 arrangement, interaction, and interdependence of system parts or elements. Its purpose is to 999 ensure that a system satisfies a specified set of operational requirements. The StdV provides the 1000 technical systems implementation guidelines upon which engineering specifications are based, 1001 common building blocks established, and product lines developed. It includes a collection of the 1002 technical standards, implementation conventions, standards options, rules, and criteria that can 1003 be organized into profile(s) that govern systems and system or service elements for a given 1004 architecture. 1005 1006 3.4.2.8 The Systems Viewpoint (SV). SV captures the information on supporting automated 1007 systems, interconnectivity, and other systems functionality in support of operating activities 1008 1009 3.5 DoDAF Development Guidelines 1010 DoDAF 2.0 provides comprehensive and practical guidance for the creation of architectures that 1011 provide added value for decision-making at whatever level of the DoD they are produced. To 1012 this end, the framework offers guiding principles in the development of architectures that 1013 transcend the tier, level, or purpose of the architecture development, and a logical method for 1014 executing architecture development for supporting critical decisions within key DoD 1015 management and change management processes. The Framework also offers flexibility in 1016 approach, toolset utilization, and techniques (such as structured analysis, object-oriented, and 1017 service-oriented). 1018 1019 3.5.1 Guiding Principles. Guiding principles are high-level concepts, which provide a general 1020 roadmap for success in architecture development under DoDAF 2.0. The principles are: 26 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1021 1022 • Architectures should clearly support the stated objective(s) (“Fit for Purpose”). The 1023 framework offers general direction in the development of architectures so that they can 1024 support critical decisions within key DoD management and change management processes. 1025 While DoDAF 2.0 describes a number of views, based on collected data, diligent scoping of 1026 a project and any guiding regulations, instructions, or standard procedures will determine the 1027 specific visualization requirements for a particular architectural effort. 1028 • Architectures should be simple and straightforward, but still achieve their stated 1029 purpose. Architectures should reflect the level of complexity defined by the purpose for 1030 their creation. Scoping of a project, as described in Section 7.0 Methodologies, will ensure 1031 that the resulting architecture data and derived information, and the views created are 1032 consistent with their original purpose. 1033 • Architectures should facilitate, not impede communications in decision processes and 1034 execution. Architecture creation is meant to support decision processes and facilitate 1035 improvement of procedures and/or technology in the enterprise. Collection of architecture 1036 data and creation of views supports the decision-making process, and provide a record to 1037 explain critical choices to technical and non-technical managerial staff. 1038 • Architectures should be relatable, comparable, and capable of facilitating cross- 1039 architecture analysis. Most architectures, except perhaps those at the highest levels of DoD 1040 or an organization, relate on their boundaries to other external processes and operations. 1041 When several processes and/or operations are evaluated, compared, or cross-referenced, it 1042 should be clear how, where and why data passes among them in similar form. 1043 • Architecture should articulate how data interoperability is achieved among federated 1044 architectures. To enable federation, the framework will provide structures to ensure that 1045 horizontal touch-points can be compared for consistency across architecture boundaries. 1046 Other mechanisms will ensure that higher tiers have access to data from lower tiers in a form 1047 that supports their decision needs. DoDAF utilizes the DoDAF Meta-model, and particularly 1048 the Physical Exchange Specification described in Volume 3, as a resource for 1049 interoperability. A key element in ensuring interoperability is the effort taken to plan for 1050 integration of data across views, architecture boundaries, and is consistent between tiers. 1051 • Architectures should be data centric and tool-agnostic. The framework assists in the 1052 design of structures that meet specific needs depending on the priorities of individual 1053 organizations. In particular, the framework calls for the development of integrated, 1054 searchable, structured architecture data sets that support analysis targeted to critical 1055 decisions. 1056 • Architecture data should be organized, reusable, and decomposed sufficiently for use 1057 by architecture development teams. Collecting and organizing architecture data for use in 1058 decision processes should not be ‘over done’, that is the depth and breadth of data collected 1059 should be sufficient to capture the major processes actions, and not be so broad that the 1060 original intent of the architecture project becomes clouded. Whenever possible, data 1061 common to other architectures should be used. New data should be created utilizing the 1062 structures described in Volume 2 and Volume 3 so that, when stored in the DoD Metadata 1063 Registry, it becomes available to others with similar requirements. 27 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1064 • Architecture development should be guided by the principles and practices of net- 1065 centricity to facilitate and support the Net-Centric Strategy of the Department. 1066 1067 Architectural guiding principles enable and facilitate validation and verification activities that 1068 will determine the success of the project, and the ability of the resulting architecture to serve the 1069 purpose for which it was created. Guiding principles support the more specific goals and 1070 objectives of a project as a roadmap. 1071 1072 3.5.2 Multiple Techniques and Toolsets, including Structured and Object Oriented 1073 Analysis. 1074 The framework allows architects to select techniques and toolsets to meet specific needs. While 1075 the framework provides examples of the application of both Structured Analysis and Design 1076 (SADT) and Object-Oriented Analysis & Design (OOAD) techniques, it mandates neither. The 1077 framework explicitly permits any technique that meets the needs of the organization, provides 1078 the appropriate architecture data, adheres to the architecture data requirements of parent tiers 1079 described further in Section 3, and is capable of producing data that can be shared in a federated 1080 environment. A brief section on essential toolset attributes desirable for creation of architectures 1081 utilizing DoDAF are contained below in Section 3.5.3. 1082 1083 3.5.3 Essential Toolset Attributes 1084 While DoDAF is toolset agnostic, allowing architects, and architecture development teams to 1085 utilize any toolset they desire to create architectures, there are some basis attributes of a toolset 1086 needed to ensure that architectures, once registered, are discoverable, sharable, and their data 1087 useful to others with similar or derived needs in their own architecture development. These 1088 attributes are: 1089 • Capable of utilizing the Physical Exchange Data Specification described in Volume 3 to 1090 collect, organize, store, and share architecture data 1091 • Capable of XML data transfer to/from the DoD Metadata Registry (DMR), and other 1092 resources, such as the DoD Architecture Registry System (DARS) for registering 1093 architecture data 1094 1095 1096 3.6 Architecture Resources 1097 1098 A number of architecture resources exist which serve as sources for guidelines that must be 1099 consulted while building architecture products. Some of these architecture resources are briefly 1100 described below with their architectural uses, and their URLs. Additional information is 1101 contained in the individual URLs.. Some architecture resources may require SIPRNET access. 28 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1102 1103 Architecture Resources Resource Description Architecture Use URL Department of Defines the key principles, rules, The DoD IEA provides the guidelines and rules that http://www.defenselink.mil/ Defense Information constraints and best practices to which the architect must keep in mind in the architecture cio-nii/cio/diea/ Enterprise applicable DoD programs, regardless of development effort. Architecture (DoD Component or portfolio, must adhere in IEA) order to enable agile, collaborative net- centric operations. DoD Architecture DARS is the DoD registry and repository To discover architectures that exist, or may be in https://dars1.army.mil Registry System of segment and solution architectures development. Depending on the purpose and scope, (DARS) comprising the federated DoD enterprise an architect may search and discover Architectures architecture that overlap the scope and purpose of the architecture effort. To register metadata about architectures that are being developed, or currently exist. DoD Information The official unclassified DoD data source The Systems metadata from the Architecture can be https://www.dadms.navy.mi Technology Portfolio for FISMA, E-Authentication, Portfolio used to populate DITPR with new or updated l/ Repository (DITPR) Management, Privacy Impact Assessments, information. DITPR can also populate the the inventory of MC/ME/MS systems, and architecture’s Systems metadata, particularly on the systems that interface with systems described in the registry for systems under DODI 5000.2 architecture, but are not part of the scope of the architecture. DoD Information Online repository for a minimal set of The DISR can be used to populate the Standards https://disronline.disa.mil Technology Standards primarily commercial IT standards models (StdV-1 and StdV-2) of the Architecture. and Profile Registry Conversely, the Standards Models can identify (DISR) additional or new standards that need to be added to DISR. Figure 3.6-1 Architecture Resources 1104 29 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 Architecture Resources Resource Description Architecture Use URL Joint C4I Program Formally assess systems and capabilities The ICD, CDD, and CPD contain architecture http://jcpat.ncr.disa.smil.mil Assessment Tool documents (Initial Capabilities Document, information. As the architecture development /JECOweb.nsf (JCPAT) Capability Development Document, and progresses, the collected architecture information Capability Production Document) for Joint can be extracted and reported in the ICD, CDD, and Staff interoperability requirements the CPD. In addition, the architecture information certification and is the ITS/NSS Lifecycle can be exchanged with the E-ISP tool which is part Repository and the archives of JCPAT. Joint Common System A standard taxonomy for terms of the Use the taxonomy to align or extend system TBD Function List system functions based on the Universal functions within the architecture being developed Joint Task List Knowledge The KM/DS tool will be used by DOD Supporting the JCIDS approval process, the https://jrockmds1.js.smil.mil Management/Decision components to submit documents and documents that are necessary for Milestone /guestjrcz/gbase.guesthome. Support (KM/DS) comments for O-6 and flag reviews, search Decisions have architecture information. As the for historical information, and track the architecture development progresses, the collected status of documents. architecture information can be extracted and reported in the required documents. Metadata Registry The DoD Metadata Registry and The Resource Flows and Physical Schemas from the http://metadata.dod.mil Clearinghouse provides software Architecture can be used to populate the Metadata developers access to data technologies to Registry. support DoD mission applications. Through the Metadata Registry and Clearinghouse, software developers can access registered XML data and metadata components, database segments, and reference data tables and related metadata information Figure 3.6-1 Architecture Resources (Cont.) 1105 30 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 Architecture Resources Resource Description Architecture Use URL Navy Architecture A standard terms of reference for the Navy The use of the critical taxonomies is a step to https://stalwart.spawar.navy. Elements Reference and Marine Corp. The Architecture ensuring integration of systems within a system of mil/naerg/ Guide (NAERG) Elements represent the critical taxonomies systems and alignment of information technology requiring concurrence and standardization (IT) functionality to mission and operational needs. for an integrated architecture. They The data contained in each element of the comprise the lexicon for the three views of Architecture list shall be used for overall the architecture framework, the operational architecture framework development, programmatic (OV), system (SV) and technical standards research, development, and acquisition activities, (TV) views. and related integration and interoperability and capability assessments. It will be updated through review periods to support DoN Program Objective Memorandum (POM) efforts and to reflect changes mandated by DoD, technology improvements, and other factors. Service Registry The Service Registry provides enterprise- The Services metadata from the Architecture effort wide insight, control and leverage of an can be used to populate the Service Registry in the organization's services. It captures service process of developing the solution. descriptions and makes them discoverable from a centrally managed, reliable, and searchable location. Universal Joint Task The Universal Joint Task List (CJCSM Use the taxonomy to align or extend operational http://www.dtic.mil/doctrine List 3500.04C) serves as a common language activities within the architecture being developed /jel/cjcsd/cjcsm/m350004c.p (UJTL) and common reference system for joint df force commanders, combat support agencies, operational planners, combat developers, and trainers to communicate mission requirements. It is the basic language for development of a joint mission essential task list (JMETL) or agency mission essential task list (AMETL) that identifies required capabilities for mission success. Figure 3.6-1 Architecture Resources (Cont.) 1106 31 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1107 4. ENTERPRISE ARCHITECTURE 1108 “Today, the encouraging coalescence among leaders is that many enterprise systems have the 1109 same architectural approach—although not all express it in the same way. A similar 1110 convergence addresses the kinds of techniques, pattern, and designs that are independent of 1111 specific application domains, and that enable effective production of responsive, scalable, 1112 flexible, and unifiable enterprise applications.”10 1113 1114 Within DoD, Enterprise Architecture (EA) has been seen for many years as providing product- 1115 oriented insight into a wide range of data, programs, and activities, organized through 1116 Communities of Interest (COI). The data-centric approach to DoDAF version 2.0 is designed to 1117 facilitate the reuse and sharing of COI data. Since DoDAF provides the conceptual, logical, and 1118 physical exchange specifications but does not otherwise prescribe the configuration of the 1119 product composition, architects and stakeholders are free to create their views of data that best 1120 serve their needs. 1121 1122 4.1 Introduction and Overview 1123 An architecture is a strategic information asset that describes the current and/or desired 1124 relationships between an organization’s business, mission and management processes, and the 1125 supporting infrastructure. Architectures define a strategy for managing change, along with 1126 transitional processes needed to evolve the state of a business or mission to one that is more 1127 efficient, effective, current, and capable of providing those actions needed to fulfill its goals and 1128 objectives. Architectures may illustrate an organization, or a part of it, as it presently exists; any 1129 changes desired (whether operational or technology-driven); and the strategies and projects 1130 employed to achieve the desired transformation. An architecture also defines principles and 1131 goals and sets direction on issues, such as the promotion of interoperability, intra-, and 1132 interagency information sharing, and improved processes, that facilitate key DoD program 1133 decisions. 1134 1135 Such support extends beyond details or summaries of operational and systems solutions, and 1136 includes program plans, programmatic status reporting, financial and budget relationships, and 1137 risk management. In addition to detailed views of individual solutions, the framework supports 1138 the communication of enterprise-wide views that illustrate the context for those solutions, and 1139 the interdependencies among the components. Beyond the solution space, standard mechanisms 1140 for communicating program plans, financial information, and project status are established so 1141 that executives and managers can evaluate and direct their programs. 1142 1143 Enterprise Architecture (EA) is the architecture described by the DoD Architecture Reference 1144 Models representing the major business areas of the Department, along with the implementing 1145 guidance, standards, and descriptions of Department-wide processes mapped to the Federal 1146 Enterprise Architecture. The DoD EA is shown in Figure 3.1-1. The DoD EA is composed of a 1147 "baseline architecture" describing the ‘segment’ architectures for each major Departmental 1148 business area (Consistent with the Federal EA Architecture described in OMB A-130). It also 10 McGovern, James, Ambler, Scott, Stevens, Michael E., Linn, James, Sharan, Vikas & Jo, Elias K. (2004) A Practical Guide to Enterprise Architecture. New Jersey: Prentice-Hall. 306pp. 32 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1149 includes a "target architecture" that includes proposed changes to the baseline architecture along 1150 with the rules, standards, services and systems life cycle information needed to optimize and 1151 maintain a process, or part of a process that a self-sufficient organization wants to create and 1152 maintain by managing its IT portfolio. EA provides a strategy that enables the organization to 1153 support its current operations while serving as the roadmap for transitioning to its target 1154 environment. Transition processes include an organization's PfM, PPBE, and EA planning 1155 processes, along with services and systems life cycle methodologies. Architectures created by 1156 Military Components, joint activities, agencies, and other organizations, at any level or tier of the 1157 Department are mappable to the DoD EA. 1158 1159 Figure 4.1-111 presents the high-level elements of the DoD EA and the relationship among them. 1160 The DoD Architecture Baseline describes the current DoD environment and the existing 1161 Department of Defense Information Environment (DoD EI) capabilities that support operations 1162 and services in today’s environment. The DoD Transition Strategy includes an enterprise-level 1163 transition plan built from JCAs and DoD Component portfolio transition plans. The JCA 1164 portfolios describe future, required operational, warfighting, business, and Defense intelligence 1165 capabilities, together with the systems and services required. The description of the future DoD 1166 operating environment and associated capability requirements represent the target architecture of 1167 the DoD EA. These are time-phased as determined by functional owners and JCA developers. 11 This figure reflects the use of enterprise architectures as defined in OMB Circular A-130. 33 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1168 1169 Figure 4.1-1: Components of the DoD EA 1170 1171 Migration in a net-centric operating environment from the “As-Is” to the “To-Be” requires that 1172 the DoD Information Environment Architecture (DoD IEA) and the Net-Centric strategies act as 1173 uniform references for, and guide the transition sequence. The DoD Architecture Federation 1174 Strategy12 describes the DoD EA structure and its relationship to federated, supporting 1175 architectures. 1176 1177 4.2 Transition Planning 1178 1179 As discussed above, one major impetus for creating and using architectures is to guide 1180 acquisition and development of new enterprises, capabilities and systems or improvements to 1181 existing ones. Earlier versions of DoDAF addressed this need exclusively using “As-Is” and 1182 “To-Be” architectures, along with a Systems and/or Services Technology Forecast. The “As-Is” 1183 and “To-Be” concepts are time-specific snapshots of DoDAF artifacts and products that initially 1184 served as the endpoints of a transition process. However, this transition strategy has several 12 Global Information Grid (GIG) Architecture Federation Strategy, 1 August 2007. Office of the Assistant Secretary of Defense (Networks & Information Integration) (NII)/DoD Chief Information Officer (DoD CIO). 34 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1185 potential pitfalls, to include the difficulty in accurately representing the “As-Is” starting point 1186 where legacy systems are sometimes poorly documented, and processes are largely undefined. 1187 There is also the consideration that long-term goals are often very flexible, resulting in flux in 1188 the “To-Be” version 1189 1190 Since the “As-Is” and “To-Be” architectures are time-specific versions of similar sets of data 1191 with contrasting viewpoints, transition planning is able to chart an evolutionary path from the 1192 “As-Is” to its corresponding “To-Be” architecture given a clear understanding of the expected 1193 outcomes or objectives through some future (perhaps undefined) future point. It is expected that 1194 the ‘To-be’ architecture will change over time as Departmental priorities shift and realign. More 1195 comprehensive discussions of the ‘As-is’ and ‘To-be’ architecture, including transition 1196 requirements, are contained in Volume 2, and the DoDAF Journal, 1197 https://www.us.army.mil/suite/page/454707. 1198 1199 4.3 Federated Approach to DoD Architecture Management 1200 The Department has adopted a federated approach to distributed architecture data collection, 1201 organization, and management among the Services, Agencies and COIs as its means of 1202 developing the "DoD Enterprise Architecture", with a virtual rather than physical data set 1203 described through supporting documentation and architecture views. This approach provides 1204 increased flexibility while retaining significant oversight and quality management services at the 1205 Departmental level. Detailed guidance on the DoD Federation Strategy is contained in DOD 1206 8210-11-M, DoD Federation Strategy. 1207 1208 4.4 Tiered Accountability. Tiered Accountability (TA) is the distribution of authority and 1209 responsibility to a DoD organization for an element of the DoD EA. Under TA, DoD is defining 1210 and building enterprise-wide capabilities that include data standards, business rules, enabling 1211 systems, and an associated layer of interfaces for Department, specified segments of the 1212 enterprise (i.e. Joint Capability Areas (JCA), DoD Components), and Programmatic solutions. 1213 Each tier – Enterprise, Capability, Component, and Solution – has specific goals, as well as 1214 responsibilities to the tiers above or below them. The DoD-established JCAs are consistent with 1215 the Segment Architectures defined in the OMB Practice Guidance and the OMB Exhibit 53 and 1216 Exhibit 300 reporting requirements. 1217 DoD Component and Solution architectures are categorized when developed to facilitate 1218 alignment (mapping and linking), cataloging, navigating, and searching disparate architecture 1219 information in a DoD registry of holdings. The TA Strategy, shown in Figure 4.4-1, identifies 1220 the three major levels of the DoD EA, along with a ‘solutions’ tier that provides specific 1221 programmatic solutions for any level of the enterprise. All architectures developed by the tiers 1222 are federated, as described in the DoD Federation Strategy. 1223 35 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 DoD Architecture DoD EA Department Federation Capabilities/ Segment Component Solutions 1224 1225 Figure 4.4-1: Architecture Levels for Tiered Accountability 1226 1227 1228 Alignment in the tiers is required for the DOD EA to be discoverable, shareable, and 1229 interoperable. Architecture can also support many goals within the tiers, each of which may 1230 imply specific requirements for structure, content, or level of detail. Alignment decisions must 1231 balance the interdependence of architectures with the need for local flexibility to address local 1232 issues. Alignment describes the minimum constraints needed to ensure consistency across 1233 architecture levels. Architectures often relate at some ‘touch point’ to other architectures on the 1234 same level, level(s) above, or level(s) below, and should be discovered and utilized in 1235 architecture development to ensure that appropriate linkages are created and maintained. The 1236 need to plan for them implies that each architecture sharing a touch-point should be available to 1237 architects on both sides. The DoD Metadata Registry (DMR) for data and the Defense 1238 Architecture Registry System (DARS) for architecture registration facilitate the ability to 1239 discover and utilize architecture data, with the caveat that any touch-points within the purview of 1240 an established COI adhere to COI guidance13. 1241 1242 4.5 DoD Architecture Enterprise Services. The next generation of DoD Enterprise 1243 Architectures will be constructed by employing a set of DoD Architecture Enterprise Services 13 Department of Defense Net-Centric Data Strategy, 9 May, 2003. Office of the Assistant Secretary of Defense (Networks & Information Integration) (NII)/DoD Chief Information Officer (DoD CIO). 36 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1244 (DAES)14 for registering, discovering, aligning, translating, and utilizing architecture data, and 1245 derived information to support key DoD decision processes through implementing the concepts 1246 of the DoD Net-Centric Strategies. 15 DAES will be implemented using Web Services, in which 1247 specific content and/or functionality is provided by one user for others, many of whom may be 1248 unknown to the provider. An Operational Resource Data Flow Description (A redesigned 1249 Operational Viewpoint 2 (OV-2) DoDAF-described View) has been retained in DoDAF 2.0 to 1250 describe those services that can be discovered and subscribed from one or more specific sources 1251 and delivered to one or more known or unknown subscribers. 1252 1253 Registration of architectures, one of the goals of the Net Centric Data Strategy (NCDS)16, is the 1254 first step toward enabling discovery of architecture metadata. DAES includes a registration 1255 service to register the metadata (Through the DoD metadata Repository), and a method to 1256 describe the purpose and scope of an architecture (Through DARS). The registration service will 1257 enable cataloging of architectures in federated repositories, and, once complete, architectures are 1258 ‘available’ for discovery. When an architecture is discoverable, it can be aligned to, linked to, or 1259 re-used by other architectures. The discovery service enables users to execute a federated search 1260 for architecture holdings meeting specified search parameters. 1261 1262 4.6 Alignment to the Federal Enterprise Architecture (FEA) 1263 1264 The Office of Management and Budget (OMB) established the Federal Enterprise Architecture 1265 (FEA) program in 2003 to build a comprehensive business-driven blueprint of the entire Federal 1266 government. OMB’s Circular A-11 requires that Cabinet-level agencies, including the DoD, link 1267 their budget submissions to the FEA, and annually evaluates those submissions through the 1268 Enterprise Architecture Assessment Program, which establishes an evaluation score for overall 1269 agency progress. 1270 1271 The core principles of the FEA program are: 1272 • business-driven approach 1273 • promote collaboration of effort and reuse 1274 • improve efficiency and effectiveness of business operations through the use of enterprise 1275 architecture for the capital investment process 1276 • Demonstrate cost savings and cost avoidance through improved core processes, and 1277 cross-agency sharing and mutual investment 1278 1279 DoD leverages the FEA construct and core principles to provide the Department with the 1280 enterprise management information it needs to achieve its own strategic transformation goals and 1281 respond to upward reporting requirements of OMB. The primary objective is to improve DoD 1282 performance, using EA, by providing a framework for cross-mission analysis and identification 14 Formerly called the GIG Architecture Enterprise Services (GAES) 15 For additional details about the services, please review Section 11, “GIG Architecture Enterprise Services (GAES) — Making the GIG Architecture Visible, Accessible, and Understandable” of the “Global Information Grid (GIG) Architecture Federation Strategy,” Version 1.2, 1 August 2007 16 Department of Defense Net-Centric Data Strategy, 9 May, 2003. Office of the Assistant Secretary of Defense (Networks & Information Integration) (NII)/DoD Chief Information Officer (DoD CIO). 37 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1283 of gaps and redundancies; and by developing transition plans and target architectures that will 1284 help move DoD to the net-centric environment. 1285 1286 Several Federal and DoD-specific EA artifacts exist that describe enterprise-level management 1287 information. These include: 1288 • The President’s Management Agenda. 1289 • OMB A-11 Exhibit 300 submissions 1290 • OMB FEA Practice Guidance 1291 • OMB EA Assessment Guide 1292 • OMB FEA Reference Models 1293 • DoD EA Reference Model (RM) Taxonomy 1294 • DoD EA Consolidated RM 1295 • DoD EA Transition Strategy 1296 • DoD Segment Architectures 1297 • DoD EA Self-Assessment 1298 • DoD Architecture Federation Strategy 1299 1300 These artifacts facilitate the alignment with the FEA, contribute to a broader understanding of 1301 architecture alignment, provide a basis for federated architectures, promote a more efficient and 1302 effective use of assets, and ultimately lead to better decision-making. 1303 When developing architectures, particularly at the Departmental and Component levels, 1304 alignment with the FEA is accomplished by utilizing the FEA-RM documents together with DoD 1305 documents and references as a basis for defining processes, data, services, and technical 1306 standards. As an example, when a process owner determines that an architecture is needed for 1307 some specific purpose, the first references to use are as shown below in Figure 4.6-1. 38 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 Action Reference(s) Usage Determine processes DoDAF (DoDAF) Determine techniques and Involved FEA Business Reference Model notation to be used (BRM) (FEA BRM) Determine FEA business processes to align to; use taxonomies in BRM to name processes Identify and Define data DoDAF Meta-model (DM2) (DM2) Data Group and metadata structures FEA Data Reference Model (DRM) (DRM) Existing Government-wide metadata for linkage to architecture Document Architecture DoDAF (DoDAF) provides described views, and DoD Metadata Registry (DMR) guidance on creating ‘Fit-for-purpose DoD Architecture Registry System Views’ for presentation purposes (DARS) Toolset (DMR) Provides existing metadata to use in OMB EA Guidance conjunction with DMR to create data OMB EA Assessment Guide required (DARS) provides registration services for architecture discovery (Toolset) provides automated notation method for creating views (OMB EA Guidance) provides information on required format and content of EA for OMB 53/300 process (OMB EA Assess. Guide) provides guidance on evaluation of architectures submitted to OMB for review Publish Architecture DoD Architecture Federation (DoD Fed. Strategy) provides guidance on Strategy architecture data discovery Agency Repository DARS (Agency Repository) stores EA Data (DARS) Providers EA contact information Figure 4.6-1. References to Architecture Development 1308 1309 39 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1310 4.7 Addressing Security Issues in DoDAF-conformant Architecture Development 1311 1312 Security continues to be a critical concern within the DOD, and architecture development efforts 1313 at any level need to ensure that appropriate security concerns are addressed clearly, so that any 1314 decisions made that rely on the architecture are valid and useful. Security concerns are routinely 1315 addressed through the risk assessment process described in Section 10 of Volume 1, and 1316 Appendix C of Volume 2. 1317 Each of the individual views described in detail in Volume 2 provides the architect and 1318 development team with a set of data for collecting, documenting, and maintaining security data. 1319 These data support physical, procedural, communications Security (COMSEC), TEMPEST, and 1320 Information Security (INFOSEC) concerns. 1321 1322 5. ARCHITECTURE PLANNING 1323 1324 5.1 Defining the Enterprise 1325 In a generic sense, an ‘enterprise’ is any collection of organizations that has a common set of 1326 goals and/or a single bottom line. An enterprise, by that definition, can encompass a Military 1327 Department, DoD as a whole, a division within an organization, an organization in a single 1328 location, or a chain of geographically distant organizations linked by a common management or 1329 purpose. An enterprise today is often thought of as an extended enterprise where partners, 1330 suppliers, customers, along with their activities and supporting systems are included in the 1331 architecture. 1332 1333 Government agencies may comprise multiple enterprises, and there may be separate enterprise 1334 architecture projects. However, the projects often have much in common about the execution of 1335 process activities and their supporting information systems, and they are all linked an enterprise 1336 architecture. The DoD Enterprise Architecture is described in Section 3.1. Architecture 1337 development in conjunction with the use of a common architecture framework, which describes 1338 the common elements of architecture, lends additional value to the effort, and provides a basis 1339 for the development of an architecture repository for the integration and re-use of models, 1340 designs, and baseline data. 1341 1342 5.2 The Enterprise-level Architecture. Enterprise-level architectures in DoD are generally 1343 created under the responsibility and authority of a senior-level official within the Department, 1344 Component, Organization, Agency, or the program office responsible for development of JCAs. 1345 As an enterprise-level effort, it is expected that all of the major processes are documented and 1346 described, even if a specific project involves only a more limited subset of processes or 1347 activities. That way, subsequent architecture efforts can build on previous efforts to ensure the 1348 integration and extension of the enterprise is not compromised. 1349 1350 Enterprise-level architectures usually exhibit breadth rather than depth. Since this architecture is 1351 the ‘capstone’, or highest level of an architecture, on which others will build, it is especially 1352 important that processes, which relate to each other, either through interaction of activities, or the 1353 use of data by internal and external stakeholders, are identified or documented. 40 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1354 1355 5.3 The Solution-Level Architecture. The solution-level architecture is scoped to include all 1356 major activities that are executed by a specified program in response to a specific requirement, 1357 and contain links to other programs, which require the data and/or outputs produced by the 1358 specified program. A solution-level architecture may represent activities within a specified 1359 functional area, cross-functional areas, or even extend to other organizations, agencies, Federal, 1360 state and local activities who may have an interest or participate in Departmental programs. 1361 1362 5.4 Architecture Management 1363 1364 Architectures are designed to describe the data on an organization or program/capability that will 1365 support continuing managing decision-making over time. Creation of architectures and their 1366 management follow an established life cycle that is similar to those other resources that have 1367 well-described life cycles. OMB Circular A-13017 describes the life cycle as: 1368 • Develop 1369 • Use 1370 • Maintain 1371 For consistency, that structure is followed in this volume as well. These phases recognize 1372 discreet actions that occur at various times, all designed to ensure that architecture data can be 1373 collected and later reused for management decision-making and reporting. 1374 1375 5.4.1 Architecture Development. Architectures are developed to represent either the state of 1376 an activity at a specified time (i.e., Baseline architecture) or the results of change in an activity 1377 that will occur over some future time (i.e., ‘to-be’ or future architecture). Enterprise 1378 architectures (Departmental, Capability/Segment, and Component) are initially created to create 1379 a common context needed to understand the organization and operations of high-level processes 1380 under their control. 1381 1382 Program-level architectures collect data that is specific to their program or capability, and data 1383 necessary to link to both the higher-level architecture with which they share common parentage, 1384 and any lower-level architectures, which describe in more detail particular aspects of the 1385 program or JCA. 1386 1387 Visualization of data provides a unique perspective of data from the viewpoint needed for 1388 decision-making. That may be a commander/director, action officer, system developer, data 1389 administrator, user, or anyone else executing some part of the architected process. More 1390 discussion of data collection and visualization is contained in DoDAF Volume 2. 1391 1392 1393 5.4.2 Architecture Utilization. The ultimate success of an architecture effort lies in the ability 1394 to use architecture-related data to support management decisions for change within the 17 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 41 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1395 organization. While architecture development is generally accomplished as an project, 1396 accomplished through a team trained for that purpose, the results of the architecture 1397 development, to be effective over the longer term, need to be adopted as the common, normal 1398 mode of performing the organization’s business. 1399 1400 The enterprise architecture, as a corporate asset, should be managed like any other asset, and 1401 reinforced by management as a key part of the formal program that results in decision-making. 1402 Achieving that level of acceptance occurs only when architectures are created that reflect reality 1403 (e.g. baseline), or planned change/growth (e.g. to-be, or target). 1404 1405 Successful execution of the EA development process in an agency-wide endeavor requires 1406 management direction and support, allocation of resources, continuity, and coordination. 1407 Creating an EA program calls for sustained leadership and strong commitment. This degree of 1408 sponsorship and commitment needs the buy-in of the agency head, leadership by the CIO, and 1409 early designation of a chief architect. These leaders and the supporting EA team are the first 1410 level of support for institutionalizing the results of the effort. 1411 1412 1413 5.4.3 Architecture Maintenance. Changes in an organization supported by architecture 1414 development will achieve institutionalization only when the senior leadership agrees with, 1415 supports, encourages, reinforces, and adopts the results of the architecture effort. Ideally, a 1416 member of the senior leadership team should be designated as the ‘champion’ of the change 1417 effort, and should work with the process owner to ensure that institutionalization occurs 1418 Employees, who actually perform the daily activities described in the architecture, must be 1419 represented in the architecture development team and contribute to the overall data collection 1420 and view creation. 1421 1422 5.4.4 Architecture Utilization. Architecture views must be easy-to-understand at all levels of 1423 the organization—and described in such a way that they become roadmaps for activity. When 1424 architecture data and views are constructed and organized in a way that they are understood, 1425 accepted, and utilized in daily activities, they facilitate management decision-making. 1426 1427 Architecture views, and data must meet standards that facilitate reuse by others whose activities 1428 border on, or replicate activities, services and systems already documented by architecture data 1429 and products. To that end, data collection must adhere to the standards set by the COI, or other 1430 recognized authority so that the data can be registered for, and used by others. 1431 1432 1433 5.4.5 Architecture Compliance Reviews. Architecture compliance reviews are a key part of 1434 the validation & verification (V&V) process ongoing throughout the architecture development 1435 effort. A compliance review is a type of review that analyzes whether architecture developers 1436 are progressing according to the specifications and requirements developed for the architecture 1437 effort by the process owner. The goals of an architecture compliance review include: 1438 42 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1439 • Identifying errors in the architecture early to reduce the cost and risk of changes required 1440 later in the project. These error-catching actions will reduce cost and schedule slips, and 1441 realize business objectives quicker. 1442 • Ensuring the application of best practices to architecture work. 1443 • Providing an overview of the compliance of architecture to mandated enterprise standards. 1444 • Identifying and communicating significant architectural gaps to product and service 1445 providers 1446 • Communicating to management the status of technical readiness of the project. 1447 1448 Utilization of architecture compliance reviews as an integral part of the development process 1449 ensures that utilization of architecture views and products later will be in conformance with 1450 applicable requirements. A more in-depth discussion of the compliance review process is 1451 contained in the DoDAF Journal, https://www.us.army.mil/suite/page/454707. 1452 1453 5.4.5.1 OMB Architecture Assessment. The Office of Management and Budget (OMB) 1454 requires departments and independent agencies to submit a self-assessment of their enterprise 1455 architecture programs in February of each year. For DoD, this applies at the Department level. 1456 The self-assessment is performed in three EA capability areas: completion of the EA, use of the 1457 EA and results, and utilization of the OMB Federal Enterprise Architecture program EA 1458 Assessment Framework.18 Specifics of the DoD/OMB architecture self-assessment are described 1459 in the DoDAF Journal, https://www.us.army.mil/suite/page/454707. 1460 1461 5.4.5.2 GAO Architecture Assessment. The Government Accountability Office (GAO) 1462 periodically requires all departments and independent agencies to submit a self-assessment of the 1463 maturity of the management of their EA programs. In addition, GAO may perform their own 1464 review and assessment of architecture efforts associated with large-scale programs. 19 In certain 1465 cases, GAO expects an agency to establish an independent quality assurance process for a large- 1466 scale architecture to determine whether it meets quality criteria such as those identified earlier in 1467 this section. 20 Specifics of the DoD/GAO architecture self-assessment are described in the 1468 DoDAF Journal, https://www.us.army.mil/suite/page/454707. 1469 18 Federal Enterprise Architecture Program: Enterprise Architecture Assessment Framework, version 2.2, October 2007. Executive Office of the President., Office of Management and Budget. The current version can be found at: http://www.whitehouse.gov/omb/egov/a-2-EAAssessment.html. 19 United States Government Accountability Office (GAO) Report: DoD Business Systems Modernization: Long-standing Weaknesses in Enterprise Architecture Development Need to Be Addressed, July 2005, GAO-05-702. A copy of the report is available at: http://www.gao.gov/new.items/d05702.pdf 20 United States Government Accountability Office (GAO) Report: Framework for Assessing and Improving Enterprise Architecture Management, version 1.1, April 2003, GAO-03-584G. A copy of the report is available at: www.gao.gov/new.items/d03584g.pdf 43 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1470 5.4.6 User Support. User support is the service that each enterprise unit provides its users, 1471 both internally and externally to the enterprise, as described in the architecture documents. 1472 1473 5.4.7 Training. It is the responsibility of agency executive management to institutionalize the 1474 control structures for the EA process as well as for the agency CPIC and Shelf Life Code (SLC) 1475 processes. For each decision-making body, all members should be trained, as appropriate, in the 1476 EA, the EA process, the relationship of the EA to the Agency’s mission, DoDAF, and the FEA. 1477 Specific training, at various levels of detail, should be tailored to the architecture role of the 1478 personnel. 1479 1480 Architecture development training for team members is provided by the team leader and Chief 1481 Architect during the course of team operations. Training for team members includes sessions on 1482 group interactions, toolset operations, data collection, and creation of models and views. 1483 1484 5.4.8 Communications Planning. Communication management is the formal and informal 1485 process of conducting or supervising the exchange of information to all stakeholders of 1486 enterprise architecture. Communication planning is the process of ensuring that the 1487 dissemination, management, and control of critical stakeholder information is planned and 1488 executed in an efficient and effective manner. 1489 1490 The purpose of communications planning is (1) to keep senior executives and business units 1491 continually informed, and (2) to disseminate EA information to management teams. The CIO’s 1492 staff, in cooperation with the Chief Architect and support staff, defines a marketing and 1493 communications plan consisting of: 1494 • constituencies 1495 • level of detail 1496 • means of communication 1497 • participant feedback 1498 • schedule for marketing efforts 1499 • method of evaluating progress and buy-in. 1500 1501 The CIO’s role is to interpret the Agency Head’s vision, and recognize innovative ideas (e.g., the 1502 creation of a digital government) that can become key drivers in the EA strategy and plan. In 1503 turn, the Chief Architect is the primary technical communicator with the community(ies) of 1504 interest involved in an architecture effort. 1505 1506 At the Process Owner level, the communications plan is similar to that described above for the 1507 CIO. As with the CIO at the enterprise, the process owner is the manager of architecture efforts, 1508 supported by an architect and development team. The process owner must clearly define the 1509 purpose and scope of an architecture effort (i.e. ‘Fit-for-Purpose’) and communicate those goals 1510 and objectives for the architecture effort to the architect and team. In turn, as development of the 1511 architecture progresses, the architect provides feedback to the process owner, participates in 1512 validation and verification activities, and provides revisions, as required to the original 1513 development plan. 1514 44 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1515 5.4.9 Quality Planning. Quality management is the process of organizing activities involving 1516 the determination of quality requirements, establishing quality policies, objectives, performance 1517 metrics, and responsibilities, and ensuring that these policies, objectives, and metrics will satisfy 1518 the needs within the enterprise. The quality management system executes policies, procedures, 1519 and quality planning processes, along with quality assurance, quality control processes, and 1520 continuous process improvement activities to improve the overall health and capability of the 1521 enterprise. The primary input into the quality management process is quality planning. 1522 1523 Quality planning for architecture development identifies which quality standards are relevant to 1524 creation of the architecture and determines how to satisfy them. Quality requirements are stated 1525 in the Project Scope Statement, further defined in the Program Management Plan and other 1526 guidance, such as that provided by the methodology being applied to the development effort. 1527 Guidance also includes other enterprise environmental factors, such as Governmental agency 1528 regulations, rules, standards, and guidelines specific to the application area. Information needed 1529 during quality planning is generally collected during architecture development, and represented 1530 in architecture products and views as controls, resources, inputs, and outputs, as appropriate. A 1531 more comprehensive discussion of quality planning is provided online in the DoDAF Journal, 1532 https://www.us.army.mil/suite/page/454707. 1533 1534 5.4.10 Risk Management. Risk management is the act or practice of dealing with risk. It 1535 includes planning for risk, assessing risk issues, developing risk handling strategies, and 1536 monitoring risk to determine how they have changed. Risk management planning is the process 1537 of deciding how to approach and conduct the risk management activities for the enterprise, 1538 program, and projects. 1539 1540 Architectural risk assessment is a risk management process that identifies flaws in architecture 1541 and determines risks to business information assets that result from those flaws. Through the 1542 process of architectural risk assessment, risks are identified and prioritized based on their impact 1543 to the business; mitigations for those risks are developed and implemented; and the architecture 1544 is reassessed to determine the efficacy of the mitigations. 1545 1546 Risk management planning should be initiated early during development of the scope for the 1547 architecture effort. Mitigation of risk is crucial to success of the overall effort. Inputs to the risk 1548 management planning process include a review of existing enterprise environmental factors, 1549 organizational process assets, the proposed scope statement, and the program management plan. 1550 Enterprise environmental factors are the attitudes toward risk and the risk tolerance of the 1551 organizations and people involved in the organization that exert influence over change. Risk 1552 attitudes and tolerances may be expressed in policy statements or revealed in actions. 1553 Organizational process assets are tools and techniques, which normally predefine organizational 1554 approaches to risk management such as established risk categories, common definitions of 1555 concepts and terms, standard templates, roles and responsibilities, and authority levels for 1556 decision-making. 1557 1558 A comprehensive discussion of Risk management can be found online in Section __ of the 1559 DoDAF Journal, https://www.us.army.mil/suite/page/454707. 45 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1560 1561 1562 6. CUSTOMER REQUIREMENTS 1563 1564 In a large organization such as DoD, there are myriad decisions made each day. These decisions 1565 require facts (i.e. valid information) for successful execution. Two things affect the ability to 1566 make decisions. First, needed information must be available; second, a decision support process 1567 must exist to frame how the decision, once made, can be executed. Decision support can be as 1568 simple as an established procedure or rule for execution, or a more complex, integrated set of 1569 actions to assure that a decision is executed properly. 1570 1571 Within DoD are a number of very complex, overarching, decision support services that provide a 1572 framework for execution on DoD’s most critical program activities. These key DoD change 1573 management decision support processes include JCIDS, DAS, systems engineering, PPBE, and 1574 PfM. The following paragraphs discuss how these key decision support processes impact 1575 management decision making in DoD using architecture data. 1576 1577 6.1 Tailoring Architecture to Customers’ Needs 1578 1579 Architectures collect information about an organization that is relevant to a requirement. This 1580 information frequently includes processes, supporting systems, needed or desired services, 1581 interfaces, business rules, and other details that can be organized to facilitate a decision. From 1582 this perspective, Architecture applies a method for tailoring information collection to a specific 1583 local need with a clear understanding of the decisions the architecture must support, how those 1584 decisions should be made, and what information they require. Responding to the organization’s 1585 requirements generally requires the following information in order to apply the methodology 1586 described in Section 7, or another selected by the architect: 1587 • Detail on specific implementations of the basic processes, including explicit identification of 1588 critical decisions mandated or implied. 1589 • Identification of performance measures that can be used to judge the effectiveness of each 1590 process (including any mandated by the authoritative documents), taking special note of 1591 those that sample the effectiveness of architecture support (the DoDAF Journal, 1592 https://www.us.army.mil/suite/page/454707, includes a tutorial on a relatively painless 1593 method for performance engineering). 1594 • For each critical decision, identification of at least one method (and optionally several 1595 alternatives) for making that decision, identifying analyses to perform and questions to 1596 answer. 1597 • For each analysis or question, identification of needed information. 1598 • Creation of additional business objects/elements and attributes as needed to capture 1599 information in the architecture repository. 1600 • Process and information definitions for utilization in architecture development. 46 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1601 The architect simplifies the architecture design by eliminating unneeded objects and attributes 1602 through a ‘best sense of opportunity’ approach, whereby interaction with the customer provides 1603 normal and expected needs that generally satisfies the majority of information needs for 1604 architecture development. Architecture views should be created to reflect, as closely as possible, 1605 the normal ‘culture’, and preferred presentation design of the agency. 1606 1607 6.2 Key Decision Support Processes 1608 1609 Organizations within the DoD may define local change management processes, supportable by 1610 architecture, while adhering to defined decision support processes mandated by the Department, 1611 including JCIDS, the DAS, systems engineering, PPBE, and PfM. These key support processes 1612 are designed to provide uniform, mandated, processes in critical decision-making areas, 1613 supplemented by individual agency operations, defined by architectures tailored to support those 1614 decisions-making requirements. 1615 1616 6.2.1 Joint Capability Integration and Development System. The primary objective of the 1617 JCIDS process is to ensure warfighters receive the capabilities required to execute their assigned 1618 missions successfully. JCIDS defines a collaborative process that utilizes joint concepts and 1619 integrated architectures to identify prioritized capability gaps and integrated joint DOTMLPF 1620 (i.e. Doctrine, Organization, Training, Materiel, Leadership, Personnel, Facilities) and policy 1621 approaches (materiel and non-materiel) to resolve those gaps21. JCIDS implements an integrated, 1622 collaborative process to guide development of new capabilities through changes in joint 1623 DOTMLPF and policy. 1624 1625 The JCIDS process owners recognized the need for architecture and wrote policy to support 1626 architecture requirements (i.e., specific product sets required in specific documents, such as the 1627 Information Support Plan, Capability Planning Document, and Capability Design Document) 1628 that permits components and lower echelon commands to invoke the JCIDS process for 1629 requirements at all levels. JCIDS description of the Functional Solution Assessment (FSA) step 1630 specifically includes both DOTMLPF analysis and business process improvement and re- 1631 engineering. A more comprehensive discussion of JCIDS is contained in the DoDAF Journal, 1632 https://www.us.army.mil/suite/page/454707. 1633 1634 6.2.2 Defense Acquisition System. The Defense Acquisition System (DAS) exists to manage 1635 the nation’s investments in technologies, programs, and product support necessary to achieve the 1636 National Security Strategy and support employment and maintenance of the United States Armed 1637 Forces.22 The DAS uses Joint Concepts, integrated architectures, and DOTMLPF analysis in an 21 Chairman of the Joint Chiefs of Staff (CJCS) Instruction 3170.01E, Joint Capabilities Integration and Development System (JCIDS), 11 May 2005. A copy of the current version of the instruction and its accompanying Manual can be found at: https://acc.dau.mil/CommunityBrowser.aspx?id=42776 22 Department of Defense Directive (DoDD) 5000.1, The Defense Acquisition System, 12 May 2003 (certified current as of November 20, 2007). A current copy of the directive can be found at: https://akss.dau.mil/dag/DoD5000.asp?view=document&doc=2) 47 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1638 integrated, collaborative processes to ensure that desired capabilities are supported by affordable 1639 systems and other resources.23 1640 1641 DoD Directive 5000.1 provides the policies and principles that govern the defense acquisition 1642 system. In turn, DOD Instruction 5000.2, Operation of the Defense Acquisition System 1643 establishes the management framework for translating mission needs and technology 1644 opportunities, based on approved mission needs and requirements, into stable, affordable, and 1645 well-managed acquisition programs that include weapon systems and automated information 1646 systems (AISs).24 The Defense Acquisition Management Framework25 provides an event-based 1647 process where acquisition programs advance through a series of milestones associated with 1648 significant program phases. 1649 1650 The USD (AT&L) leads the development of integrated plans or roadmaps using integrated 1651 architectures as its base. DoD organizations use these roadmaps to conduct capability 1652 assessments, guide systems development, and define the associated investment plans as the basis 1653 for aligning resources and as an input to the Defense Planning Guidance (DPG), Program 1654 Objective Memorandum (POM) development, and Program and Budget Reviews.26 1655 1656 6.2.3 Systems Engineering (SE). DoD Acquisition policy directs all programs responding to 1657 a capabilities or requirements document, regardless of acquisition category, to apply a robust SE 1658 approach that balances total system performance and total cost with the family-of-systems, and 1659 system-of-systems context. Programs develop a Systems Engineering Plan (SEP) for Milestone 1660 Decision Authority (MDA) that describes the program’s overall technical approach, including 1661 activities, resources, metrics, and applicable performance incentives. 1662 Systems engineering processes are applied to allow an orderly progression from one level of 1663 development to the next detailed level using controlled baselines. These processes are used for 1664 the system, subsystems, and system components as well as for the supporting or enabling 1665 systems used for the production, operation, training, support, and disposal of that system. 1666 Execution of technical management processes and activities, such as trade studies or risk 1667 management activities may point to specific requirements, interfaces, or design solutions as non- 23 Department of Defense Instruction (DoDI) 5000.2., Operation of the Defense Acquisition System.(2003) Under-Secretary of Defense (Acquisition, technology & Logistics) (OUSD AT&L). A current copy of this document can be found at: https://akss.dau.mil/dag/DoD5000.asp?view=document&doc=2 24 Department of Defense Instruction (DoDI) 5000.2., Operation of the Defense Acquisition System.(2003) Under-Secretary of Defense (Acquisition, technology & Logistics) (OUSD AT&L). A current copy of this document can be found at: https://akss.dau.mil/dag/DoD5000.asp?view=document&doc=2 25 Integrated Defense Acquisition, Technology, & Logistics Life Cycle Management Framework (2005). Defense Acquisition University, Ft. Belvoir, VA. A current copy of the chart is found at: http://www.dau.mil/pubs/IDA/IDA_04.aspx 26 Department of Defense Instruction (DoDI) 5000.2., Operation of the Defense Acquisition System.(2003) Under-Secretary of Defense (Acquisition, technology & Logistics) (OUSD AT&L). A current copy of this document can be found at: https://akss.dau.mil/dag/DoD5000.asp?view=document&doc=2 48 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1668 optimal and suggest change to increase system-wide performance, achieve cost savings, or meet 1669 scheduling deadlines27. 1670 Architecture supports systems engineering by providing a structured approach to document 1671 design and development decisions based on established requirements. 1672 1673 6.2.4 Planning, Programming, Budgeting, and Execution (PPBE). The PPBE process 1674 allocates resources within the DoD and establishes a framework and process for decision-making 1675 on future programs. PPBE is a systematic process that guides DoD’s strategy development, 1676 identification of needs for military capabilities, program planning, resource estimation, and 1677 allocation, acquisition, and other decision processes. JCIDS is a key supporting process for 1678 PPBE, providing prioritization and affordability advice. 1679 1680 DoDAF 2.0 supports the PPBE process by identifying the touch points between architecture and 1681 the PPBE process, identifying the data to be captured within an architecture description, 1682 facilitating informed decision-making, and identifying ways of presenting data to various 1683 stakeholders/roles in the PPBE decision process. 1684 1685 6.2.5 Portfolio Management. DoD policy requires that IT investments be managed as 1686 portfolios to ensure IT investments support the Department’s vision, mission, and goals; ensure 1687 efficient and effective delivery of capabilities to the warfighter; and maximize return on 1688 investment within the enterprise. Each portfolio must be managed using the architecture plans, 1689 risk management techniques, capability goals and objectives, and performance measures. 1690 Capability architecting is done primarily to support the definition of capability requirements. 1691 Portfolio management uses the architecture to analyze decisions on fielding or analysis of a 1692 needed capability.28 1693 1694 Architecture support to PfM tends to focus on the investment decision itself (although not 1695 exclusively), and assists in justifying investments, evaluating the risk, and providing a capability 1696 gap analysis. 1697 1698 6.2.6 Operations. In most cases, an enterprise will capture its routine or repeatable business 1699 and mission operations as architecture content. However, when the basic structure of an activity 1700 is very stable and the activity repeated often, such as military operations planning or project 1701 definition and management, the enterprise may choose to include that structure as part of the 1702 structure of the architecture itself. In this case, the architecture repository may be enhanced to 1703 include templates, checklists, and other artifacts commonly used to support the activity. 1704 27 DoD Acquisition Guidebook. Office of the Under-Secretary for Acquisition, Technology & Logistics (AT&L). A current copy of the Guidebook can be found at: https://akss.dau.mil/dag/DoD5000.asp?view=document&doc=2 28 Department of Defense Directive (DoDD) 8115.01, Information Technology Portfolio Management, October 10, 2005. Office of the Assistant Secretary of Defense (Networks & Information Integration)(NII)/DoD Chief Information Officer (DoD CIO). The latest copy of this directive can be found at: http://www.dtic.mil/whs/directives/corres/rtf/811501x.rtf 49 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1705 The JCIDS, PPBE, and DAS processes establish a knowledge-based approach, which requires 1706 program managers to attain the right knowledge at critical junctures to make informed program 1707 decisions throughout the acquisition process. The DoD IT PfM process continues to evolve that 1708 approach with emphasis on individual systems and/or services designed to improve overall 1709 mission capability. Consistent with OMB Capital Planning and Investment Control (CPIC) 1710 guidance, the DoD uses four continuous integrated activities to manage its portfolios -- analysis, 1711 selection, control, and evaluation. The overall process is iterative, with results being fed back 1712 into the system to guide future decisions.29 1713 1714 6.3 Information Sharing. Information sharing across the Department has existed for many 1715 years in various forms. The sharing of information took on new urgency following the events of 1716 September 2001, especially in the area of terrorist-related information. Since that time, new 1717 Federal legislation30 and presidential orders require that agencies develop a common framework 1718 for the sharing of information, and define common standards for how information is acquired, 1719 accessed, shared, and used within a newly created Information Sharing Environment (ISE). 1720 While initial efforts relate to terrorism-related data, the standards being set could apply, in the 1721 future, more broadly across the Department. 1722 1723 Importantly, an Information Sharing Environment Enterprise Architecture Framework (ISE- 1724 EAF) is under development31, which will provide guidance for information collection and 1725 dissemination within the Information Sharing Environment (ISE). This Framework is consistent 1726 with the DoDAF, and is essential data structures will be mappable to the DoDAF Meta-model 1727 described in DoDAF Volume 2 and Volume 3. When published, that ISE document should be 1728 used in coordination with DoDAF to ensure that these specific types of data meet established 1729 Federal standards. 1730 29 DoDD 8115.01, 10 30 Intelligence Reform and Terrorism Prevention Act of 2004 (IRTPA), PL 108-458 (December 17, 2004) 31 Information Sharing Environment Enterprise Architecture Framework (DRAFT) June, 2008. Office of the Program Manager, Information Sharing Environment 50 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1731 7. METHODOLOGIES. 1732 1733 This section introduces a methodology-based approach to architecture development in DoD, 1734 draws on the methodology originally introduced in DoDAF 1.5, and expands on that 1735 methodology to highlight its use in a data-driven, net-centric architecture development 1736 environment. The methodology contained in this section is notional, represents best practices 1737 that have evolved over time, and can be utilized in conjunction with, or as a replacement for 1738 other methodologies, as described below. 1739 1740 7.1 Methodology Based Approach to Architecture 1741 The Webster’s II New College Dictionary 2001 defines methodology as 1) the system of 1742 principles, procedures, and practices applied to a particular branch of knowledge, and, 2) the 1743 branch of logic dealing with the general principles of the formation of knowledge. Generally 1744 speaking, knowledge is gained through the acquisition of, and effective use of information 1745 organized from data for a particular purpose. 1746 An architecture development methodology specifies how to derive relevant information about an 1747 enterprise’s processes and business or operational requirements, and how to organize and model 1748 that information. Architecture methods describe consistent and efficient ways to collect data, 1749 organize the data in a particular grouping or structure, and store collected data for later 1750 presentation and use in decision-making processes. A methodology also provides a means for 1751 replicating the steps taken to create an architecture for a specific purpose later, by another person 1752 or team with the expectation of achieving similar results. 1753 In turn, through utilization of a method, it is possible to compare architectures created under the 1754 same, or similar methods, evaluate how disparate architectures can be linked to provide a higher- 1755 level picture of a process or capability, and to analyze the impact of future change. These 1756 analyses can include: 1757 • Static Analyses – which could include capability audit, interoperability analysis, or 1758 functional analysis. These analyses are often performed using simple analysis tools such as 1759 “paper-based” comparisons and database queries. 1760 • Dynamic Analyses – sometimes referred to as executable models, these analyses typically 1761 examine the temporal, spatial, or other performance aspects of a system through dynamic 1762 simulations. For example, these analyses might be used to assess the latency of time 1763 sensitive targeting systems or conduct traffic analyses on deployed tactical networks under a 1764 variety of loading scenarios. 1765 • Experimentation – the use of tactical capability requirements, such as the Coalition Warrior 1766 Interoperability Demonstration (CWID), sponsored annually by the JCS, and various battle 1767 labs to provide the ability to conduct human-in-the-loop simulations of operational activities. 1768 Differing degrees of live versus simulated systems can be deployed during these experiments 1769 and there is a high degree of control over the experiment variables. These can be used for a 1770 variety of purposes. 1771 The six-step method described below is a generic, time-tested method, which can be utilized, in a 1772 wide range of architecture requirements through relatively simple adaptation. The examples 51 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1773 described within the steps provide information on customization of the generic method for use in 1774 major departmental functions and operations. 1775 NOTE: The methodology described in this section is applicable to development of service- 1776 oriented architecture(SOA). The steps described in the methodology, together with the 1777 requirements of the toolset, techniques and notation desired, should be considered together 1778 when defining a SOA. Volume 2 provides specific views that are useful for services-specific 1779 data collection, and presentation models and documents that describe services. 1780 If another method is desired, then utilization of the information contained in this Volume, 1781 Volume 2, the technical specifications of DoDAF, and Volume 3, the DoDAF Meta-model, 1782 provide the information needed for use in developing an architecture. When utilizing another 1783 method, reference to the notional methodology can ensure adherence to the principles described 1784 in DoDAF 2.0, to maximize the potential for reuse of essential data, and also to ensure 1785 conformance with DoDAF 2.0. 1786 7.1.1 6-Step Architecture Development Process. The high-level, six-step architecture 1787 development process provides guidance to the architect and architecture development team and 1788 emphasizes the guiding principles described in section 3.5.1. The process is data-centric rather 1789 than product-centric (e.g. it emphasizes focus on data, and relationships among and between 1790 data, rather than DoDAF products and views). This data-centric approach ensures concordance 1791 between views in the architecture while ensuring that all essential data relationships are captured 1792 to support a wide variety of analysis tasks. The views created as a result of the architecture 1793 development process provide visual renderings of the underlying architecture data and convey 1794 information of interest from the architecture needed by specific user communities or decision 1795 makers. Figure 7.1.1-1 depicts this six-step process. 1796 1797 NOTE: It is important to note in this section that the development of architecture is an iterative 1798 process and a unique one, in that every architecture is: 1799 • Different in that architecture creation serves a specific purpose, and is created from a 1800 particular viewpoint 1801 • Serving differing requirements, necessitating different types of views to represent the 1802 collected data 1803 • Representative of a ‘snapshot in time’ (e.g., the architecture may represent the current 1804 view or baseline, or it may represent a desired view in some future time) 1805 • Changeable over time as requirements become more focused or additional knowledge 1806 about a process or requirement becomes known. 1807 1808 The methodology described below is designed to cover the broadest possible set of 1809 circumstances, and also to focus on the most commonly used steps by the architecture 1810 community. 1811 52 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1812 1813 Figure 7.1.1-1: Architecture Development Six-Step Process 1814 1815 1816 7.1.1.1 Step 1: Determine Intended Use of Architecture. Defines the purpose and intended 1817 use of the architecture (“Fit for Purpose”); how the architecture effort will be conducted; the 1818 methods to be used in architecture development; the data categories needed; the potential impact 1819 on others; and the process by which success of the effort will be measured in terms of 1820 performance and customer satisfaction. This information is generally provided by the process 1821 owner to support architecture development describing some aspect of their area of responsibility 1822 (process, activity, etc.). 1823 1824 A template for collection of high-level information relating to the purpose and scope of the 1825 architecture, its glossary, and other information, has been developed for registration of that data 1826 in DARS. An electronic copy is found on the public page of DARS, and additional information 1827 is contained in the DoDAF Journal, https://www.us.army.mil/suite/page/454707. 1828 7.1.1.2 Step 2: Determine Scope of Architecture. The scope defines the boundaries that 1829 establish the depth and breadth of the architecture and establish the architecture’s problem set, 1830 helps define its context and defines the level of detailed required for the architecture content. 1831 While many architecture development efforts are similar in their approach, each effort is also 1832 unique in that the desired results or effect may be quite different. As an example, system 53 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1833 development efforts generally focus first on process change, and then concentrate on those 1834 automated functions supporting work processes or activities. In addition to understanding the 1835 process, discovery of these ‘system functions’ is important to decide how to proceed with 1836 development or purchase of automation support. 1837 Architecture development to describe services utilization within a process collect information 1838 similar in type to systems, with additional data collection of information concerning 1839 subscriptions, directory services, distribution channels within the organization, and supporting 1840 systems/communications web requirements. 1841 1842 Similar situations occur with architecture development for joint operations. Joint capabilities are 1843 defined processes with expected results, and expected execution capability dates. The 1844 architectures supporting the development of these types of capabilities usually require the reuse 1845 of data already established by the military services and agencies, analyzed, and configured into a 1846 new or updated process that provides the desired capability. Included are the processes needed 1847 for military service and/or agency response, needed automation support, and a clear definition of 1848 both desired result and supporting performance metrics. These types of data are presented in 1849 views further described in Volume 2. 1850 The important concept for this step is the clarity of scope of effort defined for the project that 1851 enables an expected result. Broad scoping or unclear definition of the problem can delay or 1852 prevent success. The process owner has the primary responsibility for ensuring that the scoping 1853 is correct, and that the project can be successfully completed. 1854 Clarity of scope can better be determined by defining and describing the data to be used in the 1855 proposed architecture in advance of the creation of views that present desired data in a format 1856 useful to managers. Early identification of needed data, particularly data about the architecture 1857 itself, the subject-matter of the proposed architecture, and a review of existing data from COIs, 1858 can provide a rich source for ensuring that architectures, when developed, are consistent with 1859 other existing architectures. It also ensures conformance with any data-sharing requirements 1860 within the Department or individual COIs, and conformant with the DoDAF Meta-model 1861 described in Section 9. 1862 1863 An important consideration beginning with this and each subsequent step of the architecture 1864 development process is the continual collection and recording of a consistent, harmonized, and 1865 common vocabulary. The collection of terms should continue throughout the architecture 1866 development process. As architecture data is identified to help clarify the appropriate scope of 1867 the architecture effort, vocabulary terms and definitions should be disambiguated, harmonized, 1868 and recorded in a consistent AV-2 process documented in the “DoDAF Architecture 1869 Development Process for the Models” Microsoft Project Plan. 1870 Analysis of vocabularies across different architectures with similar scope may help to clarify and 1871 determine appropriate architecture scope. Specific examples of data identification utilizing the 1872 AV-2 Data Dictionary construct are found in the DoDAF Journal, 1873 https://www.us.army.mil/suite/page/454707. 1874 1875 7.1.1.3 Step 3: Determine Data Required to Support Architecture Development. The 54 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1876 required level of detail to be captured for each of the data entities and attributes is determined 1877 through the analysis of the process undergoing review conducted during the scoping in Step 2. 1878 This includes the data identified as needed for execution of the process, and other data required 1879 to effect change in the current process, e.g. administrative data required by the organization to 1880 document the architecture effort. These considerations establish the type of data collected in 1881 Step 4, which relate to the architecture structure, and the depth of detail required. 1882 1883 The initial type of architecture data content to be collected is determined by the established scope 1884 of the architecture, and recorded as attributes, associations, and concepts as described in the 1885 DoDAF meta model (DM2). A mapping from DM2 concepts, associations, and attributes to 1886 architecture models is provided that suggests relevant architecture views the architect may 1887 develop (using associated architecture techniques) during the more comprehensive and coherent 1888 data collection of Step 4. This step is normally completed in conjunction with Step 4, a bottom- 1889 up approach to organized data collection, and architecture development typically iterates over 1890 these two steps. As initial data content is scoped, additional data scope may be suggested by the 1891 more comprehensive content of architecture views desired for presentation or decision-making 1892 purposes. 1893 This step can often be simplified through reuse of data previously collected by others, but 1894 relevant to the current effort. Access to appropriate COI data and other architecture information, 1895 discoverable via DARS and the DoD Metadata Registry, can provide information on data and 1896 other architecture artifacts and views that may provide useful in a current effort. 1897 1898 Work is presently underway within the Department to ensure uniform representation for the 1899 same semantic content within architecture modeling, called "Architecture Modeling Primitives”. 1900 The Architecture Modeling Primitives, hereafter referred to as Primitives, will be a standard set 1901 of modeling elements, and associated symbols mapped to DM2 concepts and applied to 1902 modeling techniques. Using the Primitives to support the collection of architecture content and, 1903 in concert with the Physical Exchange Specification, will aid in generating common 1904 understanding and communication among architects in regard to architecture views. As the 1905 Primitives concepts are applied to more modeling techniques, they will be updated in the 1906 DoDAF Journal and details provided in subsequent releases of DoDAF. The full range of 1907 Primitives for views, as with the current BPMN Primitives, will be coordinated for adoption by 1908 architecture tool vendors. 1909 1910 NOTE: As of the distribution of this Volume for the Community-Wide Review, comments 1911 provided by the Core Management Stakeholders have not been resolved concerning the 1912 “Architecture Modeling Primitives.” It is intended to resolve the comments with the 1913 Stakeholders during the Community Review Period. 1914 1915 7.1.1.4 Step 4: Collect, Organize, Correlate, and Store Architecture Data. 1916 Architects typically collect and organize data through the use of architecture techniques designed 1917 to use views (e.g. activity, process, organization, and data models as views) for presentation and 1918 decision-making purposes. . Terms and definitions recorded are related to elements of the 1919 DoDAF Meta-model (DM2). 55 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1920 1921 Designation of a data structure for the architecture effort involves creation of a taxonomy to 1922 organize the collected data. This effort can be made considerably simpler by leveraging existing, 1923 registered artifacts registered in DARS of the DM2, to include data taxonomies and data sets. 1924 Each COI maintains its registered data on DARS, either directly or though a federated approach. 1925 In addition, some organizations, such as US Joint Forces Command (JFCOM), have developed 1926 templates, which provide the basis of a customizable solution to common problems, or 1927 requirements, which includes datasets already described and registered in the DoD Metadata 1928 Registry. Examples of this template-based approach are in the DoDAF Journal. 1929 1930 DARS provides more information that is specific, and guidance on retrieving needed data 1931 through a discovery process. Once registered data is discovered, the data can be cataloged and 1932 organized within a focused taxonomy, facilitating a means to determine what new data is 1933 required. New data is defined, registered in DARS, and incorporated into the taxonomy structure 1934 to create a complete defined list of required data. The data is arranged for upload to an 1935 automated repository, such as DARS, to permit subsequent analysis and reuse. Discovery 1936 metadata (i.e., the metadata that identifies a specific architecture, its data, products, and usage) 1937 should be registered in DARS as soon as it is available to support discovery and enable 1938 federation. Architects and data managers should use the DoD EA Business Reference Model 10 1939 (DoD EA BRM) taxonomy elements as the starting point for their registration efforts. 1940 Additional discovery metadata, such as processes and services may be required later, and should 1941 follow the same registration process. 1942 1943 7.1.1.5 Step 5: Conduct analyses in support of architecture objectives. Architecture data 1944 analysis determines the level of adherence to process owner requirements. This step may also 1945 identify additional process steps and data collection requirements needed to complete the 1946 architecture and better facilitate its intended use. Validation applies the guiding principles, 1947 goals, and objectives to the process requirement, as defined by the process owner, along with the 1948 published performance metrics, to determine the achieved level of success in the architecture 1949 effort. Completion of this step prepares the architecture for approval by the process owner. 1950 Changes required from the validation process result in iteration of the architecture process 1951 (repeat steps 3 through 5 as necessary). 1952 1953 7.1.1.6 Step 6: Document Results in Accordance with Architecture Framework. The final 1954 step in the architecture development process involves creation of architecture views based on 1955 queries of the underlying data. Presenting the architecture data to varied audiences requires 1956 transforming the architecture data into meaningful presentations for decision-makers. This is 1957 facilitated by the data requirements determined in Step 3, and the data collection methods 1958 employed during Step 4. 1959 1960 DoDAF 2.0 provides two types of views. ‘DoDAF-described Views’ are those views described 1961 in Volume 2 that enable an architect and development team to create views whose data has 1962 already been defined and described consistent with the DoDAF meta-model. These views 1963 include those previously described in earlier versions of DoDAF, along with new views 56 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 1964 incorporated from the Ministry of Defense (UK) Architecture Framework ( MODAF), the 1965 NATO Architecture Framework (NAF), and The Open Group Architecture Framework 1966 (TOGAF) that have relevance to DoD architecture development efforts. 1967 1968 The second type of views, ‘Fit-for-purpose Views’, are user-defined views that an architect and 1969 development team can create to provide information necessary for decision-making in a format 1970 customarily used in an agency. These views should be developed consistent with the DoDAF 1971 meta-model, but can be in formats (e.g. dashboards, charts, graphical representations, etc) that 1972 are normally used in an agency for briefing and decision purposes. An architecture development 1973 effort can result in an architecture that is a combination of DoDAF-described views and Fit-for- 1974 purpose Views. 1975 1976 DoDAF does not require specific views, but suggests that local organizational presentation types 1977 that can utilize DoDAF-created data are preferred for management presentation. A number of 1978 available architecture tools support the creation of views described in this step. The PES 1979 provides the format for data sharing. 1980 NOTE: While DODAF does not require specific views in an architecture, several JCS and DOD publications do require specific views in response to their stated requirements. Managers and architects, in deciding what views are created in an architecture development effort, must consider those specific requirements in order to ensure that the architecture developed is useful in satisfying those requirements. 1981 1982 1983 7.1.2 Accommodating Multiple Methods for Implementation. DoDAF v2.0 is designed to 1984 be flexible in development of architectures supporting all tiers, capabilities, component-level 1985 views, and specific functional or operational requirements. The method described within the 1986 Framework is generic, and can be used in conjunction with other frameworks, tools, or 1987 techniques to achieve the desired result. Specifically, the conceptual model supporting DoDAF 1988 v2.0 can be used to develop both relational and object-oriented (OO) databases in a wide variety 1989 of formats; supports both the structured analysis and Object-oriented analysis and design 1990 modeling techniques and their specific notations; and continues to support previous versions of 1991 this framework. 1992 1993 Many architectures are created utilizing data from architectures developed previously under 1994 another framework (i.e., MODAF, NAF, TOGAF). It is also possible, through data mapping, to 1995 link that data to the DoDAF v2.0 conceptual and logical data models, since the data models 1996 supporting these frameworks are based on either the predecessor C4ISR Framework or DoDAF, 1997 v1.0. 1998 1999 7.1.3 Architecture Life Cycle & Architecture Governance. Architecture development is only 2000 one phase of an overall architecture life cycle, similar to other process maturity and change life 2001 cycles. One such life cycle, the Architecture Governance, Implementation, and Maturity Cycle, 57 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2002 shown in Figure 7.1-1 below, is described in detail in the DoDAF Journal, 2003 https://www.us.army.mil/suite/page/454707. This life cycle relies on the commonly used Plan- 2004 Do-Check-Act (PDCA) governance method. 2005 2006 2007 2008 2009 Figure 7.1-1: PDCA Cycle 2010 2011 2012 2013 7.1.4 Planning for Architecture Development. Planning an architecture effort involves more 2014 than selection of a method for development. The architecture effort starts with the identification 2015 of a requirement, problem, or desired change by the process owner – the senior official 2016 responsible for the overall operation of the functional, tactical, component or JCA. The process 2017 owner selects a team leader and team members who will actively participate in the architecture 2018 effort. That team may have a varying membership, generally including an enterprise architect, 2019 and subject matter experts in the process area undergoing analysis and potential change, and will 2020 refine the process owner’s vision and/or initial requirement into a project through development 2021 of an appropriate architecture, as shown in the steps in sections 6.1.1, and in Section 10, 2022 Architecture Planning. 2023 2024 Managers and decision-makers are generally not technicians or information architects. They do, 2025 however, have a vital part in the decisions that need to be made early in the planning process to 2026 define the types of views they need to support their involvement in the decision-making process. 2027 Organizations differ in the type of presentation materials they prefer (i.e. dashboards, charts, 2028 tables, etc.) and these preferences need to be accommodated during architecture development. 2029 Toolsets should be selected that have the capability to provide these management views and 2030 products, along with the ability to collect and organize data consistent with the DoDAF meta- 58 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2031 models to facilitate reuse. A detailed discussion of toolset requirements and capabilities is 2032 contained in the DoDAF Journal, https://www.us.army.mil/suite/page/454707. 2033 2034 7.1.5 Approaches to Architecture Development. Several methodologies, with supporting 2035 tools, techniques, and notations (i.e., a set of written symbols used to represent something such 2036 as activity, decisions, systems, applications, interfaces, etc.) exist for developing architectures. 2037 While DoDAF does not promote a specific approach, the DoDAF provides the rules, standard 2038 entities, and relationships for developing architectures in a semantically consistent and 2039 interoperable fashion. The DoDAF conceptual and logical data models, described in Volumes 1 2040 and 2, along with the Physical Exchange Specification in Volume 3, have been designed to 2041 facilitate adoption of DoDAF by a wide range of toolsets and techniques. The DoDAF Meta- 2042 model should be used as the principal reference for creating the data structures in toolsets to 2043 ensure both interoperability and reuse capabilities. An achievable level of commonality among 2044 the notations is possible when basing architecture development on the DoDAF 2.0 conceptual 2045 and logical data models. 2046 NOTE: Several commercial toolsets that are commonly used to develop architecture views still use the terms ‘model’ of ‘diagram’ to describe those views. Within this chapter, we continue to use the terms ‘model’ and ‘diagram’, as they are used by toolset vendors, in order to avoid confusion. However, a model or diagram created by a toolset, using an appropriate notation, and included in a set of views in a DoD architecture should be understood as a ‘view’ within DoDAF. 2047 2048 2049 The two most common techniques—the Structured Analysis and Design (SADT) Approach and 2050 the Object-oriented Analysis & Design (OOAD) Approach—are discussed briefly below. 2051 Examples of the notation supporting these techniques are presented in examples contained within 2052 Volume 2. Either of these techniques can be used with the methodology described above, or by 2053 others, such as MODAF, NAF, TOGAF, or other Government or commercial offerings. 2054 2055 7.1.5.1 Structured Technique Overview. Architectures developed under a structured 2056 analysis-driven approach are process-oriented and characterized by a hierarchical process 2057 decomposition. Historically, structured models generally used in DoD originated from the 2058 Integration Definition Language developed by the US Air Force, and later used to develop the 2059 Activity Modeling standard (IDEF0) [IDEF0 1993] a Federal Information Processing Standard 2060 (FIPS) published by the National Institutes for Standards & Technology (NIST). This technique 2061 evolved from an earlier, also process-driven approach, Structured Analysis and Design 2062 Technique (SADT), developed for the U.S. Air Force Materiel Command. More recently, 2063 architecture development using structured methods has also included those utilizing the Business 2064 Process Modeling Notation (BPMN), developed by the Business Process Management Initiative, 2065 and currently managed by the Object Management Group (OMG). 2066 7.1.5.1.1 Process Data Flow.. A process flow diagram (PFD) is a graphical representation of 2067 the "flow" of data through a process. With a process flow diagram, users are able to visualize 2068 how the process will operate, what the process will accomplish, and how the process is executed 59 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2069 normally. Process flow diagrams can be used to provide the end user with a physical idea of the 2070 resulting actions that occur on data input, and how their actions ultimately have an effect upon 2071 the structure of the whole process. Process flow diagrams also define desired or required 2072 system-level functions—the level and type of automation desired to improve the time, efficiency, 2073 and results of executing a process. 2074 7.1.5.1.2 Process Task-Dependency Diagram. Process Task Dependency (PTD) Diagrams 2075 lay out clearly the step-by-step flow of a process by tracking the flow of material, information or 2076 a service through all its steps in a logical or required order. The PTD diagram assists an 2077 unfamiliar audience to picture the steps of a process and clarifies misconceptions about how the 2078 process actually operates, while providing a reference for the handling of corrective action or 2079 process improvement. Task-sequence notations work especially well for “uninterruptible” 2080 processes, meaning a set of steps that exhibits clear dependencies, doesn’t execute until 2081 explicitly triggered, and normally continues until it achieves a clear exit criterion. Such 2082 processes are generally low-level and detailed, and useful, among other things, for: 2083 2084 • Defining detailed performance metrics and metrics capture 2085 • Establishing an information base for executable architecture/process simulation 2086 • Defining automation functional requirements 2087 2088 7.1.5.1.3 Entity-Relation Model. The Entity-Relation Model describes the structure of an 2089 architecture domain’s system data types and the business process rules that govern the 2090 system data. It provides a definition of architectural domain data types, their attributes or 2091 characteristics, and their interrelationships. 2092 2093 7.1.5.2 Object-Oriented Technique Overview. Object-oriented architecture views are 2094 created utilizing the Unified Modeling Language (UML) architecture technique and notation, 2095 together with the DoDAF logical and Physical Exchange Specification data structures. This 2096 technique describes the operational need, places data (objects, or ‘performers’ in the DoDAF 2097 data structure) in the context of its use, and provides a traceable foundation for system and 2098 software design. It is based on the concepts of data abstraction and inheritance from a service- 2099 oriented view. The object-oriented technique provides an orderly arrangement of the parts of the 2100 business organization and includes a style and method of design through its highly developed 2101 notation style. 2102 2103 7.1.5.2.1 Process – Activity Diagram, Object-Sequence Diagram. An activity diagram is 2104 frequently used in conjunction with a process flow diagram that describes the sequence and other 2105 attributes (i.e. timing) of the activities. A process flow diagram further captures the precedence 2106 and causality relations between situations and events. In object modeling, Activity diagrams 2107 address the dynamic view of the system. They are especially important in modeling the function 2108 of a system and emphasize the flow of control among objects. An object diagram shows a set of 2109 objects (i.e. performers) and their relationships. Object diagrams represent static snapshots of 2110 instances of things found in class diagrams. 2111 60 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2112 7.1.5.2.2 Data – Object Class Diagram. Class diagrams offer all the UML elements 2113 needed to produce entity-relationship diagrams. Class diagrams consist of classes, interfaces, 2114 collaborations, dependency, generalization, association, and realization relationships. The 2115 attributes of these classes can be expanded to include associations and cardinality [Booch, 2116 1999]. In terms of support to DoDAF 1.5, Classes that appear in an OV-7 class diagram 2117 correlate to OV-3 information elements and OV-5 inputs and outputs. The OV-7 class diagram 2118 is a separate diagram from the class diagrams that may be developed for other products. 2119 2120 7.2 System (Component, Package, Deployment) Diagram. DoDAF 2.0 provides extensive 2121 architecture support for the systems engineering process. As the process of developing the 2122 system architecture moves from the high-level concept (e.g., system interface description, system 2123 overview diagram) to more detailed views, it becomes useful to create multiple models so that 2124 specialized views of the architecture can be depicted. Three important diagrams are the 2125 Component Model, which focuses on functional features of the system; the Package Diagram, 2126 which focuses on grouping of components for specific purposes; and the Deployment/ 2127 Operational Model, which focuses on the physical runtime infrastructure on which functional 2128 components will be deployed. 2129 2130 The value of using multiple models arises from the fact that each of these models begins to call 2131 upon different skills and knowledge sets as the level of detail increases. Since these diagrams/ 2132 models are dependent upon each other, they cannot be created in complete isolation. The 2133 architecting process thus becomes an iterative process, defining portions of each of these 2134 diagrams, then evaluating how each fits with the other, and making revisions that optimize the 2135 diagrams so they support each other effectively. 2136 2137 7.2.1 Component Model and Package Diagram. A Component Model describes the 2138 hierarchy of functional components, their responsibilities, static relationships, and the way 2139 components collaborate to deliver required functionality. A component is a relatively 2140 independent part of an IT System and is characterized by its responsibilities, and the interfaces it 2141 offers. Components can be decomposed into smaller components or aggregated into larger 2142 components. Some components already exist, but it may be necessary to build or buy others. A 2143 component can be a collection of classes, a program (e.g., one that performs event notification), a 2144 part of a product, or a hardware device with embedded functional characteristics (e.g., a Personal 2145 Digital Assistant [PDA]). Some are primarily concerned with data storage. A more 2146 comprehensive treatment of Component Models is found in the DoDAF Journal, 2147 https://www.us.army.mil/suite/page/454707. 2148 2149 7.2.2 Deployment/Operational Model. The Operational Model describes the operation of the 2150 IT system, as illustrated below in Figure 7.2.2-1. This model is derived primarily from the 2151 operational requirements) placed on the e-business application. Like the Component Model, the 2152 Operational Model is typically developed through a series of progressively more detailed 2153 elaborations (i.e., Conceptual, Specified, and Physical). Also like the Component model, at each 2154 level of elaboration there may be a need to create more than one view of the Operational Model 2155 so that no single view becomes overloaded by attempting to convey too much information. A 61 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2156 more comprehensive treatment of the Deployment/Operational Model is contained in the 2157 DoDAF Journal, https://www.us.army.mil/suite/page/454707. 2158 E SS ibd [system] ESS «node» «node» * : Central Monitoring Station : MF Residence Installation «hardware» «hardware» : Help Desk Client : Phone Lines «node» * «hardware» : Business Installation «hardware» «external» : MS LAN : Application Server : Comm Network allocatedFrom «software» MS Comm I/F «internal actor» : SF Residence Installation * «software» MS Event Monitor : Help Desk Operator «software» PS Report Mgr «hardware» «software» PS Request Mgr : PS Comm «software» Site Interface Mgr * 2 I/F «hardware» «hardware» «hardware» : Optical Sensor : Video Camera : DSL Modem «hardware» : DB Server «hardware» «hardware» : Site Processor : NW Hub «hardware» allocatedFrom : Alarm «hardware» «software» CMS RDBMS allocatedFrom allocatedFrom «hardware» «data» CMS Database «software» SF Comm I/F : CM Server «software» Device Mgr : Video Server «software» Event Mgr allocatedFrom «software» Site Config Mgr «software» S/W Distrib Mgr «software» Site RDBMS «software» System CM «software» Site Status Mgr «software» User I/F «software» User Valid Mgr 2 «hardware» : DVD-ROM Drive allocatedFrom «data» Site Database «hardware» «hardware» : Site Hard Disk : User Console allocatedFrom «data» Site Database 2159 2160 Figure 7.2.2-1: Deployment/Operational Model 2161 62 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2162 8. ARCHITECTURE PRESENTATION TECHNIQUES 2163 2164 While information is the lifeblood of enterprise architecture, it can be overwhelming to decision 2165 makers when presented in a raw format. Likewise, the structured methodology of modeling 2166 enterprise architecture information is both necessary and useful for creating architectures that can 2167 be shared between organizations. However, many of the ‘traditional’ architecture products are 2168 unwieldy because of their format and are useful only to trained architects. Many organizations 2169 develop a “mandated” architecture but make it expensive shelf-ware instead of using it to 2170 communicate important, accurate, and relevant information to the stakeholders who need it. 2171 Architects must be able to communicate architecture information in a meaningful way to process 2172 owners and other stakeholders, or the discipline of enterprise architecture will soon meet an 2173 untimely demise. 2174 2175 The results of architecture-related data collection need to be presentable to non-technical senior 2176 executives and managers at all levels. Many managers are skilled decision-makers, but have not 2177 had technical training in architecture development. Since architecture development efforts are 2178 designed to provide input to the decision-making process, graphical representation of data 2179 needed is a logical extension of the overall process. This section describes these graphical 2180 representations (architects call them 'products' or 'views'). 2181 2182 8.1 Overview. Effective presentation of business information is necessary for architects to tell 2183 the story of the architecture data with stakeholders. Since the purpose of the architecture 2184 discipline is to collect and store all relevant information about an enterprise, or some specific 2185 part of the enterprise, it can reasonably be assumed that the majority of information needed by an 2186 organization’s decision makers is contained somewhere in the architecture data. Many of the 2187 existing architecture methods are valuable for organizing architecture information, but less 2188 valuable for communicating that information to stakeholders. Presentation views are always 2189 dependent on the quality of the architecture information that is collected through the rigor of 2190 architecture methods. As figure 8.1-1 illustrates, presentation techniques pull from the 2191 architecture information store and display the data in a variety of meaningful ways to 2192 stakeholders. 63 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2193 2194 Figure 8.1-1 Presentation Techniques 2195 2196 The presentation techniques and best practices described here (And documented more fully in 2197 Volume 2) were developed based on the idea that business information, captured both internally 2198 and externally to an organization’s architecture in support of common user requirements, can be 2199 displayed in a way that enhances clarity and understanding, and facilitates decision-making. 2200 That often means that complex technical information must be ‘translated’ into a form for 2201 presentation that is useful to management. An ‘Information Bridge’, as shown in Figure 8.1-2 is 2202 the link between the architect and management. The bridge provides the means to take technical 2203 information, and recast that information in graphical or textual terms that consistent with the 2204 culture of the organization. 2205 2206 2207 Figure 8.1-2 The Information Bridge 2208 2209 DoDAF, Version 1.0 and Version 1.5 defined a set of ‘products’ for visualizing, understanding, 2210 and assimilating the broad scope and complexities of an architecture description through graphic, 64 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2211 tabular, or textual means. These products can still be produced, and are supported by the sets of 2212 views described in Volume 2. 2213 2214 8.2 Choosing an Appropriate Presentation Technique. In any given business process, 2215 decisions must be made at multiple levels of the organization. Whether one is a senior level 2216 executive, a process owner, or a system developer, he or she will need to make judgment calls 2217 based upon the available data. Each level of decision maker, in turn, has both a unique purpose 2218 and understanding of architecture, making it important to tailor the data in order to maximize its 2219 effectiveness. The presenter, with the help of an experienced architect, must determine the 2220 audience of a presentation before choosing the type of presentation technique to use. Figure 8.2- 2221 1, based on the Zachman Framework,32 summarizes the multiple levels of decision makers 2222 within a typical organization that make up an audience. 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 Figure 8.2-1 Levels of Decision-Makers 2238 2239 2240 2241 Each level has differing requirements for presentation of data. Level 1 Planners may find a 2242 graphical wall chart more useful in making decisions, whereas a Level 4 Builder will most likely 2243 require a more technical presentation, one relating more directly to the architecture. Level 5 sub- 2244 contractors are the workers who will perform the work required, and generally required varying 2245 levels of technical data and other information to accomplish their task. 2246 2247 Narrowing down the type of presentation required is done by asking the following question: 2248 What information does the decision maker need in order to make a data-supported decision? 2249 For each decision level there is a data set that can be manipulated using a presentation technique. 2250 After analyzing the audience and type of information, the presenter should consider the various 32 Zachman, John. Zachman Framework. © Zachman International. The Zachman Framework can be found at the Zachman International Website: http://zachmaninternational.com/index.php/the-zachman-framework/26-articles/13-the-zachman- framework-a-concise-definition. 65 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2251 types of techniques discussed in this section. Figure 8.2-2 is a simplified representation of the 2252 presentation development 2253 process. 2254 2255 Figure 8.2-2: Presentation Development Process 2256 2257 It is imperative to realize that when choosing how to present data sets, there is no limit on what. 2258 views to use. There are countless ways to display information to decision makers, and it is up to 2259 the presentation developer to determine the most effective way to accomplish this task. This 2260 section describes a base of view development techniques to start from, each created to serve its 2261 own unique purpose. Details are provided on five different presentation techniques that have 2262 proven to be useful in engaging various audiences. 2263 2264 A more detailed discussion of DoDAF Meta-model Groups is provided in Volume 2, Section 2, 2265 that includes a description and purpose for each group, the data capture method, and the use of 2266 each group.. There are the DoDAF-described Views that derive from and conform to the 2267 DoDAF Meta-model. Additionally, within each view are a number of described presentation 2268 views that present differing sets of possible representations, with their associated data. 2269 2270 Alternatively, user-defined views, called Fit-for-purpose Views can be created, utilizing 2271 DoDAF-conformant data that provide other forms of graphical presentation. These use 2272 presentation that are more common to briefings and decision analysis The five techniques 2273 commonly used are: 2274 2275 • Composite Products: Display multiple pieces of architecture in formats that are relevant 2276 to a specific decision maker (Section 8.3) 2277 66 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2278 • Dashboards: Integrate abstracted architecture information for a given business context 2279 (Section 8.4) 2280 2281 • Fusion Products: Display multiple pieces of architecture and incorporate disparate 2282 pieces of information that are not captured within the architecture (Section 8.5) 2283 2284 • Graphics: Visually represent manipulated data (Section 8.6) 2285 2286 • Reference Models: Capture the elements of the architecture products and translate those 2287 elements into text (Section 8.7) 2288 Fit-for-purpose Views provide wide flexibility for the architect and process owner to create 2289 architecture views easily understood and useful to management for decision-making purposes. 2290 Each of these types of views is described below. 2291 2292 2293 8.3 Composite Views. A composite view displays multiple pieces of architecture in formats 2294 that are relevant to a specific decision maker. By drawing information from numerous sources, 2295 this presentation technique provides a holistic view for the audience. Contrasting two or more 2296 snapshots next to each other, composite products allow for an easy comparison. As seen in 2297 Figures 8.3-1, and 8.3-2, below. These views will be comprised of related architecture products 2298 that directly support each other (i.e., system functions in an SV-4 that support activities in an 2299 OV-5). The view can be graphically displayed in three dimensions to tie the pieces of 2300 architecture together. 2301 2302 8.3.1 Purpose and Audience. Composite views allow decision makers to view important 2303 relationships in data without reading through large pieces of architecture. Most business owners 2304 are interested only in their particular business area and its immediate interconnections. By 2305 placing relevant parts of architecture directly in front of the audience, it is easier to gain a 2306 comprehensive understanding of the data in an efficient manner. The audience that will find 2307 these products most useful are: 2308 • Process Owners who have direct staff oversight or technical systems expertise and 2309 require high level conceptual briefings 2310 • Designers—implementers of the initiative, who require information detailing specifics of 2311 implementation 2312 • Builders—System architects who require details on how to implement and use products. 2313 2314 8.3.2 Examples. Figure 8.3.2-1 illustrates a simplified example of a Composite View. The 2315 activity Determine Accession Type is supported by the system function Maintain Candidate Data 2316 via User Interface. The information to support this system function includes Accession Type 2317 Information and Other Candidate Information. The activity is carried out by a Human Resource 2318 Specialist. 2319 67 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 Information Exchange from OV-5 Activity System Role from OV-2 Activity from OV-5 Model Function from Node Connectivity SV-4 Accession Type Human Information Determine Maintain Resource Accession Specialist Candidate Data Type via User Interface Other Candidate Information 2320 2321 Figure 8.3.2-1: Example Composite View 2322 2323 Figure 8.3.2-2 illustrates a final version of a different Composite View. Four architecture 2324 samples are displayed, and a three-dimensional Capability label lets the audience know the 2325 common tie. 2326 2327 2328 Figure 8.3.2-2: Another Composite View 2329 2330 Composite views are ideal for explaining interconnections between architectures. The audience 2331 will more easily understand relationships in data by viewing manageable slices of mappings all 2332 at once. The developer of this product can interchange architectures easily, highlighting the most 2333 important parts for the audience. Composite views are neither wordy, nor oversimplified. 2334 Additionally, they can be used by a wide range audience. 2335 2336 8.4 Dashboard Views. Dashboards integrate abstracted architecture information for a given 2337 business context and are generally geared to displaying information required by a specific 68 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2338 stakeholder. A well-constructed dashboard consists of a status, trend, or a variance to a plan, 2339 forecast, or budget (or combination thereof). Dashboards are generally user friendly, providing 2340 easy access to enterprise data to enable organizations to track performance and optimize 2341 decision-making. High-level decision makers generally like dashboards because dashboards are 2342 frequently used in other business contexts besides enterprise architecture, and decision makers 2343 have a familiarity with this presentation tool. In addition, the dashboard is formatted so key 2344 stakeholders can review valuable, insightful information at a glance to manage their 2345 organization’s performance goals effectively. 2346 2347 8.4.1 Purpose and Audience. The visual qualities of a dashboard allow executives and 2348 managers to identify which of their business areas are successful and which are problem areas 2349 that need immediate attention. Like all enterprise architecture presentation techniques, the 2350 dashboard must be designed with the stakeholder audience in mind and should be geared towards 2351 the audience’s specific goals. One of the most important goals in creating a dashboard is to 2352 deliver a highly intuitive tool that yields greater business insight for decision makers. 2353 2354 Since dashboards display highly aggregated and abstracted information, they are typically 2355 targeted to senior decision makers. However, they are also a great tool to share with junior 2356 architects to ensure they understand key business drivers and concepts as they take a deeper dive 2357 into their respective areas. 2358 2359 8.4.2 Examples. Table 8.4.2-1 illustrates various visualization techniques that can be used to 2360 create a dashboard. 2361 2362 Table 8.4.2-1: Visualization Techniques Visualization Technique Description When to Use Pie Chart Pie charts can be used for representing Pie charts should be used to represent small sets of information. However, they very small data sets that are geared to are generally considered poor data high-level relationships between data visualization for any data set with more elements. Pie charts present than half a dozen elements. The problem summary level relationships, and with pie charts is that it is very difficult to should be used carefully for detailed discern proportional differences with a analysis. radically divided circle, except in the case of a small data set that has large value differences within it. Pie charts also pose a problem for labeling, as they are either dependent on a color or pattern to describe the different data elements, or the labels need to be arranged around the perimeter of the pie, creating a visual distraction. Bar Chart Bar charts are an ideal visualization for Bar charts are best suited for showing the relationship of data elements categorical analysis but can also be within a series or multiple series. Bar used for short duration series charts allow for easy comparison of analysis (e.g., the months of a year.) values, share a common measure, and are A presenter needs to be aware of the easily compared to one another. risks in using bar charts if there is a data set that has one element with a 69 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 large outlier value; this will render the visualization for the remaining data elements unusable. This chart scale is linear, and will not clearly represent the relationships between the remaining data elements. Line Charts Time series line charts are most Use line charts when you would like commonly used with the time dimension to see trends over time in a measure, along the X-axis and the data being versus a side-by-side, detailed measured along the Y-axis. comparison of data points. Line charts are ideal for time series analysis where you want to see the progress of one or more measures over time. Line charts also allow for comparative trend analysis as you can stack multiple series of data into one chart. Area Charts Area charts can be considered a subset of Area charts are good for simple the line chart, where the area under or comparisons with multiple series of above the line is shaded or colored. data. By setting contrasting color hues you can easily compare the trends over time between two or more series. Tables and Lists Tables and lists contain large amounts of Tables and lists are best used for data that can be categorized into a list or information that either contains large divided into a table but cannot be easily lists of non-numeric data, or data that compiled into a visual or numerical has relationships not easily analysis tool. visualized or does not lend itself to easy numeric analysis. 2363 2364 2365 Figure 8.4.2-1 illustrates the use of these techniques to create a dashboard. 2366 2367 2368 Figure 8.4.2.-1: Notional Dashboard 2369 2370 2371 70 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2372 A dashboard is effective in demonstrating the number of systems supporting an Activity or 2373 modifying a data element. It can provide data from a variety of sources to create a multi- 2374 disciplined and multi-dimensional performance feedback. It combines standard components and 2375 building blocks to create an executive dashboard that meets particular needs. 2376 2377 8.5 Fusion Views. A fusion view is very similar to a composite view in that it displays multiple 2378 pieces of architecture in formats that are relevant to a specific decision maker. However, a 2379 fusion view also incorporates disparate pieces of information that are not captured within the 2380 architecture. Fusion views are frequently used to display information that is sensitive in nature 2381 and that is viewed only by certain stakeholders making specific decisions. For example, fusion 2382 views could be used to display funding information regarding a program or system. 2383 2384 8.5.1 Purpose and Audience. Fusion views serve as a single location for viewing disparate 2385 pieces of information from within and outside of the context of the architecture. A fusion view 2386 can be used to bridge the gap between an enterprise architecture analysis, other analysis, and 2387 transformation processes. It is frequently used when making a decision that incorporates 2388 information that has been deliberately not included in the architecture. 2389 2390 Fusion views can be used by all members of the development team (i.e. Planners, Owners, 2391 Designers, Builders, and Subcontractors). Planners use them to review portfolio choices within 2392 the context of the architecture and to determine how choices compare to the portfolio as a whole, 2393 as well as against an individual system or group of systems. Owners use fusion views to review 2394 current progress against planned goals, which may include cost and schedule data or to address 2395 capability gaps within the architecture. Designers, Builders, and Subcontractors can use a more 2396 detailed fusion view to review implementation impacts associated with the development of a 2397 particular system and to show the complexity of the information involved. 2398 2399 8.5.2 Examples. Figure 8.5.2-1 incorporates financial data and support information into an 2400 analysis. The outside information commonly consists of financial data gathered from authorized 2401 sources or scheduling information and constraints gathered from a Work Breakdown Structure 2402 (WBS) or similar reporting mechanism. This can be tailored so that the user can use any data 2403 that is relevant to their needs. 2404 71 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2405 2406 Figure 8.5.2-1: Financial Data Fusion View 2407 2408 A similar Fusion view is shown in Figure 8.5.2-2 that does not include the financial data. 2409 72 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2410 2411 Figure 8.5.2-2: Fusion View without external financial data 2412 2413 A fusion view is a powerful tool with the ability to portray accurately the relationships between 2414 different types of information. A fusion view can be used to provide a 360-degree view of a 2415 system, validate systems against architectures, show availability of services, or provide a 2416 perspective of a current environment (e.g. a viewpoint) that can be used in decision-making 2417 discussions. 2418 2419 8.6 Graphics Views. A graphic is a representation (as a picture, map, or graph) used especially 2420 for illustration of concepts. In the case of enterprise architecture, graphics views are used for the 2421 pictorial representation and manipulation of data. In other words graphics provide a visual 2422 representation of business information and processes. Graphics views can be of tremendous 2423 benefit in representing multiple concepts in a clean, simple design. 2424 2425 8.6.1 Purpose and Audience. Graphics views provide a visual depiction of the information 2426 and are therefore targeted at visually oriented learners. When properly executed, a graphical 2427 view allows the intended audience to view the information in an uncluttered, easy to understand, 2428 and precise design. Additionally, graphical views can attract attention and cause interest. Most 2429 people understand pictures faster and easier than they do text or model-based documents. 2430 Graphical views provide the presenter with literally unlimited options for displaying their 2431 business concepts and for tailoring their product to the targeted audience. 2432 2433 Because of the lack of underlying complexity, a graphic view tends to be more abstract and is 2434 usually presented to high-level audiences. The identification of the target stakeholder level and 2435 the intended message is the first step in determining whether a graphic view is the appropriate 2436 tool for information delivery. The appropriateness of graphical views can only be determined 73 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2437 once the message and stakeholder level have been identified. Graphical depictions of data and 2438 business processes can be tailored to any stakeholder level as long as the intended message and 2439 information can be represented in a logical, reader-friendly form. All levels of decision makers 2440 will find graphical views useful for high-level analysis. 2441 2442 8.6.2 Examples. The use of graphical views is a common practice in DoD and non-DoD 2443 organizations. Because graphical views do not usually show the underlying complexity, it is 2444 important to remember that they are tied to details within the architecture. As with dashboard 2445 views, if a stakeholder does not understand where the information came from, or if they lack 2446 faith in the detailed architecture information, then the graphic view will essentially be 2447 meaningless to them. It is also critical to emphasize the underlying architectural information 2448 when briefing the graphic to senior decision makers. An OV-1, for example, provides a high- 2449 level concept description of a business, and is usually the first, and can be the only architecture 2450 product a senior decision maker sees. In order for an OV-1 to have an impact, a decision maker 2451 must be able to see a direct correlation from the graphic view to the detailed aspects of the 2452 business. Figure 8.6.2-1 and Figure 8.6.2-2 illustrate this concept. Each part of the graphic 2453 view corresponds to a detailed area of the overall business, which will be represented and 2454 composed of a complex set of architecture products. The graphical views are also used to show 2455 the relationships between the business areas which come together to form a complete picture. 2456 2457 2458 Figure 8.6.2-1: Non-prescriptive, Illustrative High-level Concept Description (OV-1) 2459 74 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2460 2461 Figure 8.6.2-2: Non-prescriptive, Illustrative High-level Concept Description (OV-2) 2462 2463 2464 2465 Graphical views enable the efficient communication of complex quantitative ideas. In a society 2466 that is fascinated with visual stimulation, the use of graphical views provides an attractive and 2467 efficient communications tool. When effectively designed, graphical views can facilitate 2468 understanding and recognition; promote analysis; and support learning and sharing of ideas. 2469 2470 8.7 Reference Models. Reference models provide textural extractions of underlying 2471 architectural data. As Figure 8.7-1 illustrates, reference models capture the elements of the 2472 architecture products, and translate those elements into text. This reference model provides a 2473 framework for describing important elements of the Federal Enterprise Architecture (FEA) in a 2474 common and consistent way. The FEA consists of five reference models: Performance 2475 Reference Model (PRM), Business Reference Model (BRM), Service Component Reference 2476 Model (SRM), Data Reference Model (DRM), and the Technical Reference Model (TRM). 2477 Through the use of this common framework and vocabulary, IT portfolios can be better managed 2478 and leveraged across the Federal Government33. 33 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 75 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2479 2480 2481 Figure 8.7-1: A Notional Reference Model 2482 2483 8.7.1 Purpose and Audience. Reference models are designed to facilitate cross-agency 2484 analysis, through the development of a common taxonomy and ontology for describing the 2485 business operations of Federal agencies, independent of any specific agency. Cross-agency 2486 analysis is used by planners and process owners to identify duplicate investments, gaps, and 2487 opportunities for collaboration within and across agencies. Collectively, the reference models 2488 comprise a framework for describing important elements of the Federal Enterprise Architecture 2489 (FEA) in a common and consistent way. Through the use of this common framework and 2490 vocabulary, IT portfolios can be better managed and leveraged across the Federal government.34 2491 2492 8.7.2 Examples. One example of a reference model is the FEA Business Reference Model 2493 (BRM). The BRM provides an organized, hierarchical construct for describing the day-to-day 2494 business operations of the Federal government. While many models exist for describing 34 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 76 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2495 organizations - org charts, location maps, etc. - this model presents the business using a 2496 functionally driven approach. The Lines of Business and Sub-functions that comprise the BRM 2497 represent a departure from previous models of the Federal government that use antiquated, stove- 2498 piped, agency-oriented frameworks. The BRM is the first layer of the Federal Enterprise 2499 Architecture, and it is the main viewpoint for the analysis of data, service components, and 2500 technology (See Figure 8.7.2-1).35 2501 2502 2503 Figure 8.7.2-1: BRM Structure 2504 2505 The BRM is broken into four areas: Services for Citizens, Mode of Delivery, Support Delivery 2506 of Services, and Management of Government Resources. The model’s four Business Areas are 2507 decomposed into 39 Lines of Business. Each business line includes a collection of Sub-functions 2508 that represent the lowest level of granularity in the BRM. For example, the Environmental 2509 Management Line of Business encompasses three Sub-functions: (1) Environmental Monitoring 2510 and Forecasting; (2) Environmental Remediation; and (3) Pollution Prevention and Control. 2511 Within each Sub-function are the agency-specific business functions, processes, and activities 2512 (see Figure 8.3.4-2).36 2513 35 Federal Enterprise Architecture - Business Reference Model. The current version can be found at: http://www.whitehouse.gov/omb/egov/a-3-brm.html 36 Federal Enterprise Architecture Records Management Profile, Version 1.0, December 15, 2005. Executive Office of the President., Office of Management and Budget. A current version of the profile can be found here: http://www.cio.gov/documents/RM_Profile_v1.pdf 77 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2514 2515 Figure 8.3.4-2: BRM Areas 2516 2517 Federal agencies are currently using the FEA reference models to plan and develop their annual 2518 budgets and set strategic goals. Agencies’ annual budget submissions to OMB for IT must 2519 describe how these investments “align” to the business, performance, service component, and 2520 technical reference models. In practical terms, this means that agencies must describe their IT 2521 investments in terms of the business operations they will support, the functional capabilities they 2522 intend to deliver, the supporting technologies used to build or deliver the capabilities, and 2523 performance impacts.37 2524 2525 By providing a common language to describe the relationship between Federal business 2526 operations, technology, and information, the FEA enables the Government to identify 2527 opportunities to leverage technology which: 2528 2529 • Reduce unnecessary redundancy 2530 • Facilitate intergovernmental information sharing 2531 • Establish a direct relationship between IT and agency performance to support citizen 2532 centered, customer-focused Government 2533 • Maximize IT investments to better achieve mission outcomes38 2534 37 Federal Enterprise Architecture Records Management Profile, Version 1.0, December 15, 2005. Executive Office of the President., Office of Management and Budget. A current version of the profile can be found here: http://www.cio.gov/documents/RM_Profile_v1.pdf 38 Federal Enterprise Architecture Records Management Profile, 78 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2535 9. DODAF META-MODEL 2536 2537 Note: This section describes the DoDAF Meta-model(DM2), which replaces the Core 2538 Architecture Data Model referenced in previous versions of DoDAF. 2539 2540 The DM2 provides a high-level view of the data normally collected, organized, and maintained 2541 in an architecture effort. It also serves as a roadmap for the reuse of data under the federated 2542 approach to architecture development and management. Reuse of data among communities of 2543 interest provides a way for managers in any level or area of the Department to understand what 2544 has been done by others, and also what information is already available for use in their 2545 architecture, and management decision-making efforts. 2546 2547 The DM2 has several levels, each of which is important to a particular viewer of Departmental 2548 processes. A conceptual level or Conceptual Data Model (CDM) is described in this volume 2549 and defines the high-level data constructs from which architectures are created in non-technical 2550 terms,, so that executives and managers at all levels can understand the data basis of architecture. 2551 The Logical Data Model (LDM) adds technical information, such as attributes to the CDM and, 2552 when necessary, clarifies relationships into an unambiguous usage definition. The Logical data 2553 Model is described further in Volume 2. 2554 A Physical Exchange Specification (PES) is described in Volume 3, and consists of the Logical 2555 Data Model with general data types specified and implementation attributes (e.g., source, date) 2556 added, and then generated as a set of XSD’s, one schema per DoDAF-described View, except for 2557 the OV-1. 2558 2559 The DM2 defines architecture data elements and enables the integration and federation of 2560 architectures. It establishes a basis for semantic (i.e. understanding) consistency within and 2561 across architectures. In this manner, the DM2 supports the exchange and reuse of architecture 2562 information among Joint Capability Areas (JCAs), Components, and Federal and Coalition 2563 partners, thus facilitating the understanding and implementation of interoperability of processes 2564 and systems. As the DM2 matures to meet the ongoing data requirements of process owners, 2565 decision makers, architects, and new technologies, it will to a resource that more completely 2566 supports the requirements for architecture data, published in a consistently understandable way, 2567 and will enable greater ease for discovering, sharing, and reusing architecture data across 2568 organizational boundaries. 2569 2570 In order to facilitate the use of information at the data layer, the DoDAF describes a set of views 2571 for visualizing data through graphic, tabular, or textual means. These views are contained in 2572 eight (8) data groups, each of which contribute to more specific views that respond to 2573 requirements for producing an architecture. 2574 2575 a. 9.1 The DoDAF Conceptual Data Model. The CDM defines concepts involving high- 2576 level data constructs from which architectures are created, enabling executives and 2577 managers at all levels to understand the data basis of architecture. The CDM also 79 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2578 describes the relationships among data constructs in relatively non-technically and easily 2579 understood terms. Figure 9.1-1 is a graphical representation of the CDM. Definitions for 2580 the CDM are in Appendix B. Underlying the CDM is a foundation the utilizes common 2581 data modeling constructs that facilitate the reuse of common data patterns. 2582 2583 The top-level foundation elements are: 2584 2585 a. Thing, similar to other model’s “object” 2586 b. Individual, a “thing” that exists as an indivisible whole, or as a single member of a 2587 category. 2588 c. Type, a set of individuals or classes of other sets or classes 2589 d. Tuple, ordered places of “things” (e.g. a block in a spreadsheet or a table) 2590 2591 These foundation elements are similar to many other foundation high-level data constructs that 2592 exist in the industry. The common patterns that are reused are: 2593 2594 a. Composition (or whole-part) 2595 b. Super/Sub Type (or generalization/specialization, e.g. tank or main battle tank) 2596 c. Before /After, for “things” that have time-related relationships in their Type 2597 d. Interface, for “things” that can exchange other things that are parts of themselves 2598 2599 Composition and Super/Sub Type apply to almost all architecture concepts. Before/After is 2600 frequently used to model before/after situations, while Interface applies to few concepts, limited 2601 at this time to the pattern describing Activity. 80 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2602 2603 2604 Figure 9-1: DoDAF Conceptual Data Model 2605 2606 81 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2607 2608 2609 10. ARCHITECTURE-BASED ANALYTICS 2610 Architecture-based analytics includes all of the processes that transform architecture data into 2611 useful information in support of the decision making process. Various types of analysis are 2612 described below (static vs. dynamic), along with descriptions of desirable characteristics for the 2613 overall architecture data set needed for successful and accurate analysis capability. Architectures 2614 are an ideal construct to use in decision-making since they represent the most current, and 2615 accurate information about a program or mission requirement. 2616 2617 10.1 Analytics Context 2618 DoDAF 2.0 has been designed to facilitate collection of data usable through quantitative, 2619 repeatable, analytical processes to support decisions at all levels of enterprise and/or system 2620 engineering. Architecture views (formerly ‘products’) are no longer the end goal, but are 2621 described solely to facilitate useful access to information in the architecture database. All views 2622 are tailorable. The requirements for data completeness and self-consistency within the data 2623 schema are more critical than the view chosen at any particular time by a particular user. 2624 Analytics, properly conducted, represent a powerful tool for the decision-maker, ensuring that 2625 the most appropriate and current, as well as valid data is used for decision-making. 2626 2627 Figure 10.1-1 below, an adaptation of Figure 1.3-1, from Section 1, illustrates the overall 2628 architecting process. More specifically, it illustrates that analytics, the process of doing analysis 2629 with and on architecture data, is central to successful decision-making. Analysis defines and 2630 describes potential courses of action (i.e. alternatives) that can be considered when considering a 2631 mission or program decision. 2632 2633 2634 Figure 10.1-1: Analytics Process, Central to transforming architectural data into usable 2635 forms to support decision-makers 2636 82 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2637 Architecture development is an iterative process, evolved over time. Analyses developed from 2638 architecture data remain valid only as long as the processes and information do not change, and 2639 management decision-making remains focused on the same problem for which the architecture 2640 data was collected. When any of these variables (i.e. architecture purpose, process steps, 2641 information, or management direction) change, then previous analyses should be reviewed to 2642 determine if the previous analysis needs to be redone, based on the newly provided information. 2643 Constant feedback and examination needs to be understood as natural in an environment where 2644 program direction and priorities are constantly in flux. 2645 2646 The need for an iterative analytical capability points towards tool-assisted and tool-supported 2647 analyses whenever possible. Process steps, such as re-running analyses, that are difficult or time 2648 consuming to perform will likely not be performed unless automated. The iterative approach (as 2649 depicted in Figure 10.1-2) of build a little, use a little, build a little, … enables architectures to 2650 achieve incremental, reachable goals early and throughout the entire architecture life-cycle 2651 process. 2652 2653 2654 Figure 10.1-2: Iterative Approach 2655 2656 10.2 Architecture Analytics is a process that uses architecture data to support decision- 2657 making through automated extraction of data from a structured dataset. Automated extraction 2658 may be nothing more than results from a query into a database. Architectures well designed, and 2659 consistent with the purpose for which they were created, are also well suited to the analytics 2660 process. 2661 2662 10.3 Types of Architecture Analysis 2663 There are two categories of analytical activity. These are: 2664 2665 • Static Analyses: Those analyses, which are based on making a value judgment, based on 2666 data extracted from the architecture. For example, analysis of the weather patterns and 2667 measurements for the last 50 years to determine trends and correlations would be static 2668 analyses. 2669 • Dynamic Analyses: Those analyses, which are based on “running” an executable version of 2670 the architecture to observe the overall behavior of the model. For example, the construction 2671 and execution of a dynamic weather prediction model to determine the possible future 2672 weather trends is an example of dynamic analysis. 2673 83 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2674 10.4 Examples of Analytics 2675 Analytics can be used in conjunction with many aspects of the architecting process. Examples of 2676 analytical support can be found within DOTLMPF, as shown in Table 10.4-1, below. 2677 DOTMLPF is the analysis of who (people, organization, leadership) perform what operations 2678 (doctrine) at which locations (facilities) using (training) which system resources (material) to 2679 produce and consume information and data. DOTLMPF analysis leads to better definitions of 2680 warfighting capabilities by being able to anticipate effects and assess impact of change on 2681 domains and by examining usage (who/what affects something) and references (who/what is 2682 affected by something). DOTLMPF domains map to DoDAF architecture elements with the 2683 following analytical support activities. 2684 Table 10.4-1: DOTMLPF DOTMLPF DoDAF Architecture Analytical Support Activities Domains Elements Doctrine Functions, Performers, Examine Tactics, Techniques and Procedures Assets, Locations, Nodes Organization Performers, Org Units Examine organizational structure Training Functions, Performers, Train personnel on their activities and the systems Assets they use Leadership Org Units, Performers, Examine leadership issues Assets Materiel Functions, Material, Data, Examine materiel solutions – a new system? Information, Location. Assets, Performers Personnel Performers Examine personnel solutions – new personnel or personnel with better qualifications Facilities Locations Examine fixing, building or modifying facilities 2685 2686 It is not the intent for DoDAF to prescribe all possible analytical activities. The list above is 2687 only a partial listing of potential activities that relate to DoDAF architecture elements useful to 2688 the DOTMLPF Domains. As more demands are placed on architecture, and as industry spawns 2689 more automation, the flexibility described in DoDAF will encourage further innovation from 2690 architects and from tool vendors. 2691 2692 10.5 Principles of Architecture Analytics 2693 The five key foundational principles of architecture analytics are described below. These 2694 principles help in maintaining quality architecture and foster further innovation for spawning 2695 new analytical activities in the future. 2696 2697 10.5.1 Information Consistency. Information consistency means that data (and its derived 2698 information) within the architecture descriptions is consistent with an overarching metadata 2699 structure (called a ‘schema’). In addition to adhering to the explicit syntax rules of the schema, 2700 data also needs to be consistent with any additional rules specified for the project. Information 2701 consistency is often checked to some degree by commercial architecture tools, and additional 2702 checking capabilities can be implemented to help assure a more reliable architecture product. 2703 2704 Information consistency also refers to whether the data in one section of the architecture 2705 description agrees with the data in another section. For instance, if a specific Activity is assigned 84 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2706 to a role in one place, yet in another portion of the architecture, that role is shown as not having 2707 responsibility for that activity, this would be a information inconsistency. This is normally 2708 because the underlying architectural data is found in two or more places. In this case, the tool 2709 itself or some configurable process must perform rule-based checks for redundancy to ensure the 2710 data in multiple places is consistent. Consistency also involves architecture integration where 2711 the underling architectural data is stated only once—one fact, one place—and the architectural 2712 views are projections of a single, inherently consistent model. 2713 2714 10.5.2 Data Completeness. Data completeness refers to the requirement that all required 2715 attributes of data elements are specified. For example, a set of system functions where only 2716 some of the functions have associated textual descriptions would not be data complete. Data 2717 completeness also refers to the property of having all necessary data to perform certain analyses, 2718 view (product/artifact) generation, and/or simulations or executable architectures. 2719 2720 Analytics demands that the architecture data be understandable. Not every analytical procedure 2721 will need to examine every part of the architecture. However, no analytical procedure can 2722 analyze an architecture that it cannot sufficiently understand, so the architecture’s structured 2723 dataset must be complete enough to support required analytics, thus making it essential that the 2724 structured dataset support and define all aspects of the architecture. The architectural model, the 2725 projections of the model, and the transformations of the model should, to the extent possible, be 2726 based upon open standards. Open standards allow analytics choices 2727 2728 10.5.3 Transformation. Many decisions require the use of data contained in datasets created 2729 by different toolsets. Utilizing the data for analysis may require a transformation of the data into 2730 an alternative structure, which in turn may be accessed by another tool. Transformation allows 2731 the intellectual capital invested in the architecture to reach beyond the set of tools used in 2732 creating it. 2733 2734 10.5.4 Iteration. Analysis must support an iterative architecture refinement and decision 2735 process (refer to Figure 10.1-2). Analysis that takes too long in any iteration will quickly 2736 become irrelevant to the overall process. Rather, small iterative steps or modules should be 2737 created that will produce reliable, trustable results. 2738 2739 10.5.5 Lack of Ambiguity. An architecturally structured dataset must make clear the 2740 meaning of each defined element. If there are semantically variable architectural constructs, they 2741 cannot be accurately analyzed by multiple analysis tools. This limits the scope and effectiveness 2742 of analytics and therefore limits the usefulness of the architecture itself. Semantic specificity is 2743 essential to gain the full benefit of analytics. 2744 85 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2745 11. CONFIGURATION MANAGEMENT OF THE DODAF ARCHITECTURE 2746 FRAMEWORK 2747 2748 Configuration management (CM) provides an orderly way to facilitate change, based on a 2749 documented requirements baseline, and utilizing best practices in the change management 2750 process. This is intended to ensure that expectations are fully understood and realized in an 2751 efficient manner, including proper consideration of all potential impacts on customers and 2752 resources. CM is a necessary and critical process to assure an orderly and stable evolution of any 2753 architecture and also to ensure that the DoDAF remains current in the face of evolving methods 2754 and techniques of architecture creation and management. 2755 2756 This section provides a summary overview of the two primary aspects of configuration 2757 management of DoD enterprise architecture efforts: 2758 2759 • Configuration management guidance to developers of specific instance architectures 2760 prepared within DoD in accordance with the DoDAF. 2761 • Configuration Management of the DoD Framework document content itself. 2762 2763 These CM activities are complementary with existing DoD CM processes for the DoD 2764 Architecture Registry System (DARS), the DoD Information Technology Standards Registry 2765 (DISR), and the Metadata Registry (MDR). A more comprehensive description of the overall 2766 CM Process is found online in the DoDAF Journal, https://www.us.army.mil/suite/page/454707. 2767 2768 11.1 Configuration Management Authority 2769 The Configuration Management Authority for the contents of the DoDAF document is The Chief 2770 Information officer (CIO), OASD (NII). 2771 2772 11.2 Configuration Management Guidance for Program Managers 2773 2774 There are many benefits to the Department gained by adhering to a CM Program in the 2775 production of architecture data, thus providing consistency to the creation and utilization of 2776 presentation views, while still allowing flexibility in graphical presentation. These include: 2777 2778 • Utilization of the DM2 (Conceptual, Logical and Physical Exchange Specification) in 2779 architecture data collection, organization, storage, and documentation. 2780 • Utilization of DoDAF technical guidance (Contained in Volume 2, and the DoDAF 2781 Journal, https://www.us.army.mil/suite/page/454707) in the creation and graphical 2782 representation of views, based on architecture data and a desired viewpoint. This is 2783 accomplished by: 2784 - DoDAF definition of attributes for common architecture views. Thus, there is a known 2785 basis for making change to architecture views, and a means for evaluating the 2786 effectiveness of that change according to the chosen viewpoint. 2787 - DoDAF representation of a common vocabulary and grammar for documenting 2788 architectures thus facilitating common understanding among DoD components, ensuring 86 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2789 interoperability in exchanging architecture data and federation of individual architectures 2790 within a higher tier enterprise view. 2791 • Traceability of Requirements. Architectural data can more easily be associated with 2792 baseline requirements, and, as requirements change, the associated impacts on present and 2793 future actions can more easily be evaluated, and more accurately reflect the change 2794 requirement. 2795 • Configuration Identification. Utilization of DoDAF data elements allows a consistent 2796 identification of Configuration Items (CIs), which are currently defined as: 2797 - The “Vocabulary” - The Elements (e.g. process, system function, Capability, etc.) and 2798 Views (AV, OV, SV, TV, etc.) that describe the behavioral, tabular, mapping, ontological, 2799 and structural representations of an architecture.-The metadata (e.g. Information about data in 2800 the architecture). 2801 - The “Grammar” - The formal conceptual and logical relationships between elements 2802 and products of the “Vocabulary” – The Conceptual and Logical Data Model. 2803 - The Presentation Guidelines – “Fit for Purpose” view points, dashboards, decision 2804 views, etc.—The “Architecture Results” 2805 - Methods and Process Guidelines 2806 - The DoDAF Document - The narrative volumes comprising the DoDAF. 2807 • Organized Process. Change activity is controlled through a known, documented, and 2808 organized process. 2809 • Improved Change Management. Architecture data can be better managed to produce 2810 stable and consistent requirements to guide the development of interoperable systems, 2811 processes, and procedures. 2812 • Improved Analysis and Trades. Analyses that better reflect customer need through 2813 common understanding and explicit documentation of architecture baselines and change 2814 evolution. 2815 2816 11.2.1 Configuration Management Implementation. Each architecture effort must establish 2817 a configuration management process and document it in a CM plan. This plan is submitted when 2818 each version or update to the architecture is submitted to DARS for registration and discovery. 2819 In developing CM processes for architectures it is recommended that “best practices” be adopted 2820 such as those outlined in EIA Standard EA-64939. This a flexible, but well-defined standard 2821 employed most often at the ‘enterprise’ level. Its flexibility lies in the ability to provide CM 2822 practices that can be selectively applied to the degree necessary for each of the areas to be 2823 covered under this plan. 2824 11.2.2 Evaluating Architecture Changes. Appropriate evaluation criteria should be 2825 developed in the CM Plan and applied according to the scope and tier of the architecture effort. 2826 The evaluation criteria must include factors that test compliance with the Net-Centric Reference 2827 Architectures and the DoD IE as outlined in Section 3.0 of the DoDAF and the Net-Centric 2828 Guidance contained in Volume 2. The results of architecture evaluations should be used to guide 39 ANSI/GEIA Standard EIA 649-A National Consensus Standard for Configuration Management American National Standards Institute. This standard is available at: http://www.techstreet.com/cgi-bin/detail?product_id=1160265 87 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2829 decisions for approving proposed changes, as well as in planning future extensions or updates to 2830 the architecture. 2831 2832 11.2.3 The DARS Registration Process. Consistent with the federated architecture approach 2833 described in Section 3, essential architecture information must be registered with DARS so that 2834 discovery of reusable architecture data can be accomplished throughout the Department. 2835 Generally, and as further described in the instructions on registration contained online in the 2836 DARS, this consists of the Overview and Summary Information (AV-1) which can be completed 2837 online, and the Configuration Control Plan (CCP) that describes how the organization intends to 2838 manage and periodically update its information. Individual data entities and other artifacts are 2839 similarly registered in the DoD Metadata Registry. 2840 2841 11.3 Configuration Control Board (CCB). The DoD Architecture Configuration Control 2842 Board (CCB) provides an organized management review process to ensure validity, currency, 2843 and timeliness of architecture data described over time. The board provides configuration 2844 management and control carefully scoped and administered to reduce the burden and complexity 2845 of architecture sharing and maintenance, as well as update, while providing flexibility to the 2846 DoD community in the continued management of their architectural products and associated 2847 data. The CCB Consists of members appointed by the Deputy DoD CIO, and includes 2848 representatives of the Joint Staff, OSD, The Military Services, Combatant Commands, and 2849 Defense Agencies. 2850 2851 11.4 Technical Working Groups (TWGs). The CCB may, from time to time, establish 2852 technical working groups (TWG), as required, to oversee, review, and make recommendations to 2853 the board on specific technical aspects of the CM Program, or configuration items. TWGs 2854 provide the subject-matter expertise necessary to ensure that documents, database schemas, and 2855 other products under configuration control of the CCB are maintained in a responsible manner. 2856 TWGs, when tasked by the CCB, provide detailed and comprehensive technical review of 2857 proposed changes and recommendations to the CCB on action(s) to be taken that result from 2858 recommended changes. Both permanent members of the CCB and members of all technical 2859 working groups are notified about all CCB meetings and all scheduled TWG sessions, as are the 2860 Combatant Commands and Defense Agencies. 2861 2862 88 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2863 12. RELATIONSHIPS TO OTHER ARCHITECTURE FRAMEWORKS/ 2864 REFERENCE DOCUMENTS 2865 DoDAF is designed to align, map, and socialize with industry, allies with their own national 2866 frameworks, and other reference documents required for interoperability, reuse, and operational 2867 purposes. The DoDAF approach to alignment is to incorporate relevant concepts into DoDAF 2868 from other frameworks and reference documents and understand, integrate and describe the 2869 differences. 2870 2871 12.1 Frameworks 2872 2873 2874 12.1.1 Federal Enterprise Architecture (FEA) Program 2875 2876 The FEA promotes shared development for common Federal processes, interoperability, and 2877 sharing of information among the Agencies of the Federal Government and other Governmental 2878 entities through the use of a set of reference models and practices that apply to all Federal 2879 agencies in the Executive branch. The FEA Practice Guidance uses a segment architecture 2880 approach that allows critical parts of the overall Federal Enterprise, called architectural 2881 segments, to be developed individually, while integrating these segments into the larger 2882 Enterprise Architecture. The DoDAF leverages the FEA construct and core principles to provide 2883 the Department with the enterprise management information it needs to achieve its strategic 2884 transformation goals, while ensuring that upward reporting and review can be accomplished 2885 against the FEA. 2886 2887 The current version of the FEA can be found at the E-Gov Website: 2888 http://www.whitehouse.gov/omb/egov/a-1-fea.html 2889 2890 12.1.2 The Zachman Framework 2891 2892 The Zachman Framework provides a formal and highly structured way of defining an enterprise. 2893 It is based on a two-dimensional classification model, displayed as a matrix, which utilizes 6 2894 basic communication interrogatives (What, How, Where, Who, When, and Why) and 2895 intersecting 6 distinct model types which relate to stakeholder groups (Planner, Owner, Designer, 2896 Builder, Implementer and Worker) to give a holistic view of the enterprise. Decomposition of 2897 the matrix allows for several diagrams of the same data sets to be developed for the same 2898 architecture, where each diagram shows an increasing level of detail. DoDAF v2.0 supports the 2899 needs of various stakeholders’ perspective by supporting various levels of abstraction and 2900 granularity. 2901 2902 The Zachman Framework can be found at the Zachman International Website: 2903 http://zachmaninternational.com/index.php/the-zachman-framework/26-articles/13-the-zachman- 2904 framework-a-concise-definition. 2905 2906 12.1.3 The Open Group Architecture Framework (TOGAF) 2907 89 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2908 TOGAF is a comprehensive architecture framework and methodology, which enables 2909 practitioners to design, evaluate, and build an appropriate architecture for the organization. The 2910 TOGAF Architecture Development Method (ADM) supports the TOGAF architecture 2911 development approach for architectures that meet business needs. TOGAF’s ADM prescribes 2912 methodology, not products, or modeling notation, and should be used with other architecture 2913 frameworks as appropriate. TOGAF evolved from the DoD Technical Architecture Framework 2914 for Information Management (TAFIM). DoDAF v2.0 and TOGAF both provide a practical, 2915 design agnostic method for creating enterprise architectures. The DoDAF v2.0 “Fit for 2916 Purpose” approach for developing views, presentations, or generated reports are based on 2917 TOGAF’s business, data, application, and technology views. 2918 2919 The latest version of TOGAF can be found at the Open Group Website: 2920 http://www.opengroup.org/architecture/togaf/ 2921 2922 12.1.4 The Ministry of Defense Architecture Framework (MODAF) 2923 2924 MODAF is based on the DoDAF version 1.0 baseline, which it represents through the MODAF 2925 Meta Model (M3). MODAF retains compatibility with US modeling initiatives, but is 2926 specifically designed to support architecture modeling for the UK Ministry of Defense (MOD) 2927 business. MODAF uses aspects of the existing DoDAF with additional viewpoints (acquisition, 2928 capability) that are required to support MOD processes, procedures, and organizational 2929 structures. The additional viewpoints provide a rigorous method for understanding, analyzing, 2930 and specifying capabilities, systems, System of Systems (SoS), business processes, and 2931 organizational structures. DoDAF v2.0 incorporates the data elements from MODAF required to 2932 support an acquisition and capability views in Version 2.0. 2933 2934 The latest version of the MODAF can be found at the MODAF Website: 2935 http://www.modaf.org.uk/ 2936 2937 12.1.5 NATO Architecture Framework (NAF) 2938 2939 The NAF provides the rules, guidance, and product descriptions for developing, presenting, and 2940 communicating architectures across NATO and other national boundaries. Earlier versions of 2941 NAF were tightly coupled to the DoDAF. NAF’s new features include a capability, service- 2942 oriented, and program view. DoDAF v2.0 has adopted the capability and program views 2943 described in NAF as defined by NAF. 2944 2945 The NATO Architecture Framework can be found at the NATO Website (Requires User 2946 Registration) 2947 2948 12.2 Other Reference Documents 2949 2950 12.2.1 DoD Information Enterprise Architecture Reference (DoD IEA) [Add in DoD IEA Info] 2951 TBD 90 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2952 APPENDIX A ACRONYMS 2953 2954 2955 2956 This is the integrated DoDAF v2.0 acronyms and their definitions. Some have more than one 2957 definition depending on their usage; they could have a specific meanings in Architecture as well 2958 as generic English language usage. 2959 2960 Term Definition A A&T Acquisition and Technology AIS Automated Information System Assistant Secretary of Defense for Command, Control, Communications, and ASD (C3I) Computer Systems Directorate, Joint Staff AV All Viewpoint B BMM Business Motivation Model BPMN Business Process Modeling Notation BPR Business Process Reengineering BRM Business Reference Model BT Business Transformation BTA Business Transportation Agency C CADM Core Architecture Data Model C3I Command, Control, Communications, and Intelligence Command, Control, Communications, Computers, Intelligence, Surveillance, C4ISR and Reconnaissance CDM Conceptual Data Model CCB Configuration Control Board CDM Conceptual Data Model CI Configuration Item CIO Chief Information Officer CJCS Chairman of the Joint Chiefs of Staff CJCSI Chairman of the Joint Chiefs of Staff Instruction CM Configuration Management COI Communities of Interest CPIC Capital Planning and Investment Control CPM Capability Portfolio Management CRM Consolidated Reference Model CV Capability Viewpoint CWID Coalition Warrior Interoperability Demonstration D DAES DoD Architecture Enterprise Services DARS Department of Defense Architecture Registry System DAS Defense Acquisition System DDMS DoD Discovery Metadata Specification DFD Data Flow Diagrams DIE DoD Information Enterprise A-1 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 Term Definition DIEA DoD Information Enterprise Architecture DISR DoD Information Technology Standards Registry DIV Data & Information Viewpoint DM2 DoDAF Meta-model DoD Department of Defense DoD EA DoD Enterprise Architecture DoD EA BRM DoD EA Business Reference Model DoDAF DoD Architecture Framework DODI Department of Defense Instruction Doctrine, Organization, Training, Material, Leadership and education, DOTMLPF Personnel, and Facilities DRM Data Reference Model E EA Enterprise Architecture EAAF Enterprise Architecture Assessment Framework EAMMF Enterprise Architecture Management Maturity Framework EIA Electronic Industries Alliance ES Enterprise Services F FEA Federal Enterprise Architecture FEA RM Federal Enterprise Architecture Reference Model FEAF Federal Enterprise Architecture Framework FIPS Federal Information Processing Standard G GAES GIG Architecture Enterprise Services GAO Government Accountability Office GIG Global Information Grid H I IDEF Integration Definition (IEEE) IDEF0 Integration Definition for Activity Modeling IDEF1X Integration Definition for Data Modeling IDEF3 Integration Definition for Process Description Capture ISO International Standards Organization IT Information Technology JCA Joint Capability Area JCIDS Joint Capabilities Integration and Development System JCS Joint Chief of Staff JFCOM US Joint Forces Command JP Joint Publication L LDM Logical Data Model LOB Line of Business M M3 MODAF Meta Model MOD Ministry of Defense (UK) MODAF Ministry of Defense Architecture Framework N NAF NATO Architecture Framework A-2 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 Term Definition Net-Centric NC Net Centric (JCA) NCDS Net-centric Data Strategy NCDSWG Net Centric Data Strategy Working Group NCE Net-Centric Environment NCES Net-Centric Enterprise Services NCO Net-Centric Operations NCOW Net-Centric Operations and Warfare NCOW RM Net-Centric Operations and Warfare Reference Model NII Networks and Information Integration NSS National Security Systems O OASD Office of the Assistant Secretary of Defense OMB Office of Management and Budget OOAD Object-Oriented Analysis & Design Technique OSD Office of the Secretary of Defense Office of the Secretary of Defense Networks and Information Integration OSD(NII) A&I Architectures and Integration OV Operational Viewpoint P PDA Personal Digital Assistant PDCA Plan, Do, Check, Act PDM Physical Data Model PEOs Program Executive Office PFD Process Flow Diagram PfM Portfolio Management PPBE Planning, Programming, Budgeting, and Execution PRM Performance Reference Model PTD Process Task Dependency PV Project Viewpoint Q QA Quality Assurance QC Quality Control R RM Reference Model S SADT Structured Analysis and Design Technique SE Systems Engineering SECDEF Secretary of Defense SEI Systems Engineering Institute SeV Systems Viewpoint SLC Shelf-Life Code SOA Service-Oriented Architecture SRM Service Component Reference Model SrV Service Viewpoint StdV Standards Viewpoint SUMO Suggested Upper Merged Ontology SysML Systems Modeling Language T A-3 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 Term Definition Technical Architecture ?? TA Tiered Accountability TAFIM Technical Architecture for Information management TOGAF The Open Group Architecture Framework TRM Technical Reference Model TSAT Transformational Communications Satellite TTP Tactics, Techniques, and Procedures TWG Technical Working Groups U UML Unified Modeling Language URL Uniform Resource Locator USD(AT&L) Under Secretary of Defense for Acquisition, Technology & Logistics USJFCOM United States Joint Forces Command V V&V Validation & Verification W WBS Work Breakdown Structure X XSD XML Schema Definition 2961 A-4 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2962 Appendix B Conceptual Data Model Definitions 2963 2964 Table B-1: Conceptual Data Model Definitions Class Definition Activity A discrete unit of work, not specific to a single organization, weapon system, or individual that transforms inputs into outputs or changes their state. Accuracy The nearness of an functional goal to the true value Agreement A consent among parties regarding the terms and conditions of activities that said parties participate in. Capacity The amount an object can hold, receive, or absorb. Capability Capability: (n) 1. The ability to execute a specified course of action. (JP 1-02) 2. The ability to achieve a desired effect under specified standards and conditions through combinations of means and ways to perform a set of tasks. (JCIDS) CapabilityConfiguration A combination of organizational aspects (with their competencies) and equipment that combine to provide a capability. Condition A statement of the values or states needed for the execution of an action. Constraint The range of permissible states for an object. Cost 1. Cost - financial: The price paid to acquire, produce, accomplish, or maintain anything. 2. Cost - general: The expenditure of something, such as time or labor, necessary for the attainment of a goal. Data Factual information used as a basis for processing, reasoning, discussion, calculation, or decision making by humans or machines. Dependability (SEI): Availability / Robustness, Reliability, Safety, Trustworthiness, Security Effect (JP 1-02) Effect: (n) the result, outcome, or consequence of an action [activity]. Event Something that happens at an instant in the world that causes a process to be launched. Facility Real property, having a specified use, consisting of one or more of the following: a building, structure, or linear structure. Facilities are parts of Sites, which are parts of Installations. ExchangeObject FunctionalDependency A constraint on or dependence of, an activity on one or more outside influences, conditions, activities, triggers or events. FunctionalStandard (ISE FS 200): Functional standards set forth rules, conditions, guidelines, and characteristics. GeoFeature An object that encompasses meteorological, geographic, and control features mission significance. Goal Goal: An end toward which long-term, ongoing effort is directed. Guidance An authoritative statement intended to lead or steer the execution of actions. Information An instance of knowledge or data that exists in any medium or form and can be communicated or received. Installation (DODI 4165.14): A base, camp, post, station, yard, center, or other activity, including leased facilities, under the jurisdiction, custody, or control of a Performer [the Secretary of Defense or the Secretary of a Military Department or, in the case of an activity in a foreign country, under the operational control of the Secretary of Defense or the Secretary of a Military Department], without regard to the duration of operational control. An installation may include one or more sites. Materiel Equipment, apparatus, or supplies that are of military interest, without distinction as to its application for administrative or combat purposes. Measure The magnitude of some attribute of an object. Means An action or system by which a result is brought about; a method Network An interconnected or interrelated chain, group, or system B-1 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 Class Definition Objective Objective: (n) the clearly defined, decisive, and attainable end toward which every operation is directed. An objective is a specific, time-targeted, measurable, and attainable target that an enterprise seeks to meet in order to achieve its goals. Organization An assemblage of people and other resources organized through an observable power hierarchy for an on-going purpose. Performer Any entity - human, automated, or any aggregation of human and/or automated - that performs a function, activity, or role, or provides a capability. PersonType(Personnel) A category of persons defined by the activity or activities they share. PerformerState A stage in a process of change or development. Plan (BMM Concept Catalog): Courses of Action are what the enterprise has decided to do. A Course of Action is more than simply a resource, skill, or competency that the enterprise can call upon. A Course of Action is a way of configuring some aspect of the enterprise (things, processes, locations, people, and time) to channel efforts towards Desired Results - the result of a decision by the enterprise about the best way to use its resources, skills, and competencies. A Course of Action defines what has to be done, not how well it has to be done. Measures of Performance are defined in Objectives that are supported by the Courses of Action. Definition: means that is an approach or plan for configuring some aspect of the enterprise involving things, processes, locations, people, timing, or motivation undertaken to achieve ends Note: Categories of course of action include: strategy, tactic. Dictionary Basis: a mode of action; “if you persist in that course you will surely fail”; “once a nation is embarked on a course of action it becomes extremely difficult for any retraction to take place” [www.dictionary.com]. Source: WordNet® 2.0 [ 'course of action']. Dictionary Basis: a chosen manner of conducting oneself: way of acting “our wisest course is to retreat” [MWCD 'course' (3b)]. In the Business Motivation Model, Courses of Action are categorized as Strategies and Tactics. The model does not make a hard distinction between the two. Enterprises define their own criteria. Project A planned action that represents a set of activities organized and managed to produce a specified product in a specified period of time with specified resources. (DDDS Counter (19607/1) (A)). Rate The ratio of the effective or useful output to the total input in any system. RealProperty (DODI 4165.14): Land and improvements to land (i.e., facilities), equipment affixed and built into the facility as an integral part of the facility heating systems), but not movable equipment (e.g., plant equipment, industrial buoys). In many instances this term is synonymous with real estate. Rule A prescriptive set of procedures regarding the execution of activities within an enterprise. Service Site (DODI 4165.14): Physical (geographic) location that is or was owned by, leased to, or otherwise possessed by a Performer [DoD Component]. Each site is assigned to a single installation. A site may exist in one of three forms: (1) Land only, where there are no facilities present and where the land consists of either a single land parcel or two or more contiguous land parcels. (2) Facility or facilities only, where the underlying land is neither owned nor controlled by the government. A stand-alone facility can be a site. If a facility is not a stand-alone facility, it must be assigned to a site. (3) Land and all the facilities thereon, where the land consists of either a single land parcel or two or more contiguous land parcels. SoftwareService Skill The ability, coming from one's knowledge, practice, aptitude, etc., to do something well. B-2 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 Class Definition Standard A ratified and peer-reviewed specification of allowed values for outputs inputs or processes. System System: Any organized assemblage of procedures and human and/or non-human resources united and regulated by interaction or interdependence to accomplish a set of specific functions. Task A action, activity or undertaking enabling missions, activities, or functions to be performed or accomplished. Technical Standard (ISE FS 200): Technical standards document specific technical methodologies and practices to design and implement. Timeliness The time from the occurrence of an event to the time required action occurs. Trigger Recommend Delete as Milestone is a type of Event and can either be sub classed or made an attribute of the class of event Vision Vision (n) An end that describes the future state of the enterprise, without regard to how it is to be achieved; a mental image of what the future will or could be like. Couple Individual A Thing that has spatio-temporal extent. Note - this may be some that existed in the past, exists now, or may exist in some future possible world. superSubType Extends couple. Thing The union of element, type, and tuples. Tuple Type wholePart Extends couple. A couple that asserts one (part) Individual is part of another (whole) Individual. TemporalType Sets of (and powersets based on) individuals that have temporal relations (time dimension before/after) with themselves or others over time. beforeAfter Extends couple. CalendarPeriod Country endBoundary GeoPoliticalArea GeoPoliticalAreaState overlapPart A wholePart that relates a ProperOverlap to the Individual of which it is a part. Region RegionOfCountry startBoundary temporalBoundary temporalWholePart A wholePart that asserts the spatial extent of the (whole) individual is co- extensive with the spatial extent of the (part) individual for a particular period of time. InterfaceType Sets of (and powersets based on) spatio/temporal individuals that can have a boundary (common spatio-temporal existence) with other individuals. Interface A common boundary or interconnection between systems, equipment, concepts, or human beings. 2965 B-3 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 2966 APPENDIX C REFERENCES/BIBLIOGRAPHY 2967 2968 Consolidated Reference used in this Volume 2969 2970 ANSI/GEIA Standard EIA 649-A National Consensus Standard for Configuration Management 2971 American National Standards Institute. This standard is available at: 2972 http://www.techstreet.com/cgi-bin/detail?product_id=1160265 2973 2974 Chairman of the Joint Chiefs of Staff (CJCS) Instruction 3170.01E, Joint Capabilities Integration and 2975 Development System (JCIDS), 11 May 2005. A copy of the current version of the instruction and 2976 its accompanying Manual can be found at: 2977 https://acc.dau.mil/CommunityBrowser.aspx?id=42776 2978 2979 Department of Defense Directive (DoDD) 5000.1, The Defense Acquisition System, 12 May 2003 2980 (certified current as of November 20, 2007). A current copy of the directive can be found at: 2981 https://akss.dau.mil/dag/DoD5000.asp?view=document&doc=2 2982 2983 Department of Defense Directive (DoDD) 8115.01, Information Technology Portfolio Management, 2984 October 10, 2005. Office of the Assistant Secretary of Defense (Networks & Information 2985 Integration)(NII)/DoD Chief Information Officer (DoD CIO). The latest copy of this directive 2986 can be found at: 2987 http://www.dtic.mil/whs/directives/corres/rtf/811501x.rtf 2988 2989 Department of Defense Instruction 4630.8, Procedures for Interoperability and Supportability of 2990 Information Technology (IT) and National Security Systems (NSS) 30 June 2004. Office of the 2991 Assistant Secretary of Defense (Networks & Information Integration) (NII)/ DoD Chief 2992 Information Officer (DoD CIO). The current version is found at: 2993 www.dtic.mil/whs/directives/corres/pdf/463008p.pdf 2994 2995 Department of Defense Instruction (DoDI) 5000.2., Operation of the Defense Acquisition System.(2003) 2996 Under-Secretary of Defense (Acquisition, technology & Logistics) (OUSD AT&L). A current 2997 copy of this document can be found at: 2998 https://akss.dau.mil/dag/DoD5000.asp?view=document&doc=2 2999 3000 Department of Defense Manual 8210-11-M, DoD Architecture Federation Manual, dated (DRAFT) 3001 XX-XX-200X Office of the Assistant Secretary of Defense (Networks and Information 3002 Integration) (NII)/ DoD Chief Information Officer (DoD CIO).. 3003 3004 Department of Defense Net-Centric Data Strategy, 9 May, 2003. Office of the Assistant Secretary of 3005 Defense (Networks & Information Integration) (NII)/DoD Chief Information Officer (DoD 3006 CIO). 3007 3008 DoD Acquisition Guidebook. Office of the Under-Secretary for Acquisition, Technology & 3009 Logistics (AT&L). A current copy of the Guidebook can be found at: 3010 https://akss.dau.mil/dag/DoD5000.asp?view=document&doc=2 C-1 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 3011 3012 Federal Enterprise Architecture (FEA). Executive Office of the President, Office of Management 3013 and Budget E-Gov Initiative. The current version of the FEA, and its associated reference 3014 models can be found at: http://www.whitehouse.gov/omb/egov/a-2-EAModelsNEW2.html 3015 3016 Federal Enterprise Architecture - Business Reference Model. The current version can be found at: 3017 http://www.whitehouse.gov/omb/egov/a-3-brm.html 3018 3019 Federal Enterprise Architecture Consolidated Reference Model Version 2.0. Executive office of the 3020 President, Office of Management and Budget (OMB). A current version can be found at: 3021 http://www.whitehouse.gov/omb/egov/documents/FEA_CRM_v20_Final_June_2006.pdf 3022 3023 Federal Enterprise Architecture Program: Enterprise Architecture Assessment Framework, version 2.2, 3024 October 2007. Executive Office of the President., Office of Management and Budget. The 3025 current version can be found at: http://www.whitehouse.gov/omb/egov/a-2- 3026 EAAssessment.html. 3027 3028 Federal Enterprise Architecture Records Management Profile, Version 1.0, December 15, 2005. 3029 Executive Office of the President., Office of Management and Budget. A current version of the 3030 profile can be found here: http://www.cio.gov/documents/RM_Profile_v1.pdf 3031 3032 Global Information Grid (GIG) Architecture Federation Strategy, 1 August 2007. Office of the 3033 Assistant Secretary of Defense (Networks & Information Integration) (NII)/DoD Chief 3034 Information Officer (DoD CIO). 3035 3036 Information Sharing Environment Enterprise Architecture Framework (DRAFT) June, 2008. Office of 3037 the Program Manager, Information Sharing Environment. 3038 3039 Integrated Defense Acquisition, Technology, & Logistics Life Cycle Management Framework (2005). 3040 Defense Acquisition University, Ft. Belvoir, VA. A current copy of the chart is found at: 3041 http://www.dau.mil/pubs/IDA/IDA_04.aspx 3042 3043 Intelligence Reform and Terrorism Prevention Act of 2004 (IRTPA), PL 108-458 (December 17, 3044 2004) 3045 3046 Ministry of Defense Architecture Framework (MODAF). Ministry of Defense of the United 3047 Kingdom. The latest electronic version of the MODAF can be found at the MODAF Website: 3048 http://www.modaf.org.uk/ . An offline (PDF) version can be accessed here for downloading: 3049 20081001-MODAF_Handbook_V1_2_003_Adobe6-U.pdf [5.51MB] 3050 3051 NATO Architecture Framework (NAF) for C3 Systems (2006). The North Atlantic Treaty 3052 Organization. The latest version of the NAF, and other associated documents can be found at 3053 the NATO Website 3054 http://194.7.80.153/website/book.asp?menuid=15&vs=0&page=volume2%2Fch02s02.html 3055 (Requires User Registration) C-2 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 3056 3057 Office of Management and Budget (OMB) Circular-A-130, Management of Federal Information 3058 Resources, February 8, 1996. Executive Office of the President., Office of Management and 3059 Budget. The current version can be found at: 3060 http://www.whitehouse.gov/omb/circulars/a130/a130trans4.html#2 3061 3062 The Open Group Architecture Framework (TOGAF), Version 8.11 The current version can be found 3063 at: http://www.opengroup.org/architecture/togaf/ 3064 3065 United States Government Accountability Office (GAO) Report: DoD Business Systems Modernization: 3066 Long-standing Weaknesses in Enterprise Architecture Development Need to Be Addressed, July 2005, 3067 GAO-05-702. A copy of the report is available at: http://www.gao.gov/new.items/d05702.pdf 3068 3069 United States Government Accountability Office (GAO) Report: Framework for Assessing and 3070 Improving Enterprise Architecture Management, version 1.1, April 2003, GAO-03-584G. A copy of 3071 the report is available at: www.gao.gov/new.items/d03584g.pdf 3072 3073 Zachman, John. Zachman Framework. © Zachman International. The Zachman Framework 3074 can be found at the Zachman International Website: 3075 http://zachmaninternational.com/index.php/the-zachman-framework/26-articles/13-the- 3076 zachman-framework-a-concise-definition 3077 3078 3079 Bibliography 3080 3081 Dinoli, D. (2008) Enterprise Architecture A to Z: Frameworks, Business Process Modeling, SOA, and 3082 Infrastructure Technology. Auerbach Publishing. 504pp. 3083 3084 Grigoriu, A. (2007) An Enterprise Architecture Framework. Privately Published 226.pp. 3085 3086 McGovern, J,, Ambler, S,, Stevens, M. E., Linn, J, Sharan, V & Jo, E. K. (2004) A Practical 3087 Guide to Enterprise Architecture. New Jersey: Prentice-Hall. 306pp. 3088 3089 Ross, J. W., Weill, P., & Robertson, D. C.(2006). Enterprise Architecture as Strategy. Boston, 3090 MA: Harvard Business School press. 235pp. 3091 3092 Ross, R. (2005). Business Rule Concepts (2nd. Ed.) Business Rules Forum. 135pp. 3093 3094 Ross, R. (2003). Principles of the Business Rule Approach. Boston, MA: Addison-Wesley 3095 Publishing. 372pp. 3096 3097 Schekkerman, Jaap (2004). How to Survive in the Jungle of Enterprise Architecture 3098 Frameworks. Victoria, BC: Trafford 222. pp. This volume is particularly valuable for its chart 3099 showing the evolution of architecture frameworks C-3 DRAFT Content is Pre-Decisional Material
  • Content is Pre-Decisional Material 24 Dec 08 Spiral 4 3100 3101 Spewak, Steven H (1992). Enterprise Architecture Planning. New York: John Wiley & Sons. 3102 368 pp. 3103 3104 3105 C-4 DRAFT Content is Pre-Decisional Material