Leuk om te zien dat juist mijn quote over te rooskleurige verkoopverhalen is gekozen om op te nemen in het artikel. Dit is namelijk iets dat mij zéér na aan het hart ligt. Te vaak zie ik dat oplossingen worden gepresenteerd die te “vol” zijn: teveel producten in te weinig tijd. Waar echt meer bij moet worden stilgestaan dat het professionaliseren van beheer een groeipad is en dat er dus tijd nodig is om dit groeipad te doorlopen. De scope vergroten of het tempo verhogen kan véél makkelijker dan andersom. Niet voor niets blijken jaar in jaar uit vele projecten te sneuvelen, naar mijn mening veelal vanwege deze te grote ambities en te weinig rekening houden met de organisatie die het allemaal maar moet verstouwen, náást het draaiend houden van de spullenboel hetgeen vaak al een hele klus op zich is. Een tool kan héél veel verlichting brengen in de beheerlast, maar moet wel fatsoenlijk geïmplementeerd worden en met de juiste verwachtingen worden aangeschaft. Het is géén puur technische exercitie !

“Van de miljarden euro’s die bedrijven de afgelopen jaren investeerden in software voor ict-beheer, is een groot deel weggegooid geld. De toepassingen zijn vaak slecht geimplementeerd en sluiten slecht aan op de bedrijfsorganisatie.
Organisaties kunnen hun wensen voor beheersoftware niet door een enkele leverancier laten vervullen, zelfs niet een van de grootste (volgens Forrester BMC, CA, IBM en HP). Ze adviseren daarom niet alleen te kiezen voor de producten van een van grote, maar om die te combineren met een ict-beheerproduct van een kleinere leverancier.”

Het hele artikel is hier te lezen.

Naar aanleiding van dit artikel vroeg de redactie mij om een reactie te geven door het beantwoorden van vier vragen.

Hieronder de 4 vragen en mijn antwoorden daarop.

1: Deel je de mening dat beheersoftware vaak weggegooid geld is?

Ik ben van mening dat vele implementatieprojecten niet opleveren wat ze zouden moeten opleveren omdat klanten onjuiste verwachtingen koesteren, veelal in de hand gewerkt door te rooskleurige verkoopverhalen. Hierdoor worden te ambitieuze projecten opgestart die niet passen bij het huidige volwassenheidsniveau van de klant. Het is niet correct om dan maar de software de schuld te geven, de fout ligt m.i. vrijwel altijd uitsluitend bij de implementatie: men wil vaak teveel in te weinig tijd. Een goede implementatie van een breed scala aan beheersoftware is een groeipad, niet iets wat je “even” doet.

2: Klopt het dat itms-leveranciers geen allesomvattende beheeroplossing bieden en dat je dus meerdere pakketten nodig hebt?

Nee, er zijn wel degelijk leveranciers die één allesomvattende oplossing bieden, maar hiermee gaan grote investeringen gemoeid aan software licenties én personeelskosten voor de implementatie, zowel intern als extern. Wel kan het zijn dat een combinatie van puntoplossingen van diverse leveranciers een beter passende oplossing is dan alles van één leverancier betrekken. Welke oplossing het beste past voor een gegeven situatie moet van geval tot geval apart worden beoordeeld.

3: Wat is je ervaring met itms van grote leveranciers als CA en HP en met de software van kleinere aanbieders? Wat zijn de voor- en nadelen van zulke beheerpakketten?

De voordelen van ITMS pakketten van grotere leveranciers zijn met name de aandacht voor integratie met andere software en de mogelijkheid om makkelijker tot een totaaloplossing te komen. Kleinere leveranciers begeven zich -haast per definitie- in een klein stukje van het spectrum en kunnen zodoende soms op dat éne gebied een betere oplossing bieden dan een grotere leverancier. Wel kan hierdoor integratie met andere tooling lastiger zijn en kan een totaaloplossing bestaande uit pakketten van diverse leveranciers minder krachtig zijn dan een totaaloplossing van één enkele leverancier.

