GIG_Architecture

Document Sample
GIG_Architecture Powered By Docstoc
					                                                      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
20




     ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 11 Jan 07
     - A.doc
                                                    DRAFT
                                                                DRAFT


21                                                  TABLE OF CONTENTS
22
23   1.  Introduction ............................................................................................................ 1
24     1.1. Intended Audience .......................................................................................... 2
25     1.2. Background ..................................................................................................... 2
26     1.3. Related Guidance ............................................................................................ 4
27   2. Purpose ................................................................................................................... 4
28   3. Vision ...................................................................................................................... 4
29   4. Goals ....................................................................................................................... 4
30   5. Objectives ............................................................................................................... 4
31   6. Benefits ................................................................................................................... 5
32     6.1. Benefits to DoD Decision Makers .................................................................. 5
33     6.2. Benefits to DoD Architects............................................................................. 6
34     6.3. Benefits to Architectural Governance Bodies .............................................. 7
35   7. Guiding Principles ................................................................................................. 7
36   8. Scope ...................................................................................................................... 8
37   9. Federated EA Defined ............................................................................................ 8
38   10.   EA Federation Concepts .................................................................................... 9
39     10.1.    The EA Federation ....................................................................................... 9
40     10.2.    Tiered Accountability .................................................................................. 9
41     10.3.    High-level Taxonomies ............................................................................. 10
42     10.4.    Architecture Categorization ..................................................................... 10
43     10.5.    Context ....................................................................................................... 11
44     10.6.    Boundaries for Tiers ................................................................................. 11
45     10.7.    Semantic Alignment .................................................................................. 11
46   11.   EA Services — Making the EA Visible, Accessible, and Understandable ... 12
47     11.1.    Metadata ..................................................................................................... 12
48     11.2.    Registration ............................................................................................... 13
49     11.3.    Discovery ................................................................................................... 13
50   12.   Governance ....................................................................................................... 14
51     12.1.    EA Federation Roles and Responsibilities.............................................. 15
52     12.2.    Information Assurance ......................................................................... 1617
53   13.   Implementing the Federated EA ...................................................................... 17
54     13.1.    Pilot Efforts ................................................................................................ 17
55   14.   Critical Success Factors .................................................................................. 18
56   15.   The Way Ahead ................................................................................................. 18
57   APPENDIX A: ACRONYM LIST .................................................................................... 1
58   APPENDIX B: DEFINITIONS ........................................................................................ 1
59   APPENDIX C: REFERENCE DOCUMENTS ................................................................. 1
60   APPENDIX D: RELATED GUIDANCE .......................................................................... 1
61   APPENDIX E: ARCHITECTURE CATEGORIZATION, STRUCTURE (TAXONOMY) .. 1
62   APPENDIX F: DOD FEDERATED EA GOVERNANCE DOCUMENT........................... 1
63   APPENDIX G: A DETAILED LIST OF CRITICAL SUCCESS FACTORS (CSF) BY
64   CSF CATEGORY ............................................................................................................ 1
65   APPENDIX H: ACTIVITY-BASED EA FEDERATION ALIGNMENT ............................. 1
66
67
     ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 -
     A.doc                                                                                                       ii
                                                             DRAFT
                                                       DRAFT


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




     ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 -
     A.doc                                                                                                       iii
                                                     DRAFT
                                                          DRAFT



 81   1. Introduction
 82        The Department of Defense (DoD) Federated Enterprise Architecture (EA) represents the
 83   “next generation” Global Information Grid (GIG) Architecture.
 84
 85         The current GIG Architecture, along with the Net-Centric Operations and Warfare
 86   Reference Model (NCOW RM) is an overarching architecture description of the GIG.1
 87   However, the DoD is too large and complex to be described within a single integrated
 88   architecture. Additionally, Enterprise architectures have an inherent problem. To fully describe
 89   an enterprise, architects must either abstract the content into simple constructs that don’t lend
 90   themselves to supporting a broad range of decisions, or they must compile massive amounts of
 91   data that make comprehension difficult at best. One of the primary objectives of enterprise
 92   architectures is to describe the enterprise so that decision makers can make informed decisions
 93   based on or within a common context. It will result in the development of a cohesive EA
 94   supporting the alignment and integration of architecture efforts in support of DoD business and
 95   warfighter strategic goals. Therefore, architects must constantly balance complexity with utility.
 96   The DoD GIG Architecture is no different.
 97
 98         What is required is a rethinking of the GIG architecture concept to effectively leverage
 99   current architecture efforts and maintain comprehension while, at the same time, providing DoD
