Operational Views (OV) [Logical Views]

OV-2 Operational Node Relationship Description v1.2

The Operational Node Relationships Description (OV-2) addresses localisation of operational capability.

Version 1.2 highlights

More formal definition of Logical Flows to represent node connections
Introduction of SOA in OV-2’s
The allowing of Known Resources (as defined in SV-1)

Background

The primary purpose of the OV-2 View is to define the Nodes that provide the focus for the expression of capability requirements within an operational context. The OV-2 may also be used to express a capability boundary.

A secondary purpose of the OV-2 View is to define a logical network of information flows. The Nodes on the logical network need not correspond to specific organisations, systems or locations, allowing Information Exchange Requirements (IERs) to be established without prescribing the way that the information exchange is handled and without prescribing solutions.

In addition, MODAF allows the OV-2 to show flows of people, materiel or energy between Nodes.

Note that there are several significant extensions to the OV-2 as used by DoDAF. See also: IER Analysis Paper

Usage:

Data objects:

The data in an OV-2 can include:



Relationships Between Key Data Objects (Simplified from M3)

Representation:



Non-UML OV-2 Example

Structured text may also be used to provide a fuller description of the Needlines (this is sometimes referred to as OV-2b).

Detailed Product Description:

The Operational Node Relationships Description (OV-2) depicts Operational Nodes with Needlines between those Nodes that indicate a need to exchange information. The OV-2 may also show the location of Operational Nodes, and may optionally be annotated to show flows of people, materiel or energy between Nodes. The Operational Nodes shown in an OV-2 View Product may be internal to the Architecture, or external Nodes that communicate with those internal Nodes. Nodes conduct Operational Activities, and it is also possible to show these on an OV-2.

Use of OV-2 is intended to be logical. This view provides a focus for the operational requirements which may reflect any capability requirements that have been articulated but in the range of operational settings that are being used for operational architecture. In an as-is architecture, an OV-2 may be used as an abstract (i.e. simplified) representation of the information exchanges taking place in the Enterprise. An OV-2 can be a powerful way of expressing the differences between an as-is architecture and a proposed architecture to non-technical stakeholders, as it simply shows how information flows (or does not flow).

In the information arena, the purpose of an OV-2 Product is to define a logical network of information flows. The Nodes on the logical network do not correspond to specific organisations, systems or locations, allowing Information Exchange Requirements (IERs) to be established without prescribing the way that the information exchange is handled. OV-2 is intended to track the need for information exchanges from specific Operational Nodes (that play a key role in the Architecture) to others. OV-2 does not depict the physical connectivity between the Nodes. The nodal network established in an OV-2 View Product may act as the backbone onto which architectural elements may be overlaid – e.g. an SV-1 View Product can show which systems provide the necessary capability at each Node.

The main features of this View are the Operational Nodes, and the location (or type of location / environment) where the Nodes are deployed, and the Needlines between the Nodes that indicate a need to exchange or share information. An OV-2 View Product indicates the key players and the interactions necessary to conduct the corresponding operational activities of OV-5.

An Operational Node is a logical element of the operational Architecture that may produce, consume, or process information, energy, materiel or people. What constitutes an Operational Node can vary among Architectures, including:

What is considered an Operational Node will also vary depending on the level of detail addressed by the Architecture effort.

MODAF has re-emphasised the logical nature of nodes through the introduction of the Physical Asset (see SV-1). Such Physical Assets are part of the specification of capability and should not be used in OV-2.

The aim of the OV-2 View is to record the operational characteristics of the set of Nodes relevant to the architecture and their collaboration needs, as expressed in Needlines and Flows.

Known Resources

In addition to logical nodes, MODAF 1.2 allows Known Resources as a type of Node that can be represented on OV-2s. These Known Resources are defined in SV-1 and are to be used where a constraint on the logical solution is due to existing resources i.e. in a maritime operation, an aircraft carrier is always part of the solution. Known Resources should not be used in the the Problem Domain.

Needlines

