typically happen at the vendor/producer side of managed systems not at the operator side or being done by third parties.
This work addresses both systems management and systems development. It aims at finding a way how these two groups can find a better level of abstraction to communicate about systems, which is a necessary prerequisite for better IT management automation. The central idea is to take over concepts from systems engineering and process control automation which have successfully applied automation in artifacts like industrial plants, aircraft and space vehicles, and cars, to name just a few.
Based on these domains, we can enable cooperation of systems management and systems development along a common level of abstraction in terms of well-engineered automation patterns. The concept of abstract patterns can improve communication, as operators as well as developers can understand them and map them into their particular view: Operators can associate a pattern with a certain behavior and derive instructions about what an operator still has to/is allowed to take care of, while designers may have a tool-kit to map patterns to solutions/methods to enable the intended behavior. Patterns also ease the process of system managers giving input to system developers/designers. In the same way, systems designers can associate certain automated management tasks to certain functional units in a system.
1.7 Approach
Re-stating the problem of this thesis, a mapping of resource-related IT management tasks to an im- plementation in terms of automated management routines needs to be found. A major obstacle in cross-domain knowledge transfer is that the descriptions of engineering artifacts are typically targeted at domain experts. Aspects that would be applicable in other domains are often hidden between loads of domain-specific information. Instead, the system function needs to be abstracted while focusing on the system’s internal and external management. Therefore, for the automation approach itself, we can refer to results from systems engineering.
Reviewing related work in systems engineering—Sheridan, Humans and Automation [She02] with the author having a background in aviation and space applications—suggests the steps task analysis, breaking down tasks to functions, then function allocation to either humans or machines or collabora- tion of both. In task analysis he proposes to use the stepsacquire, analyze, decide, implement. This proven method for existing automation scenarios in Engineering has been adopted to be applied to IT management automation.
The following four concepts are a combination of automation concepts described in [She02] (1. and 3.) and own work (2. and 4.). The method of Engineered IT Management Automation argues to model, design, and describe SwSMC along the patterns of:
1. Task analysisis applied to break down these tasks to individual steps and to find relationships among them in terms of control/management layers. The known concept of IT management processes is replaced by IT management tasks to match Sheridan’s model.
2. Because of their repetitive nature, IT management tasks well fit a commonloop model. Instead of the observe, analyze, decide, execute loop, in IT management we are already familiar with the monitor, analyze, plan, execute based on knowledge loop proposed by IBM in its Autonomic Computing Initiative, and more loops from the high-level Deming process improvement cycle (plan, do, check, act) down to control loops in engineering. The different kinds of loops are compared for commonalities and differences to find a single loop to align the different task steps to.
Ch 1: Motivation and Problem Statement
Ch 2: Approach
Ch 7: Proof of Concept: Applying engineered automation to
a real-world problem
Ch 8: Conclusion and future work
Automation in Systems Engineering Current Automation in IT mgmt Engineered Automation in IT mgmt Ch 3: Task Analysis Ch 4: Loops Ch 5: Function Allocation Ch 6: Machine Cap's descriptive descriptive prescriptive
The need for automation in IT management (=self-management) is obvious. This automation creates systems with self-management capabilities: systems with built-in or closely attached management systems specific to a
certain set of resources. Current automation in IT management is often done ad hoc by system operators lacking
excellence in architecture, documentation, knowledge reuse, testing. In the same way, system designers only rarely predict the impact on IT operations, which can lead to limited acceptance. This split view has many negative effects.
How to improve IT mgmt automation?
Idea: Make use of knowledge from systems engineering! They have created good artifacts based on
good methods. Using their methods may bring improvements to our application domain. Support the IT management automation process with a method adapted from SE to IT management automation.
Goal: “engineered” automation in IT mgmt along task analysis, loops, function allocation, machine cap's.
Real-world problem scenario from a large WAN provider
Automation potential in End-to-end links with Quality of Service for a WAN
Future work: support this method with tools, support/automate the automation process pool/catalog of methods for common functions, incl. analysis and planning
summarize method scenario description tasks, loops, roles and task allocation, machine capabilities
(models, simulation) Task analysis Task model Task samples
Common base loop loops are similar reduce to superset: MAPDEK
loop properties high-level: PDCA (ITIL)
low-level: MAPEK (ACI) but no link between them
We have done it like this until now with deficits ...
They have done it like
that and used the aspects We should do it better like this ...
Levels of Abstraction Common base loop Loop model Loop samples
focus on monitoring and execution, limited analysis and planning, easy access to sensors and effectors
roles: ITIL (mostly focus on human roles), we need to deal with machine roles, limited allocation
mostly machine roles, limited focus on operator,
good work on allocation adjustable autonomy automation manager, levels of automation, move automation decisions to operator “manageable automation” collaboration of system designers and operators trigger an automation process for new mgmt tasks
apply task analysis from SE
Manageable task allocation Levels of automation Task allocation model Task allocation samples
clos e to m in ds et of s yste m d esi g n er cl os e to m ind se t o f sy ste m o p erato r Functions in MAPDEK Catalog of machine capabilities
Ch 3-6 describe a general automation approach: For each of these steps, structure existing knowledge, add own observations. And describe patterns to make adoption of the method easier, because a sys designer can later choose from alternative ways in most concerns of automation
Describe effects on affected human roles (system operators and system designers).
Ch7: Use of the results: (top-down and bottom-up, for system analysis and design). Related work and benefits of my work to SOTA: Automation method that is adapted to IT management, integration of knowledge from system operations and design.
1) ad hoc automation 2) process frameworks (ITIL, eTOM), BPEL/BPMN 3) self-mgmt, but hardly targeted at good automation Sheridan 2002 bri dgi ng co n cep ts machine-interpretable design knowledge, hints on use of methods many loops, some contain
a “decide” step
1.8 Vision: A tool-set for the engineering of IT management automation