DODAF - DOD Architecture Framework Version 2.02 - DOD Deputy Chief Information Officer

DoDAF Viewpoints and Models

Services Viewpoint

SvcV-1: Services Context Description

The SvcV-1 addresses the composition and interaction of Services. For DoDAF V2.0, SvcV-1 incorporates human elements as types of Performers - Organizations and Personnel Types.

The SvcV-1 links together the operational and services architecture models by depicting how resources are structured and interact to realize the logical architecture specified in an OV-2 Operational Resource Flow Description. A SvcV-1 may represent the realization of a requirement specified in an OV-2 Operational Resource Flow Description (i.e., in a "To-Be" Architectural Description), and so there may be many alternative SvcV models that could realize the operational requirement. Alternatively, in an "As-Is" Architectural Description, the OV-2 Operational Resource Flow Description may simply be a simplified, logical representation of the SvcV-1 to allow communication of key Resource Flows to non-technical stakeholders.

It is important for the architect to recognize that the SvcV-1 focuses on the Resource Flow and the providing service. This differs from a SV-1 System Interface Description which focuses on the System-to-System point-to-point interface, for which the Source System and Target System have an agreed upon interface. For the SvcV-1, the focus on the provider and the data provided is a Net-Centric Data Strategy tenet appropriate for a publish/subscribe pattern. This pattern is not the only type of service that can be captured in the SvcV-1.

Sub-services may be identified in SvcV-1 to any level (i.e., depth) of decomposition the architect sees fit. The SvcV-1 may also identify the Physical Assets (e.g., Platforms) at which Resources are deployed, and optionally overlay Operational Activities and Locations that utilize those Resources. In many cases, an operational activity and locations depicted in an OV-2 Operational Resource Flow Description may well be the logical representation of the resource that is shown in SvcV-1.

The intended usage of the SvcV-1 includes:

  • Definition of service concepts.
  • Definition of service options.
  • Service Resource Flow requirements capture.
  • Capability integration planning.
  • Service integration management.
  • Operational planning (capability and performer definition).

The SvcV-1 is used in two complementary ways:

  • Describe the Resource Flows exchanged between resources in the architecture.
  • Describe a solution, or solution option, in terms of the components of capability and their physical integration on platforms and other facilities.

Detailed Description:

A SvcV-1 can be used simply to depict services and sub-services and identify the Resource Flows between them. The real benefit of a SvcV-1 is its ability to describe the human aspects of an architecture and how they interact with Services. In addition, DoDAF has the concept of Capability and Performers (see the Capability Meta-model group in the LDM) which is used to depict Services, assets and people into a configuration, which can meet a specific capability. A primary purpose of a SvcV-1 model is to show resource structure, i.e., identify the primary sub-services, performer and activities (functions) and their interactions. SvcV-1 contributes to user understanding of the structural characteristics of the solution.

The physical resources contributing to a capability are either an organizational resource or a physical asset, i.e., a service cannot contribute alone (it must be hosted on a physical asset used by an organizational resource of both). Organizational aspects can now be shown on SvcV-1 (e.g., who uses a service). Resource structures may be identified in SvcV-1 to any level (i.e., depth) of decomposition the architect sees fit. DoDAF does not specifically use terms like sub-service and component as these terms often denote a position relative to a structural hierarchy. Any service may combine hardware and software or these can be treated as separate (sub) services. DoDAF V2.0 includes human factors (as Personnel Types and a type of Performer). Should an architect wish to describe a service which has human elements, then groupings of Services, Personnel Types and Performers should be used to wrap the human and service elements together.

A SvcV-1 can optionally be annotated with Operational Activities and Locations originally specified in OV-2 Operational Resource Flow Description. In this way, traceability can be established from the logical OV structure to the physical Service Model structure.

If a single SvcV-1 is not possible, the resource of interest should be decomposed into multiple SvcV-1 models.

Functions (Activities):

Some Resources can carry out service functions (activities) as described in SvcV-4 Services Functionality Description models and these functions can optionally be overlaid on a SvcV-1. In a sense SvcV-1 and SvcV-4 Services Functionality Description provide complementary representations (structure and function). Either could be viewed first, but usually an iterative approach is used to model these together gradually building up the level of detail in the service description. Note that the same type (class) of resource may be used in different contexts in a given SvcV-1. For this reason, the tracing of functions to resources is specified in context of their usage (see DM2 for details).

Resource Flows in SvcV-1:

In addition to depicting Services (Performers) and their structure, SvcV-1 addresses Service Resource Flows. A Service Resource Flow, as depicted in SvcV-1, is an indicator that resources pass between one service and the other. In the case of Services, this can be expanded into further detail in SvcV-2 Services Resource Flow Description model. A Service Resource Flow is a simplified representation of a pathway or network pattern, usually depicted graphically as a connector (i.e., a line with possible amplifying information). The SvcV-1 depicts all Resource Flows between resources that are of interest. Note that Resource Flows between resources may be further specified in detail in the SvcV-2 Services Resource Flow Description model and the SvcV-6 Services Resource Flow Matrix.

Interactions are only possible between services and systems. Service Resource Flows provide a specification for how the Resource Flow exchanges specified in OV-2 Operational Resource Flow Description Needlines are realized with services. A single Needline shown in the OV-2 Operational Resource Flow Description may translate into multiple Service Resource Flows. The actual implementation of Service Resource Flows may take more than one form (e.g., multiple physical links). Details of the physical pathways or network patterns that implement the interfaces are documented in SvcV-2 Services Resource Flow Description. Resource Flows are summarized in a SvcV-3a System-Service Matrix or SvcV-3b Service-Service Matrix and detailed definitions and attributes specific to each Service Resource Flows may be described in SvcV-6 Services Resource Flow Matrix.

The functions performed by the resources are specified in a SvcV-4 Service Functionality Description, but may optionally be overlaid on the Resources in a SvcV-1.

SvcV-1 Services Context Description

SvcV-2 Services Resource Flow Description

SvcV-3a Systems-Services Matrix

SvcV-3b Services-Services Matrix

SvcV-4 Services Functionality Description

SvcV-5 Operational Activity to Services Traceability Matrix

SvcV-6 Services Resource Flow Matrix

SvcV-7 Services Measures Matrix

SvcV-8 Services Evolution Description

SvcV-9 Services Technology & Skills Forecast

SvcV-10abc Introduction to SvcV-10a, SvcV-10b and SvcV-10c

SvcV-10a Services Rules Model

SvcV-10b Services State Transition Description

SvcV-10c Services Event-Trace Description