Department of Defense Enterprise Architecture Federation ...web.cse.msstate.edu/~hamilton/7700/resources/GIG_Architecture.pdf · 141 and its relationship between and among the entities

DRAFT

GIG_Architecture.doc DRAFT

Drew Hamilton� 2/11/10 11:15 PM

1 2

Department of Defense 3 Enterprise Architecture Federation Strategy 4

5

6

7

8

9

10

11

12

13

14 Draft Version 1.01 15 04 December 2006 16

17 18

Prepared by the DoD CIO 19 20

Deleted: DoD Enterprise Architecture Federation Strategy v1_01 - 11 Jan 07 - A.doc

DRAFT

GIG_Architecture.doc ii DRAFT


TABLE OF CONTENTS 20 21 1. Introduction ................................ ................................ .................1 22

1.1. Intended Audience ................................ ................................ ..2 23 1.2. Background ................................ ................................ ............2 24 1.3. Related Guidance................................ ................................ ....4 25

2. Purpose ................................ ................................ .......................4 26 3. Vision ................................ ................................ ..........................4 27 4. Goals ................................ ................................ ...........................4 28 5. Objectives ................................ ................................ ....................4 29 6. Benefits ................................ ................................ .......................5 30

6.1. Benefits to DoD Decision Makers ................................ ............5 31 6.2. Benefits to DoD Architects................................ ......................6 32 6.3. Benefits to Architectural Governance Bodies ..........................7 33

7. Guiding Principles................................ ................................ ........7 34 8. Scope ................................ ................................ ...........................8 35 9. Federated EA Defined ................................ ................................ ...8 36 10. EA Federation Concepts ................................ ............................9 37

10.1. The EA Federation ................................ ...............................9 38 10.2. Tiered Accountability ................................ ...........................9 39 10.3. High-level Taxonomies ................................ ....................... 10 40 10.4. Architecture Categorization ................................ ............... 10 41 10.5. Context ................................ ................................ .............. 11 42 10.6. Boundaries for Tiers ................................ .......................... 11 43 10.7. Semantic Alignment ................................ ........................... 11 44

11. EA Services — Making the EA Visible, Accessible, and 45 Understandable................................ ................................ ................ 12 46

11.1. Metadata ................................ ................................ ............ 12 47 11.2. Registration ................................ ................................ ....... 13 48 11.3. Discovery................................ ................................ ........... 13 49

12. Governance ................................ ................................ ............. 14 50 12.1. EA Federation Roles and Responsibilities .......................... 15 51 12.2. Information Assurance ................................ ....................... 16 52

13. Implementing the Federated EA ................................ ............... 17 53 13.1. Pilot Efforts ................................ ................................ ....... 17 54

14. Critical Success Factors ................................ .......................... 18 55 15. 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 61 (TAXONOMY)................................ ................................ ......................1 62 APPENDIX F: DOD FEDERATED EA GOVERNANCE DOCUMENT .........1 63 APPENDIX G: A DETAILED LIST OF CRITICAL SUCCESS FACTORS 64 (CSF) BY CSF CATEGORY ................................ ................................ ..1 65

Drew Hamilton� 2/11/10 11:15 PMDeleted: 17


DRAFT

GIG_Architecture.doc iii DRAFT


APPENDIX H: ACTIVITY-BASED EA FEDERATION ALIGNMENT ...........1 66 67 68

LIST OF FIGURES 69 70 FIGURE 1: ARCHITECTURE LEVELS FOR TIERED ACCOUNTABILITY…………………………...10 71 FIGURE 2: MAKING ARCHITECTURE ACCESSIBLE ...............................................................14 72 FIGURE E-1: FEDERATED DOD EA TAXONOMY................................................................ E-1 73 FIGURE H-1. FEDERATION RELATIONSHIPS AMONG ACTIVITIES ........................................H-1 74 75 76

LIST OF TABLES 77 78 TABLE 1: ROLES AND RESPONSIBILITIES FOR INDIVIDUAL LEVELS OF FEDERATION..............15 79 TABLE E-1: FEDERATED DOD AND MA TAXONOMY CM AUTHORITY................................. E-1 80

81


DRAFT

GIG_Architecture.doc 1 DRAFT


1. Introduction 81 The Department of Defense (DoD) Federated Enterprise Architecture (EA) represents the 82

“next generation” Global Information Grid (GIG) Architecture. 83 84 The current GIG Architecture, along with the Net-Centric Operations and Warfare 85

Reference Model (NCOW RM) is an overarching architecture description of the GIG.1 86 However, the DoD is too large and complex to be described within a single integrated 87 architecture. Additionally, Enterprise architectures have an inherent problem. To fully describe 88 an enterprise, architects must either abstract the content into simple constructs that don’t lend 89 themselves to supporting a broad range of decisions, or they must compile massive amounts of 90 data that make comprehension difficult at best. One of the primary objectives of enterprise 91 architectures is to describe the enterprise so that decision makers can make informed decisions 92 based on or within a common context. It will result in the development of a cohesive EA 93 supporting the alignment and integration of architecture efforts in support of DoD business and 94 warfighter strategic goals. Therefore, architects must constantly balance complexity with utility. 95 The DoD GIG Architecture is no different. 96

97 What is required is a rethinking of the GIG architecture concept to effectively leverage 98

current architecture efforts and maintain comprehension while, at the same time, providing DoD 99 decision makers with the information they need. Federating existing architectures of DoD 100 elements that describe the various echelons (or tiers) is one way to achieve this goal. Federation 101 techniques allow disparate architectures (based on a variety of established frameworks) to be 102 meaningfully related and permit acceleration of new architecture efforts across the DoD 103 community to support DoD decision makers who require more detailed content that is not 104 reasonable for the department level. 105

106 To date, there have been advancements in both the architecture and stakeholder 107

communities that use architecture information. Architecture products, however, are presently not 108 as sufficiently discoverable and accessible as needed to support decision making. Today’s 109 architectures are built for specific purposes and viewpoints; they do not normally refer to or 110 relate to each other as they should to gain maximum value from the architecture investment. 111

112 As a remedy, the Department has chosen architecture federation2 as a new GIG architecture 113

paradigm. The next generation GIG architecture will be constructed by federating the separate 114 architecture artifacts throughout the DoD and employ a set of EA Services for registering, 115

1 The current DoD overarching architecture description consists of three Components: GIG Architecture ver 1.0, GIG Architecture ver 2.0, and the NCOW RM ver 1.1. The GIG Architecture consists of architecture products describing the DoD Enterprise from the perspective of five different scenarios. Version 1.0 described the “as-is” enterprise circa 2000; ver 2.0 describes the “to-be” enterprise circa 2015. While the NCOW RM is not an architecture itself it does establish the strategies and target technical standards for migration to a net-centric operating environment as the Department moves from the “as-is” to the “to-be”and therefore servs as a part of the Enterprise Architecture as defined by OMB for Clinger-Cohen compliance. 2 The concept of federation or “federalism” infers both a division of authority, accountability and interdependence between the Department level and the Commands, Services, and Agencies. See page 8 for full explanations of Federated EA and Federation Concepts.


DRAFT



discovering, and utilizing architecture data to support key DoD decision processes by 116 implementing concepts from the DoD Net-Centric Strategies. 117

1.1. Intended Audience 118 The primary audience for the DoD Federated Enterprise Architecture Strategy Document 119

includes two distinct classes — first, those responsible for implementation of the Federated EA, 120 and second, producers and consumers of architecture information, e.g., decision makers, program 121 managers, analysts, operators, architects, and engineers within DoD and external partners in the 122 extended enterprise. 123

1.2. Background 124 The Director, Office of the Assistant Secretary of Defense for Networks and Information 125

