Back to Top

Defense Acquisitions Made Easy

Blog Archives

DoDAF Architecting

SvcV-10c Services Event-Trace Description

The SvcV-10c “Services Event-Trace Description” provides a time-ordered examination of the interactions between services functional resources. Each event-trace diagram should have an accompanying description that defines the particular scenario or situation. The SvcV-10c is valuable for moving to the next level of detail from the initial solution design, to help define a sequence of service functions and service data interfaces, and to ensure that each participating resource or Service Port role has the necessary information it needs, at the right time, to perform its assigned functionality. [1]

The intended usage of the SvcV-10c includes: [1]

  • Analysis of resource events impacting operation
  • Behavioral analysis
  • Identification of non-functional system requirements

DoDAF Architecture Framework Version 2.02 – Page 195

The SvcV-10c specifies the sequence in which Resource Flow elements are exchanged in context of a resource or Service Port. Services Event-Trace Descriptions are sometimes called sequence diagrams, event scenarios or timing diagrams. The components of a SvcV-10c include functional resources or service ports, owning performer, as well as the port which is the subject for the lifeline. [1]

Specific points in time can be identified. The Resource Flow from one resource/port to another can be labeled with events and their timing. The Service Event-Trace Description provides a time-ordered examination of the Resource Flow elements exchanged between participating resources (external and internal) or service ports. Each Event-Trace diagram should have an accompanying description that defines the particular scenario or situation.

The SvcV-10c is typically used in conjunction with the SvcV-10b “Services State Transition Description” to describe the dynamic behavior of resources. The data content of messages that connect Resource Flows in a SvcV-10c model may be related, in modeling terms, with Resource Flows (interactions, in SvcV-1 “Services Context Description”, SvcV-3a “Systems-Services Matrix”, and SvcV-3b “Services-Services Matrix”), Resource Flows (data, in SvcV-4 “Services Functionality Description” and SvcV-6 “Services Resource Flow Matrix”) and entities (in DIV-3 “Physical Data Model”) modeled in other models.

DoDAF Viewpoint Matrix
AV 1 2
CV 1 2 3 4 5 6 7
DIV 1 2 3
OV 1 2 3 4 5a 5b 6a 6b 6c
PV 1 2 3
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 6/26/2018

DoDAF Architecting

SvcV-9 Services Technology and Skills Forecast

See Services Viewpoint (SvcV) Overview

The SvcV-9 “Services Technology and Skills Forecast” defines the underlying current and expected supporting technologies and skills. Expected supporting technologies and skills are those that can be reasonably forecast given the current state of technology and skills, and expected improvements or trends. New technologies and skills are tied to specific time periods, which can correlate against the time periods used in SvcV-8 “Services Evolution Description” model milestones and linked to Capability Phases.

Guide: DoDAF Architecture Framework Version 2.02 – Page 189

The SvcV-9 provides a summary of emerging technologies and skills that impact the architecture. The SvcV-9 provides descriptions of relevant: [1]

  • Emerging capabilities
  • Industry trends
  • Predictions (with associated confidence factors) of the availability and readiness of specific hardware and software services
  • Current and possible future skills

In addition to providing an inventory of trends, capabilities and services, the SvcV-9 also includes an assessment of the potential impact of these items on the architecture. Given the future-oriented nature of this model, forecasts are typically made in short, mid and long-term timeframes, such as 6, 12 and 18-month intervals.

In addition, this model is useful in support of net-centric (service-oriented) implementation of services. As technologies change, like incorporation of Representational State Transfer (REST) services in the Web Services Description Language, this model can present a timeline of technologies related services over time.

The intended usage of the SvcV-9 includes: [1]

  • Forecasting technology readiness against time
  • HR Trends Analysis
  • Recruitment Planning
  • Planning technology insertion
  • Input to options analysis
  • The SvcV-9 can be presented in a table, timeline, or a Herringbone diagram