100   decision makers with the information they need. Federating existing architectures of DoD
101   elements that describe the various echelons (or tiers) is one way to achieve this goal. Federation
102   techniques allow disparate architectures (based on a variety of established frameworks) to be
103   meaningfully related and permit acceleration of new architecture efforts across the DoD
104   community to support DoD decision makers who require more detailed content that is not
105   reasonable for the department level.
106
107         To date, there have been advancements in both the architecture and stakeholder
108   communities that use architecture information. Architecture products, however, are presently not
109   as sufficiently discoverable and accessible as needed to support decision making. Today’s
110   architectures are built for specific purposes and viewpoints; they do not normally refer to or
111   relate to each other as they should to gain maximum value from the architecture investment.
112
113         As a remedy, the Department has chosen architecture federation2 as a new GIG architecture
114   paradigm. The next generation GIG architecture will be constructed by federating the separate
115   architecture artifacts throughout the DoD and employ a set of EA Services for registering,


      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.
      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 -
      A.doc                                                                                                       1
                                                        DRAFT
                                                           DRAFT

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

118       1.1.         Intended Audience
119          The primary audience for the DoD Federated Enterprise Architecture Strategy Document
120   includes two distinct classes — first, those responsible for implementation of the Federated EA,
121   and second, producers and consumers of architecture information, e.g., decision makers, program
122   managers, analysts, operators, architects, and engineers within DoD and external partners in the
123   extended enterprise.

124       1.2.         Background
125           The Director, Office of the Assistant Secretary of Defense for Networks and Information
126   Integration, Architecture & Interoperability (OASD[NII/A&I]) has worked with the Services
127   Chief Architects to define the federated approach. The federated approach will guide the
128   building of the next generation GIG Architecture. This approach recognizes the need for
129   autonomy but requires linkages and alignment of architectures from the Program level up to the
130   Federal Enterprise level. OASD(NII) will introduce requirements in phases to achieve enterprise-
131   wide GIG descriptions that move the Department toward a shared Net-Centric Vision and
132   Transition Plan. These requirements are being identified and met through systems engineering
133   processes that leverage architecture descriptions as blueprints. The use of shared architecture
134   descriptions in Test & Evaluation processes within the federated approach will provide the
135   ability to verify that capabilities are being fielded in accordance with (IAW) the GIG
136   Architecture.
137
138           There are challenges related to institutionalizing architecture into DoD core processes.
139
140           Challenge 1: There is no comprehensive architectural description of the DoD Enterprise
141   and its relationship between and among the entities that make up the enterprise that can be used
142   to support department-level decision making.
143
144           Challenge 2: Architectures are currently developed independently by many organizations
145   across DoD conforming to multiple frameworks. They are maintained in independent
146   repositories, and we assume this mode of operation will continue. This situation, however, raises
147   several concerns for architects and architecture end-users, specifically that there is no:
148               Capability to globally search, vertically or horizontally, for architectures
149                and/or artifacts3 that may be relevant for analysis, reference, or reuse
150               Consistent set of standards for architecture configuration management that
151                would enable users to determine the development status, quality, and authority
152                of data in various architectures and/or artifacts
153               Standard methodology for specifying linkages between architectures
154                developed using different tools and maintained in independent repositories
155                required to provide enterprise-wide context and understanding


      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.
      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 -
      A.doc                                                                                                       2
                                                        DRAFT
                                                       DRAFT


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



      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 -
      A.doc                                                                                                       3
                                                     DRAFT
                                                       DRAFT


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

206   2. Purpose
207         The purpose of this Strategy is to present an agreed upon method and strategy to achieve a
208   DoD Federated EA that would support decision makers in the DoD at the department level as
209   well as the DOD Components and Programs.
210
211         After months of study, OASD, with participation from the JS and DoD Components, has
212   determined that the best way to address the challenges presented above is to federate disparate
213   architectures into a DoD-wide Federated EA. The DoD Federated EA would be constructed
214   using a set of federation standards and Core Enterprise EA Services (registration, discovery, and
215   translation services).

216   3. Vision
217        The Federated EA vision is to provide DoD decision makers and their staffs’ access to a
218   broader and deeper architecture data set that is available, accessible, understandable, trustworthy,
219   and able to be tailored for decision support at the department and DoD Component levels.

220   4. Goals
221         The challenges identified in the Background paragraph serve as the drivers for this
222   Strategy. Their resolution can be found in the following goals necessary to achieve EA
223   Federation:
224         1) An environment to support the decision makers and their staffs with access to a
225            set of common architecture artifacts enabling common understanding of the
226            DoD Enterprise that can be used to support DoD decision making at the
227            enterprise and DoD Component levels
228         2) A means to identify internal and external interfaces to the DoD Enterprise
229         3) Improved EA information sharing of architectural content, ensuring that users,
230            including unintended users, can find and use the right information
231         4) Increased agility that leverages existing architecture and/or artifacts to swiftly
232            adjust or expand their capabilities through architecture reuse and integration to
233            meet their changing mission and business needs

234   5. Objectives
235        The following five objectives provide the focus for achieving the Goals identified above.
236   Achievement of all is critical for success.


      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 -
      A.doc                                                                                                       4
                                                     DRAFT
                                                       DRAFT