4: Waar moeten organisaties op letten als ze nieuwe beheersoftware overwegen? Kies je bijv een IBM-tool voor een IBM-omgeving en een Cisco-tool voor een Cisco-omgeving? Wat doe je bij hybride omgevingen? Wat doe je bij een beperkt budget?

ITMS tooling dient aangeschaft te worden ter ondersteuning van bepaalde bedrijfsdoelstellingen. Werk dus altijd vanuit die doelstellingen: bepaal wat voor jouw organisatie in deze fase het belangrijkste is en kijk daarnaast waar je over een paar jaar naartoe wil. Ga vervolgens aan de hand van dit groeipad een invulling zoeken. Laat je niet verleiden tot het willen bereiken van perfectie: focus op dat wat de meeste resultaten oplevert met de minste kosten/inspanning. Kies daarbij voor software die zo open mogelijk is qua integratiemogelijkheden en ondersteuning biedt aan open frameworks zoals ITIL(v3). Meer generieke software biedt als voordeel dat je niet bij iedere wisseling in je te beheren omgeving moet zoeken naar een andere tool maar kan wel als nadeel hebben dat in sommige gevallen de “diepte” niet zo groot is als gewenst. En tenslotte: bedenk dat de implementatie van beheertooling voor 20% een technische aangelegenheid is maar voor de overige 80% een organisatorische verandering is en zet de implementatieprojecten dus ook zodanig op.

Maar volgens mij kan het geen kwaad om af en toe ook weer eens op een open deur gewezen te worden

Recentelijk werd ik gevraagd om bij een organisatie een analyse te doen van de status van hun IT monitoring en een voorstel te doen om de situatie te verbeteren. Deze organisatie had in de afgelopen tijd de nodige problemen gehad met een belangrijke business applicatie en IT ligt onder vuur vanuit de business – de perceptie is dat IT de zaken qua monitoring niet onder controle heeft.

Na een paar dagen rondlopen, kijken, vragen en luisteren kreeg ik een aardig beeld van de situatie en ontstonden in mijn hoofd de contouren van een project dat uitgevoerd zou kunnen worden om de meest prangende zaken aan te pakken.

Hierop toog ik aan het werk om een conceptvoorstel te maken ter bespreking met de projectmanager. Het door mij voorgestelde project was in mijn beleving nog redelijk klein, maar omvatte toch al gauw een flink aantal manmaanden werk voor met name de eigen mensen van de organisatie.

Al gauw bleek dat deze aanpak niet zou gaan vliegen – IT Management had al een aantal projecten op dit gebied proberen op te starten maar dat was telkens geen succes. Bovendien werd duidelijk dat er absoluut geen budget vrijgemaakt zou worden voor een groot project – ook deze organisatie houdt in deze economisch slechte tijd de hand stevig op de knip.

Wat nu gedaan ? Aan de ene kant wilde mijn klant écht dingen veranderd hebben maar aan de andere kant wilde men géén groot project opstarten. De projectmanager gaf aan dat één van de redenen dat er geen budget voor een groot project zou vrijkomen was dat men niet pas na een lange periode resultaat wilde zien. Wel kon de projectmanager een aantal dagen werk geregeld krijgen bij de interne mensen en ook had hij wel wat geld om mij een beperkt aantal dagen in te huren. De truc was dus om het grote project dat eigenlijk gedaan zou moeten op te delen in kleine stukken waarbij van elk stuk de toegevoegde waarde meteen duidelijk zou worden. En dan te beginnen bij een stuk dat aan de ene kant door de klant als erg urgent werd ervaren en aan de andere kant relatief makkelijk uitgevoerd zou kunnen worden. Verder werd mij gevraagd om de scope te beperken tot de inrichting van de monitoring voor de eerder genoemde belangrijke business applicatie.