A SvcV-9 summarizes predictions about trends in technology and personnel. Architects may produce separate SvcV-9 products for technology and human resources. The specific time periods selected (and the trends being tracked) can be coordinated with architecture transition plans (which the SvcV-8 Services Evolution Description can support). That is, insertion of new capabilities and upgrading or re-training of existing resources may depend on or be driven by the availability of new technology and associated skills. The forecast includes potential impacts on current architectures and thus influences the development of transition and target architectures. The forecast is focused on technology and human resource areas that are related to the purpose for which a given architecture is being described and identifies issues affecting that architecture.   If standards are an integral part of the technologies important to the evolution of a given architecture, then it may be convenient to combine SvcV-9 with the StdV-2 “Standards Forecast” into a composite Fit-for-Purpose View.

The SvcV-9 is constructed as part of a given Architectural Description and in accordance with the its purpose. Typically, this involves starting with one or more overarching reference models or standards profiles to which the architecture is subject to using. Using these reference models or standards profiles, the architect selects the service areas and services relevant to the architecture. The SvcV-9 forecasts relate to the StdV-1 “Standards Profile” in that a timed forecast may contribute to the decision to retire or phase out the use of a certain standard in connection with a resource. Similarly, the SvcV-9 forecasts relate to the StdV-2 Standards Forecasts in that a certain standard may be adopted depending on a certain technology or skill becoming available (e.g., the availability of Java Script may influence the decision to adopt a new HTML standard).

Alternatively, the SvcV-9 may relate forecasts to Service Model elements (e.g., Services) where applicable. The list of resources potentially impacted by the forecasts can also be summarized as additional information in SvcV-9.

DoDAF Viewpoint Matrix
AV 1 2
CV 1 2 3 4 5 6 7
DIV 1 2 3
OV 1 2 3 4 5a 5b 6a 6b 6c
PV 1 2 3
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 6/26/2018

DoDAF Architecting

SvcV-10a Services Rules Model

The SvcV-10a “Services Rules Model” is to specify functional and non-functional constraints on the implementation aspects of the architecture (i.e., the structural and behavioral elements of the Services Model). The SvcV-10a describes constraints on the resources, functions, data and ports that make up the Service Model physical architecture. The constraints are specified in text and may be functional or structural (i.e., non-functional). [1]

The intended usage of the SvcV-10a includes: [1]

  • Definition of implementation logic
  • Identification of resource constraints

Guide:  DoDAF Architecture Framework Version 2.02 – Page 191

The SvcV-10a describes the rules that control, constrain or otherwise guide the implementation aspects of the architecture. Service Rules are statements that define or constrain some aspect of the business, and may be applied to: [1]

  • Performers
  • Resource Flows
  • Service Functions
  • System Ports
  • Data Elements

In contrast to the OV-6a “Operational Rules Model”, the SvcV-10a focuses physical and data constraints rather than business rules.

Constraints can be categorized as follows: [1]

  • Structural Assertions – non-functional constraints governing some physical aspect of the architecture
  • Action Assertions – functional constraints governing the behavior of resources, their interactions and Resource Flow exchanges
  • Derivations – these involve algorithms used to compute facts

Where a Service Rule is based on some standard, then that standard should be listed in the StdV-1 “Standards Profile”.
Some Service Rules can be added as annotations to other models. The SvcV-10a then should provide a listing of the complete set of rules with a reference to any models that they affect.

DoDAF Viewpoint Matrix
AV 1 2
CV 1 2 3 4 5 6 7
DIV 1 2 3
OV 1 2 3 4 5a 5b 6a 6b 6c
PV 1 2 3
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 6/26/2018

DoDAF Architecting

SvcV-10b Services State Transition Description

The SvcV-10b “Services State Transition Description” is a graphical method of describing a resource (or function) response to various events by changing its state. The diagram basically represents the sets of events to which the resources in the Activities respond (by taking an action to move to a new state) as a function of its current state. Each transition specifies an event and an action. [1]

Guide: DoDAF Architecture Framework Version 2.02 – Page 193

The explicit time sequencing of service functions in response to external and internal events is not fully expressed in SvcV-4 Services Functionality Description. SvcV-10b can be used to describe the explicit sequencing of the service functions. Alternatively, SvcV-10b can be used to reflect explicit sequencing of the actions internal to a single service function, or the sequencing of service functions with respect to a specific resource. [1]

The intended usage of the SvcV-10b includes: [1]

  • Definition of states, events, and state transitions (behavioral modeling)
  • Identification of constraints

The SvcV-10b relates events to resource states and describes the transition from one state to another.