237         A.    Provide a structure for federating architectures to achieve the DoD EA and to
238               establish a means for autonomous development of DoD Component’s EA to support
239               tiered accountability. Related Goals: 1, 2, 3
240         B.    Provide guidance for federating architectures to achieve the DoD Federated EA and
241               to establish a means to allow each DoD Component to build its Architecture within
242               the guidance given by the Enterprise to support tiered accountability. Related Goals:
243               1, 2, 4
244         C.    Align DoD Component EA within a common framework of semantic
245               understanding .This common framework is based on the use of taxonomies from the
246               C/S/As and aligned with the Department level taxonomies to ensure that the DoD
247               Components can achieve standardization and semantic understanding with DoD
248               Component’s EAs. Related Goal: 1
249         D.    Leverage Core Enterprise EA Services to provide Architecture Registration and
250               Discovery Services that are available, accessible, and usable by consumers within the
251               enterprise to share architecture information both vertically and horizontally
252               throughout and achieve information visibility in a coherent manner. Related Goals:
253               1,3,4
254         E.    Provide a foundation to support emerging capabilities through Federated EA
255               services as a way of making the underlying business, mission, or transaction function
256               in a system or application available to a broad set of consumers. These services can
257               be easily reused and repurposed to provide building blocks for new capabilities. An
258               example of these services would be to provide specific analytic capabilities
259               leveraging EA holdings to support logistics, blue force tracking, and mission
260               planning. Related Goal: 3, 4

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

270       6.1.        Benefits to DoD Decision Makers
271
272   Enables Rapid Access to Information for Strategic Decisions:
273        Access to actionable, relevant, decision quality, architecture information will accelerate the
274   leaders’ ability to make better decisions that impact the enterprise (e.g., human resource
275   capabilities; condition, status, and location of assets; and how funds are invested for the
276   warfighting mission). The ability of the Federated EA to support these types of decisions is
277   content dependent.
278
      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 -
      A.doc                                                                                                       5
                                                     DRAFT
                                                       DRAFT

279   Improves Information Sharing of Architecture Content:
280        Populating the GIG with federated architecture products and leveraging Core Enterprise
281   Services to provide EA discovery and search services ensures that architecture information can
282   be accessed throughout the enterprise. Any user who has access to the GIG will be able to find
283   and use information from any Web-enabled device.
284
285   Understanding of Interactions and Interdependencies:
286         One of the primary uses of federation is to allow an Enterprise to understand the
287   interactions and interdependencies among its component parts. DoD needs to understand the
288   interactions among its major elements, the DoD Components, with the means to govern and
289   manage the Department “cross-functionally” to realize a cost-effective, Net-Centric GIG. The
290   Department recognizes that the exchanges among the domains are vital to modernizing the
291   enterprise. By understanding the minimum set of exchanges required, the enterprise can reduce
292   or eliminate unnecessary processes and the resources required to support those unnecessary
293   processes.
294
295   Supports Portfolio Management of Technology Options:
296         The Federated EA depicts the supporting technology and implementation as defined by the
297   program and DoD Component’s architectures, for each activity within the enterprise. By
298   evaluating the set of technologies across the Federated EA, the analyst or portfolio manager can
299   gain an understanding of multiple uses of the same technology and multiple technologies applied
300   to support the same type of activities.
301
302   Supports the Joint Warfighting Capability of the DoD:
303        Joint military requirements are driving the need for greater commonality and integration of
304   mission operations across the Department. The Department’s infrastructure must enable rapid
305   response to the warfighting community and be compatible with the global, networked military it
306   supports.
307
308   Reduced Cost of Defense Operations:
309         Streamlining operations using Operational Architecture View data will enable decision
310   makers to deal with growing pressures on resources and ensure every Defense dollar is optimally
311   applied for long-term mission effectiveness.

312       6.2.        Benefits to DoD Architects
313
314   Promotes Distributed Configuration Management:
315         Once the enterprise has federated its architecture, configuration management is reduced to
316   two efforts: maintenance of the federation and configuration of enterprise artifacts. As part of
317   the centralized control and decentralized execution of developing the enterprise architecture, the
318   enterprise can very tightly manage the high-level taxonomies, the relationships with the DoD
319   Component’s activities, and the enterprise list of instances for each.
320
321   Provides Clear “stopping” rules for Enterprise Architecture Development:
322         When developing enterprise architectures, the greatest mistake comes from overstepping
323   the scope of the department level description. No architect should ever develop details that are
      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 -
      A.doc                                                                                                       6
                                                     DRAFT
                                                       DRAFT

324   clearly in the purview of a lower-level tier. For example, the department level does not have the
325   authority or expertise to develop the details as well as the DoD Components. Once the
326   relationship is established between high-level taxonomies and a DoD Component’s architecture
327   artifact, the department level should then cease its examination of details and point to the DoD
328   Components. The DoD Component maintains the responsibility and authority to detail the
329   artifact and define how the enterprise achieves the goal.
330
331   Increases Agility:
332         This benefit is the natural result of the use of Web-based services for registration and
333   discovery, which are modular, reusable, interoperable building blocks. Users can search the
334   Federated EA Registry and find existing architecture content, significantly reducing the time and
335   cost for new architecture development, fielding of a new capability, and gaining improved
336   interoperability “out of the box.” By using these building blocks, warfighters can swiftly adjust
337   their architectures to meet changing business and mission needs.