Integration, Architecture & Interoperability (OASD[NII/A&I]) has worked with the Services 126 Chief Architects to define the federated approach. The federated approach will guide the 127 building of the next generation GIG Architecture. This approach recognizes the need for 128 autonomy but requires linkages and alignment of architectures from the Program level up to the 129 Federal Enterprise level. OASD(NII) will introduce requirements in phases to achieve enterprise-130 wide GIG descriptions that move the Department toward a shared Net-Centric Vision and 131 Transition Plan. These requirements are being identified and met through systems engineering 132 processes that leverage architecture descriptions as blueprints. The use of shared architecture 133 descriptions in Test & Evaluation processes within the federated approach will provide the 134 ability to verify that capabilities are being fielded in accordance with (IAW) the GIG 135 Architecture. 136

137 There are challenges related to institutionalizing architecture into DoD core processes. 138

139 Challenge 1: There is no comprehensive architectural description of the DoD Enterprise 140

and its relationship between and among the entities that make up the enterprise that can be used 141 to support department-level decision making. 142

143 Challenge 2: Architectures are currently developed independently by many organizations 144

across DoD conforming to multiple frameworks. They are maintained in independent 145 repositories, and we assume this mode of operation will continue. This situation, however, raises 146 several concerns for architects and architecture end-users, specifically that there is no: 147

• Capability to globally search, vertically or horizontally, for architectures 148 and/or artifacts3 that may be relevant for analysis, reference, or reuse 149

• Consistent set of standards for architecture configuration management that 150 would enable users to determine the development status, quality, and authority 151 of data in various architectures and/or artifacts 152

• Standard methodology for specifying linkages between architectures 153 developed using different tools and maintained in independent repositories 154 required to provide enterprise-wide context and understanding 155

3 See Appendix B for a definition of “artifact.” Examples include: graphical models, structured models, tabular data, and structured or unstructured narratives. Individual artifacts may be aggregated.


DRAFT



• Architecture alignment through linking will require standardization of 156 vocabularies and taxonomies. The lack of these standards will impede the 157 level to which an individual architecture artifact may be federated. This work 158 is currently being addressed with such efforts as Consolidated Operational 159 Activities List (COAL), and Consolidated Systems Function List (CSFL) and 160 Joint Command, Control, and Consultation Information Exchange Data Model 161 (JC3IEDM). 162

163 Based on these challenges, DoD needs to provide an enterprise wide architecture 164

environment that will: 165

1. Improve the users’ ability to share information on architecture content. 166 2. Enable rapid access to actionable information to support strategic decisions; 167

and 168 3. Increase agility to address unforeseen requirements supporting warfighting 169

needs. 170 171 In the March 2005 National Defense Strategy, the DoD restated its commitment to 172

making operations net-centric. The foundation for net-centric operations is to give users the 173 ability to access the information and applications where and when needed. The key enabler of 174 this ability is the DoD GIG. To move the GIG from Net-Centric concept to Net-Centric reality, 175 the OASD(NII)/DoD Chief Information Officer (CIO) has established the following goals: 176

• Make information available on a network that people depend on and trust. 177 • Populate the network with new, dynamic sources of information to defeat the 178

enemy. 179 180

The DoD Net-Centric Data Strategy, May 2003, addressed the challenges of finding and 181 using information on the GIG. The Data Strategy defined a vision in which information is easily 182 made visible, accessible, and understandable. The draft GIG Enterprise Services Strategy 183 espouses a dual path approach to achieving these goals. It advocates that DoD Components—184 Combatant Commands, Services, and Agencies (C/S/As)—continue to provide and consume 185 services and embrace service-oriented architecture (SOA) principles (see Appendix B). In 186 parallel, the GIG Enterprise Services Strategy drives the enterprise to identify and adopt the 187 necessary services, standards, policies, and processes to federate C/S/As services and SOAs for 188 the benefit of the Department and its partners. 189

190 This DoD EA Federation Strategy and associated EA Services apply the net-centric 191

concept, Data Strategy, and GIG Enterprise Services Strategy to the DoD Enterprise architecture. 192 A net-centric approach to Federated EA ensures that the Department has an accessible Enterprise 193 Architecture with content derived from multiple sources. The intent of this Strategy is to enable 194 cross-departmental discovery and use of architecture artifacts to support the Department’s 195 decision makers in evolving and maintaining the enterprise information technology (IT) 196 infrastructure in accordance with law and policy while maintaining autonomy for the owners of 197 the architecture artifacts. 198


DRAFT



1.3. Related Guidance 199 Architecture requirements are solidly grounded in Law; the Clinger-Cohen Act assigned 200

CIOs the responsibility for “developing, maintaining, and facilitating the implementation of a 201 sound and integrated information technology architecture.” Additional details are provided in 202 the Office of Management and Budget Circular A-130 and are expanded upon in guidance from 203 the DoD and the Joint Staff (JS) regarding the development and use of architectures and their 204 relationship to net-centric operations. Full details are provided in Appendix D of this Strategy. 205

2. Purpose 206

The purpose of this Strategy is to present an agreed upon method and strategy to achieve a 207 DoD Federated EA that would support decision makers in the DoD at the department level as 208 well as the DOD Components and Programs. 209

210 After months of study, OASD, with participation from the JS and DoD Components, has 211

determined that the best way to address the challenges presented above is to federate disparate 212 architectures into a DoD-wide Federated EA. The DoD Federated EA would be constructed 213 using a set of federation standards and Core Enterprise EA Services (registration, discovery, and 214 translation services). 215

3. Vision 216 The Federated EA vision is to provide DoD decision makers and their staffs’ access to a 217

broader and deeper architecture data set that is available, accessible, understandable, trustworthy, 218 and able to be tailored for decision support at the department and DoD Component levels. 219

4. Goals 220 The challenges identified in the Background paragraph serve as the drivers for this 221

Strategy. Their resolution can be found in the following goals necessary to achieve EA 222 Federation: 223

1) An environment to support the decision makers and their staffs with access to a 224 set of common architecture artifacts enabling common understanding of the 225 DoD Enterprise that can be used to support DoD decision making at the 226 enterprise and DoD Component levels 227

2) A means to identify internal and external interfaces to the DoD Enterprise 228 3) Improved EA information sharing of architectural content, ensuring that users, 229

including unintended users, can find and use the right information 230 4) Increased agility that leverages existing architecture and/or artifacts to swiftly 231

adjust or expand their capabilities through architecture reuse and integration to 232 meet their changing mission and business needs 233

5. Objectives 234 The following five objectives provide the focus for achieving the Goals identified above. 235

Achievement of all is critical for success. 236


DRAFT



A. Provide a structure for federating architectures to achieve the DoD EA and to 237 establish a means for autonomous development of DoD Component’s EA to support 238 tiered accountability. Related Goals: 1, 2, 3 239

B. Provide guidance for federating architectures to achieve the DoD Federated EA and 240 to establish a means to allow each DoD Component to build its Architecture within 241 the guidance given by the Enterprise to support tiered accountability. Related Goals: 242 1, 2, 4 243

C. Align DoD Component EA within a common framework of semantic 244 understanding .This common framework is based on the use of taxonomies from the 245 C/S/As and aligned with the Department level taxonomies to ensure that the DoD 246 Components can achieve standardization and semantic understanding with DoD 247 Component’s EAs. Related Goal: 1 248

D. Leverage Core Enterprise EA Services to provide Architecture Registration and 249 Discovery Services that are available, accessible, and usable by consumers within the 250 enterprise to share architecture information both vertically and horizontally 251 throughout and achieve information visibility in a coherent manner. Related Goals: 252 1,3,4 253

E. Provide a foundation to support emerging capabilities through Federated EA 254 services as a way of making the underlying business, mission, or transaction function 255 in a system or application available to a broad set of consumers. These services can 256 be easily reused and repurposed to provide building blocks for new capabilities. An 257 example of these services would be to provide specific analytic capabilities 258 leveraging EA holdings to support logistics, blue force tracking, and mission 259 planning. Related Goal: 3, 4 260