The SvcV-10b is based on the state chart diagram. A state machine is defined as “a specification that describes all possible behaviors of some dynamic view element. Behavior is viewed as a traversal of a graph of specific states interconnected by one or more joined transition arcs that are triggered by the dispatching of series of event instances. During this traversal, the state machine executes a series of actions associated with various elements of the state machine.” State chart diagrams can be unambiguously converted to structured textual rules that specify timing aspects of events and the responses to these events, with no loss of meaning. However, the graphical form of the state diagrams can often allow quick analysis of the completeness of the rule set, and detection of dead ends or missing conditions. These errors, if not detected early during the solution analysis phase, can often lead to serious behavioral errors in fielded capabilities and to expensive correction efforts. [1]

The SvcV-10b models state transitions from a resource perspective, with a focus on how the resource responds to stimuli (e.g., triggers and events). As in the OV-6b “Operational State Transition Description”, these responses may differ depending upon the rule set or conditions that apply, as well as the resource’s state at the time the stimuli is received. A change of state is called a transition. Each transition specifies the response based on a specific event and the current state. Actions may be associated with a given state or with the transition between states. A state and its associated actions specify the response of a resource or service function, to events. When an event occurs, the next state may vary depending on the current state (and its associated action), the event, and the rule set or guard conditions. [1]

The SvcV-10b can be used to describe the detailed sequencing of service functions described in SvcV-4 “Services Functionality Description”. However, the relationship between the actions included in SvcV-10b and the functions in SvcV-4 depends on the purposes of the Architectural Description and the level of abstraction used in the models. The explicit sequencing of functions in response to external and internal events is not fully expressed in SvcV-4 Services Functionality Description. SvcV-10b can be used to reflect explicit sequencing of the functions, the sequencing of actions internal to a single function, or the sequencing of functions with respect to a specific resource. [1]

States in a SvcV-10b model may be nested. This enables quite complex models to be created to represent Services behavior. Depending upon the architecture project’s needs, the SvcV-10b may be used separately or in conjunction with the SvcV-10c “Services Event-Trace Description”. [1]

DoDAF Viewpoint Matrix
AV 1 2
CV 1 2 3 4 5 6 7
DIV 1 2 3
OV 1 2 3 4 5a 5b 6a 6b 6c
PV 1 2 3
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 6/26/2018

DoDAF Architecting

SvcV-7 Services Measures Matrix

See Services Viewpoint (SvcV) Overview

The SvcV-7 Services Measures Matrix depicts the measures (metrics) of resources. The Services Measures Matrix expands on the information presented in a SvcV-1 “Services Interface Description” by depicting the characteristics of the resources in the SvcV-1 Services Context Description.

Guide: DoDAF Architecture Framework Version 2.02 – Page 185

In addition, this model is useful in support of net-centric (service-oriented) implementation of services. Service measures for Service Level Agreements for each service and may include number of service consumers, service usage by consumers, and the minimum, average and maximum response times, allowed down time, etc. Measures of interest for a Chief Information Office or Program manager (PM) may include measures that assess service reuse, process efficiency, and business agility.

The intended usage of the SvcV-7 includes: [1]

  • Definition of performance characteristics and measures (metrics)
  • Identification of non-functional requirements

The SvcV-7 specifies qualitative and quantitative measures (metrics) of resources. It specifies all of the measures. The measures are selected by the end user community and described by the architect.

Performance parameters include all performance characteristics for which requirements can be developed and specifications defined. The complete set of performance parameters may not be known at the early stages of Architectural Description, so it is to be expected that this model is updated throughout the specification, design, development, testing, and possibly even its deployment and operations lifecycle phases. The performance characteristics are captured in the Measures Meta-model group.

One of the primary purposes of SvcV-7 is to communicate which measures are considered most crucial for the successful achievement of the mission goals assigned. These particular measures can often be the deciding factors in acquisition and deployment decisions, and figure strongly in services analysis and simulations done to support the acquisition decision processes and system design refinement and be input or may impact decisions about Service Level Agreement content. Measures of Effectiveness (MOE) and Measures of Performers (MOP) are measures that can be captured and presented in the Services Measures Matrix model.