338       6.3.        Benefits to Architectural Governance Bodies
339
340   Sets Enterprise Boundaries:
341          A Federated EA with activity-based alignment shows each DoD Component’s activities
342   and how they relate to achieving the enterprise’s goals. The relationships among the activities
343   identify the activities that are “owned” or performed uniquely and those that are shared by one or
344   more of the DoD Components. Once all the activities of the Enterprise are related to the
345   activities of the DoD Components, then the collection of all activities owned by a single DoD
346   Component sets boundaries throughout the Enterprise. Boundaries are vertical and horizontal
347   start and stop points for accountability in the roles and responsibilities for Federated EA’s.
348
349   Promotes Autonomy or Self-Governance:
350        A federated architecture supports a governance structure that defines the responsibility and
351   authority among Components to achieve and support enterprise-wide goals. Once a DoD
352   Component accepts its defined boundary, as depicted within the federated architecture, it enjoys
353   autonomous control of the development and analysis of its architecture. The DoD Components
354   determine the breadth and depth of detail relating to their individual architecture, and produce
355   and archive the artifacts, as required, to meet or support the goals of the enterprise.

356   7. Guiding Principles
357         In an effort to gain the most re-use out of existing architecture artifacts, and to minimize
358   the need for additional architecture development, the development of the DoD EA Federation is
359   guided by the principles below. The Federated EA will:
360             Respect the diverse requirements of individual DoD Component while focusing
361              on the associations that cut across organizational boundaries IAW statutory
362              roles and responsibilities for the DoD Components.
363             Focus on federating existing disparate architecture artifacts regardless of
364              structure and format – not re-building architectures.
365             Maximize the reuse of existing architectures at all tiers.
      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 -
      A.doc                                                                                                       7
                                                     DRAFT
                                                                      DRAFT


366               Evolve from a product-centric approach (focused on DoDAF and other work
367                products produced by architecture developers) towards a data-centric
368                architecture approach focusing on common semantics.
369               Support DoD’s net-centricity objectives (e.g., make information and services
370                visible, accessible, and understandable) and vision.

371   8. Scope
372        This Strategy encompasses DoD architectures at all levels of detail and classification. It
373   defines or references interfaces to architectures outside the Department under the Federal
374   Enterprise Architecture Framework (FEAF) and the Federal Enterprise Architecture Reference
375   Models.4 The GIG, a Federated EA, will not be isolated to IT but will have relevance for
376   Doctrine, Organization, Training, Material, Leadership and education, Personnel, and Facilities
377   (DOTMLPF), as the use and utility of architecture expand in those areas.
378
379          This Strategy is applicable to all DoD Mission Areas and addresses the relationships among
380   all levels of enterprise details from the program/initiative level up to the Department level. This
381   Strategy will:
382               Define architecture federation and integration concepts.
383               Define architecture alignment (linking and mapping) processes.
384               Define EA Services for registering and discovery of architecture holdings and
385                associated metadata.
386
387         This Strategy will accommodate the range of architecture formats, methodologies, toolsets,
388   and levels of abstraction, and will be applicable to multiple decision processes.
389
390        As part of this Strategy, Policy, Governance, and Implementation Planning documents will
391   need to be defined and developed to support the vision and goals of this strategy.

392   9. Federated EA Defined
393         We use the term Federated Architecture to represent the concept that architecture artifacts
394   are related in a meaningful way. Federated Architectures conform to common or shared
395   architecture standards across autonomous Program, DoD Component, Mission Area enabling
396   developing/owning entities to maintain diversity and uniqueness, while providing opportunity for
397   implementing interoperability.5
      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

      5
          Adapted from New York State Office for Technology – see definitions
      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 -
      A.doc                                                                                                       8
                                                                   DRAFT
                                                       DRAFT

398
399          A Federated Enterprise Architecture shows how a DoD Component aligns activities,
400   services, systems, and infrastructure with federation standard taxonomies, providing context.
401   Initially, EA federation will be based on semantic alignment of each Program, DoD Component,
402   Mission Area, architecture’s top-level activity with the Enterprise’s top-level taxonomy of
403   activities called the “High-level Taxonomy.” An example of “High-level Taxonomy” is the
404   implementation of the BEA activity model which serves as the Business Mission Area’s
405   (BMA’s) “High-level Taxonomy” for DoD Component alignment. Semantic Alignment will be
406   based on the context6 of the architectures and the individual activities being related – for DoDAF
407   architectures this is normally identified in the (OV-5). Semantic alignment of other architectural
408   elements will be pursued, as needed, to support key decision processes and as other federation
409   high-level taxonomies are developed.
410
411        Federated Architecture shows the allocation of responsibility across the Enterprise. In
412   contrast, Integrated Architecture shows the interaction of multiple activities to achieve a mission
413   or goal across the Enterprise.
414
415         Federation is a way to organize an enterprise’s body of knowledge (architecture) about its
416   activities (processes), people, and things within a defined context and current/future
417   environment. Federation provides the architect-analyst additional means to examine aspects of
418   the DOTMLPF concepts across organizational boundaries.