6. Benefits 261 There are many benefits to be realized from implementing a Federated EA. The 262

implementation of the Federated EA is intended to provide useful analytical information to 263 various stakeholders within the DoD. Multiple benefits accrue as the DoD GIG is federated and 264 progressively populated with widely sharable information and capabilities, which significantly 265 boost operational efficiency and effectiveness. This section will identify many of the reasons and 266 benefits and give a simple description or example of how they are used. These benefits are 267 dependent on the degree and nature of the content provided by program and DoD Component 268 architectures. 269

6.1. Benefits to DoD Decision Makers 270 271 Enables Rapid Access to Information for Strategic Decisions: 272

Access to actionable, relevant, decision quality, architecture information will accelerate the 273 leaders’ ability to make better decisions that impact the enterprise (e.g., human resource 274 capabilities; condition, status, and location of assets; and how funds are invested for the 275 warfighting mission). The ability of the Federated EA to support these types of decisions is 276 content dependent. 277 278 Deleted: DoD Enterprise Architecture

Federation Strategy v1_01 - 22 Jan 07 - A.doc

DRAFT



Improves Information Sharing of Architecture Content: 279 Populating the GIG with federated architecture products and leveraging Core Enterprise 280

Services to provide EA discovery and search services ensures that architecture information can 281 be accessed throughout the enterprise. Any user who has access to the GIG will be able to find 282 and use information from any Web-enabled device. 283

284 Understanding of Interactions and Interdependencies: 285

One of the primary uses of federation is to allow an Enterprise to understand the 286 interactions and interdependencies among its component parts. DoD needs to understand the 287 interactions among its major elements, the DoD Components, with the means to govern and 288 manage the Department “cross-functionally” to realize a cost-effective, Net-Centric GIG. The 289 Department recognizes that the exchanges among the domains are vital to modernizing the 290 enterprise. By understanding the minimum set of exchanges required, the enterprise can reduce 291 or eliminate unnecessary processes and the resources required to support those unnecessary 292 processes. 293 294 Supports Portfolio Management of Technology Options: 295

The Federated EA depicts the supporting technology and implementation as defined by the 296 program and DoD Component’s architectures, for each activity within the enterprise. By 297 evaluating the set of technologies across the Federated EA, the analyst or portfolio manager can 298 gain an understanding of multiple uses of the same technology and multiple technologies applied 299 to support the same type of activities. 300 301 Supports the Joint Warfighting Capability of the DoD: 302

Joint military requirements are driving the need for greater commonality and integration of 303 mission operations across the Department. The Department’s infrastructure must enable rapid 304 response to the warfighting community and be compatible with the global, networked military it 305 supports. 306 307 Reduced Cost of Defense Operations: 308

Streamlining operations using Operational Architecture View data will enable decision 309 makers to deal with growing pressures on resources and ensure every Defense dollar is optimally 310 applied for long-term mission effectiveness. 311

6.2. Benefits to DoD Architects 312 313 Promotes Distributed Configuration Management: 314

Once the enterprise has federated its architecture, configuration management is reduced to 315 two efforts: maintenance of the federation and configuration of enterprise artifacts. As part of 316 the centralized control and decentralized execution of developing the enterprise architecture, the 317 enterprise can very tightly manage the high-level taxonomies, the relationships with the DoD 318 Component’s activities, and the enterprise list of instances for each. 319 320 Provides Clear “stopping” rules for Enterprise Architecture Development: 321

When developing enterprise architectures, the greatest mistake comes from overstepping 322 the scope of the department level description. No architect should ever develop details that are 323 Deleted: DoD Enterprise Architecture


DRAFT



clearly in the purview of a lower-level tier. For example, the department level does not have the 324 authority or expertise to develop the details as well as the DoD Components. Once the 325 relationship is established between high-level taxonomies and a DoD Component’s architecture 326 artifact, the department level should then cease its examination of details and point to the DoD 327 Components. The DoD Component maintains the responsibility and authority to detail the 328 artifact and define how the enterprise achieves the goal. 329 330 Increases Agility: 331

This benefit is the natural result of the use of Web-based services for registration and 332 discovery, which are modular, reusable, interoperable building blocks. Users can search the 333 Federated EA Registry and find existing architecture content, significantly reducing the time and 334 cost for new architecture development, fielding of a new capability, and gaining improved 335 interoperability “out of the box.” By using these building blocks, warfighters can swiftly adjust 336 their architectures to meet changing business and mission needs. 337

6.3. Benefits to Architectural Governance Bodies 338 339 Sets Enterprise Boundaries: 340

A Federated EA with activity-based alignment shows each DoD Component’s activities 341 and how they relate to achieving the enterprise’s goals. The relationships among the activities 342 identify the activities that are “owned” or performed uniquely and those that are shared by one or 343 more of the DoD Components. Once all the activities of the Enterprise are related to the 344 activities of the DoD Components, then the collection of all activities owned by a single DoD 345 Component sets boundaries throughout the Enterprise. Boundaries are vertical and horizontal 346 start and stop points for accountability in the roles and responsibilities for Federated EA’s. 347 348 Promotes Autonomy or Self-Governance: 349

A federated architecture supports a governance structure that defines the responsibility and 350 authority among Components to achieve and support enterprise-wide goals. Once a DoD 351 Component accepts its defined boundary, as depicted within the federated architecture, it enjoys 352 autonomous control of the development and analysis of its architecture. The DoD Components 353 determine the breadth and depth of detail relating to their individual architecture, and produce 354 and archive the artifacts, as required, to meet or support the goals of the enterprise. 355

7. Guiding Principles 356 In an effort to gain the most re-use out of existing architecture artifacts, and to minimize 357

the need for additional architecture development, the development of the DoD EA Federation is 358 guided by the principles below. The Federated EA will: 359

• Respect the diverse requirements of individual DoD Component while focusing 360 on the associations that cut across organizational boundaries IAW statutory 361 roles and responsibilities for the DoD Components. 362

• Focus on federating existing disparate architecture artifacts regardless of 363 structure and format – not re-building architectures. 364

• Maximize the reuse of existing architectures at all tiers. 365 Deleted: DoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 - A.doc

DRAFT



• Evolve from a product-centric approach (focused on DoDAF and other work 366 products produced by architecture developers) towards a data-centric 367 architecture approach focusing on common semantics. 368

• Support DoD’s net-centricity objectives (e.g., make information and services 369 visible, accessible, and understandable) and vision. 370

8. Scope 371 This Strategy encompasses DoD architectures at all levels of detail and classification. It 372

defines or references interfaces to architectures outside the Department under the Federal 373 Enterprise Architecture Framework (FEAF) and the Federal Enterprise Architecture Reference 374 Models.4 The GIG, a Federated EA, will not be isolated to IT but will have relevance for 375 Doctrine, Organization, Training, Material, Leadership and education, Personnel, and Facilities 376 (DOTMLPF), as the use and utility of architecture expand in those areas. 377

378 This Strategy is applicable to all DoD Mission Areas and addresses the relationships among 379

all levels of enterprise details from the program/initiative level up to the Department level. This 380 Strategy will: 381

• Define architecture federation and integration concepts. 382 • Define architecture alignment (linking and mapping) processes. 383

• Define EA Services for registering and discovery of architecture holdings and 384 associated metadata. 385

386 This Strategy will accommodate the range of architecture formats, methodologies, toolsets, 387

and levels of abstraction, and will be applicable to multiple decision processes. 388 389

As part of this Strategy, Policy, Governance, and Implementation Planning documents will 390 need to be defined and developed to support the vision and goals of this strategy. 391

9. Federated EA Defined 392 We use the term Federated Architecture to represent the concept that architecture artifacts 393