SvcV-7 is typically a table, listing user defined measures (metrics) with a time period association. It is sometimes useful to analyze evolution by comparing measures (metrics) for current and future resources. For this reason, a hybrid SvcV-7 Model which spans architectures across multiple phases may be useful.

   DoDAF Viewpoint Matrix
AV 1 2                      
CV 1 2 3 4 5 6 7            
DIV 1 2 3                    
OV 1 2 3 4 5a 5b 6a 6b 6c        
PV 1 2 3                    
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2                      
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 6/26/2018

DoDAF Architecting

SvcV-8 Services Evolution Description

See Services Viewpoint (SvcV) Overview

The SvcV-8 “Services Evolution Description” presents a whole lifecycle view of resources (services), describing how it changes over time. It shows the structure of several resources mapped against a timeline. [1]

Guide: DoDAF Architecture Framework Version 2.02 – Page 187

In addition, this model is useful in support of net-centric (service-oriented) implementation of services. This model can present a timeline of services evolve or are replaced over time, including services that are internal and external to the scope of the architecture. [1]

The intended usage of the SvcV-8 includes: [1]

The SvcV-8, when linked together with other evolution Models such as CV-2 “Capability Taxonomy”, CV-3 “Capability Phasing” and StdV-2 “Standards Forecast”, provides a rich definition of how the Enterprise and its capabilities are expected to evolve over time. In this manner, the model can be used to support an architecture evolution project plan or transition plan. [1]

A SvcV-8 can describe historical (legacy), current, and future capabilities against a timeline. The model shows the structure of each resource, using similar modeling elements as those used in SvcV-1 “Service Interface Description”. Interactions which take place within the resource may also be shown. The changes depicted in the SvcV-8 DoDAF-described Model are derived from the project milestones that are shown in a PV-2 “Project Timelines” model. When the PV-2 Project Timelines model is used for capability acquisition projects, there is likely to be a close relationship between these two models. [1]

DoDAF Viewpoint Matrix
AV 1 2
CV 1 2 3 4 5 6 7
DIV 1 2 3
OV 1 2 3 4 5a 5b 6a 6b 6c
PV 1 2 3
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 6/26/2018

DoDAF Architecting

SvcV-4 Services Functionality Description

See Services Viewpoint (SvcV) Overview

Within an Architectural Description, the SvcV-4 “Services Functionality Description” documents service functions, the Resource Flows between those service functions, the internal system data repositories or service data stores, and the external sources and sinks for the service data flows, but not external to the Architectural Description’s scope. They may also show how users behave in relation to those services.  The primary purpose of SvcV-4 is to: [1]

  • Develop a clear description of the necessary data flows that are input (consumed) by and output (produced) by each resource
  • Ensure that the service functional connectivity is complete (i.e., that a resource’s required inputs are all satisfied)
  • Ensure that the functional decomposition reaches an appropriate level of detail

Guide: DoDAF Architecture Framework Version 2.02 – Page 179

The Services Functionality Description provides detailed information regarding the: [1]

The intended usage of the SvcV-4 includes: [1]

  • Description of task workflow
  • Identification of functional service requirements
  • Functional decomposition of Services
  • Relate human and service functions

It is important to note that one usage of the SvcV-4 can support a net-centric (service oriented) implementation in describing the producing services and consuming services. The Services Functionality Description information can support the registration of services in netcentric (service-oriented) implementation.

The SvcV-4 is used to specify the service functionality of resources in the architecture. The SvcV-4 is the behavioral counterpart to the SvcV-1 “Services Context Description” (in the same way that OV-5b Operational Activity Model is the behavioral counterpart to OV-2 “Operational Resource Flow Description”).

The scope of this model may be capability wide, without regard to which resources perform which service functions, or it may be resource-specific. Variations may focus on intra- or inter-resource data flows, or may simply allocate service functions to resources.

There are two basic ways to depict a SvcV-4: [1]

  1. The Taxonomic Service Functional Hierarchy shows a decomposition of service functions depicted in a tree structure and is typically used where tasks are concurrent but dependent, such as a production line, for example.
  2. The Data Flow Diagram shows service functions connected by data flow arrows and data stores
   DoDAF Viewpoint Matrix
AV 1 2                      
CV 1 2 3 4 5 6 7            
DIV 1 2 3                    
OV 1 2 3 4 5a 5b 6a 6b 6c        
PV 1 2 3                    
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2                      
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 9/28/2017

