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
Goal | Achieve an elegant and optimal operational activity architecture and assure that all operational activities are allocated to the right entities |
---|---|
Requirements met by this process step | None 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 |
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.
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 review | ARCH.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 |