are related in a meaningful way. Federated Architectures conform to common or shared 394 architecture standards across autonomous Program, DoD Component, Mission Area enabling 395 developing/owning entities to maintain diversity and uniqueness, while providing opportunity for 396 implementing interoperability.5 397 4 Federal Enterprise Architecture (FEA) Reference Models (RM) - The FEA is a tool used to align the DoD enterprise Architecture with the rest of the Federal Government’s Components. There are five Reference Models within the FEA: Performance Reference Model (PRM); Business Reference Model (BRM); System Reference Model (SRM); Technical Reference Model (TRM); and Data Reference Model (DRM). PRM – Identifies the performance measures of the enterprise BRM – Identifies the key activities of the enterprise SRM – Identifies the primary systems used within the enterprise TRM – Identifies the approved and emerging standards used within the enterprise DRM – Identifies the data and information used within the enterprise 5Adapted from New York State Office for Technology – see definitions


DRAFT



398 A Federated Enterprise Architecture shows how a DoD Component aligns activities, 399

services, systems, and infrastructure with federation standard taxonomies, providing context. 400 Initially, EA federation will be based on semantic alignment of each Program, DoD Component, 401 Mission Area, architecture’s top-level activity with the Enterprise’s top-level taxonomy of 402 activities called the “High-level Taxonomy.” An example of “High-level Taxonomy” is the 403 implementation of the BEA activity model which serves as the Business Mission Area’s 404 (BMA’s) “High-level Taxonomy” for DoD Component alignment. Semantic Alignment will be 405 based on the context6 of the architectures and the individual activities being related – for DoDAF 406 architectures this is normally identified in the (OV-5). Semantic alignment of other architectural 407 elements will be pursued, as needed, to support key decision processes and as other federation 408 high-level taxonomies are developed. 409

410 Federated Architecture shows the allocation of responsibility across the Enterprise. In 411

contrast, Integrated Architecture shows the interaction of multiple activities to achieve a mission 412 or goal across the Enterprise. 413

414 Federation is a way to organize an enterprise’s body of knowledge (architecture) about its 415

activities (processes), people, and things within a defined context and current/future 416 environment. Federation provides the architect-analyst additional means to examine aspects of 417 the DOTMLPF concepts across organizational boundaries. 418

10. EA Federation Concepts 419

10.1. The EA Federation 420 This section identifies key concepts that define the Federated Enterprise Architecture 421

elements. These concepts are important to understanding Federation and how it is most useful in 422 supporting decision making and Tiered Accountability. These concepts enable Department-wide 423 producers and consumers to achieve the Goals and Objectives of a Federated EA. 424

10.2. Tiered Accountability 425 Tiered accountability is distribution of authority and responsibility of an element of the 426

enterprise architecture to an organization. Through the policy of Tiered Accountability (TA), 427 DoD addresses the responsibility for producing these EA architecture artifacts. Under TA, DoD 428 is currently defining and building enterprise-wide capabilities that include data standards, 429 business rules, enabling systems, and an associated layer of interfaces for Enterprise, Mission 430 Area, DoD Components, and Programs. Each tier of the enterprise – Department, Mission Area, 431 DoD Components, and Program – has specific goals, as well as responsibilities to the tiers above 432 or below them. 433

434

Each tier has full authority and responsibility to develop their portion of the EA. 435 Unfortunately, data between tiers are often unavailable via an accurate, timely, and reliable 436

6 See definition on page 10.


DRAFT



method. In order to navigate through these tiers in a coherent way, and achieve information 437 visibility, accessibility, and responsiveness, an organizing structure is needed. 438

10.3. High-level Taxonomies 439

In the context of the Federated EA, a high-level taxonomy is a structure or model that 440 spans the enterprise. At the highest level of the enterprise, the DoD Activity High-level 441 Taxonomy7 sets the context for the alignment of the Mission Areas’ activities and associated 442 reference models. At the DoD Component level, it is used to categorize and organize the DoD 443 Component’s architectures to depict boundaries and provide context for federation. For the 444 Federated EA, the Activity High-level Taxonomy will be the first High-level taxonomy 445 produced. 446

10.4. Architecture Categorization 447

DoD EA DoD Component’s architectures need to be categorized to facilitate alignment 448 (mapping and linking), cataloging, navigating and searching disparate architecture in a DoD 449 registry of holdings, and providing a framework for aligning architectures. This Strategy 450 identifies four major levels of echelon and taxonomies to be used for categorization Figure x: 451

• Department (OSD, JCS, etc) 452 • DoD Mission Area (Warfighting, Business, DIMA, and EIE Mission Areas) 453 • DoD Component (Army, JFCOM, DLA, etc) 454 • Program (NECC, FCS, etc) 455

456 457

458 459

Figure 1 Architecture Levels for Tiered Accountability 460 461 Where possible, this should include identifying a common reference language8 or 462

model applicable to the mission areas that can be used by all participating architectures. These 463

7 The Business Reference Model (BRM) is the high-level Federated EA Activity Taxonomy. 8 As an example, for the BEA Materiel Visibility BEP, the (SFIS) provides a common reference for all DoD Logistics architectures. NOTE: This also complies with the guidance in DoD 4140.1-R, Paragraph C1.4.1.1, to use the SCOR processes of “Plan, Source, Maintain/Make, Deliver, and Return as a framework for developing, improving, and conducting


DRAFT



top level taxonomies should be complemented by other architecture categorization schemes 464 including Joint Capability Areas (JCAs), Joint Mission Areas (JMAs), Missions, Universal Joint 465 Task List (UJTL), DoDAF product type, functional area, acquisition program, transformation 466 architecture, and others, as appropriate. A full description of a proposed categorization scheme 467 is in Appendix E. 468

10.5. Context 469

Context defines the environment of the enterprise architecture. Five basic questions 470 make up the Context and help to fully define the external environment of the enterprise. 471

472 1) What is the purpose of the architecture effort and what are the questions to 473

be addressed by this architecture effort? 474 2) What is the boundary of the enterprise? What is considered inside the 475

enterprise versus external? 476 3) What is the scope of the architecture effort, what are the echelons or 477

organizational levels involved, and what level of detail will be required in 478 the descriptions? 479

4) What is the viewpoint of the architecture? From who’s perspective do we 480 examine the enterprise and write the descriptions (external customer, 481 supplier, or casual observer; internal role player; or process owner)? 482

5) What echelons are represented by the architecture? 483

The Context should be defined before the architecture effort is begun and articulated 484 within the AV-1. The context is part of the architecture’s metadata, which can be used for 485 discovery, semantic alignment, and contextual comparison with other architecture efforts. 486

10.6. Boundaries for Tiers 487

Each enterprise tier – Department, Mission Area, DoD Component, and Program – has 488 specific goals, as well as responsibilities to the tiers above or below them that are used to 489 determine the level of detail (or abstraction) necessary for their architecture. 490

10.7. Semantic Alignment 491 492

A key goal of net-centricity is to enable semantic understanding of data so that 493 interoperability can be achieved between any applications that have the ability to access and 494 interpret the structural and semantic rules associated with data. 495

496 The Federated EA will be based on the semantic alignment of tier level architecture 497

elements with elements of federation high-level taxonomies. Semantic alignment refers to the 498 relationship specified between the meanings of taxonomy elements. The semantic relationships 499 specified between activities will typically include “is equivalent to,” “is part of,” or “is similar 500 to.” These relationships provide the alignment between the elements of DoD Component’s 501

materiel management activities to satisfy customer requirements developed collaboratively with the support providers.”


DRAFT



C/S/As architectures and the high-level reference taxonomies that specify the interface points in 502 the federation for tiered accountability of the Federated EA content. 503

504 Through Tiered Accountability, Stakeholders and the DoD Components will retain the 505

authority to manage their own internal Architecture holdings, consistent with federation 506 standards or methodologies. However, the federated EA governance body at the appropriate tier 507 will have responsibility for capturing semantic consistency out of the separate DoD Components 508 and communities of interest/practice, defining the semantic (meaning) and syntactical (structure) 509 standards that will provide for consistent usage and meaning. Where possible, external and 510 industry standards will be considered for incorporation. Specifics on how semantic alignment 511 can be achieved will be included in the Federated EA Implementation Plan. 512

