GIG_Architecture.doc

1 DRAFT 1 2 3 Department of Defense 4 Enterprise Architecture Federation Strategy 5 6 7 8 9 10 11 12 13 14 15 Draft Version 1.01 16 04 December 2006 17 18 19 Prepared by the DoD CIO 2gigarchitecturedoc1917.doc 3 DRAFT

4 DRAFT 5 20 TABLE OF CONTENTS 21 221. Introduction..................................................................................................................1 23 Intended Audience......................................................................................................2 24 Background.................................................................................................................2 25 Related Guidance........................................................................................................4 262. Purpose.........................................................................................................................4 273. Vision............................................................................................................................4 284. Goals.............................................................................................................................4 295. Objectives.....................................................................................................................4 306. Benefits.........................................................................................................................5 31 Benefits to DoD Decision Makers..............................................................................5 32 Benefits to DoD Architects.........................................................................................6 33 Benefits to Architectural Governance Bodies.........................................................7 347. Guiding Principles ......................................................................................................7 358. Scope............................................................................................................................8 369. Federated EA Defined.................................................................................................8 3710. EA Federation Concepts ..........................................................................................9 38 The EA Federation.......................................................................................................9 39 Tiered Accountability..................................................................................................9 40 High-level Taxonomies.............................................................................................10 41 Architecture Categorization.....................................................................................10 42 Context.......................................................................................................................11 43 Boundaries for Tiers.................................................................................................11 44 Semantic Alignment..................................................................................................11 4511. EA Services — Making the EA Visible, Accessible, and Understandable.........12 46 Metadata.....................................................................................................................12 47 Registration...............................................................................................................13 48 Discovery...................................................................................................................13 4912. Governance..............................................................................................................14 50 EA Federation Roles and Responsibilities.............................................................15 51 Information Assurance.............................................................................................16 5213. Implementing the Federated EA ............................................................................16 53 Pilot Efforts................................................................................................................17 5414. Critical Success Factors.........................................................................................17 5515. The Way Ahead........................................................................................................18 56 APPENDIX A: ACRONYM LIST.....................................................................................1 57 APPENDIX B: DEFINITIONS..........................................................................................1 58 APPENDIX C: REFERENCE DOCUMENTS..................................................................1 59 APPENDIX D: RELATED GUIDANCE...........................................................................1 60 APPENDIX E: ARCHITECTURE CATEGORIZATION, STRUCTURE (TAXONOMY)..1 61 APPENDIX F: DOD FEDERATED EA GOVERNANCE DOCUMENT...........................1 62 APPENDIX G: A DETAILED LIST OF CRITICAL SUCCESS FACTORS (CSF) BY 63CSF CATEGORY..............................................................................................................1 64 APPENDIX H: ACTIVITY-BASED EA FEDERATION ALIGNMENT.............................1 65 66 6gigarchitecturedoc1917.doc ii 7 DRAFT

8 DRAFT 9 67 LIST OF FIGURES 68 69FIGURE 1: ARCHITECTURE LEVELS FOR TIERED ACCOUNTABILITY…………………………...10 70Figure 1 Architecture Levels for Tiered Accountability.............................................10 71Figure 2: Making Architecture Accessible.................................................................14 72Table 1: Roles and Responsibilities for Individual Levels of Federation...............15 73Figure E-1: Federated DoD EA Taxonomy...................................................................1 74Table E-1: Federated DoD and MA Taxonomy CM Authority.....................................1 75Figure H-1. Federation Relationships Among Activities............................................1 10gigarchitecturedoc1917.doc iii 11 DRAFT

12 DRAFT 13 761. Introduction 77 The Department of Defense (DoD) Federated Enterprise Architecture (EA) represents the 78“next generation” Global Information Grid (GIG) Architecture. 79 80 The current GIG Architecture, along with the Net-Centric Operations and Warfare 81Reference Model (NCOW RM) is an overarching architecture description of the GIG.1 82However, the DoD is too large and complex to be described within a single integrated 83architecture. Additionally, Enterprise architectures have an inherent problem. To fully describe 84an enterprise, architects must either abstract the content into simple constructs that don’t lend 85themselves to supporting a broad range of decisions, or they must compile massive amounts of 86data that make comprehension difficult at best. One of the primary objectives of enterprise 87architectures is to describe the enterprise so that decision makers can make informed decisions 88based on or within a common context. It will result in the development of a cohesive EA 89supporting the alignment and integration of architecture efforts in support of DoD business and 90warfighter strategic goals. Therefore, architects must constantly balance complexity with utility. 91The DoD GIG Architecture is no different. 92 93 What is required is a rethinking of the GIG architecture concept to effectively leverage 94current architecture efforts and maintain comprehension while, at the same time, providing DoD 95decision makers with the information they need. Federating existing architectures of DoD 96elements that describe the various echelons (or tiers) is one way to achieve this goal. Federation 97techniques allow disparate architectures (based on a variety of established frameworks) to be 98meaningfully related and permit acceleration of new architecture efforts across the DoD 99community to support DoD decision makers who require more detailed content that is not 100reasonable for the department level. 101 102 To date, there have been advancements in both the architecture and stakeholder 103communities that use architecture information. Architecture products, however, are presently not 104as sufficiently discoverable and accessible as needed to support decision making. Today’s 105architectures are built for specific purposes and viewpoints; they do not normally refer to or 106relate to each other as they should to gain maximum value from the architecture investment. 107 108 As a remedy, the Department has chosen architecture federation 2 as a new GIG architecture 109paradigm. The next generation GIG architecture will be constructed by federating the separate 110architecture artifacts throughout the DoD and employ a set of EA Services for registering, 141 The current DoD overarching architecture description consists of three Components: GIG Architecture ver 1.0, 15GIG Architecture ver 2.0, and the NCOW RM ver 1.1. The GIG Architecture consists of architecture products 16describing the DoD Enterprise from the perspective of five different scenarios. Version 1.0 described the “as-is” 17enterprise circa 2000; ver 2.0 describes the “to-be” enterprise circa 2015. While the NCOW RM is not an 18architecture itself it does establish the strategies and target technical standards for migration to a net-centric 19operating environment as the Department moves from the “as-is” to the “to-be”and therefore servs as a part of the 20Enterprise Architecture as defined by OMB for Clinger-Cohen compliance. 212 The concept of federation or “federalism” infers both a division of authority, accountability and interdependence 22between the Department level and the Commands, Services, and Agencies. See page 8 for full explanations of 23Federated EA and Federation Concepts. 24gigarchitecturedoc1917.doc 1 25 DRAFT

26 DRAFT 27 111discovering, and utilizing architecture data to support key DoD decision processes by 112implementing concepts from the DoD Net-Centric Strategies. 113Intended Audience 114 The primary audience for the DoD Federated Enterprise Architecture Strategy Document 115includes two distinct classes — first, those responsible for implementation of the Federated EA, 116and second, producers and consumers of architecture information, e.g., decision makers, program 117managers, analysts, operators, architects, and engineers within DoD and external partners in the 118extended enterprise. 119Background 120 The Director, Office of the Assistant Secretary of Defense for Networks and Information 121Integration, Architecture & Interoperability (OASD[NII/A&I]) has worked with the Services 122Chief Architects to define the federated approach. The federated approach will guide the 123building of the next generation GIG Architecture. This approach recognizes the need for 124autonomy but requires linkages and alignment of architectures from the Program level up to the 125Federal Enterprise level. OASD(NII) will introduce requirements in phases to achieve enterprise- 126wide GIG descriptions that move the Department toward a shared Net-Centric Vision and 127Transition Plan. These requirements are being identified and met through systems engineering 128processes that leverage architecture descriptions as blueprints. The use of shared architecture 129descriptions in Test & Evaluation processes within the federated approach will provide the 130ability to verify that capabilities are being fielded in accordance with (IAW) the GIG 131Architecture. 132 133 There are challenges related to institutionalizing architecture into DoD core processes. 134 135 Challenge 1: There is no comprehensive architectural description of the DoD Enterprise 136and its relationship between and among the entities that make up the enterprise that can be used 137to support department-level decision making. 138 139 Challenge 2: Architectures are currently developed independently by many organizations 140across DoD conforming to multiple frameworks. They are maintained in independent 141repositories, and we assume this mode of operation will continue. This situation, however, raises 142several concerns for architects and architecture end-users, specifically that there is no: 143 • Capability to globally search, vertically or horizontally, for architectures 144 and/or artifacts3 that may be relevant for analysis, reference, or reuse 145 • Consistent set of standards for architecture configuration management that 146 would enable users to determine the development status, quality, and authority 147 of data in various architectures and/or artifacts 148 • Standard methodology for specifying linkages between architectures 149 developed using different tools and maintained in independent repositories 150 required to provide enterprise-wide context and understanding 283 See Appendix B for a definition of “artifact.” Examples include: graphical models, structured models, tabular data, 29and structured or unstructured narratives. Individual artifacts may be aggregated. 30gigarchitecturedoc1917.doc 2 31 DRAFT

