Architecture† Document† Node† OperationalRole† Organization† OrganizationType† ProcessActivity† SoaService† IconCatalog OperationalElement OperationalFacility †)
The descriptions of these elements have been provided in the preceding sections Table 4-4 describes the architecture data elements for OV-4.
Table 4-4 Data Element Definitions for OV-4
Data Elements Attributes Definition
IconCatalog
defaultReferenceName The name of an instance of IconCatalog catalog that is used
by the application for internal citations.
iconTypeCode The code that represents a kind of IconCatalog.
linkArrowstyleTypeCode The code that represents the kind of arrowhead that will appear on the end(s) of a link type IconCatalog instance. linkColorIdentification
Text The text that identifies the color to be depicted for a specific link type IconCatalog instance.
linkLinePoint
CharacteristicCode The code that represents the thickness of a link type IconCatalog instance. Default value is "8" (1-point solid line).
linkLinetypeTypeCode The code that represents the kind of segmentation to be
used for a link type IconCatalog instance. Default value is "1."
nodeCategoryCode The code that represents the kind of IconCatalog that
represents a node type IconCatalog instance.
nodeSubcategoryCode The code that represents a detailed classification of
IconCatalog instances that represent a node.
OperationalElement
approvalStatusCode The code that represents the state of validity for the data for
an OperationalElement.
categoryCode The code that represents a class of OperationalElement.
useTypeCode The code that represents a kind of OperationalElement by
intended employment.
OperationalFacility
alternateIdentifierText The text that describes the identifier that acts as a substitute
for identifying an OperationalFacility.
approvalStatusCode The code that represents the state of validity for the data for
an OperationalFacility. historicalJustification
Text The text of the rationale for the application of an OperationalFacility.
iterationIdentifierText The text which describes the identifier that distinguishes the
OperationalFacility from any other OperationalFacility with the same echelon and proponent.
justificationText The text of the rationale for the application of an
OperationalFacility.
remarkText The text representing the comments regarding a specific
OperationalFacility.
Data Elements Attributes Definition
OperationalFacility.
Relationships
Parent Verb Phrase Child
IconCatalog is related to IconCatalog
OperationalElement describes type of OperationalFacility
(All previous relationships for the listed entities that comprise the information space of OV-4 should be considered part of the specification for this product, as well as those for the entities modeled via ObjectByReference and ObjectVersionAssociation. For the latter, see Volume III.)
4.5 OPERATIONAL ACTIVITY MODEL (OV-5) 4.5.1 OV-5 – Product Description
Product Definition. The OV-5 describes the operations that are normally conducted in the course of achieving a mission or a business capability. It describes capabilities, operational activities (or tasks), input and output (I/O) flows between activities, and I/O flows to/from activities that are outside the scope of the architecture. High-level operational activities should trace to (and are decompositions of) a Business Area, an Internal Line of Business, and/or a Business Sub-Function as published in OMB’s Business Reference Model [OMB, 2003].
Product Purpose. 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 scrutinized further.
• Provide a necessary foundation for depicting activity sequencing and timing in OV-6a, OV-6b, and OV-6c.
• Identify critical mission threads and operational information exchanges by annotating which activities are critical (i.e., identify the activities in the model that are critical).
Product Detailed Description. OV-5 describes capabilities, operational activities (or tasks), I/O flows between activities, and I/O flows to/from activities that are outside the scope of the architecture.
I/Os of operational activities relate to information elements of OV-3 and are further characterized by the information exchange attributes described in OV-3. I/Os that are produced or consumed by leaf operational activities that cross operational node boundaries are carried by needlines of OV-2. Operational activities can be annotated (e.g., via the mechanism arrow in an IDEF0 diagram) with the corresponding operational node from OV-2.
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 are 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.
OV-5 is a key product for describing capabilities and relating capabilities to mission accomplishment. The DoD Dictionary of Military Terms [DoD JP 1-02, 2001] defines a capability as “the ability to execute a specified course of action. (A capability may or may not be accompanied by an intention.)” A capability can be defined by one or more sequences of activities, referred to as operational threads or scenarios. A capability may be further described in terms of the attributes required to accomplish the set of activities (such as the sequence and timing of operational activities or materiel that enable the capability), in order to achieve a given
mission objective. Capability-related attributes may be associated with specific activities or with the information flow between activities, or both. When represented by a set of operational activities, a capability can also be linked to an operational node in an OV-2.
Integrated architectures with Doctrine, Organization, Training, Materiel, Leadership & education, Personnel, and Facilities (DOTMLPF) information provide a structured and organized approach for defining capabilities and understanding the underlying requirements for achieving those capabilities. The full spectrum of DOTMLPF is modeled and related so that analyses and decisions can be supported by describing the sequence and timing of activities; tying them to the operational nodes (representing organizations or human roles); relating them to their supporting systems or system functions; and specifying the actions, events, and related guard conditions or business rules that constrain those activities. Below is a detailed description of how DOTMLPF is tightly weaved into this and related products.
• Doctrine may influence controls or guard conditions in OV-5.
• Organization is represented via the operational nodes of OV-2, which can be shown as mechanisms (or annotations to the activities) in OV-5.
• Training is represented via the operational node that may represent a human role, which, in turn, embodies a certain skill set or knowledge domain required to perform the activities that are, in turn, related to operational activities of OV-5.
• Materiel is tied to the elements in OV-5, where mechanisms may be used to represent systems that support operational activities. Further materiel detail may be related to the activities via SV-5, by relating those activities to the system functions that are executed by systems that automate them (wholly or partially). Each operational thread or scenario (represented by an OV-6c) is associated with a certain capability, since a capability is defined in terms of the activities and their attributes depicted in OV-6c. Consequently, an SV-5 may also be used to relate a capability to the systems that support it, by labeling a set of activities with its associated capability (defined in OV-6c), and by labeling the system functions with the systems that execute them (defined in SV-1, SV-2, and SV- 4).
• Leadership may be represented indirectly in OV-5 by first mapping activities to operational nodes via mechanisms and through the relationships of an operational node in OV-2 to organizations, organization types, or leadership human roles in OV-4.
• Personnel may be represented indirectly through the relationships of an operational node in OV-2 to organizations, organization types, or human roles in OV-4.
• Facility is tied to OV-5, because an operational node is directly tied to the systems nodes (facilities) that house the systems, which may be shown as mechanisms that support operational activities.
OV-5 graphic(s) may include a hierarchy chart of the activities covered in the model. A hierarchy chart helps provide an overall picture of the activities involved and a quick reference for navigating the OV-5 I/O flow model.
OV-5 is frequently 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 further captures precedence and causality relations between situations and events by providing a structured method for expressing knowledge about how a process or organization works. A process flow model may be annotated with the names of the operational nodes responsible for conducting those activities. A process flow model may be described in OV-6c.
The decomposition levels and the amount of detail shown on OV-5 should be aligned with the operational nodes that are responsible for conducting the operational activities (shown on corresponding OV-2 products). It is important to note the OV-5 is intended to be only as exhaustive as necessary to attain the objectives for the architecture as stated in AV-1. Figure 4-14 depicts templates for the Operational Activity Hierarchy Chart and one level of a process- flow OV-5.