Engineering of IT Management Automation along Task Analysis, Loops, Function Allocation ...

348 Pages·2010·11.95 MB·English

by  Ralf König

Engineering of IT Management Automation along Task
Analysis, Loops, Function Allocation, Machine Capabilities
Dissertation
ander
Fakulta¨tfu¨rMathematik,InformatikundStatistik
der
Ludwig-Maximilians-Universita¨tMu¨nchen
vorgelegtvon
Ralf Ko¨nig
TagderEinreichung:12.April2010

Engineering of IT Management Automation along Task
Analysis, Loops, Function Allocation, Machine Capabilities
Dissertation
ander
Fakulta¨tfu¨rMathematik,InformatikundStatistik
der
Ludwig-Maximilians-Universita¨tMu¨nchen
vorgelegtvon
Ralf Ko¨nig
TagderEinreichung:12.April2010
TagdesRigorosums:26.April2010
1.Berichterstatter:Prof.Dr.Heinz-GerdHegering,Ludwig-Maximilians-Universita¨tMu¨nchen
2.Berichterstatter:Prof.Dr.BernhardNeumair,Georg-August-Universita¨tGo¨ttingen

Abstract
Thisthesisdealswiththeproblem,thatITmanagementautomationprojectsarealltackledinadifferent
mannerwithadifferentgeneralapproachanddifferentresultingsystemarchitecture.
It is a relevant problem for at least two reasons: 1) more and more IT resources with built-in or asso-
ciatedITmanagementautomationsystemsarebuilttoday. Itisinefficienttotrytosolveeachontheir
own. And 2) doing so, reuse of knowledge between IT management automation systems, as well as
reuseofknowledgefromotherdomainsisseverelylimited. Whilethisworkedwithsimplestand-alone
remote monitoring and remote control facilities, automation of cognitive tasks will more and more
profitfromexistingknowledgeindomainssuchasartificialintelligence,statistics,controltheory,and
automated planning. A common structure also would ease integration and coupling of such systems,
delegatingcognitivepartialtasks,andswitchingbetweencommonlydefinedlevelsofautomation.
Sofar,thisproblemisonlypartlysolved. Priorworkonapproachingsystemsdesignincludessystems
engineering with its steps task analysis and function allocation. But so far systems engineering has
notyetbeenwidelyappliedtoITmanagementautomationsystems,incontrasttotechnicalapplication
domainssuchasautomotiveoraerospaceengineering.
The state of the art in IT management automation itself on the technical side includes IBM’s Auto-
nomic Computing Initiative, proposing a structure of feedback loops for autonomic systems. On the
organizational side, a certain standardization of IT service management processes has been reached
with the introduction of process management standardization work like the IT infrastructure library
(ITIL), which is a collection of best practices in IT service management, and ISO 20.000, a standard
derivedfromITILV2. Sofar,thementioneddevelopmentsallstandeachontheirown.
The idea of this thesis is now to combine this prior knowledge to create a universal approach to the
designofITmanagementautomationsystemsinfoursteps:
Step1: TaskanalysisintheITmanagementautomationscenario,withanimplicitgoaltoassociatethe
identifiedtaskswithasubsetoftheITILreferenceprocesses(seeChapter3).
Step2: Reformulationofthetasksintofeedbackloopsofacommonstructureforcognitiveloops(see
Chapter4).
Step3: Function allocation of the loop steps to either performed by humans or machine components
(seeChapter5).
Step4: Identificationofasetofrelevantmachinecapabilitiesinacatalogstructuredalongtheprevious
threesteps(seeChapter6).
Eachofthesteps1–3istheresultofcombiningexistingknowledgeinsystemsengineeringandexisting
knowledgeinITmanagementautomation.
During this combination the author of this thesis also creates new structures, such as an automation-
orientedsubsetofITILV2called“AutoITIL”,the“MAPDEK”(monitor,analyze,plan,decide,execute
basedonknowledge)loopasbasicloopandsimplerwaysoffunctionallocationtohumans/machines.
Thecatalogofmachinecapabilities,presentedinStep4thenaddsanon-exhaustivecatalogofmachine
capabilitiesinITmanagementautomation. Itisdomain-specificbydesignandclearlyexceedssimilar
more general attempts such as Fitt’s “Men are better at, machines are better at” list, 1951. Other
conceptsaretakenoverunalteredafterareviewduringthiscombination,suchasproposalsbySheridan
(2000)onthestructureanddescriptionoftasksandlevelsofautomation. Allinall,thiswaywegaina
domain-specificmethodforengineeredITmanagementautomation(EIMA).
TheEIMAmethodisintendedtobeusedintheanalysisanddesignofITmanagementautomationsys-
tems. ItspurposeistofirstalignthestructureoftheautomationproblemtoEIMAandthentoquickly
identifyautomationpotentialenabledbyexistingmathematicalmethodsandmachinecapabilities.
In an application example (see Chapter 7), it is shown how an existing complex proposal for partial
automation in a wide area network scenario is analyzed, and a new proposal is derived that improves
automation along known concepts of control systems, and at the same time simplifies the organiza-
tional structure. It does so by decomposing the overall problem into a set of smaller problems that
can be solved by domain experts in economics, graph theory, network configuration management. A
comparison shows that while the previous proposal has created a UML-based draft model for a pro-
tocolthateasesinformationexchange, thenewproposalactuallyincludesthecognitivetasksthathad
been left to system administrators in the first proposal. A variable level of automation leaves enough
influence by network operators on the automation routine, and therefore provides the basis for better
acceptance.
Thisworkdiffersfromrelatedworkinnotfocusingonsingleautomationscenarioinstances(regarded
aspointsolutions),butinsteadproposingageneralmethodapplicabletoallsuchproblemsandbringing
abenefitbyitsassociationwithexistingconceptsinsystemsengineeringandITmanagement. Asthe
methodispartlyrootedinsystemsengineering,wecanbuildontheexperiencethathasbeengathered
thereinthedesignofcontrolsystemslikeautopilotsanddriverassistancesystems.
The main benefit of EIMA for system designers is a uniform way of describing and decomposing IT
management automation problems even of high complexity at a high level of abstraction. Only after
thishigh-leveldecomposition,systemdesignersanddomainspecialistswilltakecareofthedetailsby
furtherrefiningthetasksandimplementingsystemcomponents. Thistop-downapproachmakeseven
complex IT management automation systems comprehensible and concise in their description. Also
forsystemadministratorsthisisaclearbenefit.
Toachievethissimplicity,EIMAalsomustleavecertainaspectsunconsidered. Duetoitsuniversality,
we can hardly include scenario-specific aspects: EIMA makes no advice on the “best” automation.
Instead, it leaves out scenario-specific cost benefit analysis or return-on-investment analysis as this
dependsonexternalpoliciesaswell. EIMAalsodoesnotgivedetailedcookbook-likeadviceonwhich
machine capabilities to use for what task. In this point it must rely on the experience, background
knowledge and creativity of a user of the EIMA method, all of which is supported by EIMA, but not
guidedalongasinglepathofcauseeffectrelationshipstooneparticularsystemsdesign.
Potential follow-up work includes the creation of tools for EIMA itself: modeling tools, a knowledge
base of machine capabilities, the electronic representation of partial solutions such as loop patterns,
and simple visualization and simulation. In the same way as the design of electronic circuits today is
supported with circuit simulation programs such as SPICE, or design of 3D objects such as machines
orbuildingswithCADapplicationssuchasAutoCAD.Oncesuchtoolswereavailable,EIMAmodels
could be exchanged in terms of formal, machine-interpretable files instead of mainly verbal system
descriptionsinterpretedbyhumans.
Zusammenfassung
Diese Dissertation bescha¨ftigt sich mit dem Problem, dass Projekte zur IT-Management-Automati-
sierung jedes fu¨r sich anders angegangen werden und daraus unterschiedliche Systemarchitekturen
entstehen.
Die entstehende Heterogenita¨t ist aus mindestens zwei Gru¨nden problematisch: 1) Immer mehr IT-
SystememiteingebautenodergekoppeltenIT-Management-Automatisierungsfunktionenwerdenheute
entworfen. 2) Dabei wird nur in sehr begrenztem Maße auf vorhandenes Wissen aus anderen IT-
Management-Automatisierungsystemen oder verwandten Wissensfeldern zuru¨ckgegriffen. Wa¨hrend
der bestehende Ansatz fu¨r einfache U¨berwachungssysteme und Fernsteuersysteme noch ausreichte,
wu¨rde die Automatisierung der kognitiven Aufgaben immer mehr von Methoden aus den Gebieten
Ku¨nstliche Intelligenz, Statistik, Steuer- und Regelungstechnik, Automatisiertes Planen profitieren.
EineeinheitlicheStrukturvonIT-Management-Automatisierungssystemenwu¨rdeauchdieIntegration
und Kopplung solcher Systeme vereinfachen, sowie die Delegation von kognitiven Teilaufgaben und
dasUmschaltenzwischeneinheitlichdefiniertenAutomatisierungsgraden.
Bisher ist dieses Problem nur teilweise gelo¨st. Ein umfassender Ansatz zu Systemanalyse und Sys-
tementwurf wird im Systems Engineering beschrieben mit den Teilschritten Ta¨tigkeitsanalyse (task
analysis) und Funktionszuordnung (function allocation). Im Gegensatz zu Anwendungsdoma¨nen wie
derAutomobiltechnikundderLuft-undRaumfahrttechnikwirdeinvergleichbarerAnsatzbisheraber
kaumaufIT-Management-Automatisierungssystemeangewendet. DeraktuelleWissensstandinderIT-
Management-Automati-sierungansichbeinhaltetaufdertechnischenSeiteunteranderemIBM’sAu-
tonomicComputingInitiative,diefu¨r“autonomicsystems”eineStrukturausRu¨ckkopplungsschleifen
vorschla¨gt. Auf der organisatorischen Seite hat die Arbeit in der Standardisierung des IT-Prozess-
Management,unteranderemdurchITILundISO20.000,Verbreitunggefunden. Bisherjedochstehen
dieseEntwicklungenjeweilsfu¨rsich.
Die Idee der hier vorgelegten Arbeit ist, dieses vorhandene Wissen zu kombinieren. Damit wird ein
universellerAnsatzgeschaffen,mitdemmanIT-Management-AutomatisierungssystemeinvierSchrit-
tenentwerfenkann:
Schritt1: Ta¨tigkeitsanalyse (task analysis) des IT-Management-Automatisierungs-Szenarios mit dem
implizitenZiel,diegefundenenAufgabeneinemProzessauseinerUntermengederITIL-Prozesse
zuzuordnen(sieheKapitel3).
Schritt2: UmstrukturierungderAufgabenineinSchemaausRu¨ckkopplungsschleifenmiteinheitlicher
Strukturfu¨rkognitiveSchleifen(sieheKapitel4).
Schritt3: Funktionszuordnung (function allocation) der Schritte in den Schleifen zu Rollen, die
entwedervonMenschenoderMaschinenkomponentenausgefu¨lltwerden(sieheKapitel5).
Schritt4: IdentifikationeinerMengevonmaschinellenFa¨higkeitenineinemKatalog,deranhandder
Schritte1–3gegliedertist(sieheKapitel6).
Jeder der Schritte 1–3 ist dabei das Ergebnis einer Verschmelzung von vorhandenem Wissen im Sys-
temsEngineeringmitvorhandenemWissenausdemIT-Management.
Bei dieser Verschmelzung entstehen durch die Arbeit des Autors auch neue Strukturen, wie unter an-
deremeineautomatisierungsorientierteUntermengevonITILV2namens“AutoITIL”,die“MAPDEK-
Schleife” (u¨berwachen, analysieren, planen, entscheiden, ausfu¨hren, basierend auf Wissen) als Ba-
sisbaustein und einfachere Arten der Funktionszuordnung zu Mensch/Maschine. Der in Schritt 4
vorgeschlageneKataloggehtdeutlichinUmfangundStrukturu¨bera¨hnlicheAnsa¨tze(z.B.Fitt’sListe
“Men are better at, machines are better at”, 1951) hinaus und ist bewusst doma¨nenspezifisch fu¨r
IT-Management-Automatisierung angelegt. Andere Konzepte werden bei der Verschmelzung nach
Pru¨fung unvera¨ndert u¨bernommen, wie z.B. Vorschla¨ge von Sheridan (2000) zur Strukturierung und
Beschreibung von Aufgaben (tasks) oder Automatisierungsgraden (levels of automation). Insgesamt
erhaltenwireinedoma¨nenspezifischeMethodenamens“EIMA”(EngineeredITManagementAutoma-
tion)fu¨rIT-Management-AutomatisierungnachingenieurwissenschaftlichenGrundsa¨tzen.
DiebeschriebeneMethodeEIMAsollbeiderAnalyseunddemEntwurfvonIT-Management-Automa-
tisierungssystemeneingesetztwerden. IhrZweckistdabei,vorhandeneSzenarienanderneuenStruk-
tur auszurichten und dann vorhandenes Automatisierungspotenzial schnell zu erkennen, das durch
vorhandenemathematischeMethodenoderMaschinenfa¨higkeitengenutztwerdenkann.
IneinemAnwendungsbeispiel(sieheKapitel7)wirdexemplarischgezeigt,wieeinvorhandenerkom-
plexerVorschlagfu¨rdieTeil-AutomatisierungineinemWeitverkehrsnetz-Szenarioerstanalysiertund
danneinneuerVorschlagabgeleitetwird,derentlangbekannterPrinzipiendieAutomatisierungerho¨ht
und die organisatorische Struktur vereinfacht. Dies wird erreicht, indem man das Gesamtproblem in
kleinere Probleme zerlegt, die dann von Doma¨nenexperten in Betriebswirtschaft, Graphentheorie und
dem Konfigurationsmanagement von WAN-Komponenten jeweils einfach gelo¨st werden ko¨nnen. Ein
VergleichderbeidenVorschla¨gevor/nachEIMAzeigt,dassderersteVorschlagzwardenInformation-
saustauschmiteineminUMLmodelliertenProtokollentwurfautomatisierthat,aberderEIMA-basierte
VorschlagdieAutomatisierungderkognitivenAufgabeneinschließt,dieimerstenFalldenbeteiligten
Menschenu¨berlassen blieb. Um die gewu¨nschten Einflussmo¨glichkeiten durch diePartner des WAN-
Verbundeszubehalten,wirdeinvariablerAutomatisierungsgradvorgesehen.
Diese Arbeit unterscheidet sich von verwandten Arbeiten, indem sie nicht auf ein bestimmtes Punkt-
Szenarioabzielt,daszuautomatisierenist. StattdessenwirdhiereineallgemeineMethodeangegeben,
diesichfu¨rvieleIT-Management-Automatisierungsszenarieneignet,mitdemVorteilexistierendeKon-
zepteausSystemsEngineeringundITManagementinsichzuvereinigen. SokannauchaufErfahrun-
genaufgebautwerden,dieimZusammenhangmitSteuerungssystemenwieAutopilotenoderFahreras-
sistenzsystemengesammeltwurden.
Der Hauptvorteil von EIMA fu¨r Systemdesigner ist eine eine einheitliche Art der Beschreibung und
Zerlegung von selbst komplexen IT-Management-Automatisierungsproblemen auf einer hohen Ab-
straktionsebene. Erst nachdem man diese Zerlegung gemacht hat, wu¨rden Systemdesigner wie Fach-
leute die Detailfragestellungen angehen, in dem die Aufgaben weiter verfeinert werden und Sys-
temmodule implementiert. Dieser Ansatz der hierarchischen Dekomposition von oben nach unten
ermo¨glicht es, selbst komplexe IT-Management-Automatisierungssystems versta¨ndlich und knapp zu
beschreiben. Auchfu¨rSystemadministratorenistdieseindeutlicherVorteil.
Um diese Vereinfachung zu erreichen, muss EIMA aber auch bestimmte Aspekte unberu¨cksichtigt
lassen. Soko¨nnenwegenderUniversalita¨tbestimmteszenariospezifischenFragenkaumberu¨cksichtigt
werden: EIMAgibtdamitalsokeinenRatzur“bestmo¨glichen”Automatisierung. DadieseBewertung
auch von den a¨ußeren Rahmenbedingungen abha¨ngt, bleiben eine Kosten-Nutzen-Analyse oder eine
Amortisationsrechnungaußenvor. EIMAmachtauchkeinepunktgenauenVorgaben,welcheMaschi-
nenfa¨higkeiten fu¨r welche Aufgaben herzunehmen sind. In diesem Punkt muss es auf die Erfahrung,
dasHintergrundwissen, sowiedieKreativita¨tdesSystemdesignersvertrauen, diezwarvonEIMAmit
Vorschla¨genunterstu¨tztwerden,aberwo“dieLo¨sung”nichtentlangeineseinzigmo¨glichenPfadesaus
Ursache-Wirkung-Beziehungenhergeleitetwird.
Mo¨glicheFolgearbeitenko¨nnteninsbesonderedieAnwendungvonEIMAunterstu¨tzen,indemWerkzeuge
an EIMA angepasstoder fu¨r EIMA konzipiertund entwickelt werden, z.B. Modellierungswerkzeuge,
eine elektronische Wissensdatenbank als Implementierung des Kataloges der Maschinenfa¨higkeiten,
dieelektronischeRepra¨sentationvonTeillo¨sungenwiez.B.bestimmtenSchleifenmustern,sowieFunk-
tionenzurVisualisierungundSimulation. InvergleichbarerWeisedazu, wieheute derSchaltkreisen-
twurfdurchSchaltungssimulationsprogrammewieSPICEunterstu¨tztwird,oderderEntwurfvon3D-
Objekten wie Maschinen oder Geba¨uden durch CAD-Anwendungen wie AutoCAD. Wenn solche
Toolseinmalverfu¨gbarsind,ko¨nntenEIMA-Modellealsformale,maschinen-interpretierbareDateien
unterEntwicklernausgetauschtundwiederverwendetwerden. Bisherbeschra¨nkensichSystembeschrei-
bungenmeistaufeineweitgehendverbaleBeschreibung,dievonMenscheninterpretiertwird.