32 DRAFT 33 151 • Architecture alignment through linking will require standardization of 152 vocabularies and taxonomies. The lack of these standards will impede the 153 level to which an individual architecture artifact may be federated. This work 154 is currently being addressed with such efforts as Consolidated Operational 155 Activities List (COAL), and Consolidated Systems Function List (CSFL) and 156 Joint Command, Control, and Consultation Information Exchange Data Model 157 (JC3IEDM). 158 159 Based on these challenges, DoD needs to provide an enterprise wide architecture 160environment that will: 161 1. Improve the users’ ability to share information on architecture content. 162 2. Enable rapid access to actionable information to support strategic decisions; 163 and 164 3. Increase agility to address unforeseen requirements supporting warfighting 165 needs. 166 167 In the March 2005 National Defense Strategy, the DoD restated its commitment to 168making operations net-centric. The foundation for net-centric operations is to give users the 169ability to access the information and applications where and when needed. The key enabler of 170this ability is the DoD GIG. To move the GIG from Net-Centric concept to Net-Centric reality, 171the OASD(NII)/DoD Chief Information Officer (CIO) has established the following goals: 172 • Make information available on a network that people depend on and trust. 173 • Populate the network with new, dynamic sources of information to defeat the 174 enemy. 175 176 The DoD Net-Centric Data Strategy, May 2003, addressed the challenges of finding and 177using information on the GIG. The Data Strategy defined a vision in which information is easily 178made visible, accessible, and understandable. The draft GIG Enterprise Services Strategy 179espouses a dual path approach to achieving these goals. It advocates that DoD Components— 180Combatant Commands, Services, and Agencies (C/S/As)—continue to provide and consume 181services and embrace service-oriented architecture (SOA) principles (see Appendix B). In 182parallel, the GIG Enterprise Services Strategy drives the enterprise to identify and adopt the 183necessary services, standards, policies, and processes to federate C/S/As services and SOAs for 184the benefit of the Department and its partners. 185 186 This DoD EA Federation Strategy and associated EA Services apply the net-centric 187concept, Data Strategy, and GIG Enterprise Services Strategy to the DoD Enterprise architecture. 188A net-centric approach to Federated EA ensures that the Department has an accessible Enterprise 189Architecture with content derived from multiple sources. The intent of this Strategy is to enable 190cross-departmental discovery and use of architecture artifacts to support the Department’s 191decision makers in evolving and maintaining the enterprise information technology (IT) 192infrastructure in accordance with law and policy while maintaining autonomy for the owners of 193the architecture artifacts. 34gigarchitecturedoc1917.doc 3 35 DRAFT

36 DRAFT 37 194Related Guidance 195 Architecture requirements are solidly grounded in Law; the Clinger-Cohen Act assigned 196CIOs the responsibility for “developing, maintaining, and facilitating the implementation of a 197sound and integrated information technology architecture.” Additional details are provided in 198the Office of Management and Budget Circular A-130 and are expanded upon in guidance from 199the DoD and the Joint Staff (JS) regarding the development and use of architectures and their 200relationship to net-centric operations. Full details are provided in Appendix D of this Strategy. 2012. Purpose 202 The purpose of this Strategy is to present an agreed upon method and strategy to achieve a 203DoD Federated EA that would support decision makers in the DoD at the department level as 204well as the DOD Components and Programs. 205 206 After months of study, OASD, with participation from the JS and DoD Components, has 207determined that the best way to address the challenges presented above is to federate disparate 208architectures into a DoD-wide Federated EA. The DoD Federated EA would be constructed 209using a set of federation standards and Core Enterprise EA Services (registration, discovery, and 210translation services). 2113. Vision 212 The Federated EA vision is to provide DoD decision makers and their staffs’ access to a 213broader and deeper architecture data set that is available, accessible, understandable, trustworthy, 214and able to be tailored for decision support at the department and DoD Component levels. 2154. Goals 216 The challenges identified in the Background paragraph serve as the drivers for this 217Strategy. Their resolution can be found in the following goals necessary to achieve EA 218Federation: 219 1) An environment to support the decision makers and their staffs with access to a 220 set of common architecture artifacts enabling common understanding of the 221 DoD Enterprise that can be used to support DoD decision making at the 222 enterprise and DoD Component levels 223 2) A means to identify internal and external interfaces to the DoD Enterprise 224 3) Improved EA information sharing of architectural content, ensuring that users, 225 including unintended users, can find and use the right information 226 4) Increased agility that leverages existing architecture and/or artifacts to swiftly 227 adjust or expand their capabilities through architecture reuse and integration to 228 meet their changing mission and business needs 2295. Objectives 230 The following five objectives provide the focus for achieving the Goals identified above. 231Achievement of all is critical for success. 38gigarchitecturedoc1917.doc 4 39 DRAFT

40 DRAFT 41 232 A. Provide a structure for federating architectures to achieve the DoD EA and to 233 establish a means for autonomous development of DoD Component’s EA to support 234 tiered accountability. Related Goals: 1, 2, 3 235 B. Provide guidance for federating architectures to achieve the DoD Federated EA and to 236 establish a means to allow each DoD Component to build its Architecture within the 237 guidance given by the Enterprise to support tiered accountability. Related Goals: 1, 2, 238 4 239 C. Align DoD Component EA within a common framework of semantic 240 understanding .This common framework is based on the use of taxonomies from the 241 C/S/As and aligned with the Department level taxonomies to ensure that the DoD 242 Components can achieve standardization and semantic understanding with DoD 243 Component’s EAs. Related Goal: 1 244 D. Leverage Core Enterprise EA Services to provide Architecture Registration and 245 Discovery Services that are available, accessible, and usable by consumers within the 246 enterprise to share architecture information both vertically and horizontally throughout 247 and achieve information visibility in a coherent manner. Related Goals: 1,3,4 248 E. Provide a foundation to support emerging capabilities through Federated EA 249 services as a way of making the underlying business, mission, or transaction function in 250 a system or application available to a broad set of consumers. These services can be 251 easily reused and repurposed to provide building blocks for new capabilities. An 252 example of these services would be to provide specific analytic capabilities leveraging 253 EA holdings to support logistics, blue force tracking, and mission planning. Related 254 Goal: 3, 4 2556. Benefits 256 There are many benefits to be realized from implementing a Federated EA. The 257implementation of the Federated EA is intended to provide useful analytical information to 258various stakeholders within the DoD. Multiple benefits accrue as the DoD GIG is federated and 259progressively populated with widely sharable information and capabilities, which significantly 260boost operational efficiency and effectiveness. This section will identify many of the reasons and 261benefits and give a simple description or example of how they are used. These benefits are 262dependent on the degree and nature of the content provided by program and DoD Component 263architectures. 264Benefits to DoD Decision Makers 265 266Enables Rapid Access to Information for Strategic Decisions: 267 Access to actionable, relevant, decision quality, architecture information will accelerate the 268leaders’ ability to make better decisions that impact the enterprise (e.g., human resource 269capabilities; condition, status, and location of assets; and how funds are invested for the 270warfighting mission). The ability of the Federated EA to support these types of decisions is 271content dependent. 272 273Improves Information Sharing of Architecture Content: 42gigarchitecturedoc1917.doc 5 43 DRAFT

