View DNDAF:OV-5b Operational Process Model Subview

dnd.gif

Title

OV-5b Operational Process Model Subview

Version & Date

1.6 See DNDAF Release History

Introduction

The OV-5b subview is part of the DNDAF Operational View.

The Operations View-5b: Operational Process Model describes the business and operational processes associated with the architecture project, 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 architecture project).

Purpose

The Operational Process Model is a key component in understanding the solution space of the architecture project. It is used to develop the “how” of the Operational View in achieving the “what” as described in the Functional Model (OV-5a). Operators, users and business owners are most likely to identify with this particular model, as it most closely represents what they can see themselves in.

Background

The OV-5b creates an Operational Process Model that focuses on “how” the architecture project’s objective is accomplished. The Operational Process Model includes the sequence of the activities. The sequence of the process is often based on the approach to accomplishing the mission. In other words, different process flows will result from different ways that a service is delivered, the equipment used or the people involved. By separating the function i.e. what has to be done (OV-5a) from the process flow i.e. how the organization accomplishes its mission (OV-5b) the architect is free to specify the approach to implementing the business functions in the most appropriate fashion.

Description

Definition

The Operational Process Model depicts the sequence of interconnected activities and their relevant inputs and consequent outputs which make up a business or operational process.

Detailed Description

Operational Process Models describe the steps involved in a business or operational process and detail the inputs to those steps and the resulting outputs, which are then inputs to other steps in the process. They document the relationships and flow of information between the functions that are defined in the OV-5a.

An Operational Process Model generally includes the following:

  • one or more diagrams of the activities covered in the model which includes the information flows and sequential priority of the functions;
  • explanatory text for each diagram, which provides any required detail; and
  • a dictionary that defines all activities and terms used in the diagrams.

With respect to this last item, the Integrated Dictionary (CV-2) serves as this dictionary, and contains all terms used in all of the sub-views constructed for a given architecture, including, but not limited to, the Operational Process Model.

Although the notation can be relatively simple, Operational Process Models themselves are often quite complex. Detailed Operational Process Models are sometimes needed for analysis and discovery of issues, but only the higher levels, or abstractions of the higher levels, should be provided to decision-makers.

Additionally, it is quite common to include additional information on Operational Process Models, such as controls, resources or responsibilities. While this is not prohibited in the OV-5b, it is imperative that any additional information added here is drawn from and captured in the appropriate sub-view that is responsible for the creation of the added information here.

Subview DADM Elements

The DADM entities and attributes provided below are the elements that this sub-view is responsible for creating:

 

 

Presentation

  • graphical

The OV-5b is represented by a model that depicts a set of activities, the relationships between the activities and the sequencing of these activities. This is commonly referred to as a process flow model, an IDEF example of which is shown below. In this (and most ways of modelling process flow) the boxes depict what has to be done, and they are arranged in a specific order necessary to achieve the output of the process. The arrows represent the inputs to and the outputs from the activities or process steps. Because the activities are sequenced, the output from an activity upstream will normally be the input to an activity downstream.

Each activity may be further decomposed or broken down into more detailed process flows if it necessary. Many formalisms or notations may be used to depict process flows. Some examples are IDEF3, BPM, Gane and Sarson, and Yourdon-DeMarco DFDs, and UML Activity Diagrams.

Examples

See:

  • p57 Figure 3.10.1 in DND/CF Architecture Framework (DNDAF)  Volume 2: DND/CF Views and Sub-Views

Prerequisites

The OV-5a is the prerequisite for this sub-view:

  • OV-5a. The functions and their relationships, defined in the OV-5a, are further detailed in the design of the activities, the sequencing of activities and the flow of inputs and outputs.

 

See DNDAF Subview Dependencies

 

Comments

 

Other Frameworks

See also:

References


Category:Framework -> Specification
Category:Framework -> Subview

Categories:

 

© 2010 Eclectica Systems Ltd.