Operational Views (OV) [Logical Views]
OV-5 Operational Activity Model v1.2
The Operational Activity Model (OV-5) describes the operations that are normally conducted in the course of achieving a mission or a business goal. It describes operational activities (or tasks), Input/Output flows between activities and to/from activities that are outside the scope of the Architecture.
Version 1.2 highlights
Use of Services for SOA
Background:
OV-5 describes the operational processes and activities that are being conducted within the mission or scenario. OV-5 can be used to:
- Clearly delineate lines of responsibility for activities when coupled with OV-2;
- Uncover unnecessary Operational Activity redundancy;
- Make decisions about streamlining, combining, or omitting activities;
- Define or flag issues, opportunities, or operational activities and their interactions (information flows among the activities) that need to be scrutinised further; and
- Provide a necessary foundation for depicting activity sequencing and timing in OV-6a, OV-6b, and OV-6c
OV-5 Activity Models describe the business processes associated with the architecture, as well as the:
- relationships or dependencies among the business processes,
- information exchanged between business processes, and
- external interchanges (from/to business processes that are outside the scope of the model).
An Operational Activity is a logical process, specified independently of how it is carried out. To maintain this independence from implementation, logical Nodes in OV-2 are used to represent the structure which carries out the Operational Activities. Operational Activities are realised as Functions (SV-4) which are the “how” to the Operational Activities’ “what” – i.e. they are specified in terms of the resources that carry them out.
Usage:
- Description of business processes and workflows
- Requirements capture (input to URD)
- Definition of roles and responsibilities
- Support task analysis to determine training needs
- Problem space definition
- Operational planning
- Logistic support analysis
- Information flow analysis
Data objects:
The data in an OV-5 can include:
- Operational Activities
- Standard Operational Activities (originating in StV-6)
- Operational Activity Flow Objects
- Swimlanes (each associated with a Node)
Relationships Between Key Data Objects (Simplified from M3)
Representation:
- Hierarchy chart
- IDEF0 Activity Model
- UML Activity Diagram
- UML Activity Diagram (with swimlanes)
BPMN Activity Models may also be allowable in future
Detailed Product Description:
OV-5 and OV-2 are, to a degree, complements of each other. OV-5 focuses on the operational activities whereas OV-2 focuses on the operational nodes. Due to the relationship between nodes and operational activities, these types of view should normally be developed together.
The Operational Activity Model (OV-5) addresses operational activities and business processes. An OV-5 describes the operations that are normally conducted in the course of achieving a mission or a business goal. It describes operational activities (or tasks), Input/Output flows between activities and to/from activities that are outside the scope of the Architecture.
MODAF does not endorse a specific modelling methodology, both UML and IDEF0 are currently supported (BPMN is expected to be supported in future).
OV-5 is equally suited to describing non-military activities and is expected to be used extensively for business modelling.
The activities described in an OV-5 may be Standard Operational Activities which are defined in StV-6 (which also maps the activities to corresponding capabilities). Standard Operational Activities are those defined in doctrine, but which are not tailored to a specific system – i.e. they are generic enough to be used without closing off a range of possible solution SVs.
There are two basic ways to depict Activity Models:
- The Activity Hierarchy shows activities depicted in a tree structure and is typically used to provide a navigation aid.
- The Activity Flow Diagram shows activities connected by information flow arrows.
The OV-5 activity hierarchy chart helps provide an overall picture of the activities involved and a quick reference for navigating the OV-5 Input/Output flow model.
Example OV-5 Activity Hierarchy
The OV-5 Activity Flow Diagram shows activities related by flows. Input/Outputs of operational activities relate to information elements of OV-3 and are further characterised by the information exchange attributes described in OV-3. The information elements may be further described using OV-7.
Example OV-5 Flow Diagram
The decomposition levels and the amount of detail shown on OV-5 will be aligned with the Nodes that are responsible for conducting the operational activities (shown on corresponding OV-2 View Products). Input/Outputs that are produced or consumed by leaf operational activities that cross Node boundaries are carried by Needlines of OV-2. In this way an OV-5 can contribute to functional boundary definition within the Operational Architecture.
OV-5 is intended to be only as exhaustive as necessary to attain the objectives for the Architecture (as stated in AV-1). It may be necessary, however, to model those Operational Activities beyond the boundary of the capability of interest that are sources or sinks for information flowing across it.
Annotations to the activities may also identify the costs (actual or estimated) associated with performing each activity. The business rules that govern the performance of the activities can also be keyed to each activity (business rules may be described in OV-6a.) Annotations to OV-5s can further the purposes of the description by adding specific attributes of exchanged information, which can later be used in OV-3. In addition, a process flow model may be annotated with the names of the Nodes responsible for conducting those activities.
A graphical variant of the OV-5 activity flow view may be used which has ‘swimlanes’ associated with defined Nodes. Swimlanes are presented either vertically or horizontally. An activity is placed in the swimlane associated with a Node if it is logically responsible for that activity. This provides a graphical means of presenting the collaboration between Nodes (shown through Needlines on OV-2) in functional terms.
Example OV-5 Flow Diagram with Swimlanes
Alternatively, operational activities can be annotated (e.g., via the mechanism arrow in an IDEF0 diagram) with the corresponding Node from OV-2.
If the Unified Modelling Language (UML) method is used, then the activity models can contain decision points and branching.
Complex OV-5 Flow Diagram with Swimlanes (UML)
If the Integration Definition for Function Modelling (IDEF0) method is used, the activities also show controls (factors that affect the way that the activity is performed) and may show mechanisms (the resources, including Nodes, that perform the activity). While some may illustrate corresponding systems as mechanisms in this model, the reader is cautioned that the introduction of system data early in the development of the OV may result in limiting system design and implementation decisions.
Example OV-5 Flow Diagram (IDEF0)
OV-5 may be used in conjunction with a process flow model (such as an IDEF3 model, or a UML sequence diagram) that describes the sequence and other attributes (e.g. timing) of the activities. A process flow model may be described in OV-6c. Such a process flow model further captures precedence and causality relations between situations and events by providing a structured method for expressing knowledge about how a process or organisation works.
From a modelling perspective, operational activities can be designated as ‘acting upon’ particular information entities. This relationship between activities and information entities is different to the Input/Output flow relationship described above. This is intended to address information management types of activities where the information entity is the subject of some management action but is not necessarily part of an input-output activity flow.
Service-Oriented Architectures
If the architect is developing a Service-Oriented Architecture (SOA), an OV-5 product may be used to show which services are required to support the conduct of operational activities. This type of product is commonly termed a “service orchestration diagram”, because it helps define what services are needed to support an operation and when they are needed.
OV-5 Diagram with Services
Page version 1.2, dated 20th June 2008