44 DRAFT 45 274 Populating the GIG with federated architecture products and leveraging Core Enterprise 275Services to provide EA discovery and search services ensures that architecture information can 276be accessed throughout the enterprise. Any user who has access to the GIG will be able to find 277and use information from any Web-enabled device. 278 279Understanding of Interactions and Interdependencies: 280 One of the primary uses of federation is to allow an Enterprise to understand the 281interactions and interdependencies among its component parts. DoD needs to understand the 282interactions among its major elements, the DoD Components, with the means to govern and 283manage the Department “cross-functionally” to realize a cost-effective, Net-Centric GIG. The 284Department recognizes that the exchanges among the domains are vital to modernizing the 285enterprise. By understanding the minimum set of exchanges required, the enterprise can reduce 286or eliminate unnecessary processes and the resources required to support those unnecessary 287processes. 288 289Supports Portfolio Management of Technology Options: 290 The Federated EA depicts the supporting technology and implementation as defined by the 291program and DoD Component’s architectures, for each activity within the enterprise. By 292evaluating the set of technologies across the Federated EA, the analyst or portfolio manager can 293gain an understanding of multiple uses of the same technology and multiple technologies applied 294to support the same type of activities. 295 296Supports the Joint Warfighting Capability of the DoD: 297 Joint military requirements are driving the need for greater commonality and integration of 298mission operations across the Department. The Department’s infrastructure must enable rapid 299response to the warfighting community and be compatible with the global, networked military it 300supports. 301 302Reduced Cost of Defense Operations: 303 Streamlining operations using Operational Architecture View data will enable decision 304makers to deal with growing pressures on resources and ensure every Defense dollar is optimally 305applied for long-term mission effectiveness. 306Benefits to DoD Architects 307 308Promotes Distributed Configuration Management: 309 Once the enterprise has federated its architecture, configuration management is reduced to 310two efforts: maintenance of the federation and configuration of enterprise artifacts. As part of 311the centralized control and decentralized execution of developing the enterprise architecture, the 312enterprise can very tightly manage the high-level taxonomies, the relationships with the DoD 313Component’s activities, and the enterprise list of instances for each. 314 315Provides Clear “stopping” rules for Enterprise Architecture Development: 316 When developing enterprise architectures, the greatest mistake comes from overstepping 317the scope of the department level description. No architect should ever develop details that are 318clearly in the purview of a lower-level tier. For example, the department level does not have the 46gigarchitecturedoc1917.doc 6 47 DRAFT

48 DRAFT 49 319authority or expertise to develop the details as well as the DoD Components. Once the 320relationship is established between high-level taxonomies and a DoD Component’s architecture 321artifact, the department level should then cease its examination of details and point to the DoD 322Components. The DoD Component maintains the responsibility and authority to detail the 323artifact and define how the enterprise achieves the goal. 324 325Increases Agility: 326 This benefit is the natural result of the use of Web-based services for registration and 327discovery, which are modular, reusable, interoperable building blocks. Users can search the 328Federated EA Registry and find existing architecture content, significantly reducing the time and 329cost for new architecture development, fielding of a new capability, and gaining improved 330interoperability “out of the box.” By using these building blocks, warfighters can swiftly adjust 331their architectures to meet changing business and mission needs. 332Benefits to Architectural Governance Bodies 333 334Sets Enterprise Boundaries: 335 A Federated EA with activity-based alignment shows each DoD Component’s activities 336and how they relate to achieving the enterprise’s goals. The relationships among the activities 337identify the activities that are “owned” or performed uniquely and those that are shared by one or 338more of the DoD Components. Once all the activities of the Enterprise are related to the 339activities of the DoD Components, then the collection of all activities owned by a single DoD 340Component sets boundaries throughout the Enterprise. Boundaries are vertical and horizontal 341start and stop points for accountability in the roles and responsibilities for Federated EA’s. 342 343Promotes Autonomy or Self-Governance: 344 A federated architecture supports a governance structure that defines the responsibility and 345authority among Components to achieve and support enterprise-wide goals. Once a DoD 346Component accepts its defined boundary, as depicted within the federated architecture, it enjoys 347autonomous control of the development and analysis of its architecture. The DoD Components 348determine the breadth and depth of detail relating to their individual architecture, and produce 349and archive the artifacts, as required, to meet or support the goals of the enterprise. 3507. Guiding Principles 351 In an effort to gain the most re-use out of existing architecture artifacts, and to minimize 352the need for additional architecture development, the development of the DoD EA Federation is 353guided by the principles below. The Federated EA will: 354 • Respect the diverse requirements of individual DoD Component while focusing 355 on the associations that cut across organizational boundaries IAW statutory 356 roles and responsibilities for the DoD Components. 357 • Focus on federating existing disparate architecture artifacts regardless of 358 structure and format – not re-building architectures. 359 • Maximize the reuse of existing architectures at all tiers. 50gigarchitecturedoc1917.doc 7 51 DRAFT

52 DRAFT 53 360 • Evolve from a product-centric approach (focused on DoDAF and other work 361 products produced by architecture developers) towards a data-centric 362 architecture approach focusing on common semantics. 363 • Support DoD’s net-centricity objectives (e.g., make information and services 364 visible, accessible, and understandable) and vision. 3658. Scope 366 This Strategy encompasses DoD architectures at all levels of detail and classification. It 367defines or references interfaces to architectures outside the Department under the Federal 368Enterprise Architecture Framework (FEAF) and the Federal Enterprise Architecture Reference 369Models.4 The GIG, a Federated EA, will not be isolated to IT but will have relevance for 370Doctrine, Organization, Training, Material, Leadership and education, Personnel, and Facilities 371(DOTMLPF), as the use and utility of architecture expand in those areas. 372 373 This Strategy is applicable to all DoD Mission Areas and addresses the relationships among 374all levels of enterprise details from the program/initiative level up to the Department level. This 375Strategy will: 376 • Define architecture federation and integration concepts. 377 • Define architecture alignment (linking and mapping) processes. 378 • Define EA Services for registering and discovery of architecture holdings and 379 associated metadata. 380 381 This Strategy will accommodate the range of architecture formats, methodologies, toolsets, 382and levels of abstraction, and will be applicable to multiple decision processes. 383 384 As part of this Strategy, Policy, Governance, and Implementation Planning documents will 385need to be defined and developed to support the vision and goals of this strategy. 3869. Federated EA Defined 387 We use the term Federated Architecture to represent the concept that architecture artifacts 388are related in a meaningful way. Federated Architectures conform to common or shared 389architecture standards across autonomous Program, DoD Component, Mission Area enabling 390developing/owning entities to maintain diversity and uniqueness, while providing opportunity for 391implementing interoperability.5 544 Federal Enterprise Architecture (FEA) Reference Models (RM) - The FEA is a tool used to align the DoD 55enterprise Architecture with the rest of the Federal Government’s Components. There are five Reference Models 56within the FEA: Performance Reference Model (PRM); Business Reference Model (BRM); System Reference 57Model (SRM); Technical Reference Model (TRM); and Data Reference Model (DRM). 58 59PRM – Identifies the performance measures of the enterprise 60BRM – Identifies the key activities of the enterprise 61SRM – Identifies the primary systems used within the enterprise 62TRM – Identifies the approved and emerging standards used within the enterprise 63DRM – Identifies the data and information used within the enterprise 64 655Adapted from New York State Office for Technology – see definitions 66gigarchitecturedoc1917.doc 8 67 DRAFT

68 DRAFT 69 392 393 A Federated Enterprise Architecture shows how a DoD Component aligns activities, 394services, systems, and infrastructure with federation standard taxonomies, providing context. 395Initially, EA federation will be based on semantic alignment of each Program, DoD Component, 396Mission Area, architecture’s top-level activity with the Enterprise’s top-level taxonomy of 397activities called the “High-level Taxonomy.” An example of “High-level Taxonomy” is the 398implementation of the BEA activity model which serves as the Business Mission Area’s 399(BMA’s) “High-level Taxonomy” for DoD Component alignment. Semantic Alignment will be 400based on the context6 of the architectures and the individual activities being related – for DoDAF 401architectures this is normally identified in the (OV-5). Semantic alignment of other architectural 402elements will be pursued, as needed, to support key decision processes and as other federation 403high-level taxonomies are developed. 404 405 Federated Architecture shows the allocation of responsibility across the Enterprise. In 406contrast, Integrated Architecture shows the interaction of multiple activities to achieve a mission 407or goal across the Enterprise. 408 409 Federation is a way to organize an enterprise’s body of knowledge (architecture) about its 410activities (processes), people, and things within a defined context and current/future 411environment. Federation provides the architect-analyst additional means to examine aspects of 412the DOTMLPF concepts across organizational boundaries. 41310.EA Federation Concepts 414The EA Federation 415 This section identifies key concepts that define the Federated Enterprise Architecture 416elements. These concepts are important to understanding Federation and how it is most useful in 417supporting decision making and Tiered Accountability. These concepts enable Department-wide 418producers and consumers to achieve the Goals and Objectives of a Federated EA. 419Tiered Accountability 420 Tiered accountability is distribution of authority and responsibility of an element of the 421enterprise architecture to an organization. Through the policy of Tiered Accountability (TA), 422DoD addresses the responsibility for producing these EA architecture artifacts. Under TA, DoD 423is currently defining and building enterprise-wide capabilities that include data standards, 424business rules, enabling systems, and an associated layer of interfaces for Enterprise, Mission 425Area, DoD Components, and Programs. Each tier of the enterprise – Department, Mission Area, 426DoD Components, and Program – has specific goals, as well as responsibilities to the tiers above 427or below them. 428 429 Each tier has full authority and responsibility to develop their portion of the EA. 430Unfortunately, data between tiers are often unavailable via an accurate, timely, and reliable 431method. In order to navigate through these tiers in a coherent way, and achieve information 432visibility, accessibility, and responsiveness, an organizing structure is needed. 706 See definition on page 10. 71gigarchitecturedoc1917.doc 9 72 DRAFT