11. EA Services — Making the EA Visible, Accessible, and 513 Understandable 514 In order to make the EA visible, accessible, and understandable9, EA Services will be 515

implemented using Web Services, in which specific content and/or functionality is provided by 516 one user for others, many of whom may be unanticipated by the provider (see Figure 1). The 517 return on investment in the Federated EA will result from DoD providers continually populating 518 the Federated EA with architecture data and products that satisfy a variety of anticipated and 519 unanticipated consumer needs. This will require the following development of standards and 520 services: 521

• A set of standard metadata will be maintained for all architectures in 522 confederating repositories and Web service specifications (Web service 523 definition language [WSDL]) for discovery and registration. 524

• A registration service will enable cataloging and linking of architectures in 525 federated repositories. 526

• A discovery service will enable users to execute a federated search for 527 architecture holdings meeting specified search parameters. 528

529 The following paragraphs elaborate on those concepts. 530

11.1. Metadata 531

To implement a Federated EA search service, metadata elements must be defined to 532 capture attributes of artifacts required to support search parameters based on user needs. The 533 DoD Discovery Metadata Specification (DDMS) V1.3 provides a baseline specification for 534 architecture discovery metadata. The architecture conceptual model (currently the CADM) 535 provides additional AV-1 discovery metadata specifications. Several new metadata elements, 536 defined as “DDMS Plus” metadata, enable configuration management, architecture registration, 537 and cataloging. 538

Data may be stored in any format using relational, object oriented, or hybrid 539 technologies based on any kind of data model. These principles do, however, require that 540 9 Visible, Accessible, and Understandable are key Net-Centric concepts from the NCOW RM v1.1 as integrated from the Net-Centric Strategies.


DRAFT



agreements be reached within the DoD EA Community of Interest (COI) or Community of 541 Practice (COP) on the structure and semantics of data elements used for data asset discovery, 542 linking, exchange, and integration. Metadata elements needed to support the EA user services 543 described herein are defined and proposed for DoD EA COI/COP acceptance as the standard for 544 net-centric federated EA services. 545

11.2. Registration 546

Federation repositories will capture all architecture metadata for architectures 547 developed in local environments. Federation repository owners will be responsible for 548 implementing mechanisms to collect metadata specifics on the implementation of Registration, 549 including specific metadata requirements, which will be contained in the Federated EA Services 550 Implementation Plan. 551

11.3. Discovery 552

The Federated EA will include a federated metadata discovery capability. The intent is 553 to provide a user-friendly service that enables discovery of architecture metadata available from 554 federated repositories. Federated repositories are achieved when sources of similar content can 555 be searched via enterprise services. It will also enable the user to follow links to the source 556 architectures in the federated repositories. Specifics on the implementation of this tool will be 557 contained in the Federated EA Services Implementation Guidance Document. 558

The following sections address the two primary modes of discovery, registry browsing 559 and searching. 560 561 Registry Browsing: 562

Users may browse a catalog of holdings for Federated EA repositories to find artifacts of 563 interest. Cataloging of repository holdings should enable users to search for artifacts by 564 navigating categorization taxonomies similar to browsing item categorizations in online 565 shopping Web sites. Multiple categorizations may apply to any single architecture. Catalog 566 navigation trees should use standardized category names from “approved” enterprise 567 taxonomies, when available, and may be extended by domain extensions where needed. 568 Navigation trees should provide links to detailed metadata on architecture holdings to enable 569 users to determine potential interest value and include links to the products in source repositories 570 to enable user access to selected products. 571

572 Searching: 573

An architecture search capability must enable a user to specify a set of criteria for 574 architecture artifacts of interest. A single search interface using that set of search criteria needs 575 to be able to reach all architecture data repositories and present a consolidated response to the 576 user. The consolidated response, at a minimum, should: 577

• Provide sufficient metadata on holdings, so that users can ascertain their 578 relevance. 579

• Provide links to the results, taking the user to the source repository consistent 580 with the user’s role-based access privileges. 581 Deleted: DoD Enterprise Architecture


DRAFT



• Include all available architecture metadata, including metadata not specified as 582 search parameters. 583

Figure 2 illustrates the concept for the proposed Core Enterprise EA Services/DARS 584 implementation for the DoD Federated EA Services. It illustrates metadata registration and 585 discovery of architecture content within the federated repositories required to make the enterprise 586 architecture data visible, accessible, and understandable for the DoD community. 587 588

589 Figure 2: Making Architecture Accessible 590

12. Governance 591 Since the Federated EA is not a unitary architecture, it will require a governance structure 592

to provide direction and oversight within the framework of TA and the existing DoD and DoD 593 Component governance structures. The DoD CIO, or the CIO’s delegate, will serve as the 594 ultimate chairperson for management of the Federated EA. However, due to the complex 595 relationships between the architecture producers/developers at various levels, the governance 596 roles within the Federated EA will vary according to roles within Tiered Accountability. 597

1) At the Enterprise or OASD/JS-level, governance will address DoD-wide 598 Authority, Direction, Guidance, Monitoring, and Affirmation/Remediation. 599

2) At the Mission Area-level, governance will address Implementation, 600 Monitoring, and Affirmation/Remediation in response to DoD-wide guidance as 601 well as Mission Area unique Authority, Direction, and Guidance. 602

3) Similarly, the DoD Component-level, governance will address Implementation, 603 Monitoring, and Affirmation/Remediation in response to DoD-wide guidance 604


DRAFT



and Mission Area input, as well as individual DoD Component requirements for 605 Authority, Direction, and Guidance. 606

607 The details for governance will be provided in a separate document, the planned DoD 608

Federated EA Governance Document. It will address areas such as: 609 610

611 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

A tentative outline for Governance is provided in Appendix F. 612

12.1. EA Federation Roles and Responsibilities 613

This Federation Strategy is in accordance with DoD 8320.2-G, DoD Guidance for 614 Implementing Net-Centric Data Sharing by enforcing Tiered Accountability, whereby each tier, 615 or level, of the federation is responsible for managing its own architectures and data while also 616 making those architectures and data visible, accessible, and understandable to other members of 617 the federation. The Federation Strategy seeks to operationalize Tiered Accountability. 618

Each Tier has both internal and external roles and responsibilities that it must perform 619 to make the Federated EA function as intended. These are presented in Table 1, where external 620 roles and responsibilities are denoted with a star (*) and internal roles and responsibilities are 621 denoted with a square (■). 622

623 Table 1: Roles and Responsibilities for Individual Levels of Federation 624

Department Impose constraints on federated Mission Areas,

DoD Components, and Programs in order to achieve cross-federation.

Add or remove information from the DoD Federated EA as appropriate via the various feedback loops outlined in the Implementation Plan.

Develop top-level taxonomies and categorization schemes in order to ensure that Mission Areas, DoD Components and

Establish a governance structure for the DoD EA Federation.

Develop and maintain the environment in which the Federated EA is developed and maintained.

Create, publish, and administer the high-level Discovery and Registration Services.

Store, publish, and maintain federation mapping “links” to enable traceability through each tier and across the Department Level.

Create and manage the DoD EA RMs. Deleted: DoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 - A.doc

DRAFT



Program architectures can align in a meaningful way.

Mission Area Impose constraints on the DoD Components

and Programs in order to achieve Mission Area (MA) goals and support interoperability between mission areas.

Develop and maintain MA enterprise architectures and mapping results.

Provide configuration management (CM) to DoD Components’ taxonomies by MA.

Provide content to taxonomies and categorization schemes utilized for the DoD Federated EA.

Report changes in content for DoD EA Federation, as necessary.

625 DoD Components and Enterprise Programs

