Legal information

Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)

ARCH.121 Consolidate operational activities and interactions

GoalAchieve an elegant and optimal operational activity architecture and assure that all operational activities are allocated to the right entities
Requirements met by this process stepNone listed
Inputs

AMOD-027 Operational bare business scenario

AMOD-028 Operational activities and interaction definitions (single operational capability)

AMOD-029 Operational bare business process

AMOD-033 Operational business scenario with risk control measures

AMOD-035 Operational business process with risk control measures

AMOD-024 Operational activity definition and allocation

Outputs

AMOD-101 Consolidated operational activities & interactions

AMOD-024 Operational activity definition and allocation (updated)

AMOD-027 Operational bare business scenario (updated)

AMOD-028 Operational activities and interaction definitions (single operational capability) (updated)

AMOD-029 Operational bare business process (updated)

AMOD-033 Operational business scenario with risk control measures (updated)

AMOD-035 Operational business process with risk control measures (updated)

Methodology

The results of scenario-based analysis of operational activities will be mixed and may have gaps. There will be a large number of operational activities but there will be little structure to assist in understanding the set of activities as a whole. The set of operational activities and interactions needs to be consolidated. There are 3 main points to consider:

The activities should be grouped by common themes and consideration should be given to creating a hierarchy of activities in order to nest the leaf-level activities.

Any hierarchy should be as flat as possible. Layering for the sake of layering should be avoided. It is not necessary for every leaf level activity to be on the same layer of the hierarchy. Use just enough layering to help readers navigate the model, no more.

When looking at a group of activities, it may become obvious that there is one missing from the set. This may mean that an operational process has a missing part, or that a capability is missing. If it appears this is the case, go back and amend the capability/process. Do not simply add the activity without it appearing in at least one process. This would mean there is no known business need in the model for the activity.

Since operational activities are created by each group working on operational capabilities, it is possible that one group may have missed the fact that the other group has already created an activity. There may be duplicates. Where duplicates exist, they should be eliminated. Ensure that a duplicate is replaced by the master item on all views where it appears, BEFORE deleting the duplicate. On deletion, the duplicate should no longer be related to any other model element.

There should be an overall pattern in the flow through the operational activities. This may only be visible when looking from a high level down onto the diagram. It should be possible to differentiate between feed-forward and feedback flows. Where possible, the diagram should be arranged so that feedback interactions flow in the opposite direction to feed-forward interactions.

If not already complete, populate the view with all the operational entities and actors.
Add the operational activities currently allocated to the operational entities and actors.

NB: most of these should already have been allocated when they were included in operational entity scenarios. There should be few operational activities remaining that are not allocated, except for those that are clustered at a higher level from the leaf-level activities that were actually used in the OESs and the OPDs.

We are not concerned with allocating any activity that is not leaf-level, as long as all leaf-level activities are allocated to one entity/actor.
For each leaf-level activity that is not yet allocated

      • Determine if this activity is ever used in an OES and/or an OPD.
      • If it is used, determine (with the owner of the corresponding capability) which actor or entity should carry out this activity;
      • else if not, make it a candidate for deletion

Caution!

Where this process step results in changes to the existing activities and/or interactions, they must be updated on all views where they are used (including the viewpoints for the single operational capabilities). the single-capability views must not be allowed to lose consistency with the consolidated views.

Tools and non-human resources

Team for Capella

Cardinality

Once per package of operational capabilities

Completion criteria

The produced view is compliant with its modelling rules.

The complete set of operational activities and interactions is safe enough to try.

Design reviewARCH.R.2 Operational review - consolidated
Step done by (Responsible)

Operational concept architect

Provides input to/assists (Contributes)

System architect

Systems engineer

Cross-cutting engineer

Operations domain expert

Uses outputs (Informed)None directly