73 DRAFT 74 433High-level Taxonomies 434 In the context of the Federated EA, a high-level taxonomy is a structure or model that 435spans the enterprise. At the highest level of the enterprise, the DoD Activity High-level 436Taxonomy7 sets the context for the alignment of the Mission Areas’ activities and associated 437reference models. At the DoD Component level, it is used to categorize and organize the DoD 438Component’s architectures to depict boundaries and provide context for federation. For the 439Federated EA, the Activity High-level Taxonomy will be the first High-level taxonomy 440produced. 441Architecture Categorization 442 DoD EA DoD Component’s architectures need to be categorized to facilitate alignment 443(mapping and linking), cataloging, navigating and searching disparate architecture in a DoD 444registry of holdings, and providing a framework for aligning architectures. This Strategy 445identifies four major levels of echelon and taxonomies to be used for categorization Figure x: 446 • Department (OSD, JCS, etc) 447 • DoD Mission Area (Warfighting, Business, DIMA, and EIE Mission Areas) 448 • DoD Component (Army, JFCOM, DLA, etc) 449 • Program (NECC, FCS, etc) 450 451 Department Mission Area Component Program 452 453 454 Figure 1 Architecture Levels for Tiered Accountability 455 456 Where possible, this should include identifying a common reference language8 or 457model applicable to the mission areas that can be used by all participating architectures. These 458top level taxonomies should be complemented by other architecture categorization schemes 757 The Business Reference Model (BRM) is the high-level Federated EA Activity Taxonomy. 768 As an example, for the BEA Materiel Visibility BEP, the (SFIS) provides a common reference for all DoD 77Logistics architectures. 78NOTE: This also complies with the guidance in DoD 4140.1-R, Paragraph C1.4.1.1, to use the SCOR processes of 79“Plan, Source, Maintain/Make, Deliver, and Return as a framework for developing, improving, and conducting 80materiel management activities to satisfy customer requirements developed collaboratively with the support 81providers.” 82 83gigarchitecturedoc1917.doc 10 84 DRAFT

85 DRAFT 86 459including Joint Capability Areas (JCAs), Joint Mission Areas (JMAs), Missions, Universal Joint 460Task List (UJTL), DoDAF product type, functional area, acquisition program, transformation 461architecture, and others, as appropriate. A full description of a proposed categorization scheme 462is in Appendix E. 463Context 464 Context defines the environment of the enterprise architecture. Five basic questions 465make up the Context and help to fully define the external environment of the enterprise. 466 467 1) What is the purpose of the architecture effort and what are the questions to 468 be addressed by this architecture effort? 469 2) What is the boundary of the enterprise? What is considered inside the 470 enterprise versus external? 471 3) What is the scope of the architecture effort, what are the echelons or 472 organizational levels involved, and what level of detail will be required in 473 the descriptions? 474 4) What is the viewpoint of the architecture? From who’s perspective do we 475 examine the enterprise and write the descriptions (external customer, 476 supplier, or casual observer; internal role player; or process owner)? 477 5) What echelons are represented by the architecture? 478 The Context should be defined before the architecture effort is begun and articulated 479within the AV-1. The context is part of the architecture’s metadata, which can be used for 480discovery, semantic alignment, and contextual comparison with other architecture efforts. 481Boundaries for Tiers 482 Each enterprise tier – Department, Mission Area, DoD Component, and Program – has 483specific goals, as well as responsibilities to the tiers above or below them that are used to 484determine the level of detail (or abstraction) necessary for their architecture. 485Semantic Alignment 486 487 A key goal of net-centricity is to enable semantic understanding of data so that 488interoperability can be achieved between any applications that have the ability to access and 489interpret the structural and semantic rules associated with data. 490 491 The Federated EA will be based on the semantic alignment of tier level architecture 492elements with elements of federation high-level taxonomies. Semantic alignment refers to the 493relationship specified between the meanings of taxonomy elements. The semantic relationships 494specified between activities will typically include “is equivalent to,” “is part of,” or “is similar 495to.” These relationships provide the alignment between the elements of DoD Component’s C/S/ 496As architectures and the high-level reference taxonomies that specify the interface points in the 497federation for tiered accountability of the Federated EA content. 498 499 Through Tiered Accountability, Stakeholders and the DoD Components will retain the 500authority to manage their own internal Architecture holdings, consistent with federation 87gigarchitecturedoc1917.doc 11 88 DRAFT

89 DRAFT 90 501standards or methodologies. However, the federated EA governance body at the appropriate tier 502will have responsibility for capturing semantic consistency out of the separate DoD Components 503and communities of interest/practice, defining the semantic (meaning) and syntactical (structure) 504standards that will provide for consistent usage and meaning. Where possible, external and 505industry standards will be considered for incorporation. Specifics on how semantic alignment 506can be achieved will be included in the Federated EA Implementation Plan. 50711.EA Services — Making the EA Visible, Accessible, and 508 Understandable 509 In order to make the EA visible, accessible, and understandable 9, EA Services will be 510implemented using Web Services, in which specific content and/or functionality is provided by 511one user for others, many of whom may be unanticipated by the provider (see Figure 1). The 512return on investment in the Federated EA will result from DoD providers continually populating 513the Federated EA with architecture data and products that satisfy a variety of anticipated and 514unanticipated consumer needs. This will require the following development of standards and 515services: 516 • A set of standard metadata will be maintained for all architectures in 517 confederating repositories and Web service specifications (Web service 518 definition language [WSDL]) for discovery and registration. 519 • A registration service will enable cataloging and linking of architectures in 520 federated repositories. 521 • A discovery service will enable users to execute a federated search for 522 architecture holdings meeting specified search parameters. 523 524The following paragraphs elaborate on those concepts. 525Metadata 526 To implement a Federated EA search service, metadata elements must be defined to 527capture attributes of artifacts required to support search parameters based on user needs. The 528DoD Discovery Metadata Specification (DDMS) V1.3 provides a baseline specification for 529architecture discovery metadata. The architecture conceptual model (currently the CADM) 530provides additional AV-1 discovery metadata specifications. Several new metadata elements, 531defined as “DDMS Plus” metadata, enable configuration management, architecture registration, 532and cataloging. 533 Data may be stored in any format using relational, object oriented, or hybrid 534technologies based on any kind of data model. These principles do, however, require that 535agreements be reached within the DoD EA Community of Interest (COI) or Community of 536Practice (COP) on the structure and semantics of data elements used for data asset discovery, 537linking, exchange, and integration. Metadata elements needed to support the EA user services 538described herein are defined and proposed for DoD EA COI/COP acceptance as the standard for 539net-centric federated EA services. 919 Visible, Accessible, and Understandable are key Net-Centric concepts from the NCOW RM v1.1 as integrated 92from the Net-Centric Strategies. 93gigarchitecturedoc1917.doc 12 94 DRAFT

95 DRAFT 96 540Registration 541 Federation repositories will capture all architecture metadata for architectures 542developed in local environments. Federation repository owners will be responsible for 543implementing mechanisms to collect metadata specifics on the implementation of Registration, 544including specific metadata requirements, which will be contained in the Federated EA Services 545Implementation Plan. 546Discovery 547 The Federated EA will include a federated metadata discovery capability. The intent is 548to provide a user-friendly service that enables discovery of architecture metadata available from 549federated repositories. Federated repositories are achieved when sources of similar content can 550be searched via enterprise services. It will also enable the user to follow links to the source 551architectures in the federated repositories. Specifics on the implementation of this tool will be 552contained in the Federated EA Services Implementation Guidance Document. 553 The following sections address the two primary modes of discovery, registry browsing 554and searching. 555 556Registry Browsing: 557 Users may browse a catalog of holdings for Federated EA repositories to find artifacts of 558interest. Cataloging of repository holdings should enable users to search for artifacts by 559navigating categorization taxonomies similar to browsing item categorizations in online 560shopping Web sites. Multiple categorizations may apply to any single architecture. Catalog 561navigation trees should use standardized category names from “approved” enterprise 562taxonomies, when available, and may be extended by domain extensions where needed. 563Navigation trees should provide links to detailed metadata on architecture holdings to enable 564users to determine potential interest value and include links to the products in source repositories 565to enable user access to selected products. 566 567Searching: 568 An architecture search capability must enable a user to specify a set of criteria for 569architecture artifacts of interest. A single search interface using that set of search criteria needs 570to be able to reach all architecture data repositories and present a consolidated response to the 571user. The consolidated response, at a minimum, should: 572 • Provide sufficient metadata on holdings, so that users can ascertain their 573 relevance. 574 • Provide links to the results, taking the user to the source repository consistent 575 with the user’s role-based access privileges. 576 • Include all available architecture metadata, including metadata not specified as 577 search parameters. 578 Figure 2 illustrates the concept for the proposed Core Enterprise EA Services/DARS 579implementation for the DoD Federated EA Services. It illustrates metadata registration and 97gigarchitecturedoc1917.doc 13 98 DRAFT