Impose constraints on DoD Components’ Programs in order to achieve the DoD Components’ goals and support cross-DoD interoperability.

Manage its enterprise architecture to support its mission and vision.

Propose modifications to the DoD EA to increase/improve alignment between tiers.

Develop and maintain theDoD Components’ enterprise architectures.

Extend high-level taxonomies. Implement the discovery services within the

DoD Components’ environments.

Provide CM to domain taxonomies. Use the taxonomies and categorization

schemes provided by the MA levels to map its architectures to the DoD EA.

Make the DoD Components’ architecture and mapping results visible, accessible, and understandable.

Adhere to the standards for data sharing established by the Enterprise and MAs.

Ensure that the DoD Components’ Program architectures and mapping results are visible, accessible, and understandable.

Support metadata development.

DoD Component Program’s Maintain Program architecture element names

and definitions. Propose modifications to the DoD EA to

increase/improve alignment between tiers. Develop and maintain the Programs’

architecture and mapping results. Extend high-level taxonomies.

Map to the taxonomies and categorization schemes provided by the DoD Components as appropriate.

Make the Programs’ architecture and mapping results visible, accessible, and understandable.

Adhere to the standards for data sharing established by the Enterprise, MAs, and DoD Components.

626

Additional roles and responsibilities will be identified, as required, within the Governance 627 Document. Detailed roles and responsibilities specific to each level will be outlined in the DoD 628 EA Federation Implementation Plan. 629

12.2. Information Assurance 630

This Strategy will embrace information assurance concepts and principles and other 631 DoD guidance, as appropriate. This is to ensure the integrity of the information across the 632 Federated EA that’s required to support the goals of visibility, accessibility, understandability, 633 and trustability (through metadata tagging of artifacts). 634


DRAFT



13. Implementing the Federated EA 635

As an integral part of this Strategy, a detailed Implementation Plan will be provided as a 636 separate document. 637

13.1. Pilot Efforts 638

There are two primary areas of interest for Proof-of-Concept (PoC) Pilot efforts. One is 639 to build and analyze a Federated EA using the DoD High-level Activity Taxonomy, a Mission 640 Area Taxonomy, and DoD Components’ architecture. The other is to build and demonstrate EA 641 Services with an initial focusing on Registration and Discovery Services. 642

Enterprise Federation – Federated EA Pilot 643 The first pilot will build and analyze a Federated EA using the DoD High-level Activity 644

Taxonomy, Mission Area Taxonomy, and DoD Components’ architecture. OASD(NII) and the 645 EA Summit are currently evaluating candidates for this pilot. 646

EA Services — The DARS Pilot for Registration and Discovery 647 For the second pilot – registration and discovery capabilities – EA Registration and 648

Discovery Services will be implemented initially as Core Enterprise EA Services in DARS and a 649 selected set of federated repositories. These capabilities will then be federated to other DoD 650 Components’ repositories, resulting in a more robust department-level capability. Using this 651 federated capability, a search request on one repository, e.g., DARS, will result in a returned set 652 of records matching the search criteria and will contain as much of the architecture metadata as is 653 available from each of the federated repositories having holdings that match the search criteria. 654 URLs in the reply metadata set will provide links to the source architectures in the federated 655 repositories. 656

An architecture search capability should enable a user to specify a set of criteria for 657 architecture artifacts of interest. Users should be able to specify specific search criteria in a 658 search GUI using methods such as pick lists for the allowable values for each of the criteria. 659 That set of search criteria needs to be propagated to all architecture data repositories. The user 660 then needs to receive a single consolidated response that: 661

• Provides consistent metadata from all sources 662 • Provides sufficient metadata to enable the user to ascertain their relevance 663 • Provides links to the sources 664

Once a user determines which architecture artifacts are of interest, a link associated with 665 each result will take the user to the source repository. Depending on the security policy of the 666 source repository, the link may either provide direct access to the selected artifact in the native 667 repository format or visualization environment, or, in future versions; it may direct the user to a 668 role subscription service on the native repository for requesting access to the product. User 669 credentials may also be passed by the search service to the source repository for authentication to 670 enable automated access based on access roles/privileges associated with the user in the source 671 repository. 672


DRAFT



14. Critical Success Factors 673

A review of the business and warfighting mission drivers/needs (with respect to their 674 information needs), at an enterprise, i.e., joint level, reveals the high degree of cooperation and 675 participation needed for federating the disparate architectures across the entire DoD, including 676 alignment of external organizations and agencies in support of strategic, joint decision making. 677

Following is a list of broad categories of candidate Critical Success Factors (CSF) related 678 to the institutionalizing of a DoD Federated Architecture environment. The broad CSF 679 categories are: 680

• Required commitment by OSD, JS, and DoD DoD Components for participation 681 in the FJAWG, 682

• Adoption and implementation by OSD, JS, and DoD DoD Components for 683 architecture governance, registration, high-level taxonomies, federation levels, 684 roles and responsibilities, federation methodologies, etc. 685

• Selection and successful implementation of a PoC Pilot in order to validate EA 686 Federation concepts, governance, methods, tools, high-level taxonomies, etc. 687

• Linking Business and Warfighting mission drivers/needs. 688 • Commitment of resources at OSD, JS, and DoD DoD Components to support 689

federation development and implementation. 690 • Adoption of DARS as the Federated EA Registry. 691

692 Appendix G contains a detailed list of CSFs within each category. 693

15. The Way Ahead 694

To begin implementation of this Strategy: 695

• OSD Leadership, working with the DoD Components and other stakeholders, 696 will articulate details required for implementation. 697

• Registry and repository owners will work with the registry pilot lead on 698 federating discovery services. 699

• FJAWG as the EA Summit arm will complete the development of the high-level 700 activity taxonomies. 701

• The community will define how linkages are managed between the Tiers in the 702 Federation. 703

• DARS will implement the linkages between the Tiers in accordance with the 704 community requirements as a community extension to Core Enterprise EA 705 Services for EA. 706

• Mission Area Leads will define their high-level taxonomies for inclusion in the 707 DoD EA Reference Models. 708


DRAFT

GIG_Architecture.doc A-1 DRAFT


APPENDIX A: ACRONYM LIST 709 710 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 Deleted: DoD Enterprise Architecture

Federation Strategy v1_01 - 26 Dec 06 - B.doc

DRAFT

GIG_Architecture.doc A-2 DRAFT


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 711

Deleted: DoD Enterprise Architecture Federation Strategy v1_01 - 26 Dec 06 - B.doc

DRAFT

GIG_Architecture.doc B-1 DRAFT


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


DRAFT



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


DRAFT



Service Registry or Registry Service: 805 Is a platform neutral, network based directory that stores information about services and is 806 searchable based on the descriptive metadata defined in the service specification. [DoDAF Version 807 1.5 Vol 2 Oct 2006] 808 809 810 811


DRAFT

GIG_Architecture.doc C-1 DRAFT


APPENDIX C: REFERENCE DOCUMENTS 812 813 814 A Practical Guide to Federal Enterprise Architecture, CIO Council, February 2001. 815 816 BMA – Federation Strategy and Roadmap [Working Draft], Business Transformation Agency, 817 28 August 2006. 818 819 Concepts of Enterprise Architecture: Federating Components of an Enterprise Architecture, 820 Draft MITRE Corporation Paper for SAF/XCXA, 6 September 2006. 821 822 Department of Defense Chief Information Officer Memorandum, "DoD Net-Centric Data 823 Strategy," May 9, 2003. 824

DoD Architecture Framework, Version 1.0, 9 February 2004. 825 826 DoD Directive 8100.1, "Global Information Grid (GIG) Overarching Policy," September 19, 827 2002. 828

