C4ISR Architecture Framework

The U.S. Department of Defense (DoD) has defined a framework for architecture development, presentation, and integration to be used across the military services and defense agencies. This framework defines a coordinated approach for the Command, Control, Computers, Communication, Intelligence, Surveillance, and Reconnaissance (C4ISR) military domains. The intent of the C4ISR Architecture Framework is to promote interoperable, integrated, and cost-effective computer-based systems within and across DoD organizations. This framework is becoming the required method for the description of information systems within the DoD and is also being adopted and mandated by several other U.S. government agencies.

The motivation for the development of this framework was the lack of a common approach for architecture development and use within the DoD. The architectures being developed by the various DoD organizations differ significantly in content and format, leading to the development of fielded products that are not interoperable. These differences also prohibit useful comparisons and contrasts when analyzing the various architectures. The C4ISR Architecture Framework is intended to provide a common lingua franca for the various DoD commands, services, and agencies to describe their diverse architectures. This is intended to help with cross-system analysis and fielded-system interoperability.

The framework differentiates between an architecture description and an architecture implementation. An architecture description is a representation of the parts, what those parts do, how they relate to one another, and under what rules and constraints. The C4ISR framework is concerned only with this representation, not the implementation in the field. This is the major difference between the C4ISR framework and the thrust of this book.

The C4ISR Architecture Framework has the following main components:

• Definition of common architectural views
• Guidance for developing the architecture
• Definition of common products
• Relevant reference resources

Our interest here is in the common views prescribed by the framework.

11.5.1 Common Architectural Views of the C4ISR Framework

The C4ISR Architecture Framework defines three views: operational, system, and technical. The C4ISR Framework does not map directly to our views. The C4ISR views can be summarized as follows:

• The operational architecture view is a description of the tasks and activities, operational elements, and information flows required to accomplish or to support operations. This view defines the types of information exchanged, the frequency of exchange, the tasks and activities supported by the information exchanges, and the nature of the information exchanges in enough detail to ascertain the relevant interoperability requirements.
• The systems architecture view is a description of systems and interconnections providing for and supporting the relevant requirements. This view associates physical resources and their performance attributes to the operational view and its requirements according to criteria defined in the technical architecture.
• The technical architecture view is a minimal set of rules governing the arrangements, interaction, and interdependence of system parts. This view articulates the criteria that describe compliant implementations of the various system capabilities.

To be consistent and integrated, an architecture description must provide explicit linkages among its views. This linkage is provided by the framework products.

11.5.2 Common Products

All the necessary C4ISR architecture representation products are defined by the framework, which contains detailed descriptions of the product types that must be used to describe operational, systems, and technical architecture views. In many cases, representation formats, product templates, and examples are also provided. The architecture products to be developed are classified into two categories.

• Essential products are the minimal set of products required to develop architectures that can be commonly understood and integrated within and across DoD organizational boundaries and between DoD and multinational elements. These products must be developed for all architectures.
• Supporting products provide data that will be needed for the particular purpose and objectives of a specific architectural effort. Appropriate products from the supporting product set will be developed on the basis of the purpose and objectives of the architecture.

Tables 11.10 and 11.11 summarize the essential and supporting products, respectively, defined by the C4ISR Architecture Framework. It must be said that C4ISR, for all its attention to architecture, in fact is directed almost exclusively to documenting system architecture. None of its three views and none of its essential or supporting products prescribe anything that remotely resembles software architecture. The operational architecture speaks in terms of user-visible operations. The system architecture addresses how those operations are carried out on physical resources, that is, hardware. And the technical architecture imposes rules and constraints, which in practice has come to mean the selection of a set of interface standards and nothing more. Nowhere is the software for the system described in terms of its structure or the behavior and interrelationships of the elements of that structure.

Table 11.10. C4ISR architecture framework essential products

Architecture Product	C4ISR Architecture View
Overview and Summary Information	All views
Integrated Dictionary	All views
High-Level Operational Concept Graphic	Operational
Operational Node Connectivity Description	Operational
Operational Information Exchange Matrix	Operational
System Interface Description	Systems
Technical Architecture Profile	Technical

Table 11.11. C4ISR architecture framework supporting products

Architecture Product	C4ISR Architecture View
Command Relationships Chart	Operational
Activity Model	Operational
Operational Activity Sequence and Timing Descriptions	Operational
Operational Activity Sequence and Timing DescriptionsOperational State Transition Description	Operational
Operational Activity Sequence and Timing DescriptionsOperational Event/Trace Description	Operational
Logical Data Model	Operational
Systems Communications Description	Systems
Systems2 Matrix	Systems
Systems Functionality Description	Systems
Operational Activity to System Function Traceability Matrix	Systems
System Information Exchange Matrix	Systems
System Performance Parameters Matrix	Systems
System Evolution Description	Systems
System Technology Forecast	Systems
System Activity Sequence and Timing Descriptions	Systems
Systems Activity Sequence and Timing DescriptionsSystems Rules Model	Systems
Systems Activity Sequence and Timing DescriptionsSystems State Transition Description	Systems
Systems Activity Sequence and Timing DescriptionsSystems Event/Trace Description	Systems
Physical Data Model	Systems
Standards Technology Forecast	Technical

That said, however, if you're mandated to use C4ISR, you do have options at your disposal. The first is to recognize the difference between software and system architecture and to recognize that a software-intensive system needs documentation for both. Render unto C4ISR what is C4ISR's, and provide documentation for the software architecture, using the guidance of this book, separately. The second option is to work the documentation for the software architecture into the framework prescribed by C4ISR. This is plan B, for sure, but serves when management, having been told to adopt C4ISR, balks at learning that something separate is needed for the software aspects.

• Include system-level behavior documentation as part of the C4ISR operational architecture view, concentrating on use cases that depict information exchange. Include this documentation in the "operational activity sequence and timing descriptions" products.
• Include element-level behavior documentation as part of the C4ISR systems architecture view. Include this documentation in the "systems activity sequence and timing descriptions" products.
• Include views belonging to the allocation viewtype as part of the C4ISR system architecture view, where "physical resources" are documented.
• Include views belonging to the module and C&C viewtypes as part of the C4ISR technical architecture view, appealing to it as the repository of "rules governing the arrangements, interaction, and interdependence of system parts" and "the criteria that describe compliant implementations."
• For the information contained in the beyond views part of the documentation, C4ISR provides slots for overview and summary information and a dictionary. Use the former to hold the documentation roadmap, the view template, the system overview, and systemwide rationale. The latter can be home to the mapping between views, the element directory, and the glossary.