99 DRAFT 100 580discovery of architecture content within the federated repositories required to make the enterprise 581architecture data visible, accessible, and understandable for the DoD community. 582 583 Architecture COI Vision Federation Federation Reporting (OMB, GAO, etc) Reporting (OMB, GAO, etc) Strategy Strategy Architecture COI DoD EA RM DARS CADM •DoDAF •NCOW RM MILDEP COCOM AGENCY CO CO I yy I Ix x CO I CO REQTS. DATA REQTS. DATA DoD Decision Processes DoD Decision Processes 584 Figure 2: Making Architecture Accessible 58512.Governance 586 Since the Federated EA is not a unitary architecture, it will require a governance structure 587to provide direction and oversight within the framework of TA and the existing DoD and DoD 588Component governance structures. The DoD CIO, or the CIO’s delegate, will serve as the 589ultimate chairperson for management of the Federated EA. However, due to the complex 590relationships between the architecture producers/developers at various levels, the governance 591roles within the Federated EA will vary according to roles within Tiered Accountability. 592 1) At the Enterprise or OASD/JS-level, governance will address DoD-wide 593 Authority, Direction, Guidance, Monitoring, and Affirmation/Remediation. 594 2) At the Mission Area-level, governance will address Implementation, 595 Monitoring, and Affirmation/Remediation in response to DoD-wide guidance as 596 well as Mission Area unique Authority, Direction, and Guidance. 597 3) Similarly, the DoD Component-level, governance will address Implementation, 598 Monitoring, and Affirmation/Remediation in response to DoD-wide guidance 599 and Mission Area input, as well as individual DoD Component requirements for 600 Authority, Direction, and Guidance. 601 602 The details for governance will be provided in a separate document, the planned DoD 603Federated EA Governance Document. It will address areas such as: 101gigarchitecturedoc1917.doc 14 102 DRAFT

103 DRAFT 104 604 605  Charter Development/Approval  Services  Roles and Responsibilities  Quality  Organizational Framework  Compliance  Resource Requirements and Responsibilities  Maturity Models  Policies  Synchronization  Metrics  Repositories  Incentives  Security/Access  Data Management  Accreditation  Standards  External Relationships 606 A tentative outline for Governance is provided in Appendix F. 607EA Federation Roles and Responsibilities 608 This Federation Strategy is in accordance with DoD 8320.2-G, DoD Guidance for 609Implementing Net-Centric Data Sharing by enforcing Tiered Accountability, whereby each tier, 610or level, of the federation is responsible for managing its own architectures and data while also 611making those architectures and data visible, accessible, and understandable to other members of 612the federation. The Federation Strategy seeks to operationalize Tiered Accountability. 613 Each Tier has both internal and external roles and responsibilities that it must perform 614to make the Federated EA function as intended. These are presented in Table 1, where external 615roles and responsibilities are denoted with a star (*) and internal roles and responsibilities are 616denoted with a square (■). 617 618 Table 1: Roles and Responsibilities for Individual Levels of Federation Department  Impose constraints on federated Mission Areas,  Establish a governance structure for the DoD DoD Components, and Programs in order to EA Federation. achieve cross-federation.  Develop and maintain the environment in which the Federated EA is developed and  Add or remove information from the DoD maintained. Federated EA as appropriate via the various  Create, publish, and administer the high-level feedback loops outlined in the Implementation Discovery and Registration Services. Plan.  Store, publish, and maintain federation  Develop top-level taxonomies and mapping “links” to enable traceability through categorization schemes in order to ensure that each tier and across the Department Level. Mission Areas, DoD Components and  Create and manage the DoD EA RMs. Program architectures can align in a meaningful way. Mission Area  Impose constraints on the DoD Components  Provide configuration management (CM) to and Programs in order to achieve Mission Area DoD Components’ taxonomies by MA. (MA) goals and support interoperability  Provide content to taxonomies and 105gigarchitecturedoc1917.doc 15 106 DRAFT

107 DRAFT 108 between mission areas. categorization schemes utilized for the DoD  Develop and maintain MA enterprise Federated EA. architectures and mapping results.  Report changes in content for DoD EA Federation, as necessary. 619 DoD Components and Enterprise Programs  Impose constraints on DoD Components’  Provide CM to domain taxonomies. Programs in order to achieve the DoD  Use the taxonomies and categorization Components’ goals and support cross-DoD schemes provided by the MA levels to map its interoperability. architectures to the DoD EA.  Make the DoD Components’ architecture  Manage its enterprise architecture to support its and mapping results visible, accessible, and mission and vision. understandable.  Propose modifications to the DoD EA to  Adhere to the standards for data sharing increase/improve alignment between tiers. established by the Enterprise and MAs.  Develop and maintain theDoD Components’  Ensure that the DoD Components’ Program enterprise architectures. architectures and mapping results are visible,  Extend high-level taxonomies. accessible, and understandable.  Implement the discovery services within the  Support metadata development. DoD Components’ environments. DoD Component Program’s  Maintain Program architecture element names  Map to the taxonomies and categorization and definitions. schemes provided by the DoD Components  Propose modifications to the DoD EA to as appropriate. increase/improve alignment between tiers.  Make the Programs’ architecture and mapping results visible, accessible, and understandable.  Develop and maintain the Programs’  Adhere to the standards for data sharing architecture and mapping results. established by the Enterprise, MAs, and DoD  Extend high-level taxonomies. Components. 620 621 Additional roles and responsibilities will be identified, as required, within the Governance 622Document. Detailed roles and responsibilities specific to each level will be outlined in the DoD 623EA Federation Implementation Plan. 624Information Assurance 625 This Strategy will embrace information assurance concepts and principles and other 626DoD guidance, as appropriate. This is to ensure the integrity of the information across the 627Federated EA that’s required to support the goals of visibility, accessibility, understandability, 628and trustability (through metadata tagging of artifacts). 62913.Implementing the Federated EA 630 As an integral part of this Strategy, a detailed Implementation Plan will be provided as a 631separate document. 109gigarchitecturedoc1917.doc 16 110 DRAFT

111 DRAFT 112 632Pilot Efforts 633 There are two primary areas of interest for Proof-of-Concept (PoC) Pilot efforts. One is 634to build and analyze a Federated EA using the DoD High-level Activity Taxonomy, a Mission 635Area Taxonomy, and DoD Components’ architecture. The other is to build and demonstrate EA 636Services with an initial focusing on Registration and Discovery Services. 637Enterprise Federation – Federated EA Pilot 638 The first pilot will build and analyze a Federated EA using the DoD High-level Activity 639Taxonomy, Mission Area Taxonomy, and DoD Components’ architecture. OASD(NII) and the 640EA Summit are currently evaluating candidates for this pilot. 641EA Services — The DARS Pilot for Registration and Discovery 642 For the second pilot – registration and discovery capabilities – EA Registration and 643Discovery Services will be implemented initially as Core Enterprise EA Services in DARS and a 644selected set of federated repositories. These capabilities will then be federated to other DoD 645Components’ repositories, resulting in a more robust department-level capability. Using this 646federated capability, a search request on one repository, e.g., DARS, will result in a returned set 647of records matching the search criteria and will contain as much of the architecture metadata as is 648available from each of the federated repositories having holdings that match the search criteria. 649URLs in the reply metadata set will provide links to the source architectures in the federated 650repositories. 651 An architecture search capability should enable a user to specify a set of criteria for 652architecture artifacts of interest. Users should be able to specify specific search criteria in a 653search GUI using methods such as pick lists for the allowable values for each of the criteria. 654That set of search criteria needs to be propagated to all architecture data repositories. The user 655then needs to receive a single consolidated response that: 656 • Provides consistent metadata from all sources 657 • Provides sufficient metadata to enable the user to ascertain their relevance 658 • Provides links to the sources 659 Once a user determines which architecture artifacts are of interest, a link associated with 660each result will take the user to the source repository. Depending on the security policy of the 661source repository, the link may either provide direct access to the selected artifact in the native 662repository format or visualization environment, or, in future versions; it may direct the user to a 663role subscription service on the native repository for requesting access to the product. User 664credentials may also be passed by the search service to the source repository for authentication to 665enable automated access based on access roles/privileges associated with the user in the source 666repository. 66714.Critical Success Factors 668 A review of the business and warfighting mission drivers/needs (with respect to their 669information needs), at an enterprise, i.e., joint level, reveals the high degree of cooperation and 670participation needed for federating the disparate architectures across the entire DoD, including 671alignment of external organizations and agencies in support of strategic, joint decision making. 113gigarchitecturedoc1917.doc 17 114 DRAFT