A Needline documents the exchange (required or actual) of information between Nodes. A needline is a conduit for one or more information exchanges – i.e. it represents a logical bundle of information flows. The Needline does not indicate how the information transfer is implemented. For example, if information is produced at Node A, is simply routed through Node B, and is used at Node C, then Node B would not be shown on the OV-2 diagram – the Needline would go from Node A to Node C. OV-2 is not a communications link or communications network diagram but a high-level definition of the logical requirement for information exchange. See SV-1 and SV-2 for further discussion.

Needlines are represented by arrows (indicating the direction of flow) and are annotated with a diagram-unique identifier and a phrase that is descriptive of the principal type of exchange – it may be convenient to present these phrases in a key to the diagram to prevent cluttering. It is important to note that the arrows (with identifiers) on the diagram represent Needlines only. This means that each arrow indicates only that there is a need for some kind of information transfer between the two connected Nodes.


Generic OV-2 showing Needlines

The diagram may include the needline identifiers as numerical labels (as in the example above). Alternatively short phrases may be used.

Because needline identifiers are often needed to provide a trace reference for information exchange requirements (see OV-3), a combined approach, with numerical and text labels, can be used.

There may be several Needlines (in the same direction) from one Node to another. This may occur because some Needlines are only relevant to certain scenarios, missions or mission phases. In this case, when producing the OV-2 for the specific case, a subset of all of the Needlines will be displayed.

There is a one-to-many relationship from Needlines to information exchanges (e.g. a single Needline in OV-2 represents multiple individual information exchanges). The mapping of the exchanges to the Needlines of OV-2 occurs in the Operational Information Exchange Matrix (OV-3). For example, OV-2 may list “Situation Report” as a descriptive name for a Needline between two Operational Nodes. In this case, the Needline represents a number of information exchanges, consisting of various types of reports (information elements), and their attributes (such as periodicity and timeliness) that are associated with the “Situation Report” Needline. The identity of the individual elements and their attributes are documented in OV-3.

An OV-2 View Product will also define a need to exchange items between Operational Nodes and external Nodes (i.e. Operational Nodes that are not strictly within the scope of the subject Architecture but which interface to it either as important sources of items required by Nodes within the Architecture or important destinations for items provided by Nodes within the Architecture).

OV-2 is intended to track the need to exchange items from specific Operational Nodes (that play a key role in the Architecture) to others. OV-2 does not depict the physical connectivity between the Nodes. The logical nodes and needlines established in an OV-2 can be realised by resources and their interactions in an SV-1. There may not be a one-to-one correspondence between between a node in OV-2 and a resource in SV-1. For example, a node may be realised by two systems, where one provides backup for the other, or it may be that the functionality of a node has to be split between two locations for practical reasons.

In the MODAF Meta-Model, Node extends UML Class, and OV-2 is represented as a composite structure model. It therefore may be possible to use a particular Node class in more than one context. For this reason, Needlines associated with a pair of Nodes may be context-specific. This is also the case for Operational Activities, which may be only appropriate in certain contexts.

Flows of People, Materiel and Energy

Needlines are only one example of Logical Flows in MODAF 1.2. Other flows can can be used to model people, energy and matter. This information helps to provide context for the business roles represented by the Nodes. Examples of Flow usage would be:

This can be achieved by overlaying the Flows on the diagram using a notation that is clearly distinct from Needlines (which only represent the requirement to exchange information between Nodes).

The following example illustrates the inclusion of physical flows.[The reference in the example to <<NodeConnector>> should be a logical flow]


Generic OV-2 showing Needlines and Flows

Nesting of Nodes

It is often convenient to model Nodes as being nested, in other words one Node is ‘contained’ within another. A simple example is shown below.


Example OV-2 with nested Nodes

This technique may be used to include the same Node more than once on the diagram. This works because each occurrence of the Node has a different usage context.

