text: 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 f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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 ............................................................................. 16 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 f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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 f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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. f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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. f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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. f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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. f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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 f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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 f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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. f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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 f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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. f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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 C22.214.171.124, to use the SCOR processes of ―Plan, Source, Maintain/Make, Deliver, and Return as a framework for developing, improving, and conducting f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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.‖ f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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. f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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. f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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 f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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. f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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). f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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. f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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. f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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 f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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 f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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] f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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 f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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 f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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 f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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 f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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. f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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' f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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. f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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 f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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 f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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 f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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 f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.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 f6b5ff04-2be1-4bb6-a726-cf89229e2fa1.doc H-2 DRAFT


text:
EPA Copper Sulfate ALGAE CONTROL
LAKES, POTABLE WATER RESERVOIRS, PONDS (Golf, Farm, Fish and Fire), FISH HATCHERIES, AND CROP AND NON-CROP IRRIGATION CONVEYANCE SYSTEMS, DITCHES, CANALS, LATERALS AND SWIMMING POOLS
Buy EPA Copper Sulfate Crystals online at WHOLESALE PRICES!
It is better to Prevent pond algae problems than to Wait.
Our EPA Copper Sulfate Crystals are the purest you can buy.
Buy EPA Copper Sulfate Pond Algae Control Now!
EPA Copper Sulfate Crystal can be used in Slow Moving or Quiescent Bodies of Water, including: Lakes, Potable Water Reservoirs; Golf, Farm, Fish and Fire Ponds; Fish Hatcheries; and Crop and Non-Crop Irrigation Conveyance Systems, Ditches, Canals and Laterals.
LAKES, POTABLE WATER RESERVOIRS, PONDS (Golf, Farm, Fish and Fire), FISH HATCHERIES, AND CROP AND NON-CROP IRRIGATION CONVEYANCE SYSTEMS, DITCHES, CANALS AND LATERALS: EPA Copper Sulfate Crystal kills filamentous and planktonic algae in water. Apply at a rate of 3 to 6 pounds per acre foot of water (0.27 ppm to 0.54 ppm copper in the treated water). Apply as a uniform surface spray dissolved in at least 3 to 5 gallons of water using boat, plane or other pressurized spray device. Apply twice yearly or as needed. Determine the number of acre feet of water to be treated. An acre foot of water is equal to one acre of water one foot deep which equals 328,000 gallons or 2,720,000 pounds. An acre foot can also be defined as an area of water 660 feet X 66 feet X 1 foot depth.
How to Apply: EPA Copper Sulfate Crystal can be applied to impounded water by the following methods:
1. Application by Dragging Under Water: By placing EPA Copper Sulfate Crystal in a burlap or finer mesh bag, apply by dragging the bag attached to a boat or float so that bags are suspended in the top foot of water until the crystals are dissolved. Drag the bag of crystals first near the shoreline and continue outward by moving as the boat travels in parallel lines about 20 to 100 feet apart until area has been treated or until 1/3to 1/2 of the surface area has been treated. Continue dragging bag over treated area until the required minimum dose is applied and all crystals are dissolved. Determine the quantity of crystals needed to treat the problem area following directions and precautions on the label.
2. Application by Spraying Solution on Water Surface: Dissolve the minimum required dose of EPA Copper Sulfate Crystal in water and spray the solution uniformly over the body of water. When spraying a solution of copper sulfate, mix copper sulfate in sufficient water to thoroughly spray the water surface. While the volume per surface acre depends on the type of spray equipment being used, spray volume should be approximately 20 to 500 or more gallons per acre of surface water. Several types of solutions and spraying equipment may be used. Observe previous cautions on the effect of copper sulfate solution on various metals in spraying containers.
3. Application by Slug Method: Make a dump of EPA Copper Sulfate Crystal into the irrigation ditch or lateral at ¼ to 2 pounds per second of water per treatment. Repeat about every 2 weeks as needed. A dump is usually necessary every 5 to 30 miles depending on water hardness, alkalinity, and algae concentration. EPA Copper Sulfate becomes less effective as the bicarbonate alkalinity increases. Its effectiveness is significantly reduced when the bicarbonate alkalinity exceeds about 150 ppm as calcium carbonate (CaCO3).
4. Application by Broadcasting: Dry EPA Copper Sulfate Crystals can be broadcast on the water surface using a properly equipped boat. An air blower can be used to discharge these crystals at a specific rate over the surface of the water. When using this method, the wind direction is an important factor. Do not use this method unless completely familiar with this type of application.
5. Application by Spraying from Airplanes and Helicopters: Professional personnel licensed by the State Agricultural Extension Service are allowed to apply dry EPA Copper Sulfate Crystals in some states. Rate may not exceed 6 pounds per acre foot of water.
6. Application by Injection in Water: A solution can be made with EPA Copper Sulfate Crystals that can be injected in the water via a piping system.
CROP AND NON-CROP IRRIGATION CONVEYANCE SYSTEMS, DITCHES, CANALS AND LATERALS: EPA Copper Sulfate Crystals control the Potamogeton pondweeds, leafy and sago.
How to Apply: EPA Copper Sulfate Crystals can be applied to irrigation conveyance systems by the following methods:
1. Continuous Application Method: Using a continuous feeder, apply 1.6 to 2.4 pounds per cubic foot per second per day. These rates will produce 0.074 to 0.11 ppm copper in the treated water.
Note: For best control of leafy and sago pondweed, it is essential to begin epa copper sulfate additions when water is first turned into the system or ditch to be treated and continue throughout the irrigation season. Copper sulfate becomes less effective as the bicarbonate alkalinity increases. Its effectiveness is significantly reduced when the bicarbonate alkalinity exceeds about 150 ppm as calcium carbonate (CaCO3). Should epa copper sulfate fail to control pondweeds satisfactorily, it may be necessary to either treat the ditch with a suitable approved herbicide or use mechanical means to remove excess growth. In either case, resume epa copper sulfate addition as soon as possible.
CONTROL OF ALGAE AND BACTERIAL ODOR IN WATERSCAPES, DECORATIVE POOLS, AND FOUNTAINS (Except California):
Apply in the spring or early summer when algae and bacteria first appear. The dosages are variable and depend upon algae/bacteria species, water hardness, water temperature, amount of algae and bacteria present as well as whether the water is clear, turbid, flowing or static. Preferably, the water should be clear with temperatures above 60º F. Higher dosages are required at lower water temperatures, higher algae and bacteria concentrations and for hard waters. For each 7,500 gals. of water, dissolve ¼ lb. EPA Copper Sulfate Crystals in one gallon of water. Pour the solution into the water to be treated. Several application points speed up dispersal. Static water requires less chemical than does flowing water. If uncertain about the dosage, begin with a lower does and increase until control is achieved or until the maximum allowable level of copper has been reached.
CONTROL OF ALGAE AND BACTERIAL ODOR IN SWIMMING POOLS (Except California): Apply 1 to 2 lbs. of Copper Sulfate Crystal per 60,000 gals. (8,000 cu. ft.) of water. This will result in a concentration of 0.5 to 1.0 ppm of dissolved copper. Dissolve the required amount of copper sulfate in a plastic container and pour the solution into the pool. Use the higher rate where visible algae are present. For maintenance dosages, use the lower rate. Repeat the lower rate to control the recurrence of algae and avoid the buildup of copper. Copper Sulfate Crystal may be used to help control pool odors and algae during the winter months. Apply the higher rate while the pool is not being used during the winter. Treated pool effluent should not be discharged where it will drain into lakes, streams, ponds, or public water.
Calculate water volume as follows:
1. Obtain surface area by measuring regular shaped ponds or mapping of irregular ponds or by reference to previously recorded engineering data or maps.
2. Calculate average depth by sounding in a regular pattern and taking the mean of these readings or by reference to previously obtained data.
3. Multiply surface area in feet by average depth in feet to obtain cubic feet of water volume.
4. Multiply surface area in acres by average depth in feet to obtain total acre-feet of water volume.
Calculate weight of water to be treated as follows:
1. Multiply the volume in cubic feet by 62.44 to obtain total pounds of water, or
2. Multiply the volume in acre feet by 2,720,000 to obtain pounds of water
Calculations of active ingredient to be added:
To calculate the amount of EPA Copper Sulfate Pentahydrate needed to achieve the recommended concentration, multiply the weight of water by the recommended concentration of EPA Copper Sulfate. Since recommended concentrations are normally given in parts per million (ppm), it will first be necessary to convert the value in parts per million to a decimal equivalent. For example, 2 ppm is the same as 0.000002 when used in this calculation. Therefore, to calculate the amount of EPA Copper Sulfate Pentahydrate to treat 1 acre-foot of water with 2 ppm Copper Sulfate, the calculation would be as follows: 0.000002 x 2,720,000 = 5.44 lbs. EPA Copper Sulfate Pentahydrate.
Calculation of water flow in ditches, streams, and irrigation systems:
The amount of water flow in cubic feet per second is found by means of a weir or other measuring device.
NOTE: If treated water is to be used as potable water (after further treatment), the residual metallic copper content must not exceed 1.0 ppm (4 ppm copper sulfate pentahydrate).
PLEASE use our CONTACT FORM for questions.
All of the 50 Pounds bags with an EPA Label have full instructions on the bag for the EPA regulated claims on this site. These products are to be purchased if you plan on using the Copper Sulfate for Algae Control, Killing Roots, Fungicide or Bordeaux Mix.
All bag sizes of Copper Sulfate that do NOT have the EPA label on them have NO CLAIMS for Algae Control, Killing Roots, Fungicide, or Bordeaux Mix. If you are purchasing any of these NON EPA labeled products, it is just simply labeled "Copper Sulfate - Feed Grade" or "Copper Sulfate - Ag Grade" and is to be used for all non EPA regulated applications that are either listed on this site or others.
When placing an order, the purchaser acknowledges they have taken full responsibility to check and follow local, state and federal regulations regarding application of copper sulfate. Also, the purchaser assumes responsibility to follow proper handling and safety requirements for the product. The seller is not to be held accountable for any incidents of bodily or environmental harm due to improper handling and application.

