Engineering of IT Management Automation along Task Analysis, Loops, Function Allocation ... PDF
Preview Engineering of IT Management Automation along Task Analysis, Loops, Function Allocation ...
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.
Description:The list of books you might like