Daarom heb ik een matrix gemaakt van de functionele blokken van deze business applicatie op de ene as, en diverse IT-lagen (hardware, netwerk, storage, os, enzovoorts) op de andere as. Zo ontstaat een matrix van blokken die allemaal één of meerdere infrastructuur componenten omvatten. Het plan is nu om deze matrix blok voor blok aan te pakken, in een door de klant te bepalen volgorde. Elk blok op zichzelf is redelijk beperkt in omvang waardoor al na hele korte tijd een blok “afgevinkt” kan worden. Hiermee heeft IT Management dan ook meteen een hele bruikbare visualisatie om duidelijk te maken waar zij staan mbt. het op orde brengen van de monitoring voor deze business applicatie. Ik heb de klant gevraagd om vooraf de matrix intern te bespreken om te bepalen of de door mij opgezette indeling voor hun bruikbaar is. Voor het werk dat gedaan moet worden maakt de exacte indeling van de matrix niet echt uit, maar hoe beter de matrix aansluit bij de beleving van de mensen bij de klant, hoe makkelijker deze gebruikt zal worden. Ook laat ik de klant het eerste aan te pakken blok kiezen zodat zij zelf “in control” komen.

Deze aanpak lijkt goed te vallen: volgende week begin ik met het eerste blokje van de matrix. Hoe eea. daadwerkelijk verder gaat schrijf ik over een tijdje nog wel eens op.

Natuurlijk is het bovenstaande niet nieuw noch een garantie voor resultaat. Maar volgens mij kan het geen kwaad om af en toe ook weer eens op een open deur gewezen te worden .

Gisteren heb ik een zeer gezellige, maar vooral ook nuttige, bijeenkomst van de werkgroep ASL Best Practices bijgewoond. Deze werkgroep valt onder de ASL/BiSL foundation, een non-profit organisatie die zich ten doel stelt het ASL/BiSL raamwerk verder te (doen) ontwikkelen en gebruik hiervan te stimuleren.

Voorafgaand aan het workshop gedeelte gaf Remko van der Pols een vlammend betoog over wat Best Practices nou eigenlijk zijn en hoe ze te gebruiken. En ook: wat ze niet zijn en hoe ze niet gebruikt dienen te worden. Buiten Remko’s boeiende stijl van presenteren vond ik dit verhaal zeer interessant, en dat was eigenlijk tegen mijn verwachting in.

Want zeg nou zelf, als u de vraag krijgt “Wat zijn Best Practices ?” dan denkt u waarschijnlijk, net als ik, aan een kort en krachtig antwoord, gevormd in één of andere definitie. Echter, vaak wordt er als er over Best Practices (BP’s) wordt gesproken, voorbij gegaan aan twee hele belangrijke aspecten van BP’s.

Hoewel het eigenlijk open deuren zijn, vind ik deze punten dermate belangrijk dat ik ze hier nog eens even wil aanhalen.

1. Best Practices zijn verzamelingen van cases die in bepaalde praktijksituaties hun nut hebben bewezen.

Dit behelst nogal wat:

• Er kunnen meerdere BP’s zijn voor soortgelijke situaties
• Bij een BP hoort ook een duidelijke beschrijving (typering en categorisatie) van de situatie
• BP’s hebben in een bepaalde situatie voor een bepaalde gebruiker nut gehad (cq. hebben dat nog steeds)

Ofwel: Bij het beoordelen of een BP voor een bepaalde situatie eventueel nuttig kan zijn, is het belangrijk om zoveel mogelijk informatie te hebben over de situatie waarvoor de BP is toegepast.

Persoonlijk zou ik een BP die zonder verdere toelichting wordt aangeboden met enige argwaan bekijken.  Wat voor de ene situatie werkt, hoeft niet zomaar voor de andere situatie te werken ! En zoals zo vaak: Er leiden meerdere wegen naar Rome. Kies dus uw eigen weg !

Impressie ASL Best Practices bijeenkomst 16 juni 2009 (foto: Reyer de Boer)

2.  Best Practices zijn bedoeld om aan te passen !

