.2 Ervaringen in de praktijk met het Microsoft Operations Framework Er is reden voor een feestje: het Microsoft s Operations Framework (MOF) mag naar de basisschool, want het is onlangs jaar oud geworden. Een leeftijd van jaar betekent ook een lustrum en daarmee is er reden voor een terugblik. Dit doen we door in te gaan op de achtergrond van MOF, de diverse versies en de toekomst. Belangrijker dan de theorie is de terugblik op het gebruik van MOF, met de nadruk op cases die zich buiten Microsoft zelf afspelen. Dit artikel kiest dan ook een pragmatische benadering en zal aan de hand van enkele (anonieme) cases de praktische kant belichten. Maar eerst een korte inleiding op de actuele zaken rondom MOF. 1 Auteurs: Rudolf Liefers, Marjo van Bergen, Martin Sih, Caro Vermeule - Capgemini KORTE INTRODUCTIE MOF Ontstaan MOF zag het levenslicht in de laatste jaren van de vorige eeuw. Het was het antwoord van Microsoft op de vraag hoe de IT-organisatie ervoor kan zorgen dat de kwaliteit van haar op Microsoft-technologie gebouwde services op het gewenste peil blijft. In Redmond groeide het besef dat voor een goede IT-dienstverlening meer nodig was dan goed werkende technologische oplossingen. Hiertoe werd, samen met diverse grote en kleine marktpartijen, een framework specifiek voor beheer en exploitatie van Windows-technologie ontwikkeld. Het Microsoft Operations Framework levert concrete bouwstenen (zoals kant-en-klare procesdocumentatie), waarmee organisaties hun beheer voor bedrijfskritische omgevingen kunnen inrichten en daardoor die omgevingen beter kunnen beheren. MOF bestaat deels uit een aantal componenten van ITIL en is verrijkt met een aantal specifieke componenten van Microsoft voor de inrichting van de beheerprocessen. Microsoft bouwt bewust voort op ITIL en stelt dat het ITIL zowel adopteert als adapteert. MOF is ontworpen om breed te kunnen worden ingezet en zou dus ook geschikt zijn voor andere omgevingen dan die van Microsoft. Structuur Het Microsoft Operations Framework bestaat uit drie modellen: het procesmodel, het Team Model en het Risicomodel. Alledrie hebben ze enerzijds veel raakvlakken met ITIL en anderzijds deels hun wortels in andere concepten van Microsoft, zoals het Microsoft Solutions Framework. In voorgaande edities van dit boek is dit al uitvoerig belicht en we verwijzen dan ook naar die artikelen, of naar www.microsoft.com/mof voor details. Nieuwe versie Medio 2004 is versie 3.0 van het MOF verschenen. Deze versie is een majeure update van de vorige versie. Er is veel aangepast, en er zijn praktijkervaringen opgenomen in het model. Ook zijn er wijzigingen voortgekomen uit wijzigingen in andere modellen van Microsoft, zoals het Microsoft Solutions Framework (MSF).
2 MODEL Procesmodel Aanpassingen in versie 3 Aangepaste Service Management Functions: Security Management is toegevoegd, als aanvulling op het reeds bestaande Security Administration. Infrastructure Engineering is toegevoegd, als aanvulling op een witte plek en om consistent te blijven met ITIL. Print & Output Management is onderdeel geworden van Storage Management. Change Management Release Engineering Configuration control / asset management Intellectual property protection Software distribution/licensing Network and system security Quality assurance Intrusion detection Virus protection Audit and compliance administration Release Contingency planning Security SLA drafting / negotiation Service catalog management SLA review Service improvement initiation Customer relationship management Service level management Service 3 Team Model Risicomodel Tabel 1 Wijzigingen in de derde versie van het MOF De bovenstaande wijzigingen laten zien dat het MOF een levend model is. MOF wordt binnen Microsoft zelf op grote schaal toegepast en de ervaringen uit deze praktijk worden beschreven in het model. Daarnaast is Service Level Management Financial Management Capacity Management Availability Management IT Service Continuity Mgmt. Workforce Management Security Management Infrastructure Engineering SLA Review Service Desk Incident Management Problem Management Aangepaste Quadrants/Reviews: De namen van de Reviews zijn aangepast. Er is een Role Cluster Team toegevoegd, namelijk Service. Dit bevat taken en rollen voor het management van zowel interne als externe klantrelaties. Er is een extra matrix toegevoegd die mensen, Team Roles en SMF s beter met elkaar verbindt. Het Risk Model is hernoemd naar Risk Management Discipline, waardoor het meer generiek toepasbaar wordt. Ook is een betere relatie gelegd naar/met MSF, doordat de koppeling met Risk Management uit MSF is aangebracht. Hierdoor is MSF overigens ook meer in lijn met Prince2. Optimizing Supporting Change Initiation Review MOF Operations Review een groot aantal partijen betrokken bij de verdere ontwikkeling ervan en zorgt de alignment met ITIL ervoor dat MOF regelmatig wordt aangepast. Changing Operating Figuur 1 Het MOF Proces Model en MOF in IT service management functies (SMF s) Change Management Configuration Management Release Management Release Readiness Review System Administration Security Administration Service Monitoring & Control Directory Services Administration Network Administration Storage Management Job Scheduling Partner Managed service outsourcers Software / hardware suppliers Maintenance vendors Environment support Operations Training partners Messaging operations Database operations Network administration Monitoring / metrics Availability management Status in de markt Een aantal organisaties is bezig met de implementatie van MOF en zij worden bijgestaan door partijen als PinkRoccade, Capgemini en Fujitsu. De begin 2004 verwachte MOF-boost is nog even uitgebleven, althans in Nederland. In andere landen begint MOF meer aan te slaan. De Nederlandse voorsprong op ITIL-gebied lijkt hier de wet van de remmende voorsprong te bewijzen. Toekomstige ontwikkelingen Ontwikkelingen die verwacht worden in de komende 12-18 maanden zijn o.a.: een uitbreiding/aanpassing van de EXINcertificatie voor de ITIL-kwalificaties. Deze worden momenteel herzien en de ordening van het MOF Procesmodel vormt hiervoor een belangrijk uitgangspunt. Overigens wordt verwacht dat Microsoft zelf ook met een MOF Certificaat zal komen. ITIL ondergaat in 200/2006 een belangrijke update en het valt te verwachten dat veel MOF-content terug zal komen in ITIL versie 3. MOF heeft immers op het gebied van IT Operations veel toegevoegd aan het beheerwerkveld en ITIL moet een weerspiegeling van de markt vormen. Infrastructure Figuur 2 MOF team-rollenclusters en hun afbeelding op het MOF Proces Model Enterprise architecture Infrastructure / systems engineering Capacity management Support Cost / IT budget management Resource and long-range planning Service desk / help desk Production / production support Problem management Service level management Microsoft is bezig met het verder uitbouwen van haar Dynamic Systems Initiative. Hierin moeten uiteindelijk alle beheeroplossingen, zowel tools als procesmodellen, van Microsoft gaan samenkomen. Tools mogen hierin niet gaan overheersen ten nadele van de procesmatige benadering van beheer. Het is dan ook aan de service managers om hier de vinger meer dan goed aan de pols te houden. BESCHRIJVING CASES Case: Onderhoudsbedrijf Probleemstelling Een onderhoudsbedrijf met meerdere vestigingen in Nederland verrichtte diverse soorten klein en groot onderhoud aan haar transportmiddelen. Dit gebeurde 24 uur per dag en 7 dagen per week, zowel gepland als ongepland. Daarnaast diende het onderhoudsbedrijf ervoor te zorgen dat het juiste onderdeel op het juiste moment op de juiste locatie is, met de juiste monteurs. Dit stelde hoge eisen aan de logistiek van het bedrijf. Deze kernactiviteit werd ondersteund door de afdeling IT-beheer.
4 De IT-infrastructuur werd totaal gerenoveerd. Daarnaast werd het IT-beheer gecentraliseerd met het oog op kostenbesparingen. De invoering van de nieuwe infrastructuur moest een hoger dienstverleningsniveau opleveren, wat gewaarborgd moest worden door Service Level Agreements. De afdeling ITbeheer, die ook de huidige infrastructuur beheerde, ging de nieuwe infrastructuur vanaf één centrale locatie beheren. De behoefte aan een sterke, goed geëquipeerde beheerafdeling was dus zeer groot, niet in het minst gezien de hoge investeringen in de renovatie en de centralisatie. Bovengenoemde doelstellingen waren ambitieus te noemen, omdat de IT-afdeling op het gebied van kennis en kwaliteit van dienstverlening nog niet op het gewenste niveau was. Bij de IT-beheerders bestond geen gemeenschappelijk beeld over het gewenste serviceniveau en dat werd versterkt door de klant, die geen toereikend beeld had van de kwaliteit die IT zou kunnen leveren of zelfs daadwerkelijk leverde. Dat de IT-beheerafdeling meerdere keren met wisselend succes met ITIL had gewerkt was een extra complicerende factor. Bovendien bestonden er de nodige twijfels over het niveau van het beheer van de infrastructuur, zowel bij de beheerders zelf, als bij het management en bij klanten. Keuze voor MOF De keuze voor MOF was ingegeven door het daarin goed beschreven operationele deel, de goede aansluitmogelijkheden op al ingerichte ITIL-processen bij andere afdelingen en de beschikbaarheid van (betaalbare) tools. Heel bewust werd ervoor gekozen om te starten met het procesmodel, vanwege de goede aansluiting met het huidige, grotendeels operationele werk van de beheerders. Het Team Model en het Risicomodel leken in eerste instantie te ver van de beheerders af te staan. Aanpak Om een gemeenschappelijk draagvlak te creëren bij de beheerders werd gekozen voor het neuzen richten aan de hand van een aantal workshops. Hierin kwamen alle partijen tot een top 3 van prioriteiten, namelijk monitoring, diagnose en communicatie. Zowel de klanten, het management als de beheerders hadden belang bij inzicht in de status van applicaties en infrastructuren (monitoring). Alle partijen wilden weten wat nu waardoor werd veroorzaakt en hoe dat kon worden verbeterd (diagnose). De klanten en het management hadden een zeer sterke wens om op tijd de juiste informatie over de IT-infrastructuur te ontvangen. De beheerders zelf hadden dringend behoefte aan informatie van voornamelijk de klanten over hun bedrijfskritische momenten en applicaties (communicatie). Deze conclusies bevestigden de initiële beelden die de partijen van elkaar hadden en gaven eens te meer aan dat het opstellen van service level agreements zeker ging helpen. Op het moment dat bij deze partijen in grote lijnen dezelfde eisen en wensen bestonden ten aanzien van de IT-beheeromgeving, werd hen gevraagd om deze zaken voor zichzelf verder in te vullen. Tevens werd hen gevraagd aan te geven hoe zij de andere partijen van de voor hen noodzakelijke informatie konden voorzien. Dit artikel gaat verder niet in op de eisen en wensen van klanten en management, maar focust op de situatie rondom de IT-beheerders. Workshops In de workshops werden diverse risico s en bekende calamiteiten met het management, de klanten en de beheerders besproken. Door deze confronterende aanpak werd een aantal opgebouwde muren geslecht. Voor de beheerders volgde na de eerste workshop een aantal eigen workshops. Hierin was het aan de beheerders, samen met externe consultants, om aan te geven wat zij nodig dachten te hebben om hun eigen werk te kunnen doen en de juiste informatie aan klanten en management te verstrekken. De workshops gingen expliciet in op het procesmodel. De andere twee modellen werden niet bewust uitgewerkt, maar waar het ter sprake kwam werd wel een aantal teamrollen uit het Team Model ingevuld. In deze workshops kwamen ook de al eerder vermelde risico s en calamiteiten aan de orde en werd voor een meer probleemgestuurde oplossingsmethode gekozen. De praktijkbenadering had de voorkeur boven de theorie. Voor elk geïdentificeerd probleem werd onderzocht hoe dit met delen van het procesmodel zou kunnen worden opgelost en welke tooling daarvoor nodig was. In deze workshops lag daarom de nadruk op het operating- en het supporting kwadrant, en het configuratiemanagement (uit het changing kwadrant). Structuur MOM (Microsoft Operations Management) Workshop Bespreek hier welke services geleverd worden, en welke vorm van monitoren hierop van toepassing is. Dit is een goede insteek om feeling te krijgen met het systeem, voor detailniveau kunnen het beste de management packs van MOM worden gebruikt. Welke service leveren we? - Inventariseer de te leveren services. Te denken valt aan Network Devices, Firewall Services, en Applicatie Services. ORGANISATION Packaging Manager Packaging Technicians X 4 PACKAGING PROCESSES Authenticated Request Work Package Production Build Standards Test Standards / Plans Promotion to DSL Feedback to requester Laptop computer SMS Systeem Owner DSL IBN Compatible Figuur 3 Generiek proces van Operational Management Wat willen we per service weten? - Welke informatiebehoefte is er? (CPUgebruik, schijf vol, et cetera) - Welke servers betreft dit? - Boven welke waarde is de informatie relevant, met andere woorden wat is de threshold? Bijvoorbeeld als de schijf voor 90% vol is. - Wanneer en met welke frequentie is monitoren wenselijk? Bijvoorbeeld alleen tijdens kantooruren en dan ieder uur. In de workshops werd gewerkt met het generieke procesmodel Operational Management zoals in figuur 3 wordt weergegeven. Van diverse kanten komen gebeurtenissen en vragen op het Operational Managementproces af. Enige voorbeelden ter verduidelijking: Incident - Er is een hardware-storing op een server. Zoiets gebeurt onverwacht (monitoring ontdekt deze gebeurtenis). Afhankelijk van welke server het is en wat er aan de hand is (analyse), wordt een bepaalde actie gestart (actie). Uiteraard moet vastgelegd worden dat het incident is opgetreden, hoe lang het heeft geduurd en welke acties zijn ondernomen (rapportage). Dagelijks - Er komt een nieuwe user bij. Het verzoek komt binnen op de service SMS Enterprise Administrator X 3 ORGANISATION Service Desk Level 2 Support Software Distribution PROCESSES Confirmation of Package in DSL Confirm AD compliance for package Push process / Authority Remote Control / Authority
6 desk (monitoring). Er wordt gekeken wat er precies gedaan moet worden (zijn alle gegevens bekend, moet er ook een mailbox komen). Vervolgens wordt de nieuwe user aangemaakt (actie), en wordt teruggekoppeld dat de nieuwe gebruiker is aangemeld en aan het werk kan (rapportage). Beleid - Het beleid rondom diskquota wordt gewijzigd. Dit resulteert in een Request For Change (RFC), die vervolgens moet worden uitgevoerd. Wat er gedaan moet worden, en of zoiets zomaar kan, moet worden uitgezocht (analyse), en daarna uitgevoerd (actie). Daarnaast vindt rapportage plaats over de wijziging. Vervolgens moet gemonitored worden of een en ander goed is verlopen. Rapportage - Vanuit het Service Level Management proces komt de vraag naar de performance van de afgelopen maand. Deze vraag kan alleen maar beantwoord worden als er gemonitored is, en de resultaten daarvan zijn vastgelegd. Sommige acties kunnen van invloed zijn op de performance en daarom is het van belang te weten welke acties hebben plaatsgevonden. Al deze zaken doorlopen, al dan niet geautomatiseerd, het proces van monitoring, analyse, actie en rapportage, waarbij op diverse punten de stap van automatisch naar handmatig en vice versa kan worden gemaakt. De monitoring fase zal zoveel mogelijk geautomatiseerd verlopen. Gezien de omvang van de omgeving, meer dan honderd servers, 130 gelijktijdige gebruikers, 7 keer 24 uur ondersteuning voor bepaalde services en applicaties, is handmatig monitoren ondoenlijk. Afhankelijk van hoe een en ander wordt ingericht, zal analyse in meer of mindere mate geautomatiseerd verlopen. Dit geldt ook voor de actiefase. Sommige zaken kunnen automatisch worden geanalyseerd en afgehandeld, zoals blokkering van het opslaan van ongeoorloofde bestandsformaten en het verwijderen van virussen uit e- mail. Andere zaken dienen grondig te worden geanalyseerd en handmatig afgehandeld. Bijvoorbeeld uitzoeken waarom een bepaalde applicatie traag reageert, en bedenken en beslissen hoe een nieuwe applicatie beschikbaar gesteld zal worden. Uit bovenstaande blijkt dat het inrichten van Operations Management heel dynamisch is, wat niet hetzelfde is als chaotisch. Door het proces goed te structureren, en de discipline op te brengen om gestructureerd te werken, blijft het goed beheerbaar en beheersbaar en wordt pro-actief beheer mogelijk. Goede tooling helpt mee om die beheerbare, beheersbare en pro-actieve omgeving te creëren. Toolselectie en inrichting Bij de invoering van het procesmodel stond ondersteuning door tooling centraal en werd met de beheerders een toolselectie uitgevoerd. Cruciaal bij de implementatie van de monitoring tooling was de vraag: Wat is er nodig om te voorkomen dat jij als beheerder uit bed wordt gebeld? Dit had tot gevolg dat er meer naar proactief beheer werd gekeken en het zorgde voor een focus op de dienstverlening en de verbetering daarvan. Op basis van een aantal specificaties werden tools, zoals MOM voor monitoring en Spotlight voor diagnose geselecteerd en aangeschaft. MOM en Spotlight werden gekozen vanwege hun goede aansluiting met de MOF-processen en omdat zij de omgeving die voornamelijk uit Microsoft-componenten bestaat kwalitatief goed en proactief kunnen beheren. Deze tools werden nu door de beheerders geïmplementeerd. Ook deze implementaties vonden plaats in de vorm van workshops. Voor de Microsoft-specifieke zaken (MOM) is daarnaast ook de hulp ingeroepen van een Microsoft-consultant. Leerpunt hieruit was onder andere dat de voorgeschreven implementatiestrategie voor MOM niet goed bruikbaar was. Deze strategie werd aangepast tot een voor deze situatie meer succesvolle werkwijze. De implementatietijd van de gekozen tools was relatief kort, wat ten goede kwam aan het veranderingsproces en de flexibiliteit waar de beheerders, de klanten en het management om vroegen. De gekozen implementatievorm aan de hand van workshops verlengde wel de korte implementatietijd van de gekozen tools. Deze tijd werd echter dubbel en dwars terugverdiend door de hogere acceptatiegraad en een beter begrip van de tools. Het nut van beheerprocessen Gaandeweg realiseerden de beheerders zich dat een bepaalde mate van structuur en, ondanks hun wisselende ervaringen met ITIL, het herinrichten van hun werk met behulp van best practice beheerprocessen toch best zinvol zou zijn. Dit draaide later nog bij naar een (gematigd) enthousiasme voor het volledige procesmodel van MOF. Langzaam ontstond aandacht voor andere kwadranten en de wisselwerking daartussen. Deze vooruitgang maakte het ook mogelijk om de stap naar het Team Model te maken. Dit werd onder andere duidelijk bij het samenstellen van checklists, bijvoorbeeld die in onderstaande tabel. De combinatie van het procesmodel met de monitoring en diagnose-tooling versterkte dit nog meer. Daarnaast was het voor de beheerders mogelijk met MOF, MOM, Spotlight (en andere tooling) de communicatie een heel stuk duidelijker en tijdiger te verschaffen. De beheerders kwamen in control. Resumerend Net als in veel ITIL-trajecten werd MOF ingezet als verzameling best practices en werd van MOF alleen gebruikt wat echt nodig was, gelet op de problemen, de wensen op korte termijn en de veranderingen op langere termijn. Cruciaal in dit hele traject was het verbeteren van de dienstverlening, met, door, en voor de beheerders, de klanten en het management. MOF kon daar goed voor worden gebruikt omdat MOF en daarin opgenomen modellen voor iedere groep herkenbare aspecten en praktische waarde hadden. Door de gevolgde methode waren de beheerders steeds meer in staat om zelf de dienstverlening te verbeteren. Periodiek werd geëvalueerd wat binnen het proces goed ging en wat verbeterd kon worden. In eerste instantie werden deze evaluaties en de daar- System administation taken Frequentie Tijd benodigd 1. Beheer delegate control van AD en Exchange en CTX 2. Nieuw te beheren componenten accepteren en toevoegen op de diverse aspecten van beheer 3. Oude compenten verwijderen op de diverse aspecten van beheer 4. Procedure beheren: nieuwe componenten toevoegen en oude componenten verwijderen. Versiebeheer testomgeving 6. Versiebeheer acceptatieomgeving 7. Software library beheer bijhouden 8. Beheer delegate control van AD en Exchange en CTX 9. Opleveringen van releases accepteren 10. Oude server verwijderen op de diverse aspecten van beheer 11. Verantwoordelijk voor operations review 12. Contact met supporting en changing quadrant en andere ITIL processen 13. Rapportage operations review 14. Operations review vanuit andere processen via SMO naar service manager Tabel 2 Voorbeeld van een checklist 7
8 uit voortvloeiende verbeteracties door externe consultants geleid, maar gaandeweg werden deze initiatieven meer door de beheerders zelf opgepakt en verder uitgevoerd. De beheerders kregen ook de taak deze verbeteracties met de klant te overleggen en voor en na de uitvoering te communiceren. Het Team Model heeft bij het begin van dit traject niet de hoogste prioriteit gekregen. Maar door het inrichten van het procesmodel zijn diverse delen van het Team Model zeer nuttig gebleken. Van het Team Model zijn de Team Rollen operations, support, partner, security, en infrastructuur voor 80% geïmplementeerd. Ook het Risicomodel is niet als zodanig benoemd, maar bij de gekozen vorm van workshops is consequent een risico (of calamiteit) als voorbeeld genomen. Dit heeft gezorgd voor een beperkte introductie van dit model. Case 2: consumer products bedrijf Introductie De tweede case betreft de Europese verkooporganisatie van een multinational in consumer products. De organisatie bestond uit een Europees hoofdkantoor en nationale verkooporganisaties in vrijwel alle Europese landen. Tot voor kort opereerden de landenorganisaties vrijwel geheel zelfstandig, ook op ITgebied. Tot dan toe had iedere nationale organisatie gewerkt met eigen processen en procedures toegespitst op de eigen specifieke omgeving. Voor de kleinere vestigingen ontbraken duidelijk omschreven procedures en verantwoordelijkheden meestal geheel. In het kader van het verlagen van de kosten was men bezig om de IT-omgeving te stroomlijnen en het beheer te centraliseren in het hoofdkantoor. Er was besloten een geheel nieuwe IT service management organisatie op te zetten, die gebaseerd was op ITIL. In dit streven paste de invoering van een gecentraliseerde kantoorautomatiseringinfrastructuur gebaseerd op de Microsoft productlijn: Active Directory, SMS 2003, MOM en MIIS. De pan-europese invoering van Active Directory werd begin 2004 zo goed als afgerond. Daarna zou worden gestart met de invoering van SMS 2003. Dit pakket zou moeten worden gebruikt voor gecontroleerde OS installatie en software distributie, ter ondersteuning van asset management en ter ondersteuning van de IT service desk (remote control). Probleemstelling Evenals bij eerdere infrastructuurprojecten lag de nadruk bij het SMS 2003 project in eerste instantie op de techniek. Vrij snel na de start werd onderkend dat ook de processen en de beheerorganisatie belangrijke aspecten waren die moesten worden meegenomen. De reden dat de beheerorganisatie voor SMS extra aandacht kreeg was grotendeels te danken aan de opgedane ervaringen met het kort daarvoor geïmplementeerde pan- Europese Active Directory. In dat traject was het opzetten van een beheerorganisatie niet meegenomen, dat wil zeggen: het bevond zich wel in het ontwerp maar werd niet concreet uitgewerkt en geïmplementeerd. Redenen hiervoor waren de abstracte ontwerpen voor de beheerorganisatie en een tekort aan draagvlak voor gecentraliseerd beheer. Omdat de beheerorganisatie voor Active Directory niet goed van de grond kwam, werden de beheerverantwoordelijkheden niet belegd en ervaren. De overdracht van beheer van het projectteam naar de beheerafdeling vond derhalve niet goed plaats. Hierdoor werd het projectteam genoodzaakt om langer te blijven opereren. Men was vastbesloten om eenzelfde situatie bij de invoering van SMS te voorkomen. De invoering van SMS 2003 met de bijbehorende geïntegreerde aanpak van techniek, processen en organisatie was in dit kader een belangrijke testcase. Vooral release management van nieuwe software en patches werd gezien als een belangrijk proces, omdat tot op dat moment binnen de organisatie nog geen formeel en centraal release management proces bestond voor dit type omgevingen, feitelijk de kantoorautomatisering-applicatielaag. Het voor dit doel inrichten van release management leek op het eerste gezicht schieten met een kanon op een mug. Maar het beheer van 10.000 werkplekken vergde nu eenmaal een andere aanpak dan het beheer van 100 werkplekken. Eerdere ervaringen Binnen een andere project-stream was al gestart met het opzetten van een geheel nieuwe IT service management organisatie. Daarbij werd begonnen met het inrichten van incident management. Hierbij bleek dat de invoering van de processen werd gefrustreerd. De lokale werkwijzen bleken bijvoorbeeld niet te vertalen naar bruikbare processen en procedures in pan-europees verband. Ook boden de nationale organisaties de nodige weerstand, wat onder andere veroorzaakt werd door culturele verschillen en het gebrek aan vermogen om over de landsgrenzen heen te kijken. Uiteindelijk werd een model gekozen waarbij vier op taal gebaseerde regio s werden gedefinieerd: Latin, Nordic, Germanic en UK, met ieder hun eigen virtuele service-organisatie, waarbij de teamleden zich over het algemeen in hun land van herkomst bevonden. Eenduidige procesinrichting was echter nog steeds een wens. Keuze voor MOF Op basis van de hiervoor beschreven ervaringen werd besloten dat het beheer en de bijbehorende processen van de SMS-omgeving een belangrijk onderdeel van de implementatie zou worden. Daarna werd gezocht naar een passende methodiek. In eerste instantie wilde men aansluiten bij het lopende project voor het opzetten van een nieuwe IT service management organisatie. Dit bleek niet de gewenste aansluiting op te leveren. Een tweede insteek moest het beheervraagstuk breder neerzetten, omdat snel bleek dat op meer onderdelen binnen de organisatie beheer niet voldoende ingericht bleek. Deze insteek werd snel te omvangrijk, waarna de scope van het beheerproject werd beperkt tot die aspecten die direct aan SMS 2003 gerelateerd waren. Hierbij kregen vooral release management en het inrichten van operationeel beheer van de SMS infrastructuur prioriteit. Randvoorwaarde was dat het ontwerp voor het beheermodel zoveel mogelijk zou aansluiten bij de bestaande beheerorganisatie. Voor het uitwerken van de beheerprocessen, taken en rollen kwam men al snel uit bij MOF. Belangrijk argument hierbij was dat de MOFmethodiek reeds de juiste handvatten bevat om deze zaken snel en concreet in te vullen. Vooral het Team Model en de change management SMF s bleken goed toepasbaar te zijn. Ook was het vrij gemakkelijk om met behulp van het Team Model gedefinieerde rollen te beleggen bij de diverse beheerteams. Dit laatste was een belangrijk pluspunt gezien de in de nabije toekomst geplande reorganisaties. Aanpak Omdat het MOF gedachtegoed relatief onbekend was binnen de organisatie werd een workshop georganiseerd om een en ander te verduidelijken. Dit betrof vooral het MOF Team Model en een aantal MOF-begrippen zoals de Definitive Software Library (DSL). Vervolgens werd in een serie workshops het organisatorische deel uitgewerkt. OTAP en beheer van gedistribueerde systemen als SMS2003 Waar de beheerorganisatie voor SMS 2003 in het begin als één geheel werd beschouwd, kwam men al snel tot de conclusie dat er onderscheid moest worden gemaakt tussen degenen die de software packages bouwen en degenen die de software distribueren naar de eindgebruikers en zorgen voor het beheren van SMS. Immers, het zou onwenselijk zijn dat een ontwikkelaar zelfstandig packages in de DSL kan plaatsen, zonder dat er operationele tests hebben plaatsgevonden en de beheerder de packages geaccepteerd heeft. Dit moest in samenwerking gebeuren met degenen die verantwoordelijk zijn voor het beheer van de SMS-omgeving. Het scheiden van omgevingen in de klassieke 9
10 indeling ontwikkelomgeving, testomgeving, acceptatieomgeving en productieomgeving mag dan in de mainframe- en midrange-werelden gemeengoed zijn, in de wereld van gedistribueerde systemen bleek op dit gebied vaak nog veel te leren. Bij het inrichten van de organisatie werd dus in het bijzonder aandacht geschonken aan de functiescheiding tussen de makers van de software packages en de verantwoordelijken Packaging Team NO Start New Patch Released Is the Patch Relevant Test Patch on Standard Workstation Was test Successful YES YES Inform PE Pilot Group and Help Desks Deploy Patch to PE Pilot Group NO voor de distributie. Dit resulteerde in twee organisatieonderdelen, één voor het maken en onderhouden van software packages en één voor het distribueren van software naar eindgebruikers en het beheer van de SMSomgeving. Ieder organisatieonderdeel op zich bestond weer uit een aantal functionele teams. Het organisatiemodel is weergegeven in de onderstaande figuur. Analyse Problem Change Management Release Management Systeem Operations Incident Management In deze afbeelding valt de duidelijke scheiding op tussen een ontwikkelgroep voor de software packages en een beheerunit, die zorgt voor distributie en support. Daarbij is de afgebeelde Service Desk virtueel ingetekend, daar van de reeds bestaande regionale service desks gebruik wordt gemaakt. De strikte functionele scheiding tussen het maken en onderhouden van packages en het beheer van de SMS-omgeving stuitte wel op praktische bezwaren. De benodigde kennis voor beide functies bleek vaak verenigd in één en dezelfde persoon. Uiteindelijk zou dit waarschijnlijk geen rol spelen, omdat het maken van packages werd uitbesteed aan een externe partij. Met behulp van het MOF Team Model werden vervolgens rollen gedefinieerd, met de bijbehorende taken en verantwoordelijkheden specifiek voor SMS en het packagen. Deze werden daarna toegewezen aan de beheerteams. Als laatste werd een aantal kernprocedures met betrekking tot release management van software packages gedefinieerd. Hierin kwam duidelijk naar voren waar interactie tussen de verschillende teams noodzakelijk was en waar dus gecommuniceerd moest worden. Dit sloot aan bij een van de kernpunten van het MOF Team Dagelijks beheer Model, het centraal stellen van goede communicatie tussen de beheerafdelingen en - processen. Als voorbeeld is het patch management proces weergegeven: Resumerend Een belangrijk effect van al deze aandacht voor het aspect organisatie van beheer tijdens de ontwerpfase was dat tijdens de uitrol van een tool niet alleen werd gekeken naar technische implementatie. Er werd nadrukkelijk overlegd met de lokale beheerorganisatie, over hun toekomstige taken en verantwoordelijkheden. Ook werden de procedures aangepast en kwamen er nog steeds nieuwe procedures bij. Het initiatief werd hier genomen door de leden van het projectteam, die later ook het beheer op zich zouden nemen. Dit is een bewijs dat het MOF gedachtegoed goed aansloot bij de dagelijkse praktijk van de beheerders. Bij deze groep is duidelijk geworden dat een goed operationeel beheer niet alleen bestaat uit de juiste tools, maar ook uit communicatie, duidelijke procedures en processen. Met het MOF model kon de vertaalslag eenvoudig worden gemaakt. 11 Was Patch Deployment successfull NO Analyse Problem Monitoring SMS Enterprice Administrators and Level 2 Support RFC Passed by CAB YES Incident Handmatig Analyse Handmatig Automatisch Automatisch Inform Users and Help Desks Actie Handmatig Automatisch Deploy Patch Rapportage Beleid END Handmatig Automatisch Processondersteuning Operationeel Management Figuur 4 Organisatiemodel Figuur Patch management proces