419   10. EA Federation Concepts
420   10.1. The EA Federation
421            This section identifies key concepts that define the Federated Enterprise Architecture
422   elements. These concepts are important to understanding Federation and how it is most useful in
423   supporting decision making and Tiered Accountability. These concepts enable Department-wide
424   producers and consumers to achieve the Goals and Objectives of a Federated EA.

425   10.2. Tiered Accountability
426             Tiered accountability is distribution of authority and responsibility of an element of the
427   enterprise architecture to an organization. Through the policy of Tiered Accountability (TA),
428   DoD addresses the responsibility for producing these EA architecture artifacts. Under TA, DoD
429   is currently defining and building enterprise-wide capabilities that include data standards,
430   business rules, enabling systems, and an associated layer of interfaces for Enterprise, Mission
431   Area, DoD Components, and Programs. Each tier of the enterprise – Department, Mission Area,
432   DoD Components, and Program – has specific goals, as well as responsibilities to the tiers above
433   or below them.
434
435           Each tier has full authority and responsibility to develop their portion of the EA.
436   Unfortunately, data between tiers are often unavailable via an accurate, timely, and reliable



      6
          See definition on page 10.
      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 -
      A.doc                                                                                                       9
                                                     DRAFT
                                                        DRAFT

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

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

447   10.4. Architecture Categorization
448             DoD EA DoD Component’s architectures need to be categorized to facilitate alignment
449   (mapping and linking), cataloging, navigating and searching disparate architecture in a DoD
450   registry of holdings, and providing a framework for aligning architectures. This Strategy
451   identifies four major levels of echelon and taxonomies to be used for categorization Figure x:
452                Department (OSD, JCS, etc)
453                DoD Mission Area (Warfighting, Business, DIMA, and EIE Mission Areas)
454                DoD Component (Army, JFCOM, DLA, etc)
455                Program (NECC, FCS, etc)
456
457

                                                    Department



                                               Mission Area



                                            Component


                                          Program

458
459
460                      Figure 1 Architecture Levels for Tiered Accountability
461
462           Where possible, this should include identifying a common reference language 8 or
463   model applicable to the mission areas that can be used by all participating architectures. These

      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
      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 -
      A.doc                                                                                                       10
                                                      DRAFT
                                                        DRAFT

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

469   10.5. Context
470           Context defines the environment of the enterprise architecture. Five basic questions
471   make up the Context and help to fully define the external environment of the enterprise.
472
473             1) What is the purpose of the architecture effort and what are the questions to
474                be addressed by this architecture effort?
475             2) What is the boundary of the enterprise? What is considered inside the
476                enterprise versus external?
477             3) What is the scope of the architecture effort, what are the echelons or
478                organizational levels involved, and what level of detail will be required in
479                the descriptions?
480             4) What is the viewpoint of the architecture? From who’s perspective do we
481                examine the enterprise and write the descriptions (external customer,
482                supplier, or casual observer; internal role player; or process owner)?
483             5) What echelons are represented by the architecture?
484            The Context should be defined before the architecture effort is begun and articulated
485   within the AV-1. The context is part of the architecture’s metadata, which can be used for
486   discovery, semantic alignment, and contextual comparison with other architecture efforts.

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

491   10.7. Semantic Alignment
492
493             A key goal of net-centricity is to enable semantic understanding of data so that
494   interoperability can be achieved between any applications that have the ability to access and
495   interpret the structural and semantic rules associated with data.
496
497             The Federated EA will be based on the semantic alignment of tier level architecture
498   elements with elements of federation high-level taxonomies. Semantic alignment refers to the
499   relationship specified between the meanings of taxonomy elements. The semantic relationships
500   specified between activities will typically include “is equivalent to,” “is part of,” or “is similar
501   to.” These relationships provide the alignment between the elements of DoD Component’s

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

      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 -
      A.doc                                                                                                       11
                                                      DRAFT
                                                        DRAFT

502   C/S/As architectures and the high-level reference taxonomies that specify the interface points in
503   the federation for tiered accountability of the Federated EA content.
504
505            Through Tiered Accountability, Stakeholders and the DoD Components will retain the
506   authority to manage their own internal Architecture holdings, consistent with federation
507   standards or methodologies. However, the federated EA governance body at the appropriate tier
508   will have responsibility for capturing semantic consistency out of the separate DoD Components
509   and communities of interest/practice, defining the semantic (meaning) and syntactical (structure)
510   standards that will provide for consistent usage and meaning. Where possible, external and
511   industry standards will be considered for incorporation. Specifics on how semantic alignment
512   can be achieved will be included in the Federated EA Implementation Plan.