subset: commoncrawl


text:
By entering this competition you agree to the
terms and conditions.
Oil Imports Ltd are the authorised importer and distributor of Total Lubricants in New Zealand.
Contracting / Commercial / Food Grade / Refrigeration /Industrial / Marine / Sawmills /
Power Generation / Automotive / Forestry and more. Talk to the technical experts.
Two Australian drivers will team up and go head to head against not one but two defending champions in the NZV8 Touring Cars TLX category this weekend at Pukekohe. Richards Team Motorsport have enlisted driver Scott Taylor into the team to pilot the second Toyota Camry... More
Defending NZV8 Touring Cars TLX champion Nick Ross will be aiming to win round two at Pukekohe Park Raceway this weekend and be the first man to take a V8 powered Nissan Altima to an overall round victory in the series. After driving a Holden Commodore to an overall victory... More
Any equipment that operates in the natural environment has the potential to be a source of pollution in the event of an accidental oil spillage.
This has to be one good reason for using biodegradable lubricants for your operations in the natural environment.
Greenplus by Amtex is a new range of forestry and sawmilling products produced by Greenland Corporation in Canada. We are the sole authorised importer and distributor for this range.
The Total Bio Lubricants range of products have broader uses including hydraulic, engine oils, gear oils and greases.


text:
If you ask a hot dog cart business owner if they have enough customers, 99 percent will say no. And 1 percent will be lying.
What if I told you that I'm pretty sure I can get your hot dog biz on the first page of Google?
Recently I have been doing that very thing for a few local businesses near me. You see, word has gotten around in my town that I'm "the guy who knows all that internet stuff" and business owner friends of mine have been asking me to help them with their online marketing.
When I think back I have to laugh. When I started my first hot dog biz in 2006 I could barely spell computer. I taught myself how to build a website because I wanted one for my business. Then I wanted to put my hot dog training online so I learned how to do that. One thing leads to another I guess.
Anyways, after a lot of trial and error I came up with a strategy that is putting local businesses on page one of Google very consistently. Sometimes multiple listings on page one.
I think it would be fun to test this brand new method with a few of my hot dog slinger friends. If you want your mobile food business to be ranked high on Google so that customers in your town can find you, then this is for you.
- This works even if you don't have a website yet.
- There is no work involved on your part.
- My marketing team and I will do everything.
If you are interested leave your name, phone number, city, and state in the comments below. Tell me a little about your business too. I won't be publishing these comments. No one will read them but me.
I will select a few slingers from the list. If you are one of these, I will personally give you a call to see if we are a good fit.
If chosen, I will create an online advertising package to promote your business. It will include a video commercial, a recorded audio interview with me on Hot Dog Cart Radio, a transcript of that interview, links to your Facebook page and website (if you have them – NOT mandatory) and any customer testimonials that you have collected (again, not mandatory).
There will be a small fee to cover my costs, but I think you will find that it is more than reasonable. It will be waaaay less than a local newspaper ad. If the price is OK with you then I will get started.
Name, Email, Phone, City, State and a little info about your hot dog biz.
In the comments below.
This is going to be awesome!
{ 0 comments }


text:
November 28, 2014
TOPEKA, Kan. (WIBW) - Gov. Sam Brownback has declared November as "Kansas Adoption month."
He signed the proclamation Friday morning at a Statehouse ceremony attended by several adoptive families.
More than 380 Kansas children are currently waiting for a permanent family.
Brownback has been a strong adoption advocate. He and his wife Mary have adopted 2 children themselves.
Angie and Darrin Reith were among the adoptive parents at Friday's ceremony. They say it means more to them than they could have ever thought.
"We have learned so many life lessons through adoption about forgiveness, love and resilience of children," Angie said.
"They bring joy and happiness and challenges," Darrin added. "It has changed our lives for the better."
13 News also supports finding children forever homes in our "Wednesday's Child" segment, Wednesdays on 13 News at 10.
Click Here to access the online Public Inspection File
Viewers with disabilities can get assistance accessing this station's FCC Public Inspection File by contacting the station with the information listed below. Questions or concerns relating to the accessibility of the FCC's online public file system should be directed to the FCC at 888-225-5322, 888-835-5322 (TTY), or firstname.lastname@example.com.