|
NOTICE:
TIEMS Transportation Safety and Security Workshop January 28-29th 2003
|
Welcome to
the
Institute for Crisis, Disaster, and Risk Management Crisis and Emergency Management
|
| January 2003
Volume 3 - Number
4 |
|
Links:
Current events
|
Developing a Command, Control, Communications
and Intelligence Architecture
Process for the Department of Homeland Security
By Dana Griffin
PURPOSE This report presents a methodology for developing a Department of Homeland Security (DHS) Command, Control, Communications, Computers and Intelligence (C4I) Architecture Process for the development and presentation of a nationwide, standardized set of DHS C4I architectures for the DHS and DHS associated agencies. The Process provides the rules, guidance, and product descriptions for developing and presenting architecture descriptions that ensure a common denominator for understanding, comparing, and integrating architectures. The application of the Process will enable architectures to contribute most effectively to building interoperable and cost-effective DHS C4I systems. OBJECTIVE AND SCOPE The Process would provide the standardized guidelines by which the requirements and capabilities of DHS C4I architectures would be developed with the focus on supporting to the end user. The objective is this paper is to develop a common unifying approach for Federal, State and local DHS and DHS associated agencies to follow in developing their various C4I architectures requirements and capabilities. While the specific focus is on C4I, the approach defined herein is readily extendible to other functional areas as personnel management, acquisition, and finance. The Process provides direction on how to describe architectures requirements and capabilities; the Process does not provide guidance in how to design or implement a specific architecture or how to develop and acquire systems. The distinction between architecture description and architecture implementation is important to understand and a more in depth discussion of this should be the subject of a separate paper. The Process provides a “product-focused” method for standardizing architecture requirements and capabilities descriptions. First and foremost, the products are primarily intended to represent consistent architectural information for establishing acquisition funding requirements. However, as will be discussed in the Operational architecture, standardized lexicons/definitions, policies and procedures are an initial by-product of this effort, for without these, there is no foundation upon which to build any C4I architecture Process. The goal is to eventually reach an “information-focused” method for consistent, integrated and inter-operable DHS architectures. The standardizing of these architecture products is the only practical approach. BACKGROUND Prior to September 11, 2001, there had been no common approach for architecture development and use within the Federal government other than in DoD. The individual Departments, Services, and Agencies traditionally developed their C4I architectures using techniques, vocabularies, and presentation schemes that suited their unique needs and purposes. In recent years, National Military Strategy has placed a clearly increasing focus on Joint and multi-national military operations. Moreover, resource reductions and government-wide streamlining and downsizing initiatives have placed a premium on finding opportunities for cross-organization leveraging, increased collaboration, and redefined ways of doing business. Architectures provide a process for finding these opportunities. In October 1995, the Deputy Secretary of Defense directed that a DoD-wide effort be undertaken “... to define and develop better means and processes for ensuring that C4I capabilities meet the needs of warfighters (end users).” To accomplish this goal, the C4ISR Integration Task Force (ITF) was established under the direction of the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASD [C3I]). This task force, consisting of representatives from the Joint Chiefs of Staff, the military Services, and Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASD [C3I]). Agencies, organized itself into sets of panels and sub-panels, each charged with tackling a different aspect of the problem. This group included the Defense Information Systems Agency (DISA) which is responsible to DoD as well as rest of the Federal government for the oversight of C4I operational processes, systems standards and technical standards. This does not include doctrine, techniques or procedures, as these are left to the specific departments and agencies. The Integrated Architectures Panel (IAP) of the ITF provided the foundation for the first version of the DoD C4I Architecture Process policy by defining three related architecture types: operational, systems, and technical. This initial development of a common C4ISR Architecture Framework (Process) approach (Version 1.0) built upon other architecture efforts within the DoD capitalizing on many of their concepts and ideas. Version 1.0 was intended to provide a basis from which the community could work collectively to evolve and mature architecture development concepts and promulgate them as DoD direction via appropriate DoD policy directives and guidance instructions. Version 1.0 has been replaced by Version 2.0, which will be replaced by a newer version within the next year. Crisis and Emergency Management, in the United States, did not have such an ongoing effort prior to Sept 11, 2001, nor does it currently have such an effort ongoing. THE PAST VERSUS THE PROPOSED. As nothing previously existed to address this issue, there is nothing to make a comparison of between the past and the proposed. Thus this paper is focused on providing a process to use to establish the necessary C4I infrastructure needed to address the current and future needs of Crisis and Emergency Management, especially in light of the establishment of the Department of Homeland Security. Thus the objective of the paper will be presented by discussing the C4I Architecture Process via view’ and how they interrelate and combine to create an overarching C4I Architecture Process. ARCHITECTURE VIEWS — DEFINITIONS, ROLES, AND LINKAGES The IEEE STD 610.12, as extended slightly by the IAP of the ITF, defines “architecture” as “the structure of components, their relationships, and the principles and guidelines governing their design and evolution over time.” An architecture description is a representation, as of a current or future point in time, of a defined “domain” in terms of its component parts, what those parts do, how the parts relate to each other, and the rules and constraints under which the parts function. What constitutes each of the elements of the above definitions depends on the degree of detail of interest. For example, “domains” can be at any level, from DHS as a whole down to individual functional areas or groups of functional areas. “Component parts” can be anything from “The Secret Service” as a component of DHS, down to a satellite ground station as a component of a communications network, or “workstation A” as a component of system x. “What those parts do” can be as general as their high-level operational concept or as specific as the lowest-level action they perform. “How they relate to each other” can mean something as general as how organizations fit into a very high-level command structure or as specific as what frequency one component uses in communicating with another. “The rules and constraints under which they work” can mean something as general as high-level doctrine or as specific as the e-mail standard they must use. It is important to note the difference between an architecture description and an architecture implementation. As stated above, an architecture description is a representation or “blueprint” of a current or postulated “real-world” configuration of requirements resources, rules, and relationships. Once the blueprint enters the design, development, and acquisition process, the architecture description is then transformed into a real implementation of capabilities and assets in the field. The Process does not address this blueprint-to-implementation transformation process. DEFINITIONS OF THE ARCHITECTURE VIEWS There are three major perspectives, i.e., views, that logically combine to describe an architecture. These three architecture views are the operational, systems, and technical views. Each of the three architecture views has implications on which architecture characteristics are to be considered and/or displayed, though there is often some degree of redundancy in displaying certain characteristics from one view to another. Because the views provide different perspectives on the same architecture, it is expected that, in most cases, the most useful architecture description will be an “integrated” one, i.e., one that consists of multiple views. Compared to a single-view architecture description, an integrated architecture description often can provide closer linkage to the planning, programming, and budgeting process and to the acquisition process, and can provide more useful information to those processes. Definition of the Operational Architecture View. The operational architecture view is a description of the tasks and activities, operational elements, and information flows required to by an agency/organization or multiple agencies/organizations to accomplish or support an operation. It contains descriptions (often graphical) of the operational elements, assigned tasks and activities, and information flows required to support the end user. It defines the types of information exchanged, the frequency of exchange, which tasks and activities are supported by the information exchanges, and the nature of information exchanges in detail sufficient to ascertain specific interoperability requirements. The basic tenets that apply to the operational architecture view include the following: • The primary purpose of an operational architecture is to define operational elements, activities and tasks, and information exchange requirements. • Operational architectures incorporate doctrine and assigned tasks and activities. • Activities and information-Exchange Requirements (IERs) may cross-organizational boundaries. • Operational architectures are not generally systems-dependent. • Generic activity descriptions are not based on an organizational model or force structure. • Operational architectures should clearly identify the time phase(s) covered (e.g., specific years; “as-is” or “to-be;” “baseline,” “planned,” and/or “transitional, etc.”). Definition of the Systems Architecture View. The systems architecture view is a description, including graphics, of systems and Inter-connections providing for, or supporting, end user functions. For a domain, the systems architecture view shows how the multiple systems of an agency/organization or multiple agencies/organizations link and interoperate, and may describe the internal construction and operations of particular systems within the architecture. For the individual system, the systems architecture view includes the physical connection, location, and identification of key nodes (including materiel item nodes), circuits, networks, platforms, etc., and specifies system and component performance parameters (e.g., mean time between failure, maintainability, availability). The systems architecture view associates physical resources and their performance attributes to the operational view and its requirements per standards defined in the technical architecture. The basic tenets A systems architecture include the following: • The primary purpose of a systems architecture is to enable or facilitate operational tasks and activities through the application of physical resources • Systems architectures map systems with their associated platforms, functions, and characteristics back to the operational architecture • Systems architectures identify system interfaces and define the connectivity between systems. • Systems architectures define system constraints and bounds of system performance behavior. • Systems architectures are technology-dependent, show how multiple systems within a subject area link and interoperate, and may describe the internals of particular systems. • Systems architectures can support multiple organizations and missions. • Systems architectures should clearly identify the time phase(s) covered. • Systems architectures are based upon and constrained by technical architectures. Definition of the Technical Architecture View The technical architecture view is the minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements, whose purpose is to ensure that a conformant system satisfies a specified set of requirements. The technical architecture view provides the technical systems-implementation guidelines upon which engineering specifications are based, common building blocks are established, and product lines are developed. The technical architecture view includes a collection of the technical standards, conventions, rules and criteria that govern system services, interfaces, and relationships for particular systems architecture views and that relate to particular operational views. The basic tenets, of a technical architecture view, include the following: • Technical architecture views are based on associations between operational requirements and their supporting systems, enabling technologies, and appropriate interoperability criteria. • The primary purpose of a technical architecture is to define the set of standards and rules that govern system implementation and system operation. • A technical architecture profile is constructed from an enterprise-wide set of standards and design rules for specific standards contained in the Joint Technical Architecture and other applicable standards documents. • The technical architecture standards and criteria should reflect multiple information system implementation paradigms. • Technical architecture profiles account for the requirements of multi-node and network interconnections among all systems that produce, use, or exchange information electronically for a specifically bounded architecture configuration. • Technical architectures must accommodate new technology, evolving standards, and the phasing out of old technology. • Technical architectures should be driven by commercial standards and direction. REPRESENTATIVE ROLES OF THE OPERATIONAL, SYSTEMS, AND TECHNICAL ARCHITECTURE VIEWS End user information capabilities must be able to “plug and play” in a local, regional, nationwide or global environment. To achieve this ability, there must be a mechanism for incorporating information technology consistently, controlling the configuration of technical components, and ensuring compliance with technical “building codes.” Architectures provide this mechanism. Architectures are developed according to a defined scope and within a specific context. The scope includes the architecture type, subject area, and time frame for which the architecture is applicable. In general, the subject area for operational architecture views could theoretically be based upon such mission areas as Law-enforcement Operations, Emergency Response Operations, Anti-terrorism Defense, etc. or based upon operational processes such as planning, response, situational awareness, etc. The interrelated conditions that compose the setting in which the architecture exists constitute the context for the architecture. The context includes such things as policy/doctrine; process/tactics, techniques, and procedures; relevant goals and vision statements; and concepts of operations, scenarios, and environmental conditions. High-level, broad-scope architectures embrace the range of potential physical, and geo-political environmental conditions so that the resulting architectures are highly stable and are relatively insensitive to moderate changes in environmental conditions. Specific environmental conditions (e.g., threats, weather, geographical features, and scenario) are reflected in the doctrine, techniques and response plans and may also be more directly reflected in lower-level, issue-focused architectures (i.e., local Fire, EMS and Law-enforcement architectures). These specific conditions can be used to enhance operation planning and execution through more concrete planning support and less reactionary operation execution. In the context of C4I architectures, system architecture views are expected to address the full range of systems from sensors that collect information and pass it on, through processing and information systems, communications systems, and users that require information to accomplish their objectives. System architecture views depict the functional and physical automated systems, nodes, platforms, communications paths, and other critical elements that provide for supporting information-exchange requirements (IERs) and end user tasks described in the operational architecture views. Various attributes of the systems, nodes, and required information exchanges are included according to the purpose of the specific architecture effort. Well-planned and comprehensive technical architecture views facilitate integration and promote interoperability across systems and compatibility among related architectures. As part of a disciplined process to build systems, technical architecture views reduce information technology costs across an organization by highlighting risks, identifying technical or programmatic issues, and driving technology reuse. Adherence to a technical architecture streamlines and accelerates systems definition, approval, and implementation. Role of the Operational Architecture View The operational architecture view describes the tasks and activities of concern and the information exchanges required. These kinds of descriptions are useful for facilitating a number of actions and assessments across DHS and DHS associated agencies such as examining business processes for reengineering or technology insertion, training personnel, examining doctrinal and policy implications, coordinating Joint and multi-agency relationships, and defining the operational requirements to be supported by physical resources and systems, e.g., communications throughput, specific node-to-node interoperability levels, information transaction time windows, and security protection needed. Operational architecture views are generally independent of organization or force structures. However, for some specific purposes, it may be necessary to document how business processes are performed under current structures in order to examine possible changes to those business processes under a different structure. Operational architecture views are generally driven by doctrine. However, in some cases, events compel an organization to operate in a way that is not compliant with doctrine. In those cases, it may be useful to build an architecture description that shows how the organization really does operate, so its operations can be analyzed and a way can be found to either to bring the operations into compliance with doctrine or to present a case to change doctrine. In some cases, actual (“as-is”) operations cannot be conducted strictly in conformance with current policy because of inefficiencies induced, for example, by lack of supporting infrastructure or node and information-exchange degradation resulting from threats or acts of nature. Operational architectures are generally independent of technology. Sometimes, however, relationships may be influenced, or “pushed,” by new capabilities such as collaboration technology, where process “improvements” are in practice before policy can reflect the new procedures. There may be some cases, as well, in which it is necessary to document the way processes are performed given the restrictions of current systems, in order to examine ways in which new systems could facilitate streamlining the processes. Operational architecture views can describe activities and information exchange requirements at any level of detail and to any breadth of scope that is appropriate for the use or purpose at hand. It may be necessary to show only broad functional areas, in which case the information exchanges would be depicted at a commensurately high level. At a lower level of detail, for a different purpose, it may be necessary to show specific node-to-node information exchanges and the details of the exchanges if articulating interoperability-level distinctions and requirements is the focus. At an even lower level of detail, for still another purpose, it may be necessary to show how specific information supports a specific unit during particular circumstances, such as how specific information supports the National Infrastructure Protection Center (NIPC) Role of the Systems Architecture View DoD defines a “system” as “any organized assembly of resources and procedures united and regulated by interaction or interdependence to accomplish a set of specific functions.” In the context of the Process, a “system” may be a partially or fully automated system, or may be a non-automated system, such as some weapon systems. The systems architecture view describes the systems of concern and the connections among those systems in context with the operational architecture view. The systems architecture view may be used for many purposes, including, for example, systems base-lining, making investment decisions concerning cost-effective ways to satisfy requirements, and evaluating interoperability improvements. A systems architecture view addresses specific technologies and “systems.” These technologies can be existing, emerging, planned, or conceptual, depending on the purpose that the architecture effort is trying to facilitate (e.g., reflection of the “as-is” state, transition to a “to-be” state, or analysis of future investment strategies). A systems architecture view will need to take the information exchanges described in the operational view down a level in order to translate node-to-node exchanges into system-to-system transactions, communications capacity requirements, security protection needs, et cetera. For other purposes, it may be necessary to go further and to break down system-to-system information exchanges down into the applications that support the production and transmission of specific data elements of those exchanges. For the latter case, an modeling the information at a corresponding level of detail would be useful, specifically, one that includes the applications and their attributes and relationships. An important point to make here is that, the degree of granularity of the operational architecture view should be driven by the type of systems analysis or assessments that are of interest. Since examination of current and postulated system characteristics must be performed in context with operational missions and requirements in order to have real meaning, then the nature of the systems investigation dictates which operational requirements attributes need to be articulated. Role of the Technical Architecture View The technical architecture view describes a profile of a minimal set of time-phased standards and rules governing the implementation, arrangement, interaction, and interdependence of system elements. The appropriate use of the technical architecture view is to promote efficiency and interoperability, and to ensure that developers can adequately plan for evolution. There are a number of existing technical references available from the IEEE, DoD, DISA , and Organization-level and Agency-level. Current examples are DoD’s Joint Technical Architecture (JTA), DISA Levels of Information Systems Interoperability (LISI), as well as numerous DISA and DoD policies, directives, and conventions, in addition to Service-level and Agency-level policies, directives, and conventions. In many cases, an effort to develop a technical architecture view consists of extracting the portions of these sources that are applicable to the scope of the architecture description being developed, and tailoring their guidance to the purpose at hand. With respect to system-to-system interoperability, the technical architecture view delineates the technical implementation criteria or “rules” with which the system(s) should comply as reflected in the systems architecture view. LINKAGES AMONG THE ARCHITECTURE VIEWS To be consistent and integrated, an architecture description must provide explicit linkages among its various views. Such linkages are also needed to provide a cohesive audit trail from integrated mission operational requirements and measures of effectiveness (MOEs) to the supporting systems and their characteristics, and to the specific technical criteria governing the acquisition/ development of the supporting systems. The linkages serve to describe the interrelationships among the three architecture views. “Interoperability” is a typical architecture focus that demonstrates the criticality of developing these inter-view relationships. The operational view describes the nature of each organization/agency information exchange requirements in detail sufficient to determine what specific degree of information-exchange interoperability is required. The systems view identifies which systems support the requirement, translates the required degree of interoperability into a set of system capabilities needed, and compares current/postulated implementations with the needed capabilities. The technical view articulates the criteria that should govern the compliant implementation of each required system capability. The ITMRA requires organizations to define measures of performance for evaluating the impact and progress of their information systems. Integrated architecture descriptions (those that consist of more than one view) are essential to meet this requirement. For example, systems and/or system attributes (identified in the systems architecture view) and their “measures of performance” must be assessed with respect to the utility they provide to the missions (identified in the operational architecture view in terms of “measures of effectiveness”). Similarly, systems must be assessed with respect to the standards and conventions that apply (identified in the technical architecture view). Conclusion As outlined above, the operational architecture description provides detail regarding the information-exchange, interoperability, and performance parameters required to support a particular mission and task. The systems architecture description defines system attributes, and provides the basis for comparing system performance against operational requirements. The technical architecture description defines the specific implementation criteria that will result in the fielding of an interoperable system. Thus, the descriptions of the three architecture views and their interrelationships provide the basis for deriving measures such as interoperability or performance and also provide the basis for measuring the impact of these metrics on operational mission and task effectiveness. The impact of the derived metrics will provide the justification necessary to establish and execute an acquisition strategy that undoubtedly will be required by the DHS to establish and implement a nationwide its C4I capability. Additionally, even if billions of dollars are available to purchase C4I systems, without a C4I Architecture Process, good money will only be thrown away and a great deal of time and effort wasted without an implementation plan that properly links all DHS and DHS associated agencies’ operational, system and technical architectures into a common overarching interoperable C4I architecture. Recommendation As DISA has an existing responsibility to support a C4I Architecture Process, the DHS should immediately involve DISA in establishing, developing and implementing an overall DHS C4I Architecture Process. BIBLIOGRAPHY. Subject Type Source Date DoDD 4630.5 Interoperability and Supportability of IT Systems Directive 11 January 2002 DoDD 4630.8 Procedures for Inter-operability and Supportability of IT Directive 02 May 2002 CJCSI 6212.01B Interoperability and Supportability of IT Instruction 8 May 2000 DoD 5000.1 C4ISR Support Plans and the Chairman’s Program Recommendations Regarding C4ISR Studies in Excess of $500k Memorandum USD(A&T), ASD(C3I), VCJCS 16 July 1997 DoD 5000.2-R Mandatory Procedures for MDAPs and MAIS Acquisition Programs (includes Change 3) paragraph 2.2.1 Procedure DoD 5000.2R 23 March 1998 C4ISR Architecture Framework Document v2.0 Document OASD(C3I) 18 December 1997 Requirements Generation System Instruction CJCSI 3170.01 10 Aug 1999 C3I Memorandum on Requirements for Compliance Memorandum A&T, Comptroller 1 May 1997 Memo on Designation of Major Special Interest Initiatives & Related Oversight Requirements Memorandum OASD(C3I) 27 February 1998 Satellite Communications Instruction CJCSI 6250 20 October 1998 ACROYNMS: ASD [C3I] Assistant Secretary of Defense for Command, Control, Communications, and Intelligence C4I Command, Control, Communications, Computers and Intelligence (C4I) DHS Department of Homeland Security DISA Defense Information Systems Agency DoD Department of Defense EMS Emergency Medical Services GPRA Government Performance and Results Act of 1993 IAP Integrated Architectures Panel ITF Integration Task Force ITMRA Information Technology Management Reform Act JTA Joint Technical Architecture LISI Levels of Information Systems Interoperability SAR Search and Rescue DEFINITIONS Element An organization or a portion of an organization or a type of organization. Note: Operational Architectures typically represent an element within an operational node. Information The refinement of data through known conventions and context for purposes of imparting knowledge. Information Exchange Requirement Specific requirements placed on the content of an information flow. Requirement Associated with an IER are such performance attributes as information size, throughput, timeliness, quality, and quantity values. Mission An objective together with the purpose of the intended action. Needline A requirement that is the logical expression of the need to transfer information among nodes (e.g., operational elements, system) Network The joining of two or more nodes for a specific purpose. Node A representation of an element of architecture that produces, consumes or processes data. Operational Node. A node that performs a role or mission. Organization. An administrative structure with a mission. Platform. A system that is a physical structure that hosts systems or systems components. Process. A group of logically related activities required to execute a specific task or group of tasks. Requirement. A need or demand. Role. A function or position Service. A distinct part of the functionality that is provided a system element on one side of an interface to a system element on the other side of an interface. (Derived from IEEE 1003.0) System. A collection of components organized to accomplish a specific function or set of functions. (IEEE 610.12) System Element. Subset of a system that maintains a separate identity and performs a specific function. System Function. A data transform that supports the automation of activities or exchange requirements. Systems Node. A node with the identification and allocation of resources (e.g., people, platforms, facilities, or systems) required to implement specific roles and missions. Rule. Statement that defines or constrains some aspect of the enterprise. Task. A discrete unit of work, not specific to a single organization, weapon system, or individual, that enables missions or functions to be accomplished. |