513   11. EA Services — Making the EA Visible, Accessible, and
514       Understandable
515         In order to make the EA visible, accessible, and understandable9, EA Services will be
516   implemented using Web Services, in which specific content and/or functionality is provided by
517   one user for others, many of whom may be unanticipated by the provider (see Figure 1). The
518   return on investment in the Federated EA will result from DoD providers continually populating
519   the Federated EA with architecture data and products that satisfy a variety of anticipated and
520   unanticipated consumer needs. This will require the following development of standards and
521   services:
522            A set of standard metadata will be maintained for all architectures in
523             confederating repositories and Web service specifications (Web service
524             definition language [WSDL]) for discovery and registration.
525            A registration service will enable cataloging and linking of architectures in
526             federated repositories.
527            A discovery service will enable users to execute a federated search for
528             architecture holdings meeting specified search parameters.
529
530   The following paragraphs elaborate on those concepts.

531   11.1. Metadata
532             To implement a Federated EA search service, metadata elements must be defined to
533   capture attributes of artifacts required to support search parameters based on user needs. The
534   DoD Discovery Metadata Specification (DDMS) V1.3 provides a baseline specification for
535   architecture discovery metadata. The architecture conceptual model (currently the CADM)
536   provides additional AV-1 discovery metadata specifications. Several new metadata elements,
537   defined as “DDMS Plus” metadata, enable configuration management, architecture registration,
538   and cataloging.
539            Data may be stored in any format using relational, object oriented, or hybrid
540   technologies based on any kind of data model. These principles do, however, require that
      9
        Visible, Accessible, and Understandable are key Net-Centric concepts from the NCOW RM v1.1 as integrated
      from the Net-Centric Strategies.
      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 -
      A.doc                                                                                                       12
                                                      DRAFT
                                                        DRAFT

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

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

552   11.3. Discovery
553             The Federated EA will include a federated metadata discovery capability. The intent is
554   to provide a user-friendly service that enables discovery of architecture metadata available from
555   federated repositories. Federated repositories are achieved when sources of similar content can
556   be searched via enterprise services. It will also enable the user to follow links to the source
557   architectures in the federated repositories. Specifics on the implementation of this tool will be
558   contained in the Federated EA Services Implementation Guidance Document.
559            The following sections address the two primary modes of discovery, registry browsing
560   and searching.
561
562   Registry Browsing:
563         Users may browse a catalog of holdings for Federated EA repositories to find artifacts of
564   interest. Cataloging of repository holdings should enable users to search for artifacts by
565   navigating categorization taxonomies similar to browsing item categorizations in online
566   shopping Web sites. Multiple categorizations may apply to any single architecture. Catalog
567   navigation trees should use standardized category names from “approved” enterprise
568   taxonomies, when available, and may be extended by domain extensions where needed.
569   Navigation trees should provide links to detailed metadata on architecture holdings to enable
570   users to determine potential interest value and include links to the products in source repositories
571   to enable user access to selected products.
572
573   Searching:
574         An architecture search capability must enable a user to specify a set of criteria for
575   architecture artifacts of interest. A single search interface using that set of search criteria needs
576   to be able to reach all architecture data repositories and present a consolidated response to the
577   user. The consolidated response, at a minimum, should:
578            Provide sufficient metadata on holdings, so that users can ascertain their
579             relevance.
580            Provide links to the results, taking the user to the source repository consistent
581             with the user’s role-based access privileges.
      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 -
      A.doc                                                                                                       13
                                                      DRAFT
                                                        DRAFT


582            Include all available architecture metadata, including metadata not specified as
583             search parameters.
584         Figure 2 illustrates the concept for the proposed Core Enterprise EA Services/DARS
585   implementation for the DoD Federated EA Services. It illustrates metadata registration and
586   discovery of architecture content within the federated repositories required to make the enterprise
587   architecture data visible, accessible, and understandable for the DoD community.
588




589
590                             Figure 2: Making Architecture Accessible

591   12. Governance
592         Since the Federated EA is not a unitary architecture, it will require a governance structure
593   to provide direction and oversight within the framework of TA and the existing DoD and DoD
594   Component governance structures. The DoD CIO, or the CIO’s delegate, will serve as the
595   ultimate chairperson for management of the Federated EA. However, due to the complex
596   relationships between the architecture producers/developers at various levels, the governance
597   roles within the Federated EA will vary according to roles within Tiered Accountability.
598         1) At the Enterprise or OASD/JS-level, governance will address DoD-wide
599            Authority, Direction, Guidance, Monitoring, and Affirmation/Remediation.
600         2) At the Mission Area-level, governance will address Implementation,
601            Monitoring, and Affirmation/Remediation in response to DoD-wide guidance as
602            well as Mission Area unique Authority, Direction, and Guidance.
603         3) Similarly, the DoD Component-level, governance will address Implementation,
604            Monitoring, and Affirmation/Remediation in response to DoD-wide guidance

      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 -
      A.doc                                                                                                       14
                                                      DRAFT
                                                        DRAFT

605             and Mission Area input, as well as individual DoD Component requirements for
606             Authority, Direction, and Guidance.
607
608        The details for governance will be provided in a separate document, the planned DoD
609   Federated EA Governance Document. It will address areas such as:
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
612         A tentative outline for Governance is provided in Appendix F.

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

