Augmented Product Purpose. In a net-centric architecture, the SV-4b is used to document service functionality that is exposed to the NCE, their respective grouping into service families, and their service specifications. It is the SV counterpart to OV-5. Although there is a correlation between OV-5 or business-process hierarchies and the service functional hierarchy of SV-4b, it need not be a one-to-one mapping, hence, the need for the Operational Activity to Services Traceability Matrix (SV-5c), which provides that mapping.
Net-Centric Product Description. The SV-4a traditionally describes system functions and the flow of system data between functions and correlated to SV-1 and SV-2 systems. In the NCE, the SV-4b should capture and depict how services are orchestrated together to deliver functionality associated with an operational need. In industry, this is often referred to as composeable applications.
Services are a key means to share information and capabilities in the NCE and can be captured in the SV-4b by relevant service groupings or families to assist in understanding how a set of services align with an operational domain or a system capability. The SV-4b also documents the data flows between services and may represent external services, systems, or humans that interact with the service. Multiple SV-4b products can be utilized to show deeper levels of detail as system nodes are decomposed into service families which further decompose into services that consist of specific operations and data.
In the NCE, services require robust and consistent descriptions to operate in the NCE where service capabilities are discoverable and able to be consumed in a scalable and flexible manner. The SV-4b should capture and depict information about each service that collectively represents
the service specification. A service specification should be provided for each service that is or
will be provided to the NCE. The service specification enables services to be documented in a
consistent manner, and the DoD-wide SST should be used to the extent possible for describing each service. Regardless of the precise SST, the necessary minimum subset of information from the SST for each service must be captured in the SV-4b:
- Interface Model Category includes information of the service specification that
identifies the service and enables service consumers to discover the service and determine the service’s suitability for their needs. It also provides assistance in the usage of the service, and includes service policies and the following types of
attributes:
o Service Name is a short descriptive name for the service to be provided and
as it appears in the SV-1.
o Service Version identifies the latest revision level of the service.
o Service Description is a textual narrative that describes the service offering
and its purpose.
- Service Access Point Information Category includes information of the service
specification that identifies the lifecycle step of the service:
o SAP Type identifies the lifecycle phase of the capability (e.g., Development,
- Information Model Category includes information of the service specification that
identifies the data types that are used to interact with the service.
o Data Types refers to the URI that points to documentation of complex data
types and data structures that are used.
- Point Of Contact Information Category includes information on the types of
contacts associated with a service, which may include developers, managers, or maintenance organizations.
- Service Access Point Information Category includes technology implementation
details that identify the physical infrastructure the service is or can be deployed upon including hardware, software, message transport, and facilities. It is here (vs. the SV-1) where the transport binding details for the message exchange between services are captured (i.e., SOAP over HTTP, IDL over binary, XML over HTTP).
- Quality Model Category includes information on any performance considerations
for service deployment.
o Service Level Specifications identifies performance specification details
that stipulate expected service performance under identified circumstances and quality of service levels.
In addition to the SST elements, DODAF v1.5 extends the service interface specifications to include a Service Provider element. The Service Provider element identifies the organization
providing the service (the organization that is the Service Functionality Provider operational role from the OV-2).
For the Information Model Category of the SST,DoDAF v1.5 also extends the minimum set
of information to include the following attributes:
- Overview identifies the attributes that include the name of the operation, a narrative
that describes the operation, and the message Flow Pattern.
- Effects refer to the results that may come from invoking the operation.
- WSDL is the URI that points to a file that is composed of a bundle of other files
including a WSDL and any supporting files for that WSDL.
Additional elements from the service specification categories are identified and documented within other architecture views, resulting in an integrated view of the service specification across architecture products.
As programs develop their SV-4s to document functions and services for systems, it may be difficult to distinguish between a service and a system function. Producing separate SV-4 products for system functions and services may enable the delineation between the two, particularly in hybrid environments. A new SV-4 product, the Service Function Decomposition only depicts the services decomposition, while maintaining compatibility of the SV-4 that depicts system functions.
Figure 5-23 shows a template for the functional decomposition model for services of a net- centric SV-4b. It illustrates a hierarchy of services, with a high-level service or service family representation at its top. If the higher-level representation is a service family, services underneath it are those that are grouped into the service family. If the higher-level representation is an
individual service, the services below it are one that the higher-level service orchestrates to produce other functionality. Higher-level services or individual services may be represented in the SV-1 and may be mapped to services one-to-one or decomposed in the SV-4b. Points to note about the SV-4b are: 1) services may or may not be grouped into a service family 2) services can be decomposed into other services which are orchestrated together to provide other functionality, 3) Multiple SV-4b’s can be used to highlight different service families or different orchestrations of services. Service/Service Family Service 3 Service 1 Service 2 Service 21 Service 22 Service/Service Family Service 3 Service 1 Service 2 Service 21 Service 22
Figure 5-23: Notional Example: SV-4b: Functional Decomposition
Figure 5-24 shows a template for the Data Flow Diagram for services of a net- centric SV-4b. The ovals represent services, the squares are external system data sources and sinks, and the arrows represent the direction of the system data flows. The template illustrates exchanges between services internal to a view, between services internal to a view and services external to it, and services internal to a view and a web-portal external to it.
Service 1 Service 3 Service 2 Service 4 External System 1 Data Flow 1 Data Flow 2 Data Flow 3
External Service 1 Data Flow 4 External Portal 1
Data Flow 5 Data Flow 6 Data Flow 7 Data Flow 8 Data Flow 9
Figure 5-24: Notional Example: SV-4b: Data Flow Diagram