Vaak worden BP’s of sjablonen van raamwerken of methodieken recht uit het tekstboek overgenomen en zonder verdere aanpassingen geïmplementeerd. Berucht zijn in mijn ogen bijvoorbeeld de PINO’s (Prince In Name Only) die het resultaat zijn van het rigide gebruiken van PID (Project Initiatie Document) sjablonen. Dat is niet wat Prince beoogt ! Zo ook met de ASL Best Practices waar ik gisteravond mee heb mogen stoeien. Remko gebruikte een -in mijn ogen- briljant en pijnlijk eenvoudig voorbeeld van twee verschillende supermarktketens om dit punt te verduidelijken. Dit voorbeeld ging over het interacteren met klanten. Op zeer illustratieve wijze schilderde Remko het verschil in afhandeling van een vraag zoals “weet u waar de suiker staat” tussen (bijv.) de Lidl en de AH. Hetzelfde proces, maar op twee totaal verschillende manieren geïmplementeerd. Het punt hier is dat het botweg overnemen van een Best Practice zonder deze aan te passen op de eigen situatie meestal niet tot de gewenste resultaten leidt.

In deze tekst kan ik u overigens de “real life experience” van Remko’s betoog niet doen beleven, komt u daarvoor de volgende keer vooral zelf naar zo’n bijeenkomst !

Allereerst even dit: met ‘beheertooling’ beperk ik me specifiek voor dit artikel tot het monitoren van de beheerde ict-omgeving. Software dus die beheerders attendeert op afwijkingen zodat ze desgewenst actie kunnen nemen.

Ik denk dat implementaties van beheertooling vaak mank gaan op twee hoofdaspecten:

• De architectuur van de beheeromgeving.
• Het managen van de bijkomende veranderingen (verandermanagement).

Er is een veel fijnmazigere verdeling te maken, maar deze twee aspecten dekken naar mijn mening de lading.

Architectuur
Er bestaat in organisaties nogal eens weerzin tegen ict-architectuur, dit terwijl deze er juist voor zorgt dat de ict doet wat de business verlangt. Alles wat nodig is en niet meer dan dat. Dat zou dus ook kunnen gelden voor de architectuur die een beheer (monitoring) oplossing beschrijft. In de praktijk gaat dit echter veelal niet op. Naar mijn mening komt dat doordat wordt onderschat wat het oplevert om vooraf goed na te denken hoe de oplossing zou moeten functioneren. Of anders gezegd: men onderschat hoe groot de kans is dat de boel in het honderd loopt door niet vooraf goed na te denken. Afstemming met belanghebbenden (stakeholders) helpt overigens niet alleen dit primaire doel maar het vergroot ook nog eens de betrokkenheid van de mensen, maar daarover later meer.

Als er dan eindelijk een beheerarchitectuur is, moeten er functionele en technische ontwerpen gemaakt worden. Ook hier gaat nogal eens wat mis en één van de meest voorkomende discussies die ik hier zie is die van de uiteindelijke monitoringconfiguratie. De set van parameters dus, die bepaalt wat er in de ict-voorziening gemonitord wordt. Hiervoor bestaan twee uitersten: volledig gebruikmakend van ‘out-of-the-box’- (OOTB-)intelligentie van de tool of volledig naar wens geconfigureerd. Ik heb door de jaren heen via beide manieren en alles daartussen implementaties begeleid, en heb ervaren dat beide manieren zowel voor- als nadelen hebben. Helaas leidt niet één van deze keuzes steevast tot een goed resultaat.

Toch heeft een OOTB-implementatie duidelijk voordelen boven een volledig zelf ontwikkelde monitoringconfiguratie. Dat zijn vooral de onafhankelijkheid van kennis in de medewerkers zelf en de grotere beheerbaarheid. Wie kent niet de situatie dat ergens prachtige scriptconstructies zijn gemaakt die in beginsel fantastisch werken, maar een jaar later moeilijk up-to-date blijken te houden, niet in het minst omdat niemand meer precies weet hoe het nou allemaal ook alweer werkte. Ook kan bij gebruik van OOTB-functionaliteit makkelijker teruggevallen worden op de supportorganisatie van de leverancier en kan men bij het inregelen van de software zich concentreren op de functionaliteit in plaats van de manier waarop de functionaliteit bereikt wordt. Een belangrijk nadeel van OOTB-configuraties kan echter zijn dat de oplossing minder makkelijk geaccepteerd wordt door de gebruikers, aangezien het ‘not invented here’ is.

Genoeg zaken dus om terdege rekening mee te houden, nog vóór de implementatie van start gaat. Naast al deze technische aspecten is er ook nog een héél belangrijk aspect dat maar al te vaak verwaarloosd wordt: verandermanagement. Aandacht voor de mensen die (vaak: wéér) een verandering door moeten maken, veelal bovenop hun toch al hectische dagelijkse werkzaamheden.

