Necessity of a structuring element in the task decomposition tree

4.1.3 Necessity of machine-interpretable loop modeling . . . 93

4.2 Requirements on Loops in EIMA . . . 94

4.2.1 R2.1 Loops must be usable at multiple levels of abstraction . . . 94 4.2.2 R2.2 Commonly structured base loop . . . 94 4.2.3 R2.3 Machine-interpretable loop modeling and linking back to the tasks in

task analysis . . . 95

4.3 Existing knowledge about loops in current IT Management automation . . . 96

4.3.1 Improvement cycles in ITSM frameworks . . . 96 4.3.2 Cognitive loop in FOCALE architecture . . . 96 4.3.3 MAPEK loop of the ACI . . . 96 4.3.4 Triggered application of event, condition, action (ECA) rules . . . 99 4.3.5 Cyclic application of fix-point operators . . . 100 4.3.6 Schedule-based automated procedures . . . 100 4.3.7 Feedback control loops . . . 101

4.4 Existing knowledge about loops in related domains . . . 103

4.4.1 Quality management . . . 103 4.4.2 Business management . . . 103 4.4.3 Human Factors Engineering . . . 104 4.4.4 Medical science . . . 106 4.4.5 Systems engineering . . . 106

4.5 Requirements Check . . . 111

4.5.1 Regarding R2.1 Loops must be usable at multiple levels of abstraction . . . . 111 4.5.2 Regarding R2.2 Commonly structured base loop . . . 115 4.5.3 Regarding R2.3 Machine-interpretable loop modeling and linking back to

the tasks in task analysis . . . 117

4.6 Proposal on modeling MAPDEK loops in EIMA . . . 119

4.6.1 Regarding R2.1 Loops must be usable at multiple levels of abstraction . . . . 119 4.6.2 Regarding R2.2 Commonly structured base loop . . . 121 4.6.3 Regarding R2.3 Machine-interpretable loop modeling and linking back to

the tasks in task analysis . . . 122 4.6.4 Example . . . 124

The previous chapter described the results of task analysis in engineered IT management automation (EIMA), this one will now show how loops will serve as a structuring element in the task decompo- sition tree. The chapter opens with a motivating example, which will be used to derive three general requirements on these loops. Then, as in the previous chapter, relevant existing knowledge on loops will be presented as an overview on the state of the art in the domain of current IT management. In the same manner, and intended as a source of cross-domain inspiration, we will investigate the state of the art in other research disciplines, that can contribute to the use of cognitive loops for automation. The findings in all of these domains will then be checked against the requirements listed at the beginning to spearate the more promising items of related work from the ones being less applicable. The chapter closes with proposals on structuring tasks with loops and modeling these loops in EIMA.

4.1 Motivation and current examples

In Chapter 3 we used workflows as a starting point for task analysis, two example workflows were shown in Fig. 3.1 and 3.2 near page 47. From an automation point of view, we had identified two dis- advantages associated with such workflow structures: heterogeneity of the workflow and heterogeneity of tasks, and unclear reduction of complexity, as well as much necessary modeling. Then, in the course of task analysis in Chapter 3, the process description structures were changed from a workflow-like representation to a hierarchical one. This resulted in a task decomposition tree with tasks and relation- ships between them. See Fig. 3.7 for an example, which already looks complex enough, yet it can be assumed that it was already drastically reduced by the authors to fit on a printed page. We can expect that average real world examples to contain about 10, 100 or 1000 times more tasks in one or more task decomposition trees for a subset of the AutoITIL processes. So, even when arranged in a task decom- position tree, the number and variety of tasks in the trees are an expression of heterogeneity. They may all nicely fit into the tree structure, but the tasks are very many and very different. In the next three subsections, the requirements on structuring elements in the tree will be motivated. A preview on the intended result can be seen in Fig. 3.14 on page 85, where a single loop was introduced. Later, loop structures can also be nested and cascaded. A more complex example will be shown in the example at the end of this chapter.

4.1.1 Necessity of a structuring element in the task decomposition tree

We need to take into account, that automation is the more applicable, the more structured a problem is and the more heterogeneity is reduced (see section 1.2.1) . We had addressed number and heterogeneity of tasks with unfolding or folding the lower levels of the task decomposition tree, but there is a limit to this type of (easy) simplification. There is a certain level of complexity in tasks, that cannot be further reduced without severely veering away from the original automation task. As we need to keep this minimal required detail in tasks, there is no way around keeping the “minimal” necessary size of the task decomposition tree (being the lower limit in terms of the number of tasks, which will still result in many tasks).

Then, within a tree of this least scale, more structure needs to be added in these task decomposition trees than the simple hierarchical links with “is sub-task of” semantics. By design, we have also set the precondition, that the majority of the tasks is repetitive. Repetition is one of the necessary preconditions for automation, because if the tasks were not repetitive then we would unlikely apply automation to them. Repetition is a common pattern to fight complexity in terms of scale. Repetitive actions can be trivially simplified by specifying one cycle, and then specifying a number of iterations of that cycle.

4.1 Motivation and current examples This is called a loop in IT. Repetition well applies to all AutoITIL processes, for many of them we can assume a periodicity of multiple instances per day or month. Considering the repetition, we can translate the tasks to loops.

Therefore we want to combine tasks in the task decomposition tree into loop composites, by adding loops as an additional structure overlay. As the task tree covers multiple levels of abstraction, the loops need to be applicable at multiple levels of abstraction as well.