The systems architecture view is a description, including graphics, of systems and interconnections providing for, or supporting, war fighting functions. For a domain, the systems architecture view shows how multiple systems link and interoperate, and may describe the internal construction and operations of particular systems in 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, war fighting 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 following standards apply to the systems architecture:
▪The primary purpose of a systems architecture is to enable or facilitate operational tasks and activities through the application of physical resources
▪Map systems with their associated platforms, functions, and characteristics back to the operational architecture
▪Identify system interfaces and define the connectivity between systems
▪Define system constraints and bounds of system performance behavior
▪Systems architectures are technology-dependent, show how multiple systems in 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
SV-11 physical data models
You use the physical data model (PDM) to describe how the information represented in the logical data model is actually implemented in the systems architecture view. The physical data model shows how the information-exchange requirements are actually implemented. It also shows how both data entities and their relationships are maintained.
There should be a mapping from a given Logical Data Model to the Physical Data Model if both models are used. The form of the Physical Data Model can vary greatly depending on your project requirements. Consider the following options when creating your physical data model:
▪Create an additional IDEF1X-style diagram
▪Use Data Definition Language in cases where shared databases are used to integrate systems
▪For message oriented-implementations, use references to message format standards
▪The message format standards identify the message types and options that are used.
▪Use descriptions of file formats when file passing is the mode used to exchange information
Interoperating systems can use a variety of techniques to exchange data, and therefore have several distinct partitions in their physical data model with each partition using a different form
SV-12 service provision diagrams
The MODAF 1.2 specification shows how Service is related to Resource Type, which is an abstract type instantiated by concrete definitions such as Capability Configuration, Organizational Resource, and Software.
You can model the following artifacts on an SV-12 diagram:
Service
A high-level Service.
Resource Type
A general Resource that should have a one-to-one correspondence to a concrete resource that can be drawn on an SV-1 diagram. Concrete resources include the following elements: Capability Configuration, Software, System Resource, Physical Asset, Platform, Role Type, Organisation Type, and Post Type.
Service Level line
Drawn between a Resource Type symbol and a Service symbol, it is keyed to both definitions. You should name the line for the “deployed service level.” Once drawn, you can examine the Service Level definitions in the Explorer to quickly see deployed service levels, and see what Resource deploys what Service.
Note The Resource definition does not have a property that lists Services. To see what Resources deploy what Service, you can run a report that captures the information of what Service Level lines connect what Resource to what Service, via the Reporting system or the Explorer diagram.