115 DRAFT 116 672 Following is a list of broad categories of candidate Critical Success Factors (CSF) related 673to the institutionalizing of a DoD Federated Architecture environment. The broad CSF 674categories are: 675 • Required commitment by OSD, JS, and DoD DoD Components for participation 676 in the FJAWG, 677 • Adoption and implementation by OSD, JS, and DoD DoD Component s for 678 architecture governance, registration, high-level taxonomies, federation levels, 679 roles and responsibilities, federation methodologies, etc. 680 • Selection and successful implementation of a PoC Pilot in order to validate EA 681 Federation concepts, governance, methods, tools, high-level taxonomies, etc. 682 • Linking Business and Warfighting mission drivers/needs. 683 • Commitment of resources at OSD, JS, and DoD DoD Components to support 684 federation development and implementation. 685 • Adoption of DARS as the Federated EA Registry. 686 687 Appendix G contains a detailed list of CSFs within each category. 68815.The Way Ahead 689 To begin implementation of this Strategy: 690 • OSD Leadership, working with the DoD Components and other stakeholders, 691 will articulate details required for implementation. 692 • Registry and repository owners will work with the registry pilot lead on 693 federating discovery services. 694 • FJAWG as the EA Summit arm will complete the development of the high-level 695 activity taxonomies. 696 • The community will define how linkages are managed between the Tiers in the 697 Federation. 698 • DARS will implement the linkages between the Tiers in accordance with the 699 community requirements as a community extension to Core Enterprise EA 700 Services for EA. 701 • Mission Area Leads will define their high-level taxonomies for inclusion in the 702 DoD EA Reference Models. 117gigarchitecturedoc1917.doc 18 118 DRAFT

119 DRAFT 120 703 APPENDIX A: ACRONYM LIST 704 ACAT Acquisition Category ACCB Architecture Configuration Control Board BEA Business Enterprise Architecture BMA Business Mission Area BRM Business Reference Model BTA Business Transformation Area C/S/A Command/Service/Agency CADM Core Architecture Data Model CCB Configuration Control Board CIO Chief Information Officer CJCS Chairman of the Joint Chiefs of Staff CJCSI CJCS Instruction CM Configuration Management COAL Consolidated Operational Activities List COI Community of Interest COP Community of Practice COTS Commercial Off The Shelf C/S/As Combatant Commands, Services, and Agencies CSF Critical Success Factors CSFL Consolidated Systems Function List DARS DoD Architecture Registry System DDMS DoD Discovery Metadata Specification DIA Defense Intelligence Agency DoD Department of Defense DODD DoD Directive DODI DoD Instruction DOTMLPF Doctrine, Organization, Training, Material, Leadership and education, Personnel, and Facilities DRM Data Reference Model EA Enterprise Architecture EIE Enterprise Information Environment FCB Functional Control Board FEAF Federal Enterprise Architecture Framework FJAWG Federated Joint Architecture Working Group GIG Global Information Grid GOTS Government Off The Shelf IT Information Technology JCA Joint Capability Area JC3IEDM Joint Consultation Command and Control Information Exchange Data Model JCS Joint Chiefs of Staff JMA Joint Mission Area JS Joint Staff 121gigarchitecturedoc1917.doc A-1 122 DRAFT

123 DRAFT 124 MA Mission Area NCOW Net Centric Operations and Warfare OASD Office of the Assistant Secretary of Defense PoC Proof of Concept PRM Performance Reference Model RM Reference Model SFIS SOA Service Oriented Architecture SRM System Reference Model TA Tiered Accountability TRM Technical Reference Model UJTL Universal Joint Task List WSDL Web Service Definition Language 705 125gigarchitecturedoc1917.doc A-2 126 DRAFT