Verandermanagement
Torenhoge ambities, onrealistisch korte implementatietijden en alleen maar aandacht voor de techniek is kenmerkend voor implementaties van beheertooling. Wie dat niet herkent is een gelukkig mens, zou ik haast zeggen. Vaak heeft de opdrachtgever, veelal gevoed door commerciële contacten, grote verwachtingen en ambities met betrekking tot de beheertooling. De indruk bestaat dat de tooling de panacee is. Wel, ik heb nieuws: die beheertooling is dat niet! Hoewel in een ideale wereld implementaties vanuit een technisch oogpunt makkelijk en vlot zouden moeten kunnen lopen, is de realiteit weerbarstiger. Houd daar dus rekening mee met het inschatten van de implementatietijden en te bereiken mijlpalen. Deel een implementatietraject op in realistische delen en neem tussendoor de tijd om terug te kijken en te leren van de afgelopen periode.

Hoewel het heel goed kan werken om een ‘smalle’ implementatie over de hele diepte van een ict-keten te doen, waardoor er dus een showcase ontstaat om de mogelijkheden van de nieuwe software te laten zien, werkt een solide implementatie bottom-up in veel gevallen beter. Dit hangt echter van een groot aantal factoren af, waaronder de eventueel al aanwezige tooling, het volwassenheidsniveau van de beheerorganisatie, de mogelijkheden van de nieuw te implementeren tooling, de mate waarin de ict-voorziening momenteel voor problemen zorgt en het politieke klimaat in de organisatie.

Maar bovenal: vergeet de mensen niet. Beheerkosten omlaag brengen en tegelijkertijd de kwaliteit verhogen via een implementatie van (betere) monitoring-tooling werkt alleen als de mensen die de tooling zouden moeten gebruiken dat ook echt optimaal doen. Een andere manier van werken, vaak over beheerdomeinen heen is daarbij geen uitzondering. Hier passen modellen zoals ASL/BiSL en ITIL, maar daar wil ik het hier niet eens over hebben. Waar mijn gedachten naar uitgaan is dat de mensen op de ict-afdeling vaak vele veranderingen doorgeduwd krijgen die slecht zijn verlopen. En er dus vaak een voorgeschiedenis is die mensen voorzichtiger maakt om wéér aan een nieuw project deel te nemen. Dat het anders leren werken niet het volgen van een cursus ‘hoe configureer ik de nieuwe tool’ is. Dit soort trajecten vergen aandacht en begeleiding, veel meer dan dat ik doorgaans zie. Wat goed verandermanagement is, is niet wat ik hier wil vertellen. Het punt dat ik wil maken is dat goed verandermanagement essentieel is. Juist bij dit soort ‘technische’ trajecten, omdat hierbij van nature de aandacht naar de techniek uitgaat en niet naar de mensen voor wie de techniek bedoeld is.

Tot dusver in het kort mijn gedachten en ervaringen omtrent het al dan niet slagen van beheertooling-implementaties. Ik ben benieuwd wat jullie hiervan denken. Laat me jullie gedachten en ervaringen weten!

Dit bericht is ook gepubliceerd op de website van Computable:
http://www.computable.nl/artikel/ict_topics/beheer/2876875/1277800/waarom-beheertoolingimplementaties-vaak-mislukken.html

Trends

Beter benutten bestaande capaciteit
Momenteel zie ik, zeker bij outsourcing trajecten, een toename van de aandacht voor de benuttingsgraad van hardware. Dit zal naar mijn mening nog meer versterkt worden door het slechte economische tij in de komende jaren.

Meer en beter automatiseren IT Beheer
Nog te vaak zie ik bedrijven waar IT Beheer ondergeautomatiseerd is. Een voorbeeld hiervan is configuratiemanagement. Dit is vaak nog handmatig proces dat veel tijd kost, foutgevoelig is en steevast achter de feiten aanloopt.