DoDAF Architecting

SvcV-5 Operational Activity to Services Traceability Matrix

See Services Viewpoint (SvcV) Overview

The SvcV-5 “Operational Activity to Services Traceability Matrix” addresses the linkage between service functions described in SvcV-4 “Service Functionality DEscription” and Operational Activities specified in OV-5a “Operational Activity Decomposition Tree” or OV-5b “Operational Activity Model”. The SvcV-5 depicts the mapping of service functions (and, optionally, the capabilities and performers that provide them) to operational activities and thus identifies the transformation of an operational need into a purposeful action performed by a service solution. [1]

Guide: DoDAF Architecture Framework Version 2.02 – Page 181

During requirements definition, the SvcV-5 plays a particularly important role in tracing the architectural elements associated with system function requirements to those associated with user requirements.

The intended usage of the SvcV-5 includes: [1]

  • Tracing service functional requirements to user requirements
  • Tracing solution options to requirements
  • Identification of overlaps or gaps

An SvcV-5 is a specification of the relationships between the set of operational activities applicable to an Architectural Description and the set of service functions applicable to that Architectural Description. The relationship between operational activities and service functions can also be expected to be many-to-many (i.e., one activity may be supported by multiple functions, and one function may support multiple activities). The service functions shown in the SvcV-5 may be those associated with capabilities and performers. More focused SvcV-5 models might be used to specifically trace system functions to operational activities if desired. [1] 

DoDAF uses the term Operational Activity in the OVs and the term Service Function in the SVs to refer to essentially the same kind of thing-both activities and service functions are tasks that are performed, accept inputs, and develop outputs. The distinction between an Operational Activity and a Service Function is a question of what and how. The Operational Activity is a specification of what is to be done, regardless of the mechanism used. A Service Function specifies how a resource carries it out. For this reason, the SvcV-5 is a significant model, as it ties together the logical specification in the OV-5a Operational Activity Decomposition Tree or OV-5b Operational Activity Model with the physical specification of the SvcV-4 Services Functionality Description. Service Functions can be carried out by Resources. [1] 

The SvcV-5 is generally presented as a matrix of the relationship between service functions and activities. The SvcV-5 can show requirements traceability with Operational Activities on one axis of a matrix, the System Functions on the other axis, and with an X, date, or phase in the intersecting cells, where appropriate. An alternate version of the tabular SvcV-5 can allow the implementation status of each function to be shown. In this variant model, each service function-to-operational activity mapping is described by a traffic light symbol that may indicate the status of the service support. DoDAF V2.0 does not prescribe a presentation technique. These symbols are usually colored circles with the following possible representations: [1]

  • Red may indicate that the functionality is planned but not developed
  • Yellow may indicate that partial functionality has been provided (or full functionality provided but system has not been fielded)
  • Green may indicate that full functionality has been provided to the field
  • A blank cell may indicate that there is no service support planned for an Operational
  • Activity, or that a relationship does not exist between the Operational Activity and the Service Function
   DoDAF Viewpoint Matrix
AV 1 2                      
CV 1 2 3 4 5 6 7            
DIV 1 2 3                    
OV 1 2 3 4 5a 5b 6a 6b 6c        
PV 1 2 3                    
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2                      
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 9/28/2017

DoDAF Architecting

SvcV-6 Services Resource Flow Matrix

See Services Viewpoint (SvcV) Overview

The SvcV-6 “Services Resource Flow Matrix” specifies the characteristics of the Service Resource Flows exchanged between Services. The focus is on resource crossing the service boundary. The SvcV-6 focuses on the specific aspects of the Service Resource Flow and the Service Resource Flow content in a tabular format. [1]

Guide: DoDAF Architecture Framework Version 2.02 – Page 183

In addition, this model is useful in support of net-centric (service-oriented) implementation of services. According to the Net-Centric Data Strategy, a net-centric implementation needs to focus in on the data in the Service Resource Flow, as well as the services that produce or consume the data of the Service Resource Flow. In a net-centric implementation, not all the consumers are known and this model emphasizes the focus on the producer and Service Resource Flow. [1]

The intended usage of the SvcV-6 includes: [1]

  • Detailed definition of Resource Flows