619            Each Tier has both internal and external roles and responsibilities that it must perform
620   to make the Federated EA function as intended. These are presented in Table 1, where external
621   roles and responsibilities are denoted with a star (*) and internal roles and responsibilities are
622   denoted with a square (■).
623
624          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.
       Develop       top-level    taxonomies     and
                                                               Store, publish, and maintain federation
                                                                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.
      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 -
      A.doc                                                                                                       15
                                                      DRAFT
                                                           DRAFT

          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
        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.
625
                             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’
          architecture and mapping results.            Adhere to the standards for data sharing
                                                        established by the Enterprise, MAs, and DoD
         Extend high-level taxonomies.
                                                        Components.
626
627       Additional roles and responsibilities will be identified, as required, within the Governance
628   Document. Detailed roles and responsibilities specific to each level will be outlined in the DoD
629   EA Federation Implementation Plan.

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


      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 -
      A.doc                                                                                                       16
                                                      DRAFT
                                                        DRAFT


635   13. Implementing the Federated EA
636        As an integral part of this Strategy, a detailed Implementation Plan will be provided as a
637   separate document.

638   13.1. Pilot Efforts
639             There are two primary areas of interest for Proof-of-Concept (PoC) Pilot efforts. One is
640   to build and analyze a Federated EA using the DoD High-level Activity Taxonomy, a Mission
641   Area Taxonomy, and DoD Components’ architecture. The other is to build and demonstrate EA
642   Services with an initial focusing on Registration and Discovery Services.
643   Enterprise Federation – Federated EA Pilot
644       The first pilot will build and analyze a Federated EA using the DoD High-level Activity
645   Taxonomy, Mission Area Taxonomy, and DoD Components’ architecture. OASD(NII) and the
646   EA Summit are currently evaluating candidates for this pilot.

647   EA Services — The DARS Pilot for Registration and Discovery
648         For the second pilot – registration and discovery capabilities – EA Registration and
649   Discovery Services will be implemented initially as Core Enterprise EA Services in DARS and a
650   selected set of federated repositories. These capabilities will then be federated to other DoD
651   Components’ repositories, resulting in a more robust department-level capability. Using this
652   federated capability, a search request on one repository, e.g., DARS, will result in a returned set
653   of records matching the search criteria and will contain as much of the architecture metadata as is
654   available from each of the federated repositories having holdings that match the search criteria.
655   URLs in the reply metadata set will provide links to the source architectures in the federated
656   repositories.
657         An architecture search capability should enable a user to specify a set of criteria for
658   architecture artifacts of interest. Users should be able to specify specific search criteria in a
659   search GUI using methods such as pick lists for the allowable values for each of the criteria.
660   That set of search criteria needs to be propagated to all architecture data repositories. The user
661   then needs to receive a single consolidated response that:
662            Provides consistent metadata from all sources
663            Provides sufficient metadata to enable the user to ascertain their relevance
664            Provides links to the sources
665         Once a user determines which architecture artifacts are of interest, a link associated with
666   each result will take the user to the source repository. Depending on the security policy of the
667   source repository, the link may either provide direct access to the selected artifact in the native
668   repository format or visualization environment, or, in future versions; it may direct the user to a
669   role subscription service on the native repository for requesting access to the product. User
670   credentials may also be passed by the search service to the source repository for authentication to
671   enable automated access based on access roles/privileges associated with the user in the source
672   repository.



      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 -
      A.doc                                                                                                       17
                                                      DRAFT
                                                        DRAFT


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

678        Following is a list of broad categories of candidate Critical Success Factors (CSF) related
679   to the institutionalizing of a DoD Federated Architecture environment. The broad CSF
680   categories are:
681            Required commitment by OSD, JS, and DoD DoD Components for participation
682             in the FJAWG,
683            Adoption and implementation by OSD, JS, and DoD DoD Components for
684             architecture governance, registration, high-level taxonomies, federation levels,
685             roles and responsibilities, federation methodologies, etc.
686            Selection and successful implementation of a PoC Pilot in order to validate EA
687             Federation concepts, governance, methods, tools, high-level taxonomies, etc.
688            Linking Business and Warfighting mission drivers/needs.
689            Commitment of resources at OSD, JS, and DoD DoD Components to support
690             federation development and implementation.
691            Adoption of DARS as the Federated EA Registry.
692
693         Appendix G contains a detailed list of CSFs within each category.

694   15. The Way Ahead
695         To begin implementation of this Strategy:
696            OSD Leadership, working with the DoD Components and other stakeholders,
697             will articulate details required for implementation.
698            Registry and repository owners will work with the registry pilot lead on
699             federating discovery services.
700            FJAWG as the EA Summit arm will complete the development of the high-level
701             activity taxonomies.
702            The community will define how linkages are managed between the Tiers in the
703             Federation.
704            DARS will implement the linkages between the Tiers in accordance with the
705             community requirements as a community extension to Core Enterprise EA
706             Services for EA.
707            Mission Area Leads will define their high-level taxonomies for inclusion in the
708             DoD EA Reference Models.


      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 22 Jan 07 -
      A.doc                                                                                                       18
                                                      DRAFT
                                                        DRAFT