DoD Federated Joint Architecture Working Group (FJAWG) Internal Working Papers, 829 December 2005-Present. 830 831 DoD Net Centric Spectrum Management Strategy, OASD (NII), 25 April 2005. 832 833 Federated Architectures, Enterprise Integration Inc., 2005. 834 835 Global Information Grid Enterprise Services Strategy, Working Draft, OASD(NII) CIO, Oct 836 2006. 837 838 http://www.ocio.usda.gov/e_arch/glossary.html, U.S. Department of Agriculture Office of the 839 CIO. 840 841 http://www.oft.state.ny.us/arcPolicy/policy/glossary.htm, New York State Office for 842 Technology. 843 844 National Defense Strategy of the United States of America, March 2005. 845 846 The “Net-Centric Operations and Warfare Reference Model, OASD (NII)”, 17 Nov 2005. 847 848 “Joint Concept of Operations for Global Information Grid NETOPS version 2.0”, 849 USSTRATCOM, 10 Aug 2005 850 851


DRAFT

GIG_Architecture.doc D-1 DRAFT


APPENDIX D: RELATED GUIDANCE 852 853

Architecture requirements are solidly grounded in Law; the Clinger-Cohen Act assigned 854 Chief Information Officers the responsibility for “developing, maintaining, and facilitating the 855 implementation of a sound and integrated information technology architecture.” Additional 856 details are provided in Office of Management and Budget Circular A-130. The Circular 857 establishes an Enterprise Architecture (replacing the term “information technology architecture”) 858 as consisting of the following elements: business processes, information flows, data 859 descriptions, applications, technology infrastructure, and standards. The Circular also establishes 860 the requirement for the EA to be incorporated in the Executive Agency’s Capital Planning and 861 Investment Control Process. 862 863

DoD prescribes the DoDAF version 1.0 (DoDAF) as the basis for DoD developing 864 architecture descriptions. DoDAF-based architecture descriptions are required in many of the 865 Department’s major processes; these descriptions are also required to be consistent with the GIG 866 Architecture and NCOW RM. The following policies require the development of architecture 867 descriptions: 868

• CJCSI 3170.01E, Joint Capabilities Integration and Development System 869 • CJCSI 6212.01D, Interoperability and Supportability of Information 870

Technology and National Security Systems 871 • DoDD 5000.1, The Defense Acquisition System 872 • DoDI 5000.2, Operation of the Defense Acquisition System 873 • DoDD 4630.5, Interoperability and Supportability of Information Technology 874

and National Security Systems 875 • DoDI 4630.8, Procedures for Interoperability and Supportability of Information 876

Technology and National Security Systems 877 • DoDD 8000.1, Management of DoD Information Resources and Information 878

Technology 879 • DoDD 8115.1, Information Technology Portfolio Management 880

881 These policies are enforced through processes that include assessments of compliance with 882

applicable architectures. DoDI 5000.2, for example, includes requirements for Clinger-Cohen 883 Compliance. One of the compliance criteria requires that acquisitions are “consistent with the 884 Global Information Grid policies and architecture, to include relevant standards.” The DoD CIO 885 as well as the DoD Component CIO’s assess lower Acquisition Category (ACAT) programs. 886

The development of a DoD Federated EA will be conducted in accordance with both DoD 887 and Federal policy on the development and use of Enterprise Architectures. The approach to 888 federation described herein shall closely follow DoD policy and directives on net-centric data 889 management. The following net-centric references are applicable: 890

• DoD CIO Memorandum, DoD Net-Centric Data Strategies: 891

– Net-Centric Data 892 – Shared Services 893 – Information Assurance 894


DRAFT

GIG_Architecture.doc D-2 DRAFT


– Spectrum 895 – Networking 896 – Computing Infrastructure 897

• DoD Directive 8320.2, Data Sharing in a Net-Centric Department of Defense 898

• Federal Enterprise Architecture Program, EA Assessment Framework 2.0 899 • Federal Enterprise Architecture Program, Data Reference Model 2.0 900

Key net-centric principles that must be adhered to are that data assets must be made visible, 901 accessible, understandable, and trusted (when referring to IA), and they must be enabled to 902 support interoperability. These principles do not assume or prescribe any requirements for 903 physical data storage. Data may be stored in any format using relational, object oriented, or 904 hybrid technologies based on any kind of data model. These principles do, however, require that 905 agreements be reached within the DoD EA Community of Interest (COI) or Community of 906 Practice (COP) on the structure and semantics of data elements used for data asset discovery, 907 linking, exchange, and integration. Metadata elements needed to support the EA user services 908 described herein are defined and proposed for DoD EA COI/COP acceptance as the standard for 909 net-centric federated EA services. 910


DRAFT

GIG_Architecture.doc E-1 DRAFT


APPENDIX E: ARCHITECTURE CATEGORIZATION, 911 STRUCTURE (TAXONOMY) 912

913

The top level of the DoD Federated EA taxonomy will initially consist of the four DoD 914 Business Reference Model (BRM) Mission Areas (MAs) [see Figure E-1] and be coordinated by 915 a federated DoD EA control board. 916

917

918 Figure E-1: Federated DoD EA Taxonomy 919

Table E-1 identifies MA Taxonomy Configuration Management (CM) Authorities that will 920 have autonomy for defining and managing a core set of taxonomy elements for each MA. 921 Mission area taxonomies should be derived from MA activity decomposition and synchronized 922 with the DoD BRM. 923

Table E-1: Federated DoD and MA Taxonomy CM Authority 924

BRM Mission Area Taxonomy Content CM Authority Decomposition Basis

Warfighting JS FCBs/JCAs Business BTA BEA (TBD) Intelligence DIA DoD BRM for Intel Enterprise Information Environment DoD CIO DoD BRM for EIE

The number of High-level taxonomy tiers defined and managed, as a core set will depend 925 on the degree to which the MA Taxonomy CM Authority wishes to exercise CM control over the 926 taxonomy structure. Decomposition levels below the MA core structure will be defined by DoD 927 Components, as authorized by the MA Taxonomy CM Authority. Each EA DoD Components’ 928

Service

Agency

COCOM

Warfighter M

A

Business M

A

Intel MA

EIE MA

Managed by MA Authority

Subordinate architectures mapped to

MA - level by Components

Federated

DoD

EA Control Board

Service

Agency

COCOM

Warfighter M

A

Business M

A

Intel MA

EIE MA

Managed by MA Authority

Subordinate architectures mapped to

MA - level by Components

Federated

DoD

EA Control Board


DRAFT

GIG_Architecture.doc E-2 DRAFT


architecture developer will classify its architectures in the DoD Architecture Registry System 929 (DARS) by associating DoD Components’ architectures with nodes of the MA core or authorized 930 DoD Component extensions to the core by registering Taxonomy Node and Association Type 931 metadata. 932

The Federated Joint Architecture Working Group (FJAWG) has already developed several 933 assessments and recommendations in regard to taxonomy, which are provided here for reference, 934 pending establishment of the formal structure for their implementation: 935

1. Mission Area Taxonomy CM Authorities must accept responsibility for defining 936 and managing MA core upper tier taxonomy nodes. Therefore, the EA summit 937 should adopt and promulgate the recommended EA High-level Taxonomy 938 strategy. 939

2. DoD Components will have autonomy in developing domain taxonomies. 940 However, domain architecture mappings and extensions to the MA core must be 941 regulated to minimize categorization redundancies. Therefore: 942 a. MA authorities should provide guidance on developing and mapping 943

domain extensions to the MA core, to include approval and mapping of 944 “authoritative” extensions. 945

b. The FJAWG should recommend guidance to MA authorities on regulating 946 DoD Component domain extensions and mappings to the MA core. 947

3. MA core taxonomies need to be coordinated to maximize uniqueness of top-948 level nodes and minimize potential categorization redundancy; and business 949 analysis needs may drive requirements for additional taxonomies to be 950 incorporated into the MA high-level taxonomy in the future. Therefore, a 951 Federated EA high-level taxonomy configuration control function and 952 governance should be established above the individual MAs for regulating the 953 high-level taxonomy structure and coordinating/de-conflicting the MA-954 taxonomy top-level nodes. Governance authority should be assigned to the 955 DoD Architecture Configuration Control Board (ACCB). Execution 956 responsibility should be assigned to the FJAWG as the technical advisor to the 957 ACCB. 958