The SvcV-6 specifies the characteristics of Service Resource Flow exchanges between Services. The SvcV-6 is the physical equivalent of the logical OV-3 “Operational Resource Flow Matrix” and provides detailed information on the service connections which implement the Resource Flow exchanges specified in OV-3 “Operational Resource Flow Matrix”. Resource flow exchange solutions, whether automated or not, e.g., such as verbal orders, are also captured.

Service Resource Flow exchanges express the relationship across the three basic architectural data elements of a SvcV (Services, service functions, and Service Resource Flows) and focus on the specific aspects of the Service Resource Flow and the service resource content. These aspects of the service Resource Flow exchange can be crucial to the operational mission and are critical to understanding the potential for overhead and constraints introduced by the physical aspects of the implementation such as security policy and communications and logistics limitations.

The focus of SvcV-6 is on how the Service Resource Flow exchange is affected, in service specific details covering periodicity, timeliness, throughput, size, information assurance, and security characteristics of the resource exchange. In addition, for Service Resource Flow of data, their format and media type, accuracy, units of measurement, applicable system data standards, and any DIV-3 “Physical Data Models” are also described or referenced in the matrix.
Modeling discipline is needed to ensure that the architecture models are coherent. Each Service Resource Flow exchange listed in the SvcV-6 table should be traceable to at least one Operational Resource Flow exchanged listed in the corresponding OV-3 Operational Resource Flow Matrix and these in turn trace to OV-2 “Operational Resource Flow Description”.

It should be noted that each resource exchanged may relate to a known service function (from SvcV-4 “Sevice Functionality Description”) that produces or consumes it. However, there need not be a one-to-one correlation between data elements listed in the SvcV-6 matrix and the Resource Flows (inputs and outputs) that are produced or consumed in a related SvcV-4 because the SvcV-4 is more a logical solution, whereas the SvcV-6 is a more physical solution. In addition, Resource flows between known service functions performed by the same Services may not be shown in the SvcV-6 matrix. The SvcV-6 is about showing flows across service boundaries or a service boundary. If the Resource Flow is information, it may need to be reflected in the Data and Information Models.

The SvcV-7 “Services Measures Matrix” builds on the SvcV-6 and should be developed at the same time.

DoDAF does not prescribe the column headings in a SvcV-6 Matrix. Identifiers of the OV-3 “Operational Resource Flow Matrix” that are implemented by the Service Resource Flow Exchanges may be included in the table. All elements carried by the Resource Flow exchanges may be shown. [1]

   DoDAF Viewpoint Matrix
AV 1 2                      
CV 1 2 3 4 5 6 7            
DIV 1 2 3                    
OV 1 2 3 4 5a 5b 6a 6b 6c        
PV 1 2 3                    
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2                      
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 6/26/2018

DoDAF Architecting

SvcV-2 Services Resource Flow Description

See Services Viewpoint (SvcV) Overview

A SvcV-2 “Services Resource Flow Description” specifies the Resource Flows between Services and may also list the protocol stacks used in connections. A SvcV-2 is used to give a precise specification of a connection between Services. This may be an existing connection or a specification of a connection that is to be made for a future connection.

The intended usage of the SvcV-2 includes: [1]

  • Resource Flow specification

Guide: DoDAF Architecture Framework Version 2.02 – Page 173

For a network data service, a SvcV-2 comprises Services, their ports, and the Service Resource Flows between those ports. The SvcV-2 may also be used to describe non-IT type services such as Search and Rescue. The architect may choose to create a diagram for each Service Resource Flow and the producing Service, each Service Resource Flow and consuming Service, or to show all the Service Resource Flows on one diagram, if this is possible. [1]

Each SvcV-2 model can show: [1]

  • Which ports are connected
  • The producing Services that the ports belong to
  • The Services that the Service Resource Flows are consumed by
  • The definition of the Service Resource Flow in terms of the physical/logical connectivity and any protocols that are used in the connection

Note that networks are represented as Services. The architect may choose to show other Services being components of the network, i.e., if they are part of the network infrastructure.

   DoDAF Viewpoint Matrix
AV 1 2                      
CV 1 2 3 4 5 6 7            
DIV 1 2 3                    
OV 1 2 3 4 5a 5b 6a 6b 6c        
PV 1 2 3                    
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2                      
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 9/28/2017