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:
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:
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.
|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|
|Architecture Product||C4ISR Architecture View|
|Command Relationships Chart||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|
|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.
Software Architectures and Documentation
Part I. Software Architecture Viewtypes and Styles
The Module Viewtype
Styles of the Module Viewtype
The Component-and-Connector Viewtype
Styles of the Component-and-Connector Viewtype
The Allocation Viewtype and Styles
Part II. Software Architecture Documentation in Practice
Documenting Software Interfaces
Choosing the Views
Building the Documentation Package
Other Views and Beyond
Rationale, Background, and Design Constraints