Nesting is also sometimes used to show ‘roles’ associated with each Node (often together with the activities those roles perform). Care is needed here that the OV-2 logical view maintains focus on the operational requirements and avoids solutioneering. The ‘roles’ that may feature on an OV-2 are really just a way of compartmenting the logical architecture. A legitimate example of this is the use of an OV-2 to depict a generic set of functional cells within a generic headquarters (such as a Land Battlegroup HQ). The capability required of each functional cell may be delivered by people alone or through a combination of systems and people (see Capability Configurations within SV-1).

Capability Boundary and Requirements

There is a separate article relating to MODAF support for user requirements which explains how Nodes relate to capability requirements (see also StV-2).

As explained in that article, the OV-2 View may also represent operational concepts that are of critical importance to requirements definition. In OV-2, this is achieved by mapping Capabilities onto Nodes, to represent the required level of capability in the architecture. The requirements specified in this way may then be realised by more than one suite of SV view – i.e. there may be multiple potential specifications that can be traded off against each other.

A new feature in MODAF is the ability to describe, within an OV-2, the capability boundary. This uses a concept in M3 called ProblemDomain. The intention is that modellers will be able to specify the extent of the operational capability of interest by modelling certain Nodes and identifying these as being outside the boundary.

This is important for several reasons


OV-2 showing Problem Domain

A Node can only be realised by a Resource or combination of resources (specified in SV-1).

Operational Activities

The operational activities (from the OV-5 Operational Activity Model) performed by a given Node may be listed on the graphic, if space permits. OV-2 and OV-5 are complementary descriptions. OV-2 focuses on the Operational Nodes, with the activities being a secondary adornment. OV-5, on the other hand, places first-order attention on operational activities and only second-order attention on Nodes, which can be shown as annotations or swim-lanes on the activities. In developing an Architecture, OV-2 and OV-5 are often the starting points and these may be worked up iteratively.

Examples of how this can be depicted are illustrated below.


OV-2 showing Nodes having Operational Activities

Locations

An OV-2 View Product may optionally show the location of each operational node, if the location is known or knowable. The location may be specified geographically, and this in turn may be a specific geographic location (e.g. RAF Wyton) or a type of location or environment (e.g. behind enemy lines).


Generic OV-2 with locations

Note that this form of localisation is distinct from the concept of deployment to a platform (e.g. a warship). In MODAF this would be represented as a Physical Asset which forms part of a Capability Configuration that is associated with Node and fulfils the capability requirements associated with that Node.

OV-2 View Presentation

For complex Architectures, OV-2 may consist of multiple graphics. There are several different ways to decompose OV-2. One method involves using multiple levels of abstraction and decomposing the Nodes. Another method involves restricting the Nodes and Needlines on any given graphic to those associated with a subset of operational activities. Finally it is possible to organise OV-2 in terms of scenarios, missions or mission phases. All of these methods are valid and can be used together.

The default UML representation of OV-2 is as a composite structure diagram. This results in some complexity in the MODAF Meta-Model UML Profile. The nodes shown in an OV-2 diagram are actually usages of a node class in a particular context. This has the benefit that the same class of node can appear in more than one context on the same diagram. For this reason, Node Connectors, Needlines and relationships to Operational Activities are all specified in context of the usage of the Node class. The SysML concept of NestedConnectorEnd is used to provide the context for connections in an OV-2.

UML may not always be the best visual presentation for OV-2. An OV-2 product is often used to communicate the “big picture” to stakeholders who are unlikely to be familiar with UML models.

Service-Oriented Architectures

If the architect is developing a Service-Oriented Architecture (SOA), an OV-2 product may be used to show which logical agents (nodes) produce and consume services. The concept of producing and consuming services replaces the idea of fixed needlines – loose coupling is a tenet of SOA.


OV-2 showing Service Elements

As with a non-SOA OV-2, the capabilities of the nodes may also be shown. Most architectures are likely to consist of point-to-point connections as well as service interactions, so it is possible to have OV-2 products which combine the needline and service approach:


OV-2 showing Service Elements with traditional needlines

Page version 1.2, dated 20th June 2008

Top of Page