Changes in the MA core taxonomies will impact alignments in the registry and should be 959 managed. Therefore, MA Authorities should develop and implement a core taxonomy CM 960 process subject to ACCB approval. 961


DRAFT

GIG_Architecture.doc F-1 DRAFT


APPENDIX F: DOD FEDERATED EA GOVERNANCE 962 DOCUMENT 963

964

Draft Governance Outline 965

Scope 966 Governance Framework 967 OASD/JS Level 968

• Authority 969 o Charter Development/Approval 970 o Organizational Framework 971

Governance Bodies 972 Voting Members 973 Stakeholder Participation 974

o Roles and Responsibilities 975 o Resource Requirements and Responsibilities 976

• Guidance 977 o Policies 978 o Synchronization 979 o Security/Access 980

Accreditation of content 981 Accreditation of members 982 Access control and privileges 983

o External Relationships 984 • Direction 985

o Standards 986 Tools 987 Metadata 988

o Quality 989 o Maturity Models 990 o Repositories 991 o Registries 992 o Data Management 993 o Services 994 o Configuration Management 995

• Monitoring 996 o Metrics 997 o Compliance 998

• Affirmation/Remediation 999 Mission Area and DoD Component Levels 1000

• Implementation Responsibilities 1001 • Monitoring Responsibilities 1002 • Affirmation/Remediation Responsibilities 1003 1004


DRAFT

GIG_Architecture.doc G-1 DRAFT


APPENDIX G: A DETAILED LIST OF CRITICAL SUCCESS 1005 FACTORS (CSF) BY CSF CATEGORY 1006

1007 • Commitment by DoD DoD Components to: 1008

o Actively participate in FJAWG effort 1009 o Maintain DoD Components -level architecture metadata 1010 o Be willing to participate in and support EA Federation PoC Pilot efforts 1011 o Organizations external to DoD that need to assist or provide access to information for 1012

identifying external architecture interface needs 1013 1014 • Adoption and implementation by DoD DoD Components of the following: 1015

o Federated EA registration and discovery services 1016 o Architecture federation rules 1017 o Federated EA metadata standards 1018 o Recommended Federation structure 1019 o EA Federation roles and responsibilities 1020 o Proposed high-level taxonomies 1021 o Standard methodologies for aligning and linking architectures 1022 o Architecture categorization schemes 1023 o Architecture federation governance 1024

1025 • Proof-of-Concept Pilot is needed to validate the following: 1026

o Applicability & effectiveness of proposed high-level taxonomies 1027 o Architecture configuration management 1028 o Architecture discovery capabilities and performance requirements are satisfied 1029 o Architecture governance at the all levels ensures integrity, visibility, accessibility, 1030

availability, understandability, and usability of architecture data by business/mission 1031 users 1032

o Architecture metadata at DoD Components level satisfies business/Mission Area 1033 information discovery needs 1034

o Architecture navigation and discovery provides correct architecture content 1035 o Architecture registration and discovery capabilities and performance requirements are 1036

satisfied 1037 o Capability to discover (and acquire) architecture content via navigation, search, and 1038

browsing services 1039 o Capability to provide and search on user-defined search criteria 1040 o Categorization schemes are effective in serving business and MA information 1041

discovery needs 1042 o Correctness of rules for federating architectures across the DoD 1043 o Discovery capabilities meet unanticipated user needs 1044 o Effectiveness and efficiency of architecture navigation schemes 1045 o Effectiveness and efficiency of registration service 1046 o Guidance for federation structure 1047 o Key interface points for linking architectures are the correct ones 1048 o Linkage to architectures external to the DoD EA Federation 1049 Deleted: DoD Enterprise Architecture


DRAFT

GIG_Architecture.doc G-2 DRAFT


o Linkages are established, on different platforms, with independent repositories within 1050 the federation 1051

o Viability and effectiveness of implemented EA Federation roles and responsibilities 1052 framework 1053

o Viability of accommodating various formats and toolsets 1054 1055

• Linking Business and Warfighting mission drivers/needs: 1056 o Alignment of operational activities 1057 o Identifying a “common scenario” applicable to the business or warfighting missions 1058 o Supporting IT enablers for the operational activities 1059

1060 • Resources at DoD Components and EA Federation levels must be available to: 1061

o Participate in and support the PoC Pilot efforts 1062 o Aid in identifying all architecture formats and toolsets in use 1063 o Identify interface needs 1064 o Assist in identifying architecture interface points 1065 o Develop and governance structure at DoD Enterprise and DoD Component levels 1066 o Develop and update architecture metadata at DoD Component level 1067 o Develop and update links to architecture content at the DoD Component level 1068 o Map Mission Areas to each other 1069 o Assist in DoD Component repository federation effort 1070

1071 • Adoption of DARS as the Federated EA Registry for Architecture - DARS must be: 1072

o Accessible and available across entire DoD 1073 o Intuitive, user-friendly, fast, responsive, and timely for architecture registration and 1074

discovery 1075 1076

• EA Federation Tools performance requirements involve the following: 1077 o Automated mapping and linking of architecture content 1078 o Applications that must have timely response times 1079 o Must be user-friendly, intuitive, fast online response 1080 o Interfaces that must be developed to accommodate all architecture formats and 1081

toolsets for architecture registration and discovery 1082 1083 • Knowledge and/or skills in: 1084

o Architectures external to the DoD that need to be interfaced with the Federated EA 1085 o DoD technology infrastructure 1086 o Existing disparate architectures across the DoD 1087 o Technologies and tools to provide linking to architecture content 1088 o Web technology 1089 o Metadata standards that need to be implemented 1090 o Architecture formats, methodologies, and toolsets 1091 o Prospective current and future types of unanticipated users of Federated EA 1092 o Types of architecture artifacts needed by unanticipated users 1093


DRAFT

GIG_Architecture.doc H-1 DRAFT


APPENDIX H: ACTIVITY-BASED EA FEDERATION 1094 ALIGNMENT 1095

1096 Activity-Relationship-Activity: 1097 1098

Federating the architecture in an enterprise requires a high-level taxonomy (under 1099 development) of the enterprise and an activity model for each DoD Componentof interest in the 1100 enterprise. The activities within the high-level taxonomy and DoD Components’ activity models 1101 will be related in one of the following four ways as illustrated in Figure H-1 below. 1102

• Equivalent to 1103 • Similar to 1104 • Part of 1105 • No relationship 1106

1107

1108 Figure H-1. Federation Relationships Among Activities 1109

A DoD Components’ activity is considered “equivalent to” a high-level activity if the 1110 descriptions and artifacts of both are identical. 1111

A DoD Components’ activity is considered “similar to” a high-level activity if the 1112 descriptions are the same but the primitives differ in some specification between the enterprise 1113 design and the DoD Components implementation, the activity is done differently by two or more 1114 DoD Components, or two or more DoD Components accomplish the same activity with different 1115 primitive specifications. 1116

A DoD Components’ activity is considered “part of” a high-level activity if the description 1117 of the DoD Components’ activity achieves part of the high-level activity’s goal, and another 1118


DRAFT

GIG_Architecture.doc H-2 DRAFT


DoD Components’ activity that also has a “part of” relationship with the same high-level activity 1119 completes the goal. 1120

If a DoD Components’ activity has no relationship with any of the high-level activities, 1121 then no relationship is shown. 1122

Relationships between the high-level and DoD Components’ activities can occur at any 1123 level of decomposition. 1124 1125


Documents

Department of Defense Enterprise Architecture Federation ...web.cse.msstate.edu/~hamilton/7700/resources/GIG_Architecture.pdf · 141 and its relationship between and among the entities