127 DRAFT 128 706 APPENDIX B: DEFINITIONS 707 708Architecture: 709Architecture is the structure of components, their interrelationships, and the principles and 710guidelines governing their design and evolution over time. [CIO Council, A Practical Guide to Federal 711Enterprise Architecture, February 2001] 712 713Architecture Integration: 714Architecture Integration is the process of consolidating the content of disparate architectures to 715support analyses of a broader scope than that possible with any single disparate architecture. 716Architecture integration includes the mapping or standardization of terms and definitions across 717disparate architectures and the integration results in a set of data and products that support Joint 718operations and development efforts. [DoD Federated Joint Architecture Working Group (FJAWG) 719recommendation, Dec 2005] 720 721Artifact: 722An abstract representation of some aspect of an existing or to-be-built system, component, or 723view. Examples of individual artifacts are a graphical model, structured model, tabular data, and 724structured or unstructured narrative. Individual artifacts may be aggregated. [US Department of 725Agriculture Office of the CIO, http://www.ocio.usda.gov/e_arch/glossary.html] 726 727High-level (Adj.): 728For purposes of this Strategy, the phrase “high-level” is used as an adjective representing the 729highest-level structure within an enterprise, mission area, or DoD Components providing context 730and guidance for all lower levels. It is used primarily as a modifier to another term “taxonomy” 731to represent highest-level structure within an echelon shown above. 732 733Core Enterprise EA Services: 734Core Enterprise Services are IT services that provide the foundation for DoD service and data 735providers by delivering and managing the underlying capabilities from which communities build 736and receive the services they need to meet their business and information processing needs. For 737EA, the initial IT services that support the registration and discovery of architectural artifacts, 738architectures, or products will be developed. Additional anticipated services include translation 739services that ensure artifacts, architectures, or products are understandable between DARS and 740other architectural repositories. 741 742Discovery: 743The act of locating a machine-processable description of a Web service-related resource that may 744have been previously unknown and that meets certain functional criteria. It involves matching a 745set of functional and other criteria with a set of resource descriptions. The goal is to find an 746appropriate Web service-related resource. [Web Services Glossary, W3C Working Group Note 11 February 7472004] 748 749Discovery Service: 750A discovery service is a service that enables agents to retrieve Web services-related resource 751description. [Web Services Glossary,W3C Working Group Note 11 February 2004] 129gigarchitecturedoc1917.doc B-1 130 DRAFT

131 DRAFT 132 752 753Enterprise: 754Enterprise is an organization (or cross-organizational entity) supporting a defined business scope 755and mission. An enterprise includes interdependent resources (people, organizations, and 756technology) that must coordinate their functions and share information in support of a common 757mission (or set of related missions). [CIO Council, A Practical Guide to Federal Enterprise Architecture, 758February 2001] 759 760Federated Architecture: 761Federated architectures define common or shared architecture standards across autonomous 762program areas, enabling state government entities to maintain diversity and uniqueness, while 763providing interoperability. [New York State Office for Technology http://www.oft.state.ny.us/arcPolicy/policy/ 764glossary.htm] 765 766An Architecture Federation is a framework for enterprise architecture development, maintenance 767and use that links, locates, and aggregates disparate architectures and architecture information. 768A federated architecture approach recognizes the uniqueness and specific purpose of disparate 769architectures, and allows for their autonomy and local governance, while enabling the enterprise 770to benefit from their content. [DoD FJAWG recommendation, Dec 2005] 771 772Federated Architectures: Separate, Distinct, Individual Architectures: 773Separate architectures were built under different contexts but may be aligned within an 774overarching scope and boundary, viewed from a common point of view, for a common purpose, 775and a specified set of questions to be addressed by the resulting federated architecture. [DoD 776FJAWG recommendation, Dec 2005] 777 778Services: 779A mechanism to enable access to one or more capabilities, where the access is provided using a 780prescribed interface and is exercised consistent with constraints and policies as specified by the 781service description. [From the GIG Enterprise Services Strategy, Oct 2006] 782 783Service-Oriented Architecture and SOA Principles: 784 785SOA is a paradigm for organizing and utilizing distributed capabilities that may be under the 786control of different ownership domains. It represents a collection of services on a network that 787communicate with one another. It is any architecture that can be decomposed, on a logical level, 788into three categories of components: a service, a provider of the service, and a consumer of the 789service. SOA addresses three roles and three operations. The three roles are the service producer 790(provider), the service consumer (requester), and the service registry The objects acted upon are 791the service and the service description, and the operations performed on these objects are 792publish, find, and bind. Within industry and DoD the concept and service principles are evolving 793as we gain experience with SOA. Some general service-oriented principals are: discoverable, 794accessible, and dynamically bound; enable interoperability; are loosely coupled; have a network 795addressable interface; are location transparent; and are not bound to specific systems. [NCOW RM 796v1.2 (draft)] 797 798 133gigarchitecturedoc1917.doc B-2 134 DRAFT

135 DRAFT 136 799Service Registry or Registry Service: 800Is a platform neutral, network based directory that stores information about services and is 801searchable based on the descriptive metadata defined in the service specification. [DoDAF Version 8021.5 Vol 2 Oct 2006] 803 804 805 137gigarchitecturedoc1917.doc B-3 138 DRAFT

139 DRAFT 140 806 APPENDIX C: REFERENCE DOCUMENTS 807 808 809A Practical Guide to Federal Enterprise Architecture, CIO Council, February 2001. 810 811BMA – Federation Strategy and Roadmap [Working Draft], Business Transformation Agency, 81228 August 2006. 813 814Concepts of Enterprise Architecture: Federating Components of an Enterprise Architecture, 815Draft MITRE Corporation Paper for SAF/XCXA, 6 September 2006. 816 817Department of Defense Chief Information Officer Memorandum, "DoD Net-Centric Data 818Strategy," May 9, 2003. 819DoD Architecture Framework, Version 1.0, 9 February 2004. 820 821DoD Directive 8100.1, "Global Information Grid (GIG) Overarching Policy," September 19, 8222002. 823DoD Federated Joint Architecture Working Group (FJAWG) Internal Working Papers, 824December 2005-Present. 825 826DoD Net Centric Spectrum Management Strategy, OASD (NII), 25 April 2005. 827 828Federated Architectures, Enterprise Integration Inc., 2005. 829 830Global Information Grid Enterprise Services Strategy, Working Draft, OASD(NII) CIO, Oct 8312006. 832 833http://www.ocio.usda.gov/e_arch/glossary.html, U.S. Department of Agriculture Office of the 834CIO. 835 836http://www.oft.state.ny.us/arcPolicy/policy/glossary.htm, New York State Office for 837Technology. 838 839National Defense Strategy of the United States of America, March 2005. 840 841The “Net-Centric Operations and Warfare Reference Model, OASD (NII)”, 17 Nov 2005. 842 843“Joint Concept of Operations for Global Information Grid NETOPS version 2.0”, 844USSTRATCOM, 10 Aug 2005 845 141gigarchitecturedoc1917.doc C-1 142 DRAFT

143 DRAFT 144 846 APPENDIX D: RELATED GUIDANCE 847 848 Architecture requirements are solidly grounded in Law; the Clinger-Cohen Act assigned 849Chief Information Officers the responsibility for “developing, maintaining, and facilitating the 850implementation of a sound and integrated information technology architecture.” Additional 851details are provided in Office of Management and Budget Circular A-130. The Circular 852establishes an Enterprise Architecture (replacing the term “information technology architecture”) 853as consisting of the following elements: business processes, information flows, data 854descriptions, applications, technology infrastructure, and standards. The Circular also establishes 855the requirement for the EA to be incorporated in the Executive Agency’s Capital Planning and 856Investment Control Process. 857 858 DoD prescribes the DoDAF version 1.0 (DoDAF) as the basis for DoD developing 859architecture descriptions. DoDAF-based architecture descriptions are required in many of the 860Department’s major processes; these descriptions are also required to be consistent with the GIG 861Architecture and NCOW RM. The following policies require the development of architecture 862descriptions: 863 • CJCSI 3170.01E, Joint Capabilities Integration and Development System 864 • CJCSI 6212.01D, Interoperability and Supportability of Information 865 Technology and National Security Systems 866 • DoDD 5000.1, The Defense Acquisition System 867 • DoDI 5000.2, Operation of the Defense Acquisition System 868 • DoDD 4630.5, Interoperability and Supportability of Information Technology 869 and National Security Systems 870 • DoDI 4630.8, Procedures for Interoperability and Supportability of Information 871 Technology and National Security Systems 872 • DoDD 8000.1, Management of DoD Information Resources and Information 873 Technology 874 • DoDD 8115.1, Information Technology Portfolio Management 875 876 These policies are enforced through processes that include assessments of compliance with 877applicable architectures. DoDI 5000.2, for example, includes requirements for Clinger-Cohen 878Compliance. One of the compliance criteria requires that acquisitions are “consistent with the 879Global Information Grid policies and architecture, to include relevant standards.” The DoD CIO 880as well as the DoD Component CIO’s assess lower Acquisition Category (ACAT) programs. 881 The development of a DoD Federated EA will be conducted in accordance with both DoD 882and Federal policy on the development and use of Enterprise Architectures. The approach to 883federation described herein shall closely follow DoD policy and directives on net-centric data 884management. The following net-centric references are applicable: 885 • DoD CIO Memorandum, DoD Net-Centric Data Strategies: 886 – Net-Centric Data 887 – Shared Services 888 – Information Assurance 145gigarchitecturedoc1917.doc D-1 146 DRAFT

147 DRAFT 148 889 – Spectrum 890 – Networking 891 – Computing Infrastructure 892 • DoD Directive 8320.2, Data Sharing in a Net-Centric Department of Defense 893 • Federal Enterprise Architecture Program, EA Assessment Framework 2.0 894 • Federal Enterprise Architecture Program, Data Reference Model 2.0 895 Key net-centric principles that must be adhered to are that data assets must be made visible, 896accessible, understandable, and trusted (when referring to IA), and they must be enabled to 897support interoperability. These principles do not assume or prescribe any requirements for 898physical data storage. Data may be stored in any format using relational, object oriented, or 899hybrid technologies based on any kind of data model. These principles do, however, require that 900agreements be reached within the DoD EA Community of Interest (COI) or Community of 901Practice (COP) on the structure and semantics of data elements used for data asset discovery, 902linking, exchange, and integration. Metadata elements needed to support the EA user services 903described herein are defined and proposed for DoD EA COI/COP acceptance as the standard for 904net-centric federated EA services. 149gigarchitecturedoc1917.doc D-2 150 DRAFT

151 DRAFT 152 905 APPENDIX E: ARCHITECTURE CATEGORIZATION, 906 STRUCTURE (TAXONOMY) 907 908 The top level of the DoD Federated EA taxonomy will initially consist of the four DoD 909Business Reference Model (BRM) Mission Areas (MAs) [see Figure E-1] and be coordinated by 910a federated DoD EA control board. 911 912 Federated DoD EA Control Board EIE Warfighter Business Intel EIE MA MA MA MA MA Managed by MA Authority Service Agency COCOM Subordinate architectures -level by mapped to MA Components 913 Figure E-1: Federated DoD EA Taxonomy 914 Table E-1 identifies MA Taxonomy Configuration Management (CM) Authorities that will 915have autonomy for defining and managing a core set of taxonomy elements for each MA. 916Mission area taxonomies should be derived from MA activity decomposition and synchronized 917with the DoD BRM. 918 Table E-1: Federated DoD and MA Taxonomy CM Authority Taxonomy Content BRM Mission Area Decomposition Basis CM Authority Warfighting JS FCBs/JCAs Business BTA BEA (TBD) Intelligence DIA DoD BRM for Intel Enterprise Information Environment DoD CIO DoD BRM for EIE 919 The number of High-level taxonomy tiers defined and managed, as a core set will depend 920on the degree to which the MA Taxonomy CM Authority wishes to exercise CM control over the 921taxonomy structure. Decomposition levels below the MA core structure will be defined by DoD 922Components, as authorized by the MA Taxonomy CM Authority. Each EA DoD Components’ 153gigarchitecturedoc1917.doc E-1 154 DRAFT

155 DRAFT 156 923architecture developer will classify its architectures in the DoD Architecture Registry System 924(DARS) by associating DoD Components’ architectures with nodes of the MA core or authorized 925DoD Component extensions to the core by registering Taxonomy Node and Association Type 926metadata. 927 The Federated Joint Architecture Working Group (FJAWG) has already developed several 928assessments and recommendations in regard to taxonomy, which are provided here for reference, 929pending establishment of the formal structure for their implementation: 930 1. Mission Area Taxonomy CM Authorities must accept responsibility for defining 931 and managing MA core upper tier taxonomy nodes. Therefore, the EA summit 932 should adopt and promulgate the recommended EA High-level Taxonomy 933 strategy. 934 2. DoD Components will have autonomy in developing domain taxonomies. 935 However, domain architecture mappings and extensions to the MA core must be 936 regulated to minimize categorization redundancies. Therefore: 937 a. MA authorities should provide guidance on developing and mapping 938 domain extensions to the MA core, to include approval and mapping of 939 “authoritative” extensions. 940 b. The FJAWG should recommend guidance to MA authorities on regulating 941 DoD Component domain extensions and mappings to the MA core. 942 3. MA core taxonomies need to be coordinated to maximize uniqueness of top- 943 level nodes and minimize potential categorization redundancy; and business 944 analysis needs may drive requirements for additional taxonomies to be 945 incorporated into the MA high-level taxonomy in the future. Therefore, a 946 Federated EA high-level taxonomy configuration control function and 947 governance should be established above the individual MAs for regulating the 948 high-level taxonomy structure and coordinating/de-conflicting the MA- 949 taxonomy top-level nodes. Governance authority should be assigned to the 950 DoD Architecture Configuration Control Board (ACCB). Execution 951 responsibility should be assigned to the FJAWG as the technical advisor to the 952 ACCB. 953 Changes in the MA core taxonomies will impact alignments in the registry and should be 954managed. Therefore, MA Authorities should develop and implement a core taxonomy CM 955process subject to ACCB approval. 157gigarchitecturedoc1917.doc E-2 158 DRAFT

159 DRAFT 160 956 APPENDIX F: DOD FEDERATED EA GOVERNANCE 957 DOCUMENT 958 959Draft Governance Outline 960Scope 961Governance Framework 962OASD/JS Level 963 • Authority 964 o Charter Development/Approval 965 o Organizational Framework 966  Governance Bodies 967  Voting Members 968  Stakeholder Participation 969 o Roles and Responsibilities 970 o Resource Requirements and Responsibilities 971 • Guidance 972 o Policies 973 o Synchronization 974 o Security/Access 975  Accreditation of content 976  Accreditation of members 977  Access control and privileges 978 o External Relationships 979 • Direction 980 o Standards 981  Tools 982  Metadata 983 o Quality 984 o Maturity Models 985 o Repositories 986 o Registries 987 o Data Management 988 o Services 989 o Configuration Management 990 • Monitoring 991 o Metrics 992 o Compliance 993 • Affirmation/Remediation 994Mission Area and DoD Component Levels 995 • Implementation Responsibilities 996 • Monitoring Responsibilities 161gigarchitecturedoc1917.doc F-1 162 DRAFT

163 DRAFT 164 997 • Affirmation/Remediation Responsibilities 998 165gigarchitecturedoc1917.doc F-2 166 DRAFT

167 DRAFT 168 999 APPENDIX G: A DETAILED LIST OF CRITICAL SUCCESS 1000 FACTORS (CSF) BY CSF CATEGORY 1001 1002• Commitment by DoD DoD Components to: 1003 o Actively participate in FJAWG effort 1004 o Maintain DoD Components -level architecture metadata 1005 o Be willing to participate in and support EA Federation PoC Pilot efforts 1006 o Organizations external to DoD that need to assist or provide access to information for 1007 identifying external architecture interface needs 1008 1009• Adoption and implementation by DoD DoD Components of the following: 1010 o Federated EA registration and discovery services 1011 o Architecture federation rules 1012 o Federated EA metadata standards 1013 o Recommended Federation structure 1014 o EA Federation roles and responsibilities 1015 o Proposed high-level taxonomies 1016 o Standard methodologies for aligning and linking architectures 1017 o Architecture categorization schemes 1018 o Architecture federation governance 1019 1020• Proof-of-Concept Pilot is needed to validate the following: 1021 o Applicability & effectiveness of proposed high-level taxonomies 1022 o Architecture configuration management 1023 o Architecture discovery capabilities and performance requirements are satisfied 1024 o Architecture governance at the all levels ensures integrity, visibility, accessibility, 1025 availability, understandability, and usability of architecture data by business/mission 1026 users 1027 o Architecture metadata at DoD Components level satisfies business/Mission Area 1028 information discovery needs 1029 o Architecture navigation and discovery provides correct architecture content 1030 o Architecture registration and discovery capabilities and performance requirements are 1031 satisfied 1032 o Capability to discover (and acquire) architecture content via navigation, search, and 1033 browsing services 1034 o Capability to provide and search on user-defined search criteria 1035 o Categorization schemes are effective in serving business and MA information 1036 discovery needs 1037 o Correctness of rules for federating architectures across the DoD 1038 o Discovery capabilities meet unanticipated user needs 1039 o Effectiveness and efficiency of architecture navigation schemes 1040 o Effectiveness and efficiency of registration service 1041 o Guidance for federation structure 169gigarchitecturedoc1917.doc G-1 170 DRAFT

171 DRAFT 172 1042 o Key interface points for linking architectures are the correct ones 1043 o Linkage to architectures external to the DoD EA Federation 1044 o Linkages are established, on different platforms, with independent repositories within 1045 the federation 1046 o Viability and effectiveness of implemented EA Federation roles and responsibilities 1047 framework 1048 o Viability of accommodating various formats and toolsets 1049 1050• Linking Business and Warfighting mission drivers/needs: 1051 o Alignment of operational activities 1052 o Identifying a “common scenario” applicable to the business or warfighting missions 1053 o Supporting IT enablers for the operational activities 1054 1055• Resources at DoD Components and EA Federation levels must be available to: 1056 o Participate in and support the PoC Pilot efforts 1057 o Aid in identifying all architecture formats and toolsets in use 1058 o Identify interface needs 1059 o Assist in identifying architecture interface points 1060 o Develop and governance structure at DoD Enterprise and DoD Component levels 1061 o Develop and update architecture metadata at DoD Component level 1062 o Develop and update links to architecture content at the DoD Component level 1063 o Map Mission Areas to each other 1064 o Assist in DoD Component repository federation effort 1065 1066• Adoption of DARS as the Federated EA Registry for Architecture - DARS must be: 1067 o Accessible and available across entire DoD 1068 o Intuitive, user-friendly, fast, responsive, and timely for architecture registration and 1069 discovery 1070 1071• EA Federation Tools performance requirements involve the following: 1072 o Automated mapping and linking of architecture content 1073 o Applications that must have timely response times 1074 o Must be user-friendly, intuitive, fast online response 1075 o Interfaces that must be developed to accommodate all architecture formats and 1076 toolsets for architecture registration and discovery 1077 1078• Knowledge and/or skills in: 1079 o Architectures external to the DoD that need to be interfaced with the Federated EA 1080 o DoD technology infrastructure 1081 o Existing disparate architectures across the DoD 1082 o Technologies and tools to provide linking to architecture content 1083 o Web technology 1084 o Metadata standards that need to be implemented 1085 o Architecture formats, methodologies, and toolsets 173gigarchitecturedoc1917.doc G-2 174 DRAFT

175 DRAFT 176 1086 o Prospective current and future types of unanticipated users of Federated EA 1087 o Types of architecture artifacts needed by unanticipated users 177gigarchitecturedoc1917.doc G-3 178 DRAFT

179 DRAFT 180 1088 APPENDIX H: ACTIVITY-BASED EA FEDERATION 1089 ALIGNMENT 1090 1091Activity-Relationship-Activity: 1092 1093 Federating the architecture in an enterprise requires a high-level taxonomy (under 1094development) of the enterprise and an activity model for each DoD Componentof interest in the 1095enterprise. The activities within the high-level taxonomy and DoD Components’ activity models 1096will be related in one of the following four ways as illustrated in Figure H-1 below. 1097 • Equivalent to 1098 • Similar to 1099 • Part of 1100 • No relationship 1101 Federated Architecture Relationships High-level Activity Taxonomy … … FM IL AFMC Is Equivalent to Is Equivalentto Is Similar to Is Part of 1102 1103 Figure H-1. Federation Relationships Among Activities 1104 A DoD Components’ activity is considered “equivalent to” a high-level activity if the 1105descriptions and artifacts of both are identical. 1106 A DoD Components’ activity is considered “similar to” a high-level activity if the 1107descriptions are the same but the primitives differ in some specification between the enterprise 1108design and the DoD Components implementation, the activity is done differently by two or more 1109DoD Components, or two or more DoD Components accomplish the same activity with different 1110primitive specifications. 1111 A DoD Components’ activity is considered “part of” a high-level activity if the description 1112of the DoD Components’ activity achieves part of the high-level activity’s goal, and another 181gigarchitecturedoc1917.doc H-1 182 DRAFT

183 DRAFT 184 1113DoD Components’ activity that also has a “part of” relationship with the same high-level activity 1114completes the goal. 1115 If a DoD Components’ activity has no relationship with any of the high-level activities, 1116then no relationship is shown. 1117 Relationships between the high-level and DoD Components’ activities can occur at any 1118level of decomposition. 1119 185gigarchitecturedoc1917.doc H-2 186 DRAFT

GIG_Architecture.doc

by Zubin67

Accessibility

Upload Details

Usage Rights

Statistics

GIG_Architecture.doc Document Transcript