709                              APPENDIX A: ACRONYM LIST
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
      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 26 Dec 06 -
      B.doc                                        A-1
                                                     DRAFT
                                                        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




      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 26 Dec 06 -
      B.doc                                        A-2
                                                     DRAFT
                                                         DRAFT



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


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


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




      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 26 Dec 06 -
      B.doc                                        B-3
                                                     DRAFT
                                                        DRAFT



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

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

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




      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 26 Dec 06 -
      B.doc                                        C-1
                                                     DRAFT
                                                        DRAFT



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

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




      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 26 Dec 06 -
      B.doc                                        D-2
                                                     DRAFT
                                                        DRAFT



911               APPENDIX E: ARCHITECTURE CATEGORIZATION,
912                       STRUCTURE (TAXONOMY)
913
914         The top level of the DoD Federated EA taxonomy will initially consist of the four DoD
915   Business Reference Model (BRM) Mission Areas (MAs) [see Figure E-1] and be coordinated by
916   a federated DoD EA control board.
917

                                 Federated DoD EA Control Board

                      Warfighter                Business                 Intel                  EIE
                                                                                              EIE MA
                        MA                        MA                      MA                    MA




           Managed by
           MA Authority



                              Service                      Agency                      COCOM


                                                  Subordinate architectures
                                              mapped to MA-level by Components
918
919                             Figure E-1: Federated DoD EA Taxonomy
920         Table E-1 identifies MA Taxonomy Configuration Management (CM) Authorities that will
921   have autonomy for defining and managing a core set of taxonomy elements for each MA.
922   Mission area taxonomies should be derived from MA activity decomposition and synchronized
923   with the DoD BRM.
924                  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
925        The number of High-level taxonomy tiers defined and managed, as a core set will depend
926   on the degree to which the MA Taxonomy CM Authority wishes to exercise CM control over the
927   taxonomy structure. Decomposition levels below the MA core structure will be defined by DoD
928   Components, as authorized by the MA Taxonomy CM Authority. Each EA DoD Components’
      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 26 Dec 06 -
      B.doc                                        E-1
                                                     DRAFT
                                                        DRAFT

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




      ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 26 Dec 06 -
      B.doc                                        E-2
                                                     DRAFT
                                                         DRAFT



 962           APPENDIX F: DOD FEDERATED EA GOVERNANCE
 963                           DOCUMENT
 964
 965   Draft Governance Outline
 966   Scope
 967   Governance Framework
 968   OASD/JS Level
 969       Authority
 970             o Charter Development/Approval
 971             o Organizational Framework
 972                        Governance Bodies
 973                        Voting Members
 974                        Stakeholder Participation
 975             o Roles and Responsibilities
 976             o Resource Requirements and Responsibilities
 977       Guidance
 978             o Policies
 979             o Synchronization
 980             o Security/Access
 981                        Accreditation of content
 982                        Accreditation of members
 983                        Access control and privileges
 984             o External Relationships
 985       Direction
 986             o Standards
 987                        Tools
 988                        Metadata
 989             o Quality
 990             o Maturity Models
 991             o Repositories
 992             o Registries
 993             o Data Management
 994             o Services
 995             o Configuration Management
 996       Monitoring
 997             o Metrics
 998             o Compliance
 999       Affirmation/Remediation
1000   Mission Area and DoD Component Levels
1001       Implementation Responsibilities
1002       Monitoring Responsibilities
1003       Affirmation/Remediation Responsibilities
1004
       ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 26 Dec 06 -
       B.doc                                        F-1
                                                      DRAFT
                                                         DRAFT



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

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


       ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 26 Dec 06 -
       B.doc                                        G-2
                                                      DRAFT
                                                                  DRAFT



1094             APPENDIX H: ACTIVITY-BASED EA FEDERATION
1095                            ALIGNMENT
1096
1097   Activity-Relationship-Activity:
1098
1099         Federating the architecture in an enterprise requires a high-level taxonomy (under
1100   development) of the enterprise and an activity model for each DoD Componentof interest in the
1101   enterprise. The activities within the high-level taxonomy and DoD Components’ activity models
1102   will be related in one of the following four ways as illustrated in Figure H-1 below.
1103            Equivalent to
1104            Similar to
1105            Part of
1106         
                 Federated Architecture Relationships
                 No relationship
1107

                                                            High-level Activity Taxonomy




                                           …                                               …


                        FM                                             IL                        AFMC
                                                                   Is Equivalent to               Is Similar to
                                                                                               Is Equivalentto

                                               Is Part of
1108
1109                     Figure H-1. Federation Relationships Among Activities

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

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

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

       ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 26 Dec 06 -
       B.doc                                        H-1
                                                              DRAFT
                                                         DRAFT

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

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

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




       ba52d915-42f1-48f6-84d4-3214f0215837.docDoD Enterprise Architecture Federation Strategy v1_01 - 26 Dec 06 -
       B.doc                                        H-2
                                                      DRAFT

				
DOCUMENT INFO
Categories:
Tags:
Stats:
views:1
posted:7/30/2012
language:English
pages:36