Meer aandacht voor ketenbewaking
Het maakt een eindgebruiker niet uit wat de status van individuele IT componenten is. De eindgebruiker neemt een IT dienst af die bestaat uit een keten van IT componenten. Steeds meer bedrijven zijn zich hiervan bewust en richten zich op implementatie van beheertooling die hieraan invulling kan geven.

Oplossingen

Virtualisatiesoftware
Er is tegenwoordig hele goede virtualisatiesoftware op de markt die ook steeds interessanter wordt voor kleinere bedrijven. Virtualisatie van systemen is een uitstekende manier om de bezettingsgraad van hardware te verbeteren, maar biedt ook voordelen op andere gebieden. Zo is met gevirtualiseerde systemen hardware onderhoud steeds makkelijker te doen zonder downtime en hoeft dit dus steeds minder op “lastige” (en dus dure) tijdstippen te gebeuren. Maar ook uit oogpunt van redundantie en disaster recovery biedt virtualisatie vele mogelijkheden.

Configuratiemanagement software
In de markt is tegenwoordig software te krijgen die het configuratiemanagement proces verregaand kan automatiseren. Bij deze software worden ook de relaties tussen systemen geautomatiseerd in kaart gebracht en up-to-date gehouden. Met name dit laatste is vaak nog een onderbelicht maar wel zeer belangrijk aspect.

Implementaties van geautomatiseerde ketenbewaking
Software die heterogene ketens van IT componenten kan bewaken is niet nieuw. Wel zijn er steeds meer bedrijven die hier invulling aan geven en daarmee beter gehoor geven aan de wensen van eindgebruikers.

Het TMN model

Dit model toont ondermeer dat een functionaliteit of ICT diensten is opgebouwd uit componenten zoals databases, processen etcetera, die op hun beurt weer zijn opgebouwd uit componenten zoals CPU’s, disks, enzovoorts.

De bedrijfslaag definieert hoe effectief een functionaliteit is in termen van winstgevendheid. In de hier gevolgde aanpak is deze laag niet geïmplementeerd. Wel is al de wens geuit om hier in de toekomst ook invulling aan te geven, maar daarvoor dienen eerst de daaronder gelegen lagen goed geïmplementeerd te zijn.

Omdat onze opdracht zich in eerste instantie beperkt tot het IT-gedeelte van het netwerk van deze operator is ook de onderste laag (NEL) weggelaten. De NEL laag is vooral van belang voor het managen van het transmissie netwerk, dus het netwerk waar het telefoonverkeer daadwerkelijk overheen gaat. Wij beperken ons hier tot de diensten die geleverd worden vanuit het IT netwerk: SMS, ringtones, etcetera. Hiervoor zijn op het IT netwerk vele systemen nodig die allen interactie hebben met diverse andere systemen.

Gebaseerd op het TMN model kan aldus een service gemodelleerd worden door het in kaart brengen van alle componenten die nodig zijn voor die specifieke dienst, evenals hun afhankelijkheden. Een dergelijk model wordt een Service Model genoemd. Het is dit model dat ten grondslag ligt aan de inrichting van het monitoring systeem, maar daarover dadelijk meer.

Een ander model dat gebruikt is bij het inrichten van de monitoring is het SAC model: Service Assurance Centre model. Dit model is ontwikkeld door BMC software en beschrijft hoe er met de informatie die uit de monitoring systemen komt omgegaan moet worden teneinde een volledige set informatie op de juiste plaats te krijgen.

Het SAC model

Cpu 1, disk 1, disk 2, geheugen van server 1
Database 1
……

Het probleem is dat deze 100% realistische modellen enorm complex zijn en even zo moeilijk te implementeren. Daarbovenop komt dat deze realistische modellen meteen een break-down structuur hebben die is uitgedrukt in het allerlaagste technische niveau, en daarom moeilijk te begrijpen zijn zonder technische kennis. En één van de zaken die onze aanpak beoogt te bewerkstelligen, is dat juist mensen met een niet-technische achtergrond in staat zijn om bruikbare informatie uit het systeem te verkrijgen.

Daarom tonen in de door ons gevolgde aanpak de service modellen niet exact de relaties tussen de componenten. In plaats daarvan worden componenten die een dienst opmaken logischerwijs gegroepeerd in component groepen. Deze groepen zijn direct afgeleid van het TMN model:

- functionaliteit (afgeleid van de Service Management laag)
- applicaties (afgeleid van de Network Management laag)
- elementen (afgeleid van de Element Management laag)

Hierdoor worden de aldus gemaakte service modellen:

- eenvoudig te maken
- uniform voor alle services
- makkelijk te begrijpen
- pas geleidelijk steeds meer technische details

Dit levert belangrijke voordelen voor de praktijk. Doordat de modellen eenvoudig te maken zijn is de tijd die nodig is om een dienst onder monitoring te brengen drastisch korter dan bij gebruik van waarheidsgetrouwe modellen (enkele weken tegenover misschien wel enkele maanden bij zeer complexe diensten). Bij de hier besproken klant zijn een kleine twintig diensten geïdentificeerd dus het is duidelijk dat deze tijdsverkorting een enorme tijdswinst voor het gehele project teweeg brengt.

Omdat de service modellen uniform zijn, is de presentatie vanuit het monitoring systeem daarvan dat ook. Als een service manager van service X eenmaal bekend is met de presentatie van zijn (of haar) service is het voor hem zeer eenvoudig om ook voor een willekeurige andere service de informatie te vinden en te begrijpen. Met andere woorden: alle service managers gebruiken ineens hetzelfde model en dus dezelfde presentatie voor de voor hen van belang zijnde service. Ze hebben nu dus een gezamenlijke, zelfde, basis wat de communicatie onderling sterk vereenvoudigt.

En omdat de service modellen pas geleidelijk steeds meer technische details bieden, verdrinken mensen niet in technische details. Die worden simpelweg niet weergegeven op het allerhoogste niveau. Dit is overigens geen specifiek kenmerk van de door ons gekozen manier om service modellen te maken, het is inherent aan het concept van service modellen in het algemeen.

Genoeg over de theorie nu, laten we in de volgende paragraaf bekijken hoe een en ander er in de praktijk uit komt te zien.

Implementatie

Bij de bespreking van de modellen is uitgelegd dat er voor gekozen is om elk service model als eerste stap onder te verdelen in 3 hoofdgroepen: functionaliteit, applicaties en elementen. Onder deze groepen zijn subgroepen gedefinieerd, die voor elke service hetzelfde zijn. Ook hier dus weer de consequente doorvoering van hetzelfde uniforme service model. Uiteraard zijn de uiteindelijke basiscomponenten voor iedere service anders, maar niet de presentatie daarvan.

Momenteel worden bij de klant in kwestie de volgende subgroepen ondersteund (onderstreept):

Functionaliteit
Functionele ketens
Applicaties
Databases
Processen
Elementen
Hardware en Operating System componenten
Netwerk Interface componenten

Deze subgroepen zijn dus voor elke service aanwezig, op dezelfde plek.

De monitoring systemen waarmee dit alles ingericht is zijn alle uit de HP OpenView suite. We gebruiken de volgende applicaties om de juiste informatie uit de infrastructuur te krijgen:

- Network Node Manager
- Internet Services
- Reporter
- Operations (inclusief Service Navigator)

Network Node Manager wordt gebruikt om de IP lay-out van het netwerk weer te kunnen geven, evenals via SNMP details over systemen te kunnen raadplegen. Internet Services wordt gebruikt voor het monitoren van de ketenfunctionaliteit. Door middel van probes die gebruik maken van diverse protocollen is vast te stellen of een keten nog functioneert. Reporter wordt gebruikt om rapporten voor de diverse belanghebbenden te genereren. En Operations tenslotte is het centrale punt waar alle informatie bijeenkomt. Bovendien is Operations in staat om op een intelligente manier, al dan niet met gebruik van Agents, allerlei informatie over het functioneren van systemen en applicaties boven water te krijgen. Geïntegreerd in Operations is Service Navigator, een applicatieonderdeel waarmee de conditie van de services grafisch weergegeven kan worden. In de afbeelding hieronder zijn de eerste twee lagen van het service model voor de service Bulk SMS weergegeven.

Een Service View