STRUCTURERENVANEEN IT-BEHEERORGANISATIE MET ITIL, ONTWIKKELEN VAN EEN SERVICE LEVEL RAPPORTAGE SYSTEEM MET BEHULP VAN SOM

TeS-ED 6ss

Technische Universiteit

tv

Eindhoven

Faculty of Electrical Engineering Section of Digital Information Systems (ICSIEB)

Master's Thesis:

STRUCTURERENVANEEN IT-BEHEERORGANISATIE MET ITIL, ONTWIKKELEN VAN EEN SERVICE LEVEL RAPPORTAGE SYSTEEM MET BEHULP VAN SOM By M.l Prins.

Author: Supervisor: Professor:

M.J. Prins (idnr.: 353741). Drs. H.L.J.J. Simons, from Civility Amsterdam Ir. F. van den 0001.

Date:

20 August 1997.

The Faculty of Electrical Engineering of Eindhoven University of Technology does not accept any responsibility regarding the contents of Master's Theses

av.

Structureren van IT-beheer met ITIL, ontwikkeling van een Service Level Rapportage systeem met SDM

Proloog Mijn werk als parttimer bij Pink Elephant Industry b.v., een bijbaantje om de karige studiebeurs wat op te krikken, gaf aan mijn op telecommunicatie georienteerde opleiding een IT tintje. Het werken in de IT sector beviel mij dermate dat ik aan de oproep om naar de voorlichtingsdag van Roccade te gaan graag gehoor gaf. Deze 'open dag', bestemd voor ouderejaarsstudenten, was bedoeld om kennis te maken met de bedrijven die deeI uitmaken van de Roccade holding. Op deze dag, 7 september 1996, kwam ik onder andere in contact met de heren Henk Simons (Hoofd Midrange Verwerking - Produktie en Beheer) en Aby Hartog (Hoofd Personeel & Organisatie) beiden van GCE!. Tijdens het gesprek dat wij voerden vertelde ik, dat voordat er iiberhaupt sprake van een dienstbetrekking zou kunnen zijn, ik nog moest beginnen met afstuderen. Hierop werd mij duidelijk gemaakt dat voor academici bij GCE! voldoende opdrachten beschikbaar zijn om op af te studeren. Aangezien er te weinig tijd was om uitvoerig in te gaan op mogelijke opdrachten heb ik wat algemene informatiebrochures mee genomen. Na het doorlezen van de brochures werd telefonisch een afspraak gemaakt waarbij GCEI mij een opdracht zou voorleggen. Deze opdracht moest kunnen voldoen aan de zware eisen die de Technische Universiteit Eindhoven aan een externe afstudeeropdracht stelt. Tijdens de afspraak, op 24 september 1996, werd mij een interessante opdracht voor gehouden, welke mijns inziens voldoende zwaar was om de toets der kritiek te kunnen doorstaan. Met deze opdracht in de hand heb ik de interne organisatie van de TUE op de hoogte gesteld van mijn wensen. Binnen de vakgroep Informatie en Communicatie Systemen is prof. ir. F. van den Dool de expert op het gebied van computer-netwerken, hij was bereid als afstudeerhoogleraar op te treden om zo het wetenschappelijke niveau van de opdracht te waarborgen. Met de uitvoering van deze opdracht is gestart op 13 januari bij GCE! in Amsterdam, tot eind augustus 1997 was er de tijd om aan de opdracht te werken. Vanaf 1 augustus is de naam GCEI Informatieplanning en Automatisering veranderd in Civility Amsterdam b.v.

Civility Amsterdam bv.

Technische Universiteit Eindhoven


Management Samenvatting Ret bedrijfsleven en de overheid zijn in grote mate afhankelijk van de informatiesystemen die zij gebruiken. Door deze afhankelijkheid is de kwaliteit van de informatiesystemen een erg belangrijk onderwerp geworden; er worden steeds zwaardere eisen gesteld aan de kwaliteit. Ret controleren van de kwaliteit van de IT-dienstverlening, om zo de afnemers beter te kunnen bedienen, is mogelijk met het kwaliteitssysteem ITIL. De steeds complexer wordende systemen vragen om een goed georganiseerde en uitgeruste beheerorganisatie. Deze beheerorganisatie dient de continulteit en de kwaliteit van de dienst te waarborgen. Afspraken tussen de IT-dienstverlener en afnemer aangaande de hoeveelheid en kwaliteit van de te leveren IT-dienst worden vastgelegd in service level agreements (SLAs). Ret bewaken van deze afspraken gebeurt door het terugkoppelen van de gerealiseerde kwaliteitsniveaus en deze te vergelijken met de norm zoals vastgelegd in het service level agreement. Dit terugkoPpelen gebeurt door middel van zogenaamde service level rapporten. Met deze objectieve rapporten moet de klant kunnen bepalen of voldaan is aan de afspraken overeengekomen in het SLA en een eventuele uitbreiding dan wel beperking van de dienstverlening gewenst is. De interne organisatie van de IT-dienstverlener kan deze rapporten gebruiken voor het aansturen van tactische processen die de kwaliteit van de dienstverlening op het gewenste niveau houden of brengen. Het doel van de opdracht was het ontwikkelen van een generiek service level rapportage systeem dat voldoet aan de wensen van de gebruikers en de rapporten kan leveren waar nu of in de nabije toekomst om kan worden gevraagd. De rapporten moeten informatie bevatten over ITIL processen die voor de klant relevant zijn, zoals beschikbaarheidsbeheer (met rapportage items als beschikbaarheid en betrouwbaarheid van een dienst) en capaciteitsbeheer (met rapportage items als gebruik en responstijden van de dienst). Voor de objectiviteit en het gebruiksgemak diende zoveel als mogelijk de functies binnen het rapportage proces geautomatiseerd te worden. Bij het inbeeld brengen van de input soorten, de output soorten en de omgeving van het rapporterend informatiesysteem is gebruik gemaakt van het besturingsparadigma. Voor het ontwikkelen van het service level rapportage systeem is de Systems Development Methodology (SDM) toegepast. Deze methode onderkent vier stappen in de ontwikkeling van een informatiesysteem, namelijk: 1. het opstellen van een informatiemodel, hier komen aan bod de structuur van het bedrijf, de problemen die er spelen en de bijdrage die het systeem dient te leveren aan de oplossing daarvan en onder welke voorwaarden dat moet gebeuren; 2. het functioneel ontwerp, hier komen aan bod de functies die binnen het systeem zijn te onderscheiden en volgens welke regels er interactie plaatsvindt; 3. het technisch ontwerp, dit ontwerp bevat alternatieve technische oplossingen, met dezelfde functionaliteit, voor de organisatie van het informatiesysteem; 4. de implementatie fase, verder onder te verdelen in realisatie, testen, conversie en invoering en gebruik en beheer. Civility Amsterdam bv.

3



Door de complexiteit van de infrastructuur en de diversiteit van de te leveren rapportage items is het niet mogelijk een van de op dit moment beschikbare standaardpakketten te gebruiken als middel voor het realiseren van alle vereiste functionaliteiten. Voor het verzamelen en opslaan van de benodigde netwerken systeemmanagementgegevens zijn weI standaard applicaties te gebruiken (NSM-pakket), aangevuld met zelf te schrijven scripts. Ook het afleveren van de uiteindelijke rapporten op internet, via email of als gedrukt exemplaar bij de klanten kan gerealiseerd worden met behulp van een standaardpakket (rapportage tool). Echter, voor de verwerking van de grote hoeveelheden managementgegevens tot correcte en duidelijke (eenvoudig te interpreteren) rapportage items, zal het systeem moeten beschikken over een snel en intelligent verwerkingsprogramma dat de gegevens opsplits, selecteert en aggregeert. Tevens moeten scripts geschreven worden voor de te gebruiken standaardpakketten en het koppelvlak tussen de diverse functies. Het verdient aanbevelingen om de kennis, van het netwerk, de aangesloten computersystemen en de geleverde diensten, die onder ander is opgedaan tijdens de uitvoering van de opdracht te structureren en samen te voegen tot een overzicht. Met dit overzicht is het voor de beheerorganisatie eenvoudiger in te schatten welke gevolgen storingen of wijzigingen hebben voor de aangesloten klanten.


4


Structureren van IT-beheer met ITIL, ontwikkeling van een Service Level Rapportage systeem met SOM

Inhoudsopgave

Proloog

1

Management Samenvatting

3

HI

Inleiding

7

H2

De Organisatie en haar Produkten

11

2.1 De Organisatie 2.2 De Produkten

11

H3

13

Netwerk Management Architecturen

15 15 19 27 29 35

3.1 Beheer van Communicatienetten 3.2 OSI-management 3.3 TMN-management 3.4 Internet Management 3.5 Generieke Conclusies

H4

Ontwikkelen van Bestuurlijke Informatiesystemen 4.1 Ret ontwerpen van een Informatiesysteem 4.2 Kwaliteit en Informatiesystemen 4.3 Veranderingsanalyse en Systeemontwikkeling 4.4 Doelmatigheid bij Informatiesystemen 4.5 Beheren van een Informatiesysteem

H5

Oude situatie 5.1 De Infrastructuur 5.2 Ret Service Level Management 5.3 De Service Level Agreement 5.4 De Service Level Rapportage 5.5 De Knelpunten

H6

37 37 43 46

47 49 53 53 57 58

59 62

Gewenste situatie

65

6.1 IT-beheer bij Civility 6.2 Gestructureerd IT-beheer met ITIL 6.3 Generieke Service Level Agreements 6.4 Ret Rapportage systeem 6.5 Toekomstvisie op IT-beheer

65


5

67

75 75 85 Technische Universiteit Eindhoven


H7

H8

Ontwikkeling Service Level Rapportage systeem

91

7.1 Netwerk en Systemen Management bij Civility 7.2 Het Informatiemodel 7.3 Het Logisch ontwerp 7.4 Het Technisch ontwerp 7.5 De Implementatie fase

91 94 102 108 145

Conc1usies en Aanbevelingen

147

8.1 Conclusies 8.2 Aanbevelingen

147 149

Literatuur

151

Epiloog

155

Bijlagen

157

Bij lage 1: Atkortingen met verklaring Bijlage 2: Invulling van het GDA & NSM Bijlage 3: Takenoverzicht MY Bijlage 4: SLR voor Civility-diensten volgens ITIL-structuur Bijlage 5: Begrippen en Definities Bijlage 6: Beheerobjecten Bijlage 7: Gegevensverzameling Bijlage 8: Rapport definities Bijlage 9: Rapportage tools


6

157 161 165 167 177 183 185 187 191



HI

Inleiding

Achtergrond De groei van gedistribueerde verwerking en client-server technologie heeft geleid tot een corresponderende groei in Local Area Networks (LANs). Door de jaren heen zijn miljoenen Ethernet en token-ring LANs geYnstalleerd. LANs zijn bijvoorkeur de manier geworden voor het onderling verbinden van terminals, kleine en grote computers om zodoende de toegang tot algemene bronnen, (bedrijfs)informatie en communicatie middelen te delen. Zakelijke investeringen worden besteed aan een wijde keus van computers, van micro- tot supercomputers, welke allemaal kunnen worden samengevoegd onder een enkele management paraplu [2].

Netwerk en Systemen Management (NSM) heeft tot doel, het inzetten en coordineren van bronnen voor het plannen, gebruiken, administreren, analyseren, evalueren, ontwerpen en uitbreiden van communicatie netwerken om zo te allen tijde, tegen geringe kosten, met een optimale capaciteit aan de service niveau wensen te voldoen. De laatste paar jaar zijn enkele problemen aangepakt door verschillende bedrijven, jammer genoeg zijn de geboden oplossingen noch compleet noch toepasbaar op alle situaties.

De meeste organisaties hebben de strategische belangen van hun communicatienetwerk en het management daarvan ingezien. In de meeste gevallen waarborgt een betere controle een betere performance, met deze performance correspondeert een hogere productiviteit. Op zijn beurt laat een hogere productiviteit zich vertalen in een verbetering van het uiteindelijke financiele resultaat. Dit brengt ons tot de vraag wat de stuwende factoren zijn voor investeringen en hogere uitgaven in netwerkmanagement [3]. • Beheren strategische bedrijfsmiddelen: netwerken zijn in toenemende mate een essentieel deel van de dagelijkse bedrijfsactiviteiten voor een onderneming. • Beheersen van de complexiteit: het constant toenemende aantal netwerkcomponenten, gebruikers, interfaces, protocollen en aanbieders laten veel managers achter met weinig of geen controle over wat is aangesloten op het netwerk. • Verbeteren van de service: gebruikers verlangen tenminste het zelfde service niveau ondanks de constante groei en veranderende technologie. • Uitbalanceren van de verschillende behoeften: van hen die het netwerk managen wordt verwacht dat voldaan kan worden aan bepaalde bedrijfsbehoeften zoals het ondersteunen van nieuwe toepassingen en klanten, verbeteren van de aansluitingen en waarborgen van stabiliteit en flexibiliteit. Op het zelfde moment moet voldaan worden aan gebruikersbehoeften, zoals beschikbaarheid, betrouwbaarheid, performance, stabiliteit en inzichtelijkheid. Dit alles in een netwerkmanagement omgeving waar er een gebrek is aan procedures en gereedschappen, de kundigheid beperkt is en er een tekort is aan voldoende opgeleid personeel. • Reduceren van de downtime: het waarborgen van permanent beschikbare netwerk bronnen en diensten is het ultieme doel van de bedrijfscommunicatie. • Beheersen van de kosten: het netwerkmanagement moet een oogie op de totale kosten houden welke geassocieerd kunnen worden met data en spraak communicatie. De kosten die een gemiddeld bedrijf maakt voor netwerkmanagement beslaan zo'n 12% tot 20% van het totale communicatie budget. Civility Amsterdam bv.

7



Voor het gestructureerd laten functioneren van de IT-organisatie wordt bij Civility de ITILmethodiek toegepast. ITIL (Information Technology Infrastructure Library) kan worden beschouwd als de beschrijving van een op de exploitatie van de IT-infrastructuur toegespitst kwaliteitssysteem. Ten behoeve van de IT-dienstverlening wordt een aantal noodzakelijke processen onderscheiden en beschreven. De kwaliteit van de dienstverlening en de toegevoegde waarde voor de klant staan hierbij centraal [17]. GCEI informatieplanning en automatisering heeft op verzoek van de gemeente Amsterdam de Gemeenschappelijke Datacommunicatie infrastructuur voor de Amsterdamse gemeente instellingen (GDA) ontwikkeld en gebouwd. Via het GDA kunnen gemeente instellingen (en daaraan gelieerde bedrijven) diensten aanbieden en afnemen van GCEI (Civility) of van andere gebruikers. In hoofdstuk 2 wordt verder in gegaan op de Civility organisatie en haar produkten. De Opdracht Maandelijks werd er een rapport gemaakt met daarin een summiere beschrijving van het gerealiseerde kwaliteitsniveau van de geboden netwerkdiensten. Deze rapportages zijn bestemd voor de opdrachtgever (gemeente Amsterdam) en de gebruikers, de rapporten dienen een duidelijk beeld te geven van het kwaliteitsniveau van de geboden service. Er waren echter enkele knelpunten bij het verzamelen, verwerken en presenteren van de gegevens. Bovendien kon nog niet van aIle netwerkdiensten het kwaliteitsniveau worden bepaald. Voor een aansluiting op het GDA, en voor andere af te nemen diensten, wordt een contract afgesloten tussen Civility en de klant, in dit contract is o.a. het Service Level Agreement (SLA) opgenomen. Rierin staan de kwaliteitseisen beschreven en de afspraken over beheer vastgelegd. Over het gerealiseerde service niveau dient gerapporteerd te worden, het Service Level Rapport (SLR). Ret maken van deze rapportages verliep nogal stroef, het doel van deze opdracht was derhalve, de rapportage structureel te verbeteren en deze verbeteringen met het ITIL-systeem te onderbouwen. De gevolgde Aanpak De opdracht valt in twee delen uiteen, het eerste deel omvat het onderzoek naar de technieken die gebruikt kunnen worden voor het beheren van een netwerk. Ret tweede deel bestaat uit het ontwikkelen van een informatiesysteem dat rapporten genereert betreffende het gerealiseerde kwaliteitsniveau van de netwerkdiensten. De twee delen zijn in eerste instantie bekeken vanuit een theoretisch perspectief, en later toegepast bij het ontwikkelen van het rapportage systeem. Zie ook figuur 1.1 voor een schematisch overzicht van de behandelde onderwerpen in dit verslag. Voor een goed inzicht in de technische organisatie van het netwerkmanagement wordt in hoofdstuk 3 een aantal gestandaardiseerde netwerkmanagement architecturen behandeld. Deze architecturen worden toegepast in managementsystemen, welke worden gebruikt voor het beheren van het Internet of data- en telecommunicatienetwerken. De structuur en de invulling van drie architecturen worden uitgewerkt en met elkaar vergeleken. Tevens worden enkele intrinsieke problemen van de architecturen uit de doeken gedaan.


8



Om tot een effectieve en structurele oplossing te komen voor het rapportage probleem, is onderzocht welke strategieen er gehanteerd kunnen worden en aan welke randvoorwaarden voldaan moet worden bij het ontwikkelen van (rapporterende) Informatiesystemen (IS). In hoofdstuk 4 wordt respectievelijk behandeld wat de doelen, eisen, ontwikkel stappen, gevolgen en het beheer van een informatiesysteem zijn. Achtergrond, de opdracht en de gevolgde aanpak (HI).

1

De organisatie en haar produkten (H2)

..

I

Netwerk Management Architecturen (H3)

..

Ontwikkeling van een Bestuurlijk Informatiesysteem (H4)

1 De Huidige Situatie (H5)

1 De Gewenste Situatie (H6)

1

De ontwikkeling van een ! Service Level Rapportage I systeem (H7)

1

Conclusies en Aanbevelingen (H8)

Figuur 1.1 Schematisch overzicht van de behandelde onderdelen in dit verslag. De hoofdstukken 3 en 4 behandelen de theoretische achtergrond van het project. In dit verslag is veel aandacht voor deze onderwerpen, omdat deze hoogstwaarschijnlijk geen deel uitmaken van de kennis van de (student) lezer, maar weI de basis vormen van dit project. Met de verworven kennis is er vervolgens aan de hand van een drie stappen plan te werk gegaan. In de eerste stap is met de informatie uit literatuuronderzoek de start situatie beschreven. De nadruk lag hier op de invulling van de netwerkdiensten, het beheer van deze diensten, de afspraken en overeenkomsten met de klanten, de opbouw van het oude rapportage systeem en de knelpunten die er bestonden. Meer hierover in hoofdstuk 5. Tijdens de tweede stap moest duidelijk worden wat de eisen en wensen zijn van, Civility, de opdrachtgever, de service level manager en de klanten ten aanzien van een service level rapportage systeem, en welke wensen in de (nabije) toekomst te verwachten zijn; veroorzaakt door nieuwe diensten, organisatorische veranderingen en verbetering van het IT-beheer. Dit Civility Amsterdam bv.

9



wordt uitgebreid behandeld in hoofdstuk 6. Daar Civility er naar streeft om het IT-beheer volledig in te richten en te structureren volgens de ITIL-methodiek, wordt die methodiek ook in dit hoofdstuk behandeld. De derde en laatste stap besloeg het realiseren van de wensen door het ontwikkelen van een informatiesysteem. Dit diende zo te gebeuren dat er een flexibel, betrouwbaar en goed gedocumenteerd rapportage systeem zou ontstaat. Het ontwikkelen van een informatiesysteem is in belangrijke mate een kwestie van modelleren. Dat modelleren gebeurt in parallelle en successievelijke werkstappen. Volgens SDM (Systems Development Methodology) te verdelen in het opstellen van een informatiemodel, het logisch ontwerp en het technisch ontwerp. Na het modelleren start de implementatie fase, op te delen in de bouw, het testen en tot slot conversie en invoering. In hoofdstuk 7 komen deze onderwerpen aan de orde. De invoering van het rapportage systeem maakt onderdeel uit van het project verbetering van het IT-beheer, daar dit project randvoorwaarden stelt aan het systeem, worden het doel en de opzet van dit projekt ook in dit hoofdstuk behandeld. Dit verslag is bestemd voor medewerkers en studenten van de Technische Universiteit Eindhoven met name voor hen die bij de faculteit Elektrotechniek, vakgroep Informatie en Communicatie Systemen, actief zijn. Voor de nieuwe (afstudeer-)stagiaires bij afdeling Midrange Verwerking Productie en Beheer van Civility Amsterdam b.v. kan dit document dienen als eerste kennismaking met de beheerorganisatie en -middelen die daar gebruikt worden. De Service Level Managers kunnen in dit document vinden wat de achtergronden, de mogelijkheden en onmogelijkheden van een rapportage systeem zijn. Zij die geYnteresseerd zijn in IT-beheer, systeemontwikkeling en service level rapportage kunnen in dit verslag veel informatie, met referenties, vinden.


10



H2

De Organisatie en haar Produkten

2.1

De Organisatie

Civility was van origine een diensttak van de gemeente Amsterdam en verleent al jaren de automatiseringsdiensten voor onderdelen van de gemeente Amsterdam. De sterkte van Civility (± 270 medewerkers) ligt in het ontwikkelen, beheren, onderhouden en het exploiteren van mainframe georienteerde applicaties. Door afschaffing van gedwongen winkelnering, de decentralisatie van Amsterdam en de technologische ontwikkeling kwam eind jaren '80 een eind aan de stijgende lijn van de omzet. Vanaf eind 1990 is onder een nieuw management een nieuw beleid ingezet waarbij een begin gemaakt is met de transformatie van GCEI naar een marktconform bedrijf (Civility), primair gericht op de Amsterdamse gemeentemarkt met een op midrange systemen gericht produktbeleid. Voor GCEI was 1994 een belangrijk jaar. De samenwerkingsovereenkomst met de huidige Roccade Informatica Groep N.V. werd per 1 juli 1994 effectief waarmee GCEI een nieuwe fase in haar bestaan is ingegaan. Dit betekende het definitieve einde van de periode waarin GCEI het gemeentelijk rekencentrum was en de start van het op commerciele basis opererende automatiseringsbedrijf GCEI Informatieplanning en Automatisering. Door de samenwerking met Roccade is GCEI in staat haar klanten een betere set produkten op basis van continuYteit aan te bieden en haar markt buiten Amsterdam uit te breiden. De samenwerkingsovereenkomst beschrijft een overgangsfase welke loopt tot 1 juli 1997. De doelstelling in deze periode is, om naast het genereren van een bescheiden winst, de reeds ingezette transformatie naar een marktconform bedrijf op commerciele basis met succes te voltooien. Hierbij staat het continueren en verder verbeteren van de dienstverlening aan de gemeente Amsterdam voorop. Gedurende de overgangsfase heeft Roccade een minderheidsbelang van 49% in het verzelfstandigde GCEI en draagt de verantwoordelijkheid voor het management van het bedrijfinclusiefde daaraan verbonden financiele risico's [6]. Voor de Roccade holding als geheel is de volgende missie geformuleerd: 'Roccade Informatica Groep NV is de facilitaire dienstverlener voor informatie-intensieve organisaties, door het gebruiksklaar opleveren en houden van informatiesystemen, waarbij gebruik wordt gemaakt van moderne technologie. ' De missie van Civility Amsterdam b.v. luidt: 'Het verlenen van automatiseringsdiensten in de vorm van competence centers voor midrange-verwerking, sociale diensten, vastgoed en DIS/Worliflow systemen. ' Het dienstverleningspakket bestaat uit: - Mainframe verwerking - Midrange verwerking (MV) * Centrale en decentrale midrange exploitatie * Netwerkdiensten * Werkplek exploitatie Civility Amsterdam bv.

11



- Applicatie Services (AS) * Maatwerk (ver)nieuwbouw * Onderhoud maatwerk * Beveiliging * Implementatie. Deze diensten worden zowel apart als in combinatie aangeboden, indien gewenst op basis van 'fixed price fixed date '. GCEI heeft daarbij in tal van projecten expertise opgebouwd om op basis van een meerjarig contract verwerking, applicatievernieuwing en onderhoud te leveren volgens een vooraf overeengekomen 'service niveau overeenkomst' (SNO) [7]. Naast deze sectoren is nog een aantal stafdiensten te onderscheiden zoals Personeel en Organisatie, Financiele zaken, Interne dienst en Commerciele zaken. De missie voor de sector Midrange Verwerking luidt: 'Met voorspelbare kwaliteit en kosten uitvoeren van de verwerking van informatievoorziening op midrange systemen in een netwerk met intelligente werkplekken. '

--

Bowhouse Data BV

RCC

r-- Pink Elephant BV

./ Trendsoft Automatisering

Data Process

Roccade

I

\

Informatica Groep NV

JBAlRatioplan Benelux BV

,

Infracare BV

•

Twinfo BV

"

Consist BV

, L+T* Informatica BV

I

Mainframe Faciliteiten

GRC*

- ......

I

GCEI*

~

I Midrange Verwerking

I

* deze bedrijven vorrnen samen de Roccade Civility groep

I

•

Applicatie Services

I

Figuur 2.1 Overzicht organisatie structuur Roccade/GCEI. . De sector Midrange Verwerking is als voIgt georganiseerd: Facilities Management Services (FMS), 3 medewerkers


12



GCEI richt zich voor de uitvoering van haar services een organisatie en communicatie structuur in die aansluit op de organisatie van de klant. Facilities Managers die het contact onderhouden met de klant, sturen de MV organisatie aan op tactisch niveau. MV-Engineering (MV-E), 21 medewerkers MV-Engineering is verantwoordelijk voor het ontwerp en inrichten van de midrange omgeving. Het afstemmen van de mogelijkheden van apparatuur en systeemprogrammatuur op de wensen van de klant is een specialiteit van de groep. Produktie en Beheer (MV-PB), 18 medewerkers Produktie en Beheer is verantwoordelijk voor de verwerking en het beheer van applicaties op de midrange omgeving. Binnen MV heeft met name MV-PB als taak het afhandelen van verstoringen in de produktie-omgeving (incidenten). De organisatie is min of meer als een matrix organisatie ingericht. Per 'klantcontract' (dienst) is de organisatie een Service Level Manager (SLM) benoemd. Haaks daarop staat een indeling gebaseerd op technische ofbeheer specialisatie (LAN, WAN, VMS, CMDB, Uitwijk ... ). Personeel en Salaris, 8 medewerkers Binnen deze groep worden activiteiten verricht op het gebied van personeelsinformatie en salarisverwerking voor de diensten van de bedrijven van de gemeente Amsterdam [5].

2.2

De Produkten

De produkten portfolio van de sector MV bestaat uit een aantal automatiserings- en netwerkdiensten. De werkzaamheden die uitgevoerd dienen te worden binnen deze contracten zijn vastgelegd in Service Level overeenkomsten. Op de belangrijkste produkten zal hier verder kort op worden ingegaan. Vastgoed Van oudsher is GCEI vertrouwd met de administratieve en geometrische informatiestromen in Amsterdam. De belangrijkste ontwikkeling binnen de vastgoed-informatievoorziening is de wet waardering onroerende zaken. Een ander belangrijk onderwerp is de vastgoedbalie, waarmee gemeenten de dienstverlening aan de burger en het bedrijfsleven nader vorm geven. Tevens speelt de groeiende behoefte aan ruimtelijke gegevens een roi. Voor GCEI betekent dit, dat koppelingen tussen taakgerichte applicaties en geografische informatiesystemen tot stand worden gebracht. GISP (Gemeentelijk Informatiesysteem Salaris en Personeel) GISP is het door GCEI geleverde en geexploiteerde salaris- en personeelssysteem dat door alle diensten, bedrijven en stadsdelen van de gemeente Amsterdam wordt gebruikt. Dit systeem waarbij men op meer dan 200 werkplekken bij ruim 60 organisaties on-line de beschikking heeft over de eigen personeelsgegevens, werd in 1993 en 1994 in de stad gelmplementeerd. In 1995 werd dit systeem met een omvangrijke financiele module voor loonverantwoording uit gebreid. Het systeem biedt hiermee inzichtelijke informatie, niet alleen voor de P&O-afdelingen, maar vooral ook voor integrale sturing door het management van de gemeentelijke organisaties in Amsterdam.


13



NUS (Nieuw Uitkeringen Systeem) GCEI heeft onder een meerjarig vast-prijscontract vanaf 1 januari 1994 de exploitatie en het onderhoud van het bestaande uitkeringensysteem van de Gemeentelijke Sociale-Dienst (GSD) op zich genomen, alsmede de complete vemieuwing van infrastructuur en applicatie van het uitkeringensysteem van de GSD. In 1994 is naast de exploitatie van de bestaande systemen de eerste stap gezet met een basisontwerp van de nieuwe applicatie en het ontwerp van de nieuwe infrastructuur in de rayonkantoren. De nieuwe applicatie NUS wordt gerealiseerd in clientserver technologie. In de eerste maanden van 1995 is deze nieuwe infrastructuur (PC werkstations, LAN en RS6000 minicomputer) in de rayonkantoren geleverd en operationeel geworden. Daarbij werd vruchtbaar gebruik gemaakt van de samenwerking in Roccadeverband met de Roccade-dochter Infracare. In 1995 is deze nieuwe infrastructuur als eerste deel van· het gefaseerd op te leveren Nieuw Uitkeringen Systeem (NUS) het Client Voig Systeem (CVS) opgeleverd en operationeel geworden. In 1996 zullen de resterende delen van NUS ontwikkeld en gefaseerd worden opgeleverd. GRS (Geautomatiseerd Registratie Systeem) De in 1994 in gang gezette ontwikkeling van een nieuw 'casco'-systeem voor postregistratie en documentbeheer op basis van GRS-voor-Windows, is in 1995 doorgezet. Op basis van deze casco-software zijn voor vijf klanten maatwerkoplossingen gebouwd. Voor de Vreemdelingenpolitie Amsterdam/Amstelland is met GRS-voor-Windows een dossiermodule aan het Vreemdelingen-AdministratieSysteem (VAS) gebouwd. Het VAS is een door derden ontwikkelde applicatie die landelijk wordt gebruikt door alle politiekorpsen. De Vreemdelingenpolitie Amsterdam/Amstelland is met ruim honderd gebruikers aangesloten op het VAS en op GRS-voor-Windows. Een groot deel van de organisatie-onderdelen van de Koninklijke Landmacht maakt gebruik van GRS-voor-Windows voor hun postregistratie. Ook het eerste Nederland/Duits legerkorps in MUnster is uitgerust met een applicatie op basis van GRS-voor-Windows. In dit geval is een Engelstalige versie gemaakt. WVG (Wet Voorziening Gehandicapten) Het WVG-project (Wet Voorziening Gehandicapten), een project voor de Sociale Dienst, de Stedelijke Woningdienst en de Stichting Tot en Met die gezamenlijk de uitvoering van de WVG voor hun rekening nemen. GCEI bouwde een client server systeem op PC/RS6000 in Uniface/Oracle. Zij bracht integratie tot stand met Open Image en WP en met koppeling naar de mainframe systemen voor Bevolking en Uitkeringen. Via het WVG systeem zijn 10 locaties met elkaar verbonden. GDA (Gemeenschappelijke Datacommunicatie-infrastructuur Amsterdam) Midden 1995 ontving GCEI na een lange periode van grondige voorbereiding de opdracht voor de realisatie van de Gemeenschappelijke Datacommunicatie-infrastructuur Amsterdam (GDA). Met GDA wordt voor de gemeente Amsterdam een modeme datacommunicatieinfrastructuur gerealiseerd. Via een aansluiting op GDA zal Amsterdam op het Nederlandse gemeentenetwerk Gernnet worden aangesloten. In 1995 is een pilot GDA voor de uitwisseling van geografische en administratieve vastgoedinformatie met succes uitgevoerd. Ook een proeftuin Email werd via een GDA pilot gerealiseerd. In 1996 zijn de gemeentelijke concemsystemen via GDA voor de gebruikers beschikbaar gekomen [7].


14



H3 Netwerk Management Architecturen 3.1

Beheer van Communicatienetten

In dit hoofdstuk wordt een aantal gestandaardiseerde netwerkmanagement architecturen behandeld. Deze technieken worden toegepast in managementsystemen, welke worden gebruikt voor het beheren van het Internet of data- en telecommunicatienetwerken. De structuur en de invulling van drie veel gebruikte methoden worden uitgewerkt en met elkaar vergeleken. Tevens worden enkele problemen van de architecturen uit de doeken gedaan. Beheerorganisatie Binnen een organisatie, en daarmee ook in een beheerorganisatie, kan men drie niveaus van verantwoordelijkheden onderkennen: strategisch, tactisch en operationeel beheer. Deze drie niveaus kunnen weergegeven worden in een piramide, zie figuur 3.1. Kenmerkend voor deze piramide is dat er van boven naar beneden in toenemende mate sprake is van programmeerbare beslissingen en de daaruit voortvloeiende behoefte aan meer gedetailleerde en gestructureerde informatie. Bovendien geldt dat in het algemeen de berichtgeving boven in de piramide (strategisch niveau) met een veel grotere tijdsdimensie werkt dan onder in de piramide (operationeel niveau), waar het soms om seconden gaat [36].

Operationeel niveau

FM = Fault Management CM = Configuration Management PM = Perfonnance Mana ement

AM = Accounting Management SM = Security Management

Figuur 3.1 De beheerpiramide. De taken van de verschillende management functies worden in hoofdstuk 3.2 behandeld. Bij strategisch beheer worden beslissingen op lange termijn (3-5 jaar) genomen. Het omvat ondermeer de volgende taken: * bepalen van het lange termijn beleid op basis van technologische ontwikkelingen en de communicatie-behoefte van de potentiele gebruikers; * opstellen van een informatieplan, automatiseringsplan en een communicatieplan (zie ook hoofdstuk 4); * bepalen van de gewenste netwerkfunctionaliteit, in samenwerking met het informatie- en automatiseringsplan; * vormgeven van de beheerorganisatie. Bij tactisch beheer worden de strategische beleidslijnen naar de praktijk vertaald. Het omvat taken op de middellange termijn (1-2 jaar): * zorgdragen voor opbouw van de infrastructuur op basis van het communicatieplan; Civility Amsterdam bv.

15



* per applicatie definieren van de te bieden netwerkkwaliteit (de zogenaamde service levels); * controleren of de gewenste kwaliteit wordt geleverd; * vaststellen van de procedures, richtlijnen en aansluitvoorwaarden; * aanpassen van de infrastructuur en oplossen van knelpunten. Bij operationeel beheer worden vooral de dagelijkse en wekelijkse beheertaken uitgevoerd: * instandhouden van de infrastructuur en het oplossen van storingen; * leveren van de gedefinieerde diensten aan de eindgebruikers; * registreren van gegevens met betrekking tot samenstelling, status en gebruik van het netwerk; * realiseren en wijzigen van aansluitingen. Beheerinfrastructuur In deze paragraaf wordt een raamwerk voor een beheerinfrastructuur geschetst waarmee structuur wordt aangebracht in de functies, nodig om de infrastructuur te beheren. Met de beheerinfrastructuur wordt de technische beheerinfrastructuur bedoeld, dat wil zeggen, de computer systemen, de datacommunicatie-faciliteiten etc. Het geautomatiseerde deel van de processen dus, en niet dat deel van de activiteiten dat door mensen wordt uitgevoerd.

Een aantal indelingen kan voor de beheerinfrastructuur worden gebruikt. De indelingen naar lagen van abstractie en naar functionele categorieen lijken op de indelingen gebruikt voor de beheerorganisatie. Nu ligt de nadruk echter op de functies (de geautomatiseerde beheeractiviteiten). Een ander soort indeling is de procesindeling. De drie invalshoeken worden gebruikt om de vereiste beheerfunctionaliteit te inventariseren. De invalshoeken zijn orthogonaal, ze staan loodrecht op elkaar, zodat de beheerkubus in figuur 3.2 ontstaat.

Service management

Netwerkmanagement

Netwerkelement management

Netwerkelement

Figuur 3.2 De beheerkubus.

Indeling naar functionele categorieen, per abstractielaag kan een functionele indeling gemaakt worden, zie voor een beschrijving hoofdstuk 3.2. De categorieen omvatten daarbij geen taken maar functies (geautomatiseerde activiteiten). Figuur 3.2 toont de relatie van de functionele categorieen met de andere indelingen.


16



Indeling naar proces, iedere functionele categorie kan procesmatig worden ontleed. Ret model wat hieraan ten grondslag ligt is het zogenaamde ADI-modeI, het model onderscheidt drie processen die bij de functie betrokken zijn: * het proces waarin een bepaald probleem wordt herkend Awareness Creation. Een voorbeeld hiervan is het constateren dat het serviceniveau (Quality of Service, QoS) te laag is. * het proces dat het probleem analyseert en dat besluit, na eventuele consultatie van een operator of bovengelegen laag, een actie aan te sturen, noemen we Decision Making and Support. Dit proces bekijkt dus waarom de QoS te laag is en besluit of er actieCs) ondernomen dient te worden en welke dit moet(en) zijn. * het proces dat de gevraagde actie(s) uitvoert, Decision Implementation. In geval van een te lage QoS kan dit een opdracht zijn om de QoS weer naar het gewenste peil terug te brengen. Indeling naar lagen van abstractie, in het geheel van beheerfuncties zijn vier soorten faciliteiten te herkennen, zie figuur 3.2. Iedere Iaag representeert functies met overeenkomstige kenmerken, waarbij iedere laag functies van een ander niveau van abstractie biedt. Een Iaag maakt gebruik van de management services die de onderliggende Iaag biedt; op zijn beurt biedt de betreffende Iaag management services aan zijn naast hoger gelegen Iaag. Deze management services representeren de beheerfuncties en beheerinformatie van een Iaag. De reden van het opdelen van de beheerinfrastructuur in Iagen wordt eerst besproken vervolgens de Iagen zeif. De argumentatie voor de opdeling van de beheerinfrastructuur in Iagen valt uiteen in vier redenen. Ten eerste is het gewenst vraag en aanbod te ontkoppelen. Riermee wordt bedoeld dat bij het bepalen van een architectuur in ieder geval twee factoren van invioed zijn. De aanbodzijde, het datacommunicatienetwerk zeIf, en de vraagzijde, de beheerprocessen. Beide factoren zijn onderhevig aan wijzigingen. Om deze wijzigingen zo min mogeIijk door te Iaten werken in de beheerarchitectuur en flexibel op deze wijzigingen in te kunnen speIen, is het gewenst om de processen in de beheerorganisatie via een tussenlaag te koppelen aan de netwerkelementen. Een tweede argument is de wens om een netwerk te beheren en niet slechts een aantal individuele netwerkelementen. Een van de taken van een ge'integreerde beheerarchitectuur is het integraal besturen van een netwerk, waarbij samenhangende activiteiten op (delen van) het netwerk uitgevoerd kunnen worden. Ten derde dient een beheerarchitectuur de verschillen in functies en presentatie van de functies van verschillende netwerkelementen weg te werken. Er dient conversie plaats te vinden naar standaard beheerfuncties. Ais voorbeeld kan hier dienen de verschillen die bestaan in de man-machine taal van de verschillende typen centraies. Uiteraard is het dan noodzakelijk een gemeenschappeIijk model te hebben of te ontwerpen voor de verschillende netwerkelementen. Tegelijkertijd bIijft het voor een aantal bedrijfsprocessen, waaronder onderhoud, nodig om fabrikantspecifieke informatie te Ieveren. Ten vierde bestaat er behoefte om een scheiding aan te brengen in het beheer van services en het beheer van het netwerk. Ret beheer van services omvat allerlei functies die ter ondersteuning dienen voor processen die klantgericht zijn, bijvoorbeeld notaproduktie, kiantafhandeling, aan- en afsIuiten.


17



De geYntegreerde beheerarchitectuur bestaat uit vier lagen van beheerfuncties. Vanaf de onderste laag en hoger zijn dit de netwerkelement-Iaag, de netwerkelement-managementlaag, de netwerkmanagement-Iaag en de service-managementlaag. De netwerkelement-laag (NE-Iaag) representeert de beheerfuncties in de (data- en/of tele-) communicatiesystemen zelf, met andere woorden, aIle beheerfuncties die door de communicatie-infrastructuur zelfworden geboden. De netwerkelement-managementlaag (NEM-Iaag) heeft twee doelen. Ten eerste biedt het beheerfuncties voor het beheer van een verzameling netwerkelementen van een bepaalde klasse, bijvoorbeeld routers van dezelfde leverancier. Ten tweede fungeert de NEM-Iaag als intermediair voor de NE-Iaag en de netwerkmanagement-Iaag (NM-Iaag), zodat de NM-Iaag van de fabrikantspecifieke beheerfuncties afgeschermd wordt. In de NEM-Iaag worden fabrikantspecifieke gegevens opgeslagen en geilniformeerd naar een standaardformaat. De netwerk-managementlaag, het begrip netwerkmanagement veronderstelt de aanwezigheid van een beeld van het netwerk. Dat impliceert dat de topologie van het netwerk bekend is, maar ook dat individuele systemen zichtbaar zijn; van die individuele systemen zijn de fabrikantspecifieke kenmerken echter niet zichtbaar. Het kenmerkende daarbij is dat activiteiten uitgevoerd kunnen worden op delen van het netwerk of op het totale netwerk. Daarbij is er sprake van gecoordineerde acties. Er wordt gebruik gemaakt van kennis van (delen van) het netwerk bij het analyseren van (fout)situaties in het netwerk en bij het bepalen of (en zo ja, welke) actie moet worden uitgevoerd. De functies in de netwerkmanagement-Iaag (NM-Iaag) zijn verantwoordelijk voor geYntegreerd beheer van de netwerkelementen, zowel individueel als deel uitmakend van een verzameling van NE's. Daarbij hebben de NM-functies geen betrekking op de wijze waarop een specifiek netwerkelement intern zijn functies vervult. Het overzicht van het netwerk en de leveranciersonafhankelijkheid zijn kenmerkend. Daarbij zijn fault, configuration en performance management belangrijke managementaspecten. De service managementlaag (SM-Iaag) biedt functies voor het beheer van de diensten die via het netwerk aan de klant worden geboden. De fysieke details betreffende de wijze waarop deze diensten in het netwerk zijn geYmplementeerd, zijn in deze laag minder zichtbaar. De beheerfuncties kunnen in twee groepen worden onderscheiden: * beheerfuncties ter onderscheiding van operationele klantprocessen, hieronder zijn beheerfuncties te rekenen die relaties vastleggen tussen de klant en de te leveren dienst. Met dienst wordt hier niet aIleen de datacommunicatiedienst bedoeld, maar ook de quality of service (QoS) etc. Voorbeelden van dergelijke functies zijn: * het vastleggen van de servicecontracten; * het bepalen en innen van de kosten van de geleverde diensten; * het afhandelen van klachten over de kwaliteit en de kosten van diensten; * het verstrekken van informatie over het gebruik van diensten.

*

beheerfuncties ter ondersteuning van service managers, met deze beheerfunctie wordt het mogelijk om statistieken op te leveren met betrekking tot het gebruik van bepaalde diensten, al dan niet uitgesplitst naar marktsegment. Ook dienen de beheerfuncties in te


18



spelen op vragen van de service managers ten aanzien van trends in de markt, voorbeelden van deze statistieken zijn: * omzet per dienst per aanbiedingsgebied; * leveringskwaliteit per geboden dienst; * trends in de afname van diensten per aanbiedingsgebied.

3.2

OSI-management

Inleiding Management Architecturen Netwerkmanagement heeft tot taak de werking van communicatienetwerken te controleren en te verbeteren, alsmede het netwerk aan te passen in het geval de eisen van de netwerkgebruikers veranderen. Management betreft het initialiseren, observeren en modificeren van de netwerkfuncties. Voor het verrichten van management zijn speciale functies nodig, zogenaamde 'managementfuncties'. Om management functies te kunnen onderscheiden van de normale netwerkfuncties die de primaire gebruikerseisen realiseren worden die in het vervolg 'primaire functies' genoemd.

Managementfuncties kunnen op een handmatige wijze worden uitgevoerd door personen ('expliciet management'), maar ook op een geautomatiseerde wijze via hard- en software modules ('impliciet management'). In het geval managementfuncties handmatig worden uitgevoerd, zal het merendeel van deze functies worden verricht vanaf speciale managementsystemen die zich bevinden op een beperkt aantal lokaties. Indien managementfuncties automatisch worden uitgevoerd, kan het beter zijn een groot deel van deze functies over het hele netwerk te distribueren en te implementeren als onderdeel van de te managen systemen. Architecturen voor netwerkmanagement bieden de ontwerper de mogelijkheid managementfuncties op een hoog abstractieniveau te beschouwen en een goed beeld te ontwikkelen van de te ontwerpen managementservices en protocollen. In het algemeen geldt dat dergelijke architecturen bestaan uit de volgende componenten: * een verzameling architecturele concepten, * regels die aangeven hoe deze concepten gebruikt moeten worden, en * modellen die de toepassing van deze regels en concepten demonstreren en hierdoor het ontwerp van een specifieke klasse van systemen vereenvoudigen. Management is nodig voor het activeren en in stand houden van het netwerksysteem dat de primaire functies uitvoert. Dit houdt in dat management eerst de verschillende netwerksystemen (configuration management) moet initialiseren. Ais er geen fouten zijn gemaakt komt het systeem in gebruik en start de operationele fase. Gedurende deze fase bewaakt het management de verschillende netwerksystemen om te kijken of er geen fouten optreden. Zodra er een fout optreedt zal het defecte systeemonderdeel gevonden, geisoleerd en gerepareerd moeten worden (fault management). Ais het onderdeel niet kan worden gerepareerd, moet het worden vervangen, deze activiteit moet geinitieerd worden. Ook kunnen nieuwe systemen worden toegevoegd om uitbreiding van het aantal gebruikers mogelijk te maken, de performance te verbeteren of nieuwe functionaliteiten te bieden. Toevoegen van nieuwe systeemonderdelen leidt dikwijls tot herconfiguratie. Bewaking van het netwerk is ook zinvol voor het detecteren van veranderingen in verkeersstromen. Ais er dergelijke


19



wijzigingen waargenomen worden kan het noodzakelijk zijn de netwerk parameters aan te passen ter optimalisatie van de netwerk performance (performance management). Verschillende organisaties hebben zich bezig gehouden met de ontwikkeling van diensten, protocollen en architecturen voor het netwerkmanagement. De drie meest belangrijke organisaties zijn: * The International Organization for Standardization (ISO). * The Comite Consultative Internationale de Telegraphique et Telephonique (CCITT); deze organisatie heet tegenwoordig the Telecommunication Standardization Sector (T) van de International Telecommunications Union (ITU). * The Internet Engineering Task Force (IETF). Van de drie bovengenoemde organisaties was ISO de eerste die startte met, als onderdeel van haar 'Open Systems Interconnection' (OSI) programma, de ontwikkeling van een architectuur voor netwerkmanagement.. De eerste voorstellen voor zo een architectuur verschenen tijdens de beginjaren tachtig; tegenwoordig bestaat er een groot aantal standaarden voor de architectuur als wel voor de netwerkmanagement diensten en protocollen. Van deze standaarden zijn de 'OSI Management Framework', de 'OSI Systems Management Overview' en de 'Common Management Information Protocol' (CMIP) waarschijnlijk de meest bekende voorbeelden. OSI Management Framework De eerste Working Drafts van het Management Framework bevatte al onderdelen over management functies. Deze management functies groeiden tot wat nu bekend staat als de vijf functiegebieden van OSI.

Fault management is de verzameling van faciliteiten welke zorgen voor detectie, isolatie en correctie van abnormale operaties. Mogelijke oorzaken voor abnormaal gedrag zijn: ontwerp en implementatiefouten, overbelasting, externe verstoringen en levensduur verwachting (ouderdomsgebreken). Fault management bevat functies voor: * het detecteren van storingen (drempeloverschreidingen, testresultaten); * het stellen van de storingsdiagnose; * het uitvoeren van de storingscorrectie; * het registreren van storingen; * het controleren op het opheffen van storingen; * het voorkomen van storingen (preventie), bijvoorbeeld door het testen van verdachte delen van het netwerk; * het initieren van activiteiten en procedures na escalatie; * het toewijzen van de storingen aan de afdelingen die ze dienen op te lossen.

Configuration management, dit soort management houdt activiteiten in om de functionaliteit van het netwerk te identificeren, er gegevens over te verzamelen en het van gegevens te voorzien. Deze activiteiten hebben dus betrekking op de gegevens van aIle netwerkcomponenten. Daarmee is tegelijkertijd op elk moment bekend hoe het netwerk in elkaar zit. Te onderscheiden taken zijn: * het verzorgen van netwerkwijzigingen en uitbreidingen; * het instellen van netwerkparameters; Civility Amsterdam bv.

20



* het besturen van de status van de netwerkcomponenten; * het registreren en weergeven van de netwerkcomponenten en de status daarvan. Accounting management is de verzameling van faciliteiten die het doorbelasten mogelijk maakt en kosten identificeert voor het gebruik van netwerk bronnen. Dergelijke bronnen zijn: * De aanbieder van netwerkdiensten, die verantwoordelijk is voor de overdracht van gebruikersdata (b.v. het publieke netwerk). * Netwerk toepassingen (b.v. directory diensten). Accounting management zorgt voor: * het berekenen van gebruikskosten; * het genereren van kostenoverzichten; * het verhogen van het kostenbewustzijn onder gebruikers; * het bewaken van budgetten van organisatie-eenheden. * het toerekenen van vaste en variabele kosten; * het instellen van kostenparameters. Performance management is nodig voor het optimaliseren van de Quality of Service (QoS). Voor het detecteren van wijzigingen in de netwerk performance, statistische gegevens moeten verzameld en in gelogd worden op een incidentele of periodieke basis. Te onderscheiden taken zijn: * het verzamelen van netwerkstatistieken (responstijden, verkeersgedrag, gemiddelde hersteltijd bij foutmeldingen etc.); * het analyseren en presenteren van netwerkstatistieken (rapportages). Het gebruik van dergelijke gegevens is niet voorbehouden aan het performance management; ook andere management gebieden kunnen hun voordeel doen met deze gegevens: * Performance gegevens kunnen gebruikt worden door Fault management voor het detecteren van fouten. * Performance gegevens kunnen gebruikt worden door Configuration management voor de beslissing wanneer een wijziging in de configuratie nodig is. * Performance gegevens kunnen gebruikt worden door Account management voor het bijstellen van de rekeningen (b.v. bij boete c1ausules). Security management is de verzameling van faciliteiten die de manager de mogelijkheid biedt tot het initialiseren en modificeren van functies die bijdragen tot de beveiliging van het netwerk tegen misdragingen en ongeautoriseerde toegang. Belangrijke delen van het security management zijn sleutelbeheer (voor autorisatie, encryptie en authenticatie), onderhoud van firewalls en creeren van beveiligingslogboeken. Te onderscheiden taken zijn; * het instellen van identificatie- en authenticatiemogelijkheden (distribueren, controleren van passwords of andere sleutels); * het instellen van autorisatieregels (wie mag wat); * het maken van back-ups van de gegevens over het netwerk; * het controleren van veiligheidsvoorzieningen; * het opstellen van procedures en het toezien op de naleving daarvan. Er zijn drie verschillende manieren voor het uitwisselen van managementinformatie, aangegeven in het OSI Reference Model, te weten systems management, layer management en Civility Amsterdam bv.

21



layer operation. Systems management wordt gekarakteriseerd door het feit dat applicatie protocollen zouden moeten worden gebruikt voor het uitwisselen van managementinformatie. De applicatieprotocollen zijn gebouwd op betrouwbare, connection-oriented onderliggende diensten.

De beslissing om applicatielaag protocollen te gebruiken is gebaseerd op de veronderstelling dat managementinformatie uitgewisseld moet worden volgens de zelfde methode als alle andere vormen van informatie. Vanuit dit oogpunt bekeken is het management beschouwd als een gewone applicatie aan de top van het netwerk. Voor het modelleren van de uitwisseling van managementinformatie, is het concept van Systems Management Application Entities (SMAEs) ge"introduceerd. SMAEs bevinden zich in de applicatielaag en realiseren de communicatie aspecten van de systeem managementfuncties. Zie figuur 3.3.

~

Systems management protoco

~

Application layer Presentation layer Session layer Transport layer Network layer Data link layer Physical layer

Medium

Figuur 3.3 Systems management moet gezien worden als een applicatie protocol. Hoewel systems management is gedefinieerd als de te prefereren methode voor het uitwisselen van managementinformatie, is het niet de enige methode. Het OSI Management Framework staat ook een altematief toe, bijvoorbeeld layer management, die de volgende eigenschappen bezit: * (N)-layer management ondersteunt de bewaking, controle en coordinatie van (N)-layer beheer objecten. * (N)-layer management protocollen worden ondersteund door protocollen van de laag (N-I) en lager. Het eerste item behandeld wat er beheerd wordt door het layer management, het tweede verteld ons hoe (N)-layer managementinformatie moet worden uitgewisseld. In figuur 3.4 is een voorbeeld te zien van OSI netwerk layer management-informatie, welke wordt uitgewisseld met behulp van een speciaal daarvoor bestemd layer management-protocol dat zich bevindt boven de laag waarop de normale communicatie plaats heeft. Een belangrijk verschil tussen systems management en layer management is dat systems management gebruik maakt van de presentatie dienst voor het uitwisselen van management informatie, terwijl (N)-layer management de (N-I)-diensten gebruikt. Volgens het


22



management Framework is 'het gebruik van layer management is beperkt tot die gevallen waar het gebruik van systems management niet mogelijk is'. Ret laatste type management informatie uitwisseling is de layer operation. Layer operation is gedefinieerd als 'bewaken en controle van een enkele aansluiting of request-response paar'. Bij layer operation wordt de management informatie vervoerd als een deeI van een normaal layer protocol. Net als bij (N)-layer management, gebruikt (N)-layer operation de onderliggende (N-1 )-protocollen voor het uitwisselen van managementinformatie. Special purpose layer ........ management protocol

Normal Communica.. -~ tions protocol I

Network

• •

---- -- -- --

Network

-~

-~

Medium

Figuur 3.4 Layer management ten opzichte van gewone communicatieprotocollen. OSI Systems Management Overview De definitie van de OSI Systems Management Overview (SMa) startte rend 1987. In juni 1991 was de uiteindelijke SMa tekst klaar en werd het document toegewezen voor registratie als International Standard (IS). Vergeleken met het OSI Management Framework, bevat het SMO meer informatie en is het veel beter geaccepteerd. Ret SMO bevat een verdergaande beschrijving van het systems management. Deze beschrijving maakt onderscheidt tussen de volgende aspecten: * Informatie-aspecten * Organisatie-aspecten * Functionele aspecten * Communicatie-aspecten Beheerobject operaties

meldingen

Figuur 3.5 Een beheerobject (managed object). De informatie-aspecten van het systems management model behandelen de bronnen die beheert worden. Deze bronnen worden beschouwt als beheerobject (managed objects). Volgens het OSI Management Information Model is de management kijk op een beheerobject Civility Amsterdam bv.

23



zichtbaar aan de rand van het beheerobject. Aan deze rand word de managementkijk beschreven in termen van (figuur 3.5): * Attributen, de eigenschappen ofkarakteristieken van het object. * Operaties, uitgevoerd op het object. * Gedrag, hetgeen dat voIgt als response op de operaties. * Meldingen, voortgebracht door het object.

Organisatie-aspecten, het OSI systems management kent een gecentraliseerde organisatie, een enkele manager kan de controle hebben over verschillende agenten. De manager voert taken uit op de agenten (althans op de beheerobjecten daarbinnen), de agenten geven terugmeldingen aan hun managers. Figuur 3.6 illustreert dit manager-agent concept.

Figuur 3.6 Het manager-agent concept. De OSI management omgeving mag worden onderverdeeld in een aantal management domeinen. Deze verdeling kan worden gebaseerd op functionele eisen (b.v. security, accounting en fault management), maar ook op andere eisen (b.v. geografische en technische).

Functionele aspecten, spoedig nadat de eerste working drafts van het Management Framework verschenen, startte ISO met het definieren van protocol standaarden voor elk van de vijf functionele gebieden. Na enige tijd werd er een interessante observatie gedaan, de meeste 'functionele gebieden protocollen' gebruikten een vergelijkbare set van elementaire management functies. In december 1988 werd dan ook besloten te stoppen met het verder ontwikkelen van de vijf 'functionele gebieden protocollen' en te concentreren op de elementaire management functies (figuur 3.7).

Voor 1988

Na 1988

_-----------...y ~----------_......)

\......

elementaire management functies

Figuur 3.7 Functionele gebieden en elementaire management functies.


24



De e1ementaire functies, die op een vee1 lager abstractieniveau worden gedefinieerd dan de originele functione1e gebieden, worden 'Systems Management Functions' (SMF) genoemd. Tabel 3.1 geeft een korte lijst van enke1e van deze functies. Tite1

ISO/IEC

ITU-T

Object Management Function State Management Function Attributes for representing Relationships Alarm Reporting Function Event Report Management Function Log Control Function Security Alarm Reporting Function Security Audit Trail Function Objects and Attributes for Access Control Accounting Meter Function

10164-1 10164-2 10164-3 10164-4 10164-5 10164-6 10164-7 10164-8 10164-9 10164-10

X.730 X.731 X.732 X.733 X.734 X.735 X.736 X.740 X.741 X.742

Tabel 3.1 Systems Management Functions. Communicatie-aspecten, OSI definieerde de 'Common Management Information Service' (CMIS) als de geprefereerde dienst voor de uitwisseling van managementinformatie. De rol van CMIS is beperkt tot de overdracht van managementinformatie; daadwerke1ijke controle van systemen wordt overge1aten aan de MIS-gebruikers die zich bovenop de CMIS bevinden (figuur 3.8).

-

-

MIS-user

MIS-user CMIS

Figuur 3.8 MIS-gebruiker boven op de CMIS De CMIS dienst aanbieder mag zijn opgebouwd uit verschillende delen, in dat geval verschijnen er twee of meer 'Systems Management Application Entities' (SMAEs). Deze entiteiten bevatten een aantal 'Application Service Elements' (ASEs) en gebruiken de presentatie dienst aanbieder voor het verzenden van hun data (figuur 3.9). De wisselwerking tussen SMAEs is gedefinieerd door de 'Common Management Information Protocol' (CMIP).

~ -

+-CMIS

........

~ ........ Presentation service

-

Figuur 3.9 Decompositie van CMIS.


25



Analyse De ISO-managementarchitectuur, zoals deze is vastgelegd in het 'OSI Management Framework' en de 'Systems Management Overview', laat nog steeds een aantal tekortkomingen zien. Een belangrijk probleem binnen het OSI management is het feit dat het op een andere manier de modellering principes van het OSI Reference Model, ten behoeve van communicatie, toepast. Zo overschrijdt OSI management het lagen principe, dat zegt dat gebruikers in een specifieke laag niet de interne structuur van de onderliggende dienst aanbieder (service provider) dienen te kennen. Volgens het lagen principe kunnen verschillende entiteiten aIleen interactie hebben met naastgelegen lagen via serviceprimitieven; het is niet mogelijk dat entiteiten op een andere manier zich willekeurig toegang verschaffen tot componenten op andere lagen. Voorbeeld: We beschouwen twee systemen, een is manager en de ander is agent. Het systeem dat opereert als agent is degene die gemanaged wordt; het bevat meerdere beheerobjecten voor het representeren van de bronnen die gemanaged kunnen worden. De beheerobjecten kunnen benaderd worden met een SMA£. Deze SMAE communiceert via een systeem management protocol (CMIP) met een SMAE die zich bevindt in het manager systeem. Elke laag van het OSI Reference Model kan management nodig hebben. Beheerobjecten kunnen derhalve in aIle lagen van het OSI Reference Model gevonden worden. De SMAE bevindt zich per definitie in de application layer. Volgens het OSI management kan de SMAE beheerobjecten manipuleren, onafhankelijk van de laag waarin deze objecten zich bevinden. Dit impliceert dat de SMAE kennis moet hebben van de interne structuur van de onderliggende dienst en toegang hebben tot componenten binnen deze dienst via een of ander 'magisch' interactie mechanisme. Dit is in tegenspraak met de modellering principes zo als gedefinieerd door het OSI Reference Model Een ander zwak punt binnen de OSI management benadering is dat (impliciet) de laagprotocollen die worden beheerd, ook worden gebruikt voor het uitwisselen van managementinformatie. Het probleem van deze afhankelijkheid is, de kans dat fault management onmogelijk wordt. Bijvoorbeeld, een systeem waarin de transport entiteit het plotseling begeeft. In het geval aIle andere entiteiten binnen dat systeem operationeel blijven zal de storing kunnen worden gedetectereerd door de SMAE, welke kan besluiten tot het genereren van een alarm. Dit alarm kan echter niet getransporteerd worden, door de storing binnen de transport entiteit. Naast deze twee problemen bestaan er nog andere: * Er bestaan nauwelijks oplossingen voor echte management problemen. * Het OSI management is tamelijk complex. * Tijdens het standaardisatie proces zijn er ingrijpende wijzigingen in de concepten gemaakt. * Het standaardiseren nam te veel tijd in beslag, hierdoor kregen andere benaderingen de tijd om te ontstaan. * Het aanbod van de op OSI architectuur gebaseerde systemen is beperkt en zijn duurder dan management systemen gebaseerd op andere architecturen. Civility Amsterdam bv.

26



Door deze problemen is het nog maar de vraag of OSI management de dominante markt positie zal bereiken waarop geanticipeerd was.

3.3

TMN-management

Initieel had ISO tot doel het definieren van managementstandaarden voor datacommunicatienetwerken; ontwikkeling van managementstandaarden voor telecommunicatienetwerken werd overgelaten aan de CCITT. In 1985 startte de CCITT (nu ITU-T) met de ontwikkeling van dergelijke standaarden. Oorspronkelijk waren deze recommendations zelfstandig, maar gedurende de periode 1988-1992 zijn ze herschreven om zo de ideeen van OSI management toe te voegen. Tegenwoordig worden de beide managementarchitecturen gezien als elkaars complement. De managementarchitectuur van de ITU-T staat bekend als het 'Telecommunications Management Network' (TMN). De naam van deze architectuur geeft reeds aan dat deze architectuur primair bedoeld is voor management van telecommunicatie- (b.v. telefonie) netwerken. In feite beschrijft TMN meerdere kleinere architecturen: * een functionele architectuur, * een fysieke architectuur, * een informatie-architectuur, die veel ideeen van ISO management bevat, * een architectuur van 'logische lagen' (logical layered architecture), inclusief een 'verantwoordelijkheidsmodel' (responsibility model). Zie hoofdstuk hiervoor ook 3.1. De functionele architectuur De TMN functionele architectuur is een functioneel referentiemodel. Het TMN functioneel referentiemodel is een eerste stap om tot standaarden voor uitwisseling van managementinformatie te komen. In dit model worden de plaatsen gedefinieerd waar die informatie-uitwisseling kan plaatsvinden. TMN definieert de volgende vijffunctieblokken: * Network Element Function (NEF), dit zijn de beheerfuncties die in het netwerkelement zelf aanwezig zijn, bijvoorbeeld functies voor het doen van metingen, voor het genereren van alarmen of voar het initialiseren van systeemparameters. Deze functies bevinden zich in de netwerkelementlaag.

* Operations System Function (OSF), dit zijn de beheerfuncties binnen het TMN die ruet in de netwerkelementen zelf zijn opgenomen. Voorbeelden van dergelijke functies zijn beheerfuncties voor het verzamelen van netwerkstatistieken, het berekenen van gebruikskosten en het detecteren en opheffen van storingen in het netwerk. De OSF's komen op drie lagen voor, n.l. de netwerkelement-managementlaag, de netwerkmanagement-laag en de service managementlaag.

* Mediation Function (MF), deze functies hebben als belangrijkste doel het uniformeren van de functies die NEF's zijn van een zeer elementair niveau, bijvoorbeeld wanneer er op basis van polling (hierbij vraagt de MF de NEF om gegevens) met de NEF moet worden gecommuniceerd om de toestand van de NEF te weten te komen. Een MF verricht dan de polling en levert spontane alarmmeldingen aan de bijbehorende OSF's. Andere functies van de MF zijn het concentreren (aggregeren) van informatie en het tijdelijk opslaan van informatie van de NEF. De MF is in feite een technische oplossing voor een economisch Civility Amsterdam bv.

27



probleem. Wanneer we namelijk bij zeer eenvoudige netwerkelementen zouden eisen dat deze in staat moeten zijn om spontane meldingen te kunnen genereren en in staat moeten zijn om informatie voor langere tijd vast te houden, dan betekent dit een relatief grote management overhead. Daarom worden deze functies door een MF verricht ten behoeve van een groep NEF's.

* Work Station Function (WSF), dit zijn de functies die de interactie tussen de beheerfuncties (OSF's) en de gebruiker verzorgen. Enerzijds wordt beheerinformatie die de OSF's opleveren geYnterpreteerd en gepresenteerd aan de gebruiker van het TMN. Anderzijds wordt invoer van de gebruiker aangenomen en doorgegeven aan de betreffende OSF's.

* Q Adaptor Function

(QAF), dit zijn de functies die de interactie tussen het TMN en die entiteiten verzorgt die niet de standaard TMN referentiepunten ondersteunen.

De functieblokken wisselen informatie met elkaar uit. Referentiepunten zijn de plaatsen waar de functieblokken met elkaar communiceren. Ze worden aangegeven met een kleine letter (f, g, m, q of x). De naam van een referentie punt wordt bepaald door de plaats waar deze zich bevindt, dat wil zeggen, afhankelijk van het type functieblok waartussen het referentiepunt zich bevindt. De fysieke architectuur De TMN fysieke architectuur is afgeleid van het TMN functioneel referentiemodel. In deze fysieke architectuur worden gekoppelde systemen gedefinieerd. De grenzen van de systemen worden bepaald door de referentiepunten uit het TMN functioneel referentiemodel. Voor elk functieblok bestaat er een fysieke bouwsteen dat de betreffende functie implementeert en voor elk referentiepunt bestaat er een interface. De informatie architectuur De TMN informatie architectuur beschrijft de principes die gehanteerd moeten worden bij de uitwisseling van informatie tussen de functieblokken die in de functionele architectuur zijn gedefinieerd. Daarbij komt aan de orde welke technieken er gebruikt moeten worden om de informatie uitwisseling te specificeren. Er worden technieken en methoden gebruikt die door ISO in de OSI-standaarden zijn gedefinieerd. Een administratie zal bij het ontwerpen van de beheerinfrastructuur eerst een ingevulde functionele architectuur specificeren waarin duidelijk is aangegeven welke groepen van functies er in de beheerinfrastructuur bestaan en met welke andere groepen van functies zij informatie uitwisselen. Een beschrijving van de functies in de functieblokken maakt daar onderdeel van uit. De informatie architectuur beschrijft hoe informatie tussen twee functieblokken wordt uitgewisseld. De informatie-uitwisseling tussen twee functieblokken bestaat uit drie groepen operaties. Ons verplaatsend in de positie van een van de functieblokken moet het volgende mogelijk zijn: * het instellen en opvragen van gegevens; * het geven van opdrachten voor het uitvoeren van processen; * het ontvangen van spontane meldingen. Analyse De huidige TMN architectuur, in het bijzonder de TMN information architecture, bevatten veeI ideeen van OSI systemen management. Daardoor is de analyse gegeven in het vorige hoofdstuk over OSI management voor een groot deel ook van toepassing op dit hoofdstuk. Civility Amsterdam bv.

28



Ondanks de grote overeenkomst tussen TMN en OSI management zijn er ook enkele verschillen. De TMN management architectuur is onderverdeeld in verschillende abstractielagen. De functionele architectuur laat de verschillende TMN management functies zien en de fysieke architectuur laat zien hoe deze functies ge'implementeerd kunnen worden met fysieke bouwstenen. TMN voorziet in een structuur voor meerdere niveaus van verantwoordelijkheid zoals die ook bestaan in reele netwerken (zie ook hoofdstuk 3.1 in bijzonder figuur 3.2). Het voordeel van een dergelijke structuur is dat het makkelijker wordt de verschillende management verantwoordelijkheden te begrijpen en onderscheiden. In tegenstelling tot de OSI management standaarden, bevat recommendation M.3010 (TMN) geen apart deel dat duidelijk definieert wat de hoofd architecturele concepten (zoals, functieblok, referentie punt, bouwsteen en interface) zijn. Voor het begrijpen van deze concepten moeten de ideeen daar achter afgeleid worden van de diverse stukjes tekst die deze concepten noemen. Op deze manier kan een concept op verschillend wijze ge'interpreteerd worden naar gelang het gelezen stukje tekst.

3.4

Internet Management

Terug kijkend op de laatste tienjaar kan geconcludeerd worden dat de groei van het Internet een doorslaggevende rol heeft gespeeld in de ontwikkeling van netwerkmanagement protocollen. In eerste instantie probeerde het Internet Architecture Board (lAB) de OSI management benadering toe te passen, maar tegen de tijd dat het Internet een grootte bereikte waarbij beheersing onontkoombaar was, waren OSI management groepen nog immer bezig met het discussieren over het 'OSI Management Framework'. Om de korte termijn managementproblemen van het Internet het hoofd te kunnen bieden, heeft de The Internet Engineering Task Force (lETF), op verzoek van het lAB, in 1988 het 'Simple Network Management Protocol' (SNMP) gedefinieerd. De volgende basisprincipes liggen achter het Internet management: * alle systemen aangesloten op het netwerk moeten beheert kunnen worden met SNMP; * de kosten voor het toevoegen van netwerkmanagement aan bestaande systemen moeten minimaal zijn; * het moet relatief eenvoudig zijn om de management mogelijkheden van bestaande systemen uit te breiden (uitbreiden van de Management Information Base, MIB); * netwerkmanagement moet robuust zijn. Zelfs in het geval van storingen. Moet een klein deel van de management mogelijkheden beschikbaar blijven. Het originele SNMP protocol De ideeen achter het SNMP zijn relatief 'rechttoe rechtaan' en eenvoudig te begrijpen. In feite, is er weinig verschil tussen de ideeen achter SNMP en de ideeen die bestonden bij ISO rond 1987.

Bij SNMP kan een manager de controle hebben over meerdere agenten. Het SNMP protocol is geplaatst bovenop het User Datagram Protocol (UDP), dat een connectionless transport Civility Amsterdam bv.

29



protocol is, zie figuur 3.10. Daar zowel de Internet managementinformatie als de formaten van de SNMP PDU's gedefinieerd zijn volgens de ASN.1 syntact, zijn codeer functies nodig direct boven de UDP laag. Deze functies handelen volgens de Basic Encoding Rules (BER). Vijftypen SNMP POU's zijn gedefinieerd: GetRequest, GetNextRequest, SetRequest, Respose en Trap. De SNMP protocol standaard stuurt niet de functies die specifiek voor de managers of de agenten zijn aan; de SNMP standaard is dus beperkt tot de functies onder de gestreepte lijn, zie figuur 3.10. Dit houdt in dat de scoop van SNMP gelijk is aan die van CMIP (Common Management Information Protocol); zoals voorgesteld voor CMIP bestaat er, ook hier, geen standaard die diensten definieert bovenop de SNMP laag. manager

SNMP

UDP

Figuur 3.10 De Internet management structuur. De keuze om SNMP uit te voeren over het connectionless UDP heeft meerdere gevolgen. In de eerste plaats is UDP onbetrouwbaar, dat betekent dat gegevens van de gebruiker (user data) kwijt kan raken. De beslissing om een onbetrouwbare transport dienst te gebruiken is met opzet genomen. De reden is dat in het geval van herhaalde transportstoringen, het nog mogelijk is om een deel van de managementinformatie uit te wisselen. Met een betrouwbare (connection-oriented) dienst was dit niet mogelijk geweest. Connection-oriented diensten zijn ontworpen volgens een 'alles of niets' benadering: of aIle data wordt afgeleverd of helemaal niets. Als er geen data afgeleverd kan worden, wordt de verbinding vrijgegeven. Connectionless diensten zijn ontworpen volgens een 'uiterste inspanning' benadering: zelfs als er storingen optreden kan er data arriveren bij de bestemming. Management kan zodoende nog steeds mogelijk zijn, echter weI op een beperkte manier. Het is interessant om te zien dat het SNMP protocol zelf geen hertransmissies uitvoert. De verantwoordelijkheid voor het detecteren van dataverlies en het initieren van hertransmissie wordt overgelaten aan de manager, omdat wordt aangenomen dat de managers in het algemeen beter uitgerust zijn om te bepalen of en wanneer hertransmissie nodig is. Een tweede gevolg van het gebruik van een connectionless transport, is dat managers een soort van polling, om te detecteren of agenten nog operationeel zijn, moeten uitvoeren. Bij connection-oriented diensten (b.v. OSI's presentatie service) was dit niet nodig geweest, omdat die diensten al 'levensduur controle functies' in zich heeft. Dergelijke functies controleren periodiek, op afstand, of de systemen (hier de agenten) nog operationeel zijn. Ais ze down zijn, zal de dienst initiatieven moeten nemen voor het vrijgeven van de verbindingen en het informeren van de gebruiker (hier de manager). Civility Amsterdam bv.

30



Een karakteristieke eigenschap van UDP is dat pakketen niet een bepaalde grootte kan overschrijden. am zeker te zijn dat aIleen pakketen van een gelimiteerde grootte worden gegenereerd, zijn in het SNMP protocol meerdere rege1s geformuleerd. Een van deze regels zegt dat, als de response op een bepaalde SNMP request de maximum pakketgrootte overschrijdt, geen informatie teruggestuurd wordt. Managers moeten op de hoogte zijn van deze regel en in plaats van een allesomvattende request, moeten meerdere kleine requests gebruikt worden voor het beetje bij beetje binnen halen van de informatie. Jarnmergenoeg is het voor de managers in veel gevallen niet mogelijk de hoeveelheid informatie, die vrijkomt bij een request, te bepalen. Hoewe1 SNMP bedoeld is om te werken over UDP, zijn er ook RFC's die definieren hoe werking van SNMP boven op andere protocollen (b.v. Ethernet, IPX of zelfs OSI) mogelijk is. In SNMP wordt communicatie van de manager naar het agent systeem uitgevoerd met bevestigingen. De SNMP entiteit aan de kant van de manager neemt het initiatief bij het sturen van de volgende PDU's: GetRequest, GetNextRequest ofSetRequest. De GetRequest en GetNextRequest worden gebruikt voor het verkrijgen van managementinformatie van de agent, de SetRequest wordt gebruikt voor het opslaan (of veranderen) managementinformatie. Na ontvangst van een van de PDU's komt de SNMP entiteit aan de agent kant met een response PDU, zie figuur 3.11. Deze PDU bevat de gevraagde informatie of een foutindicatie van de vorige request.

manager side GetRequest

agent side

.. .. . ...

GetNextRequest

"

'

"

"

agent side

manager side

SetRequest

. .. .. .

.. ...

response

"

manager side

response

agent side

... . .. ... . . "

response

Figuur 3.11 De manager neemt het initiatief. Het is ook mogelijk dat de SNMP entiteit aan de kant van de agent het initiatief neemt. Dit gebeurt in het geval dat de agent een buitengewone gebeurtenis waarneemt, bijvoorbeeld een status verandering van een link. Ais reactie daarop zendt de SNMP entiteit van de agent een Trap PDU naar het managementsysteem (Traps zijn vergelijkbaar met de OSI Event-Reports). De ontvangst van een Trap wordt niet bevestigd, zie figuur 3.12. manager side

agent side

. - .".. ."~ Trap

Figuur 3.12 De agent neemt het initiatief. Civility Amsterdam bv.

31



SNMP beschrijft niet hoe de verschillende Get, Set en Trap interacties aan elkaar moeten worden gerelateerd. Wat er bijvoorbeeld moet gebeuren na de ontvangst van een Trap is niet gedefinieerd door SNMP. In plaats daarvan wordt de uitkomst van deze relatie beschouwt als een verantwoordelijkheid van de specifieke manager functies. SNMPv2 Sinds de publicatie van het originele SNMP protocol zijn er verschillende protocollen gepresenteerd ter verbetering van SNMP. In 1992 werd besloten deze voorstellen te verzamelen en daarmee een nieuwe standaard te maken: SNMPv2. De belangrijkste uitkomsten van SNMPv2 zijn een verbetering in de performance, de beveiliging en de mogelijkheid om een hierarchie in de managementstructuur aan te brengen.

Voor het verbeteren van de performance heeft SNMPv2 de GetBulk PDU gerntroduceerd. in tegenstelling tot de Get en GetNext request, bevat de response op de GetBulk altijd zo veel informatie als mogelijk. Ais de gevraagde informatie de maximum UDP pakketgrootte overschrijdt, wordt de informatie afgebroken en alleen het deeI dat in het pakket past teruggestuurd. Ret originele SNMP protocol bezat, naast een eenvoudig mechanisme voor de uitwisseling van paswoorden, geen beveiligingsopties. Om deze zwakte te verhelpen introduceert SNMPv2 een volledig dekkend beveiligingsmechanisme. Dit beveiligingsmechanisme is gebaseerd op het gebruik van 'parties' en 'contexts '; twee concepten die niet in andere management benaderingen terug te vinden zijn, zie ook figuur 3.13.

MIB

UDP

Figuur 3.13

Parties en contexts.

Parties, vertonen enige overeenkomst met protocol entltelten. Ret is gebruikelijk dat er meerdere parties actief zijn in een SNMPv2 subsysteem en dat deze parties verschillend geconfigureerd zijn. Zo kan een party communiceren met alle andere parties, een bepaalde groep parties of met slechts een andere party. Voor de toegangsbeveiliging van verschillende delen van een MIB heeft SNMPv2 het contexts concept gerntroduceerd. Elke context wijst naar een specifiek deel van een MIB, deze Civility Amsterdam bv.

32



delen mogen elkaar ook overlappen. Met behulp van een Access Control List (ACL) wordt bepaald welke party in welke context wat mag doen (Get en/of Set request). Hierarchie in de managementstructuur. Praktijkervaring met het originele SNMP protocol leerde dat in veel gevallen managers niet bij machtte waren om meer dan een paar honderd agent systemen te managen. De oorzaak van deze restrictie ligt in de polling methode van SNMP: de manager moet periodiek elk systeem pollen dat onder zijn controle valt, dit kost tijd. Voor de oplossing van dit probleem introduceert SNMPv2 het idee van Intermediate Level Managers (ILM). Het pollen wordt nu gedaan door een aantal van dergelijke ILM's onder de controle van de Top Level Manager (TLM), zie figuur 3.14. TML = Top Level Manager IML = Intermediate Level Manager A=Agent

Figuur 3.14 Intermediate Level Managers. Voordat de Intermediate Level Managers (ILM's) starten met pollen, vertelt de Top Level Manager de ILM's welke variabelen bij welke agenten gepold dienen te worden. Daarnaast vertelt de Top Level Manager de ILM's over welke events deze geYnformeerd wil worden. Nadat de ILM's geconfigureerd zijn, starten ze met pollen. Als een ILM een event detecteert bij een specifieke agent waarover de TLM geYnformeerd wenst te worden, wordt een speciale Inform PDU gegenereerd. Na de ontvangst van deze PDU gaat de TLM direct acties uitvoeren op de agent die de event veroorzaakte, zie ook figuur 3.14. Management Information Base (MIB) Voor het identificeren van alle variabelen die gemanaged kunnen worden, is een groot aantal Management Information Base (MIB) standaarden ontwikkelt. Naast deze standaarden, bestaat een speciale standaard die definieert hoe men MIB variabelen moet omschrijven. Deze standaard wordt de Structure of Management Information (SMI) genoemd.

Voor het zeker stellen van een unieke identificatie van elke managementvariabele, introduceert de SMI het concept van een naamboom. De bladeren van deze boom representeren de daadwerkelijke managementinformatie. Een voorbeeld hiervan is afgebeeld in figuur 3.15; in dit figuur is de objectidentiteit van het 'networkaddress' root.}.}, de objectidentiteit van de 'collision counter' is root.2.2 en de identiteit van de 'token holding timer' is root. 3.4. De MIB-II is de belangrijkste en waarschijnlijk meest bekende MIB; het bevat alle variabelen voor het beheren van de grote Internet protocollen (b.v. IP, ICMP, UDP, TCP, EGP en Civility Amsterdam bv.

33



SNMP). De structuur van deze MIB is eenvoudig: alle managementvariabelen behorende bij hetzelfde protocol worden gegroepeerd (zie figuur 3.16). Binnen een protocolgroep bestaat er nauwelijks een additionele structuur die helpt bij het begrijpen van de verschillende variabelen binnen die groep. root

1~1 /

network address

""

!

/

1~3 I

collision counter

3

~

~s

~/

I

"'-----token holding timer

Figuur 3.15 Concept van de naamboom. Naast de gestandaardiseerde MIBs bestaat een groot aantal ontwerper specifieke MIBs. Samen definieren dit soort MIBs meer dan twintigduizend managementvariabelen! Helaas is er geen heldere structuur ontwikkeld die de relatie verklaart tussen die MIBs; de enige indicatie van het doel van een MIB is zijn naam. MIB-II

TRANSMISSION (10) INTERFACES (2)

IP (4)

TCP (6)

EGP(8)

SNMP (11)

Figuur 3.16 De verschillende protocolgroepen van de MIB-II.

Analyse Daar Internet management vergeleken kan worden met OSI management, SNMP gebruikt de ideeen die bij OSI rond 1987 bestonden, zijn de opmerkingen die gemaakt werden bij de analyse van OSI ook hier geldig. In tegenstelling tot OSI, echter, gebruikt Internet management slechts een klein deel van de managementfuncties voor het uitwisselen van informatie. Hierdoor zijn problemen met fault management minder waarschijnlijk. Er zijn geen standaarden geproduceerd die de Internet managementarchitectuur definieren. Voor het begrijpen van de architecturele concepten achter Internet management, moet de bedoeling van de verschillende concepten uit de protocol standaarden afgeleid worden. Dit zal weinig problemen opleveren voor de originele SNMP versie, maar duidelijk weI voor de SNMPv2 versie. Ervaringen laten zien dat zonder een goed begrip van deze concepten de implementatie van SNMPv2 erg lastig is. Door het definieren van duizenden managementvariabelen, is het gebrek aan een goede functionele structuur voor het classificeren van deze variabelen een probleem geworden. Civility Amsterdam bv.

34



Zonder zo een structuur zullen managers worden geconfronteerd met een grote lijst van managementvariabelen. Voor het bepalen, welke variabelen in de gaten gehouden moeten worden en welke aanpassingen nodig zijn, moeten managers een duidelijk begrip hebben van de precieze bedoeling van veel variabelen. Wanneer het management wordt uitgevoerd door mensen, is het onwaarschijnlijk dat er veel mensen zijn met voldoende kennis aan boord. Ais consequentie kan verwacht worden dat managers veel tijd nodig hebben alvorens ze beslissen wat er moet gebeuren. Netwerkmanagement kan daardoor een tijd verslindende en daarmee erg dure activiteit worden.

3.5 Generieke Conclusies Netwerkmanagement heeft tot taak de werking van communicatienetwerken te controleren en te verbeteren, alsmede het netwerk aan te passen in het geval de eisen van de netwerkgebruikers veranderen. Management betreft het initialiseren, observeren en modificeren van de 'normale' netwerkfuncties. Voor het verrichten van management zijn speciale functies nodig, zogenaamde 'managementfuncties'. Netwerkmanagementarchitecturen bieden de mogelijkheid voor het op een hoog abstractieniveau beschouwen en ontwikkelen van managementdiensten en -protocollen. Alle bestaande managementarchitecturen, dus ook die van de ISO (met OSI), ITU-T voorheen CCITT (met TMN) en de IETF (met SNMP), zijn ontwikkeld nadat het ontwerp van de normale netwerkfuncties was afgerond. Een dergelijke aanpak getuigt van een specifieke zienswijze betreffende de rol van management en nodigt uit tot het toepassen van verschillende architectureIe concepten voor het ontwerp van normale netwerkfuncties enerzijds en het ontwerp van managementfuncties anderzijds. Dit leidt tot inconsistentie in de architecturen waardoor een meervoudige uitleg voor de diverse basisideeen mogelijk is. Dit wordt nog eens versterkt door het feit dat de hoofdconcepten, bij TMN en SNMP, nauwelijks zijn gedocumenteerd. Hierdoor is het opzetten van een generiek netwerkmanagementsysteem een zeer lastige aangelegenheid. TMN voorziet in een structuur voor meerdere niveaus van verantwoordelijkheid zoals die ook bestaan in reele netwerken. Het voordeel van een dergelijke structuur is dat het makkelijker wordt de verschillende management verantwoordelijkheden te begrijpen en onderscheiden. Voor complexe (tele-)communicatienetwerken is TMN wellicht een goede oplossing, zeker nu er oplossingen gebaseerd op TMN beschikbaar komen. Het 'simpele' van SNMP verdwijnt steeds meer en daarmee groeit SNMP uit tot een volwassen managementarchitectuur. Daarnaast wordt SNMP heden ten dagen dermate wijdverbreid toegepast, dat netwerkmanagement zonder gebruik van SNMP gegevens nauwelijks mogelijk wordt geacht. De verschillende managementarchitecturen groeien naar elkaar toe, de TMN en de OSI managementarchitecturen kunnen tegenwoordig worden gezien als elkaars complement.


35



Bij het ontwikkelen van een nieuwe generatie managementarchitectuur moet getracht worden, naast het herbergen van de normale netwerkfuncties, in het ontwerp plan ook de functies voor management en beveiliging op te nemen. Door het steeds verder integreren van data- met telecommunicatienetwerken ontstaan heterogene netwerken die met een architectuur moeten worden beheert. Hierdoor moet de architectuur een zeer brede opzet hebben, veel verschillende protocollen, systemen en gegevensvormen dienen ondersteund te worden. Waarmee een scala aan managementinformatiesoorten en -niveaus (van probleem- tot bedrijfsgericht) etc. moet worden bediend.


36



H4

Ontwikkelen van Bestuurlijke Informatiesystemen

4.1

Het ontwerpen van een Informatiesysteem

Inleiding Om tot een effectieve oplossing te komen voor het rapportage probleem worden hier mogelijke (ontwikkel)strategieen en randvoorwaarden behandeld waaraan voldaan moet worden bij het ontwikkelen van (rapporterende) Informatiesystemen (IS). In hoofdstuk 4 wordt respectievelijk behandeld wat de doelen, de eisen, de ontwikkel stappen, de gevolgen en het beheer van een informatiesysteem zijn.

Het te ontwikkelen informatiesysteem moet de performance van de geleverde diensten (bijv. het GDA) inzichtelijk maken en daarover aan de klanten (maar ook, de opdrachtgever en verantwoordelijken binnen Civility zoals de Service level manager en de Facilties Manager) te rapporteren. Zo een systeem is onderdeel van het bestuurlijke aspect van geautomatiseerde werkpleksystemen [30]. Dat aspect kan men verdelen in drie afzonderlijke delen, te weten: * een bestuurd systeem, zijnde het deelsysteem dat moet worden bestuurd; * een besturend orgaan, zijnde de persoon of groep personen die stuurt. Terzijde zij opgemerkt dat ook een machine besturend orgaan kan zijn; * een bestuurlijk informatiesysteem, zijnde het deelsysteem dat op grand van gegevens van het bestuurde systeem zelf (interne gegevens) of van gegevens over de omgeving (externe gegevens) informatie vastlegt en praduceert voor het besturend orgaan. Een en ander is weergegeven in figuur 4.1 onder de term besturingsparadigma. Omgeving Extern gegeven

Besturend orgaan

Output

Informatiesysteem

Interne gegevens

Bestuurd systeem

Figuur 4.1 Het besturingsparadigma, samenhang tussen besturend orgaan, bestuurd en inforrnatiesysteem. Zoals uit figuur 4.1 naar voren komt, staat het beschouwde beslissingssysteem in interactie met een omgeving. Men spreekt daarom van een open systeem.


37



Elk van de genoemde deelsystemen kan men in eerste instantie weergeven worden als een black box met input en output, in het schema weergegevens door pijlen. Zo zijn input voor het bestuurlijk informatiesysteem: * externe gegevens: gegevens over de omgeving, voor zover die relevant zijn voor het besturend orgaan; * interne gegevens: gegevens over de toestand van het bestuurde systeem op de diverse tijdstippen. Het bestuurlijke informatiesysteem heeft tot taak de relevante interne en externe gegevens vast te leggen, op te slaan en te verwerken tot bestuurlijke informatie voor het besturend orgaan. De output van het bestuurlijke informatiesysteem is derhalve bestuurlijke informatie. Het informatiesysteem omvat het geheel van methoden, faciliteiten en activiteiten waarmee een organisatie in haar informatiebehoeften tracht te voorzien. Onder methoden vallen o.a. procedures en werkvoorschriften met betrekking tot het vergaren bewerken en verstrekken van gegevens. De term 'faciliteiten' duidt op hulpmiddelen die bij het informatieproces worden ingeschakeld, waaronder o.a. personeel en de materiele en financiele middelen. 'Activiteiten' zijn al die werkzaamheden die tot doel hebben gegevens te transformeren tot informatie. Bestuurlijke informatie is, zoals uit figuur 4.1 blijkt, op zijn beurt weer input voor het besturend orgaan, dat o.a. op grond daarvan beslissingen neemt. Dergelijke beslissingen worden omgezet in stuuracties, die zich als output van het besturend orgaan manifesteren. Tot slot de input en output van het bestuurd systeem. Input van een bestuurd systeem kunnen zijn, ten eerste, externe invloeden vanuit de omgeving, die niet door het besturend orgaan worden beheerst. Deze invloeden kan men representeren door irreguliere variabelen, bijvoorbeeld een calamiteit. Ten tweede, acties die kunnen worden gerepresenteerd door stuurvariabelen, bijvoorbeeld in te zetten personeel en materieel. De output van een bestuurd systeem kan vele vormen aannemen. In het geval van Civility zal de output bestaan uit geleverde (automatiserings-)diensten aan de deelnemers. Die klanten worden opnieuw aangeduid met de algemene term 'omgeving'. Om nu een bestuurlijk informatiesysteem te ontwerpen zal men allereerst zo scherp mogelijk moeten ajbakenen wat bestuurd systeem is, welke omgeving daarbij geldt en wie besturend orgaan is (i.e. afbakening systeemgrenzen).

Kijkt men in algemene zin naar een besturend orgaan, dan ligt het voor de hand dat dit orgaan informatie wil hebben over: * de relevante invloeden van buiten af (irreguliere variabelen); * de stuurmogelijkheden (stuurvariabelen) en de mogelijke consequenties daarvan; * de toestand van het bestuurde systeem en de geproduceerde output van het bestuurde systeem. Vanzelfsprekend zal een besturend orgaan behoefte hebben aan informatie over de mate waarin bepaalde doelstellingen zijn bereikt (rapportage). Daarbij zal men tevens ge'informeerd willen worden over de effectiviteit van genomen beslissingen, met andere woorden over de samenhang tussen (stuur)acties enerzijds en het realiseren van bepaalde waarden van de doelvariabelen anderzijds.


38



Heeft een ontwerper het voorgaande zo goed mogelijk gemodelleerd, dan kan hij dat model nog gaan verfijnen door zich af te vragen welk soort ondersteuning een besturend orgaan in het bijzonder wil hebben van een informatiesysteem. Een van die verfijningsmogelijkheden is het onderkennen van verschillende fasen in de besluitvorming. Er worden in dit verband de volgende fasen onderkend [30]: 1. een verkennende fase (intelligence); 2. een probleemformulerende fase (design); 3. een probleemoplossende fase (choice). Strategiebepaling en informatieplanning Het is, in het algemeen, geen uitzondering dat het business management met een voortdurende stroom van investeringsvoorstellen wordt geconfronteerd voor telkenmale kleine stukjes hardware en 'harde' systeemprogrammatuur, zonder dat duidelijk wordt gemaakt in welk totaalbeeld een en ander past of zou moeten passen. Om nu verlost te worden van dit soort ad hoc-beslissingen en -procedures streeft het management terecht naar een informatiebeleid enplan, met het doel automatisering qua investeringsbeslissingen inzichtelijk en beheersbaar te maken.

Vele organisaties hebben reeds zonder veel resultaat geprobeerd een goede informatiestrategie te bepalen. In vele gevallen bleek de poging zelfs contra-produktief. Er lag weliswaar een fraai en vooral dik strategierapport, maar niemand in de organisatie wist hoe het nu verder moest. Uit een onderzoek [30], waarbij (informatie)managers werd gevraagd naar hun ervaringen met informatiestrategieen, kwamen de volgende drie clusters vanfaalfactoren naar voren: 1. methodische aspecten 2. procesmatige aspecten 3. implementatie-aspecten Onder methodische faalfactoren vallen zaken als gebrek aan strategisch denken, te veel intern gerichte aandacht, overmatige of juist te geringe aandacht voor architecturen, te lange doorlooptijd en te hoge kosten en inspanningen voor het planproces, en tot slot ineffectieve allocatiemechanismen en prioriteitenstellingen. Procesmatige faalfactoren zijn o.a. te lage betrokkenheid van het management, slechte verhoudingen tussen automatiseringsspecialisten en gebruikers, lage awareness bij gebruikers en lijnmanagers. Implementatie-aspecten van mislukkingen zijn vooral het onvermogen om een strategisch plan om te zetten in actie en het te lage budget (en dus de te lage prioriteit) voor uitvoering. Gevolg: grote delen van een strategisch plan blijven fraaie voomemens op papier, maar frustreren de betrokkenen die op uitvoering wachten.

Uit de opgesomde faalfactoren is min of meer af te leiden wat de meest cruciale succesfactoren zijn. Gevraagd naar die succesfactoren antwoordden de ondervraagden in volgorde van belangrijkheid: 1. betrokkenheid van het topmanagement 2. ondersteuning van het topmanagement 3. reeds bestaan van een algemene bedrijfsstrategie 4. eerst analyseren van de organisatie en pas daarna automatiseren 5. een goed 'Information Systems Management'. Civility Amsterdam bv.

39



In de klassieke aanpak is de strategiebepaling gericht op, een volledige inventarisatie van bedrijfsprocessen en de bijbehorende informatievoorziening. Ret vervolgens bloodeggen van lacunes en tekortkomingen in die informatievoorziening, om tot slot te komen tot een prioriteitenstelling welke toepassingen eerst en welke pas later aangepakt moeten worden. Een andere benadering van Informatiesysteem (IS)-strategieformulering is de assessmentmethode. Kern van die methode is dat men de belangrijkste informatiesystemen binnen een organisatie in kaart brengt en doorlicht naar een aantal aspecten. Doorgaans licht men de diverse informatiesystemen door naar de volgende aspecten, het strategisch belang, 'state of the art' qua technologie, flexibiliteit, aanpasbaarheid, doelmatigheid, kwaliteit van informatie, tijdigheid van informatie, etc. Sterke punten van de assessment-aanpak zijn het direct op het doel afstevenen (ni. een kritische evaluatie van informatiesystemen waarbij de uitvoerige proces- en organisatieanalyses, zoals bij de klassieke methode, achterwege blijven) en de makkelijke hanteerbaarheid van de methode. Een zwak punt blijft, evenals bij de klassieke methoden, het overmatige accent op aIleen toepassingen, zonder oog voor de noodzakelijke infrastructuur op basis waarvan zich die toepassingen kunnen ontwikkelen. Een bijzondere vorm van een IS-strategieformulering kent de Rijksoverheid door middel van informatie-structuurschetsen per ministerie of per gebied van zorg. Achtergrond van structuurschetsen is de constatering dat vele overheids- en particuliere organisaties verplicht zijn informatie van elkaar te betrekken of aan elkaar te leveren. Kenmerk van deze interbestuurlijke gegevensuitwisseling is dat er geen eenduidig bevoegd gezag is. Er zijn weliswaar vele partijen in het spel, maar geen van die partijen heeft het formele gezag om voor te schrijven waar, wanneer en hoe welke gegevens worden uitgewisseld van wie en naar wie. Een structuurschets brengt nu die partijen in kaart, alsmede de gegevensstromen tussen die partijen. Tevens worden knelpunten en problemen gesignaleerd en adviezen voor oplossingsrichtingen. Grote voordelen van structuurschetsen t.o.v. andere strategiemethoden zijn, de sterke nadruk op het ervaringsfeit dat informatiesystemen veelal communicatiesystemen zijn of worden. Ret groeiende inzicht dat ook informatiesystemen binnen allerlei organisaties of afdelingen dan en slechts dan kunnen 'opbloeien' wanneer ze kunnen voortbouwen op een infrastructuur aan basisregistraties. In modernere methoden voor strategieformulering en -planning ZlJn infrastructuren het belangrijkste object van analyse aanbevelingen, namelijk: * de technische infrastructuur * de infrastructuur van gegevens en kennis * de infrastructuur van applicaties * de infrastructuur van organisatorische inrichting en bemanning van de informatiefunctie. Methodiek en methoden Ontwikkelen van specifieke systemen, meestal toepassingen ofwel applicaties, betekent in dit kader het inventariseren, analyseren, ontwerpen, bouwen, testen en invoeren van een systeem. Civility Amsterdam bv.

40



Indien men besluit geen maatwerksoftware te maken maar standaardsoftware te kopen, dan vervallen de activiteiten 'bouwen' en 'testen' in de voorgaande opsomming en worden deze vervangen door inventariseren, selecteren en aanschaffen van een standaardsysteem. Een bestuurlijk informatiesysteem wordt niet omwille van zichzelf opgezet, maar heeft betrekking op een bepaalde besturingssituatie. Wil men nu een informatiesysteem opzetten dat daarvoor relevante informatie produceert, dan zal men eerst een informatiemodel van de besturingssituatie moeten opstellen. Hoe beter dit model, hoe beter op basis daarvan een informatiesysteem ontwikkeld kan worden. Het ontwikkelen van een informatiesysteem is in belangrijke mate een kwestie van modelleren. Dat modelleren gebeurt in parallelle en successievelijke werkstappen. Om dat in beeld te brengen gebruiken we het schema gegeven in figuur 4.2. In de systeemleer is het gebruikelijk de werkelijkheid te modelleren in termen van objecten en relaties tussen die objecten. 20 een model is nooit een volledige beschrijving van de werkelijkheid maar steeds een abstractie naar een bepaald gezichtspunt. Welke abstractie men kiest is niet een gegeven van buiten af, maar is een expliciete keuze van de modelbouwer zelf. Eerste stap in de ontwikkeling van een informatiesysteem is de afbakening en analyse van het objectensysteem. Doel daarvan is het opbouwen van een goed begrip hoe dat objectensysteem in elkaar zit en werkt. Heeft men dat begrip eenmaal, dan voIgt een eerste afbakening en analyse welk informatiesysteem relevant kan zijn als weergave van dat objectsysteem. Aldus ontstaat er een beeld van welke informatiedeelsystemen gewenst zijn en in welke prioriteitsvolgorde die systemen ontwikkeld moeten worden. Het deelsysteem, dat qua prioriteit het eerst moet worden aangepast, is vervolgens object van een vervolgstudie. Deze vervolgstudie start met functionele decompositie conform het principe van top-down-decompositie. Toestandsruimte, actie- en reactieruimte worden per informatiecomponent beschreven, alsmede transistierelatie en herkomst en bestemming van de gegevens. Een en ander is in figuur 4.2 aangeduid met de termen 'globale procesanalyse' en 'globale gegevensanalyse'. Daarnaast is het van belang een eerste analyse uit te voeren met betrekking tot de relevante kwaliteitseisen. Resultaat van het voorgaande is successievelijk: * een procesmodel * een gegevensmodel * een kwaliteitseisenmodel. De drie genoemde modellen dienen verder uitgewerkt en gespecificeerd te worden in nieuwe werkstappen. Schematisch is dat weergegeven in figuur 4.2. Hoofdstappen zijn achtereenvolgens; logisch ontwerp, technisch ontwerp, bouw, testen, conversie en invoering en tot slot evaluatie en onderhoud. Het eerste globale procesmodel wordt in de successieve hoofdstappen meer en meer uitgewerkt en verftind, totdat daar uiteindelijk schetsen voor computerprogramma's en procedures uit voortvloeien. Na bouwen en testen resulteert dit in objectcode (geteste computerprogramma's) en geteste procedurebeschrijvingen voor het handmatige deel van de gegevensverwerking.


41



Atbakening en analyse objectsysteem

Globale procesanalyse

Globale gegevensanalyse

Gegevensmodel

Procesmodel

Detail procesanalyse

Detail gegevensanalyse

Detailmodel processen

Detailmodel gegevens

Analyse programma's en procedures

Programma- en proceduremodel

Databasemodel

Testen Programmatest, databasetest, systeemtest en acceptatietest

Figuur 4.2 Objectsysteemanalyse, functionele decompositie en successieve hoofdstappen bij systeemontwikkeling. Civility Amsterdam bv.

42


Structureren van IT-beheer met ITlL, ontwikkeling van een Service Level Rapportage systeem met SDM

Het globale gegevensmodel wordt eveneens meer en meer verfijnd tot een implementeerbaar datamodel. Vervolgens wordt nagegaan of het betreffende datamodel kan terugvallen op de reeds aanwezige infrastructuur van data- en kennisbanken of dat nieuwe banken opgezet moeten worden (databasemodellering). Uiteindelijk komt er ofwel een aansluiting op de reeds aanwezige fysieke data- en kennisbanken, ofwel men besluit tot het invoeren van compleet nieuwe banken. In figuur 4.2 wordt in dit kader alleen gesproken van databases, waarmee zowel databanken als kennisbanken worden bedoeld. Is ook documentaire informatievoorziening onderdeel van het informatiesysteem in kwestie, dan zijn ook de documentbanken 'databases' in algemene zin. Tot slot de verdere verfijning van de kwaliteitseisen. Uit figuur 4.2 komt naar voren dat ook die in de successieve hoofdstappen onderwerp van nadere studie blijven, totdat er uiteindelijk een fysiek werkend informatiesysteem gebouwd moet worden dat voldoet aan de gevraagde functionaliteit en de vereiste kwaliteitseisen. Vanaf de hoofdstap 'Bouw' is derhalve de separate tak 'kwaliteitseisen' vervallen, omdat deze eisen waargemaakt moeten worden in de constructie van programma's, procedures en databases.

4.2

Kwaliteit en Informatiesystemen

Voordat men een systeem kan modelleren in termen van het voorgaande, zal men zich allereerst moeten afvragen aan welke eisen zo een systeem moet voldoen. In het algemeen worden dergelijke eisen aangeduid met de term logische eisen, dit ter onderscheiding van technische eisen, die pas later in een ontwikkelingstraject aan de orde komen en betrekking hebben op de (technische) uitrusting en de realisatie van een systeem. We onderscheiden logische eisen in twee hoofdgroepen, te weten: - functionele eisen. Deze eisen leggen vast wat het systeem in functionele zin moet doen. Anders gezegd: welke gegevens moeten worden verwerkt, opgeslagen en verstrekt. - prestatie- ofwel kwaliteitseisen. Deze eisen geven aan hoe, dus onder welke voorwaarden, gegevensverwerking, -opslag en -versterking moet plaatsvinden (hoe snel, hoe flexibel, etc.) Naast het onderscheid in soorten eisen kan men ten aanzien van zowel functionele als kwaliteitseisen een onderscheid maken naar rata van belangrijkheid. Onderscheiden worden: - dwingende eisen: een systeem moet per se voldoen aan deze eisen. Indien niet voldaan is aan deze eisen, faalt het systeem geheel of gedeeltelijk. - dringende eisen: eisen waarvan het zeer gewenst, doch niet absoluut noodzakelijk is dat een systeem hieraan voldoet. - bijkomstige eisen c.q. wensen: eisen waarvan het plezierig is wanneer een systeem daaraan voldoet, maar die laag scoren qua noodzakelijkheid c.q. dringende wenselijkheid. Er zijn verschillende redenen om onderscheid aan te brengen tussen functionele eisen en kwaliteitseisen. Drie belangrijke redenen zijn: 1. Het verschil in het achterhalen van dergelijke eisen. Functionele eisen worden telkenmale afgeleid van de aard van de beslissingssituaties en het type beslissers dat erbij betrokken is. Ze zijn dus specifiek per situatie en per beslisser. Kwaliteitseisen zijn meer generiek, dat wil zeggen afleidbaar uit algemene karakteristieken van besturingssituaties. 2. De impact van kwaliteitseisen op kosten en doorlooptijd van de ontwikkeling van een systeem. Het is algemeen bekend dat systemen niet zozeer duur zijn en lange Civility Amsterdam bv.

43



ontwikkeltijden vergen ten gevolge van functionele eisen als weI ten gevolge van hoge ambitieniveaus ten aanzien van kwaliteitseisen. Realisatie van kwaliteitseisen betekent veelal een kostenfactor 5 tot 10 ten opzichte van de oorspronkelijke systeemkosten voor het 'kale' systeem [30]. 3. De meeste methoden concentreren zich alleen op de functionele eisen. Men delibereert dagen en dagen over wat een systeem in functionele zin moet gaan doen, maar laat een analyse van kwaliteitseisen achterwege of behandelt dat slechts marginaal. Daarmee simplificeert men het ontwikkelen van informatiesystemen op een ontoelaatbare wijze. Ret laatst genoemde punt verdient extra toelichting. Ret ontwikkelen van informatiesystemen is naast modelleren, organiseren, beheersen e.d. ook en vooral een kwestie van balanceren. Datgene wat een informatiesysteem groot, complex en kostbaar maakt, is zoals aangeduid veelal niet de realisatie van de functionele eisen, maar de realisatie van de kwaliteitseisen. Indien gebruikers ten aanzien van de kwaliteitseisen hoge tot zelfs extreem hoge eisen stellen, resulteert dit in dure, grote en zeer complexe informatiesystemen. Ret is de plicht van een informatie-analist om op deze consequenties te wijzen en gebruikers en opdrachtgevers altematieve ontwerpen qua kwaliteitsniveaus aan te bieden. Van elk altematief zal de informatie-analist het 'prijskaartje' moeten laten zien in termen van kosten en inspanning, doorlooptijd van de ontwikkeling, benodigde capaciteiten, etc. De trade-off-problematiek. Balanceren heeft alles te maken met kwaliteit. De norm NEN-ISO 8402 definieert kwaliteit als voIgt: Kwaliteit is het geheel van eigenschappen en kenmerken van een produkt ofdienst, dat van belang is voor het voldoen aan vastgelegde ofvanzelfsprekende behoeften. Eisen voor bet produkt 'informatie' Een gebruiker die informatie krijgt toegeleverd, moet erop kunnen vertrouwen dat deze informatie juist, volledig en actueel is. Gegevens waarop men geen staat kan maken, bijvoorbeeld omdat ze onvolledig of zelfs onjuist zijn, zijn ongeschikt voor beslissingsondersteuning. Voor de gegevens betekent dat in concreto dat expliciet op de output aangegeven moet zijn van welke datum de gegevens zijn c.q. wat de mate van juistheid en volledigheid is. Een additionele eis in dit verband is controleerbaarheid, bijvoorbeeld aan te tonen door het laten reproduceren van de output door andere personen; scheiden van verantwoordelijkheden (trias political). Eisen voor het produkt 'informatie'

Systeemeisen gebruikerseisen

* juistheid * volledigheid * actualiteit * controleerbaarheid * nauwkeurigheid

* tijdigheid * security ofwel beveiliging * effectiviteit * gebruiksvriendelijkheid * doelmatigheid * integriteit

- aggregatie - selectie

Tabel4.1

- juistheid - volledigheid - betrouwbaarheid

beheerseisen

* flexibiliteit * onderhoudbaarheid * testbaarheid * portabiliteit * integreerbaarheid * herbruikbaarheid * inpasbaarheid in de technische infrastructuur

Kwaliteitseisen voor het produkt 'informatie' en voor het systeem van informatie verwerking.

Civility Amsterdam by.

44



Een andere eis welke in tabel 4.1 wordt genoemd is nauwkeurigheid. De mate waarin gegevens nauwkeurig moeten zijn, zal afhangen van het besturings- ofwel beslissingsprobleem dat aan de orde is (omzetontwikkeling in miljoenen guldens versus uitstaande debiteuren in centen). Tevens hangt nauwkeurigheid nauw samen met de scoop van de beslissingen. In het algemeen neemt deze scoop toe naarmate men hoger in de beslissingspiramide komt. Hoe hoger het beslissingsniveau, hoe groter de behoefte aan sterk gecondenseerde informatie over zeer veel aspecten. Kwaliteitseisen vanuit het gebruikersperspectief De kwaliteitseis 'tijdigheid' is onder te verdelen in drie deeleisen, nl. responstijd, frequentie van informatieverstrekking en bewaartijd van de gegevens. De responstijd is de tijd waarbinnen een systeem aangeboden transacties afhandelt. De meetgrootheid die men daarbij hanteert, is het aantal tijdseenheden. De responstijd is afhankelijk van de verwerkingswijze die men kiest. De frequentie van informatieverwerking hangt nauw samen met de periode waarover men verslag wil doen. De bewaartijd van gegevens, gegevens worden in het algemeen minder relevant naarmate ze van oudere datum zijn. Hoe ouder gegevens zijn, hoe minder de voorspellende kracht ervan en dus hoe minder goed bruikbaar ze zijn voor de besturing van een systeem.

De integriteit van het systeem van informatieverwerking, dus voor de software, hardware en procedures, is op te delen in deeleisen zoals juistheid, volledigheid en betrouwbaarheid. Juistheid heeft met name te maken met de correctheid van computer-programma's en handmatige procedures. Volledigheid is een andere deeleis van integriteit. Men moet kunnen garanderen dat input slechts een keer wordt verwerkt, en dat die volledig wordt verwerkt. De laatste deeleis van integriteit is de betrouwbaarheid van zowel hardware als software, onder te verdelen in: - beschikbaarheid: het systeem moet beschikbaar zijn op het moment dat dit vereist is. - bedrijfszekerheid: het systeem mag niet behept zijn met een onacceptabel hoge kans op storingen of uitval. Gegevens, programmatuur en apparatuur dienen te worden beveiligd tegen ongeoodoofd gebruik. De beveiliging moet privacygevoelige gegevens en vertrouwelijke gegevens ontoegankelijk maken voor onbevoegden. Nu automatisering meer en meer doordringt tot elke werkplek binnen een organisatie, wordt gebruiksvriendelijkheid een van de toponderwerpen binnen de automatisering. Gebruiksvriendelijkheid heeft alles te maken met fysieke en cognitieve ergonomie. Fysieke ergonomie houdt zich bezig met de werkbaarheid van een systeem en met de omgevingscondities waaronder men werkt. Veel belangrijker blijkt bij automatisering de cognitieve ergonomie. Daarbij tracht men na te gaan of het automatiseringsconcept aansluit bij de mentale processen van de mens. Een belangrijk onderdeel daarvan is de wijze van informatiepresentatie. Maatregelen in dit kader zijn: 1. Vermijd complexe output, dit leidt tot interpretatiefouten. 2. Zorg voor herhalingsboodschappen, tot de gewenste actie is uitgevoerd. 3. Opmaak van de output, hoe belangrijker een gegeven, hoe opvallender de vorm. 4. Streef naar een standaardlayout, gebruikers kunnen zo beter en sneller de gegevens vinden. Civility Amsterdam bv.

45



5. Gebruik grafieken en kengetallen, 'een plaatje zegt meer dan duizend woorden: 6. Gebruik geen afkortingen of coderingen, de gebruiker moet dan gaan uitzoeken wat deze betekenen. Kwaliteitseisen vanuit het beheersperspectief Hoe groter de dynamiek in de besturingssituaties waarvoor een informatiesysteem wordt opgezet, hoe geringer de duurzaamheid van het informatiesysteem, tenzij men het systeem zodanig flexibel maakt dat men kan inspelen op de genoemde dynamiek. Flexibiliteit heeft te maken met de mogelijkheid om een eenmaal gebouwd systeem alsnog te reviseren, aan te passen, uit te breiden, etc. Deeleisen zijn in dit verband: onderhoudbaarheid, aanpasbaarheid, uitbreidbaarheid en overdraagbaarheid van apparatuur, programmatuur en handmatige procedures. In de eisenpakketten voor een nieuw systeem dient men ten aanzien van deze deeleisen expliciet te formuleren welke keuzen men acceptabel vindt en waarom (argumentatie). Zo zullen ten aanzien van de apparatuur aan de orde moeten komen: 1. uitbreidbaarheid: mogelijkheid om stapsgewijze de apparatuur, waaronder de centrale verwerkingseenheid en allerlei randapparatuur, uit te breiden (peaceful upgrading). 2. overdraagbaarheid (compatibility): mogelijkheid om apparatuur uit te wisselen en te vervangen door andere apparatuur tegen betrekkelijk geringe conversiekosten.

Ten aanzien van de genoemde deeleisen wat de programmatuur betreft, worden III de literatuur vaak genoemd: 1. aanpasbaarheid (adaptability) en onderhoudbaarheid (maintainability) van programmatuur. Beide worden in positieve zin beYnvloed door een modulaire opbouw van de programmatuur en door het toepassen van de principes van het gestructureerd programmeren. 2. overdraagbaarheid (portability) van programmatuur van de ene naar de andere machineconfiguratie. Deze overdraagbaarheid is o.a. groter als men kiest voor een internationaal gestandaardiseerde taal. De eis van integreerbaarheid probeert men gestalte te geven door middel van architectuurplannen voor applicaties, voor gegevensbestanden, etc. lets soortgelijks geldt met betrekking tot technische middelen, die moeten passen binnen de reeds aanwezige infrastructuur. Een van de recente aandachtsgebieden binnen de automatisering is de herbruikbaarheid van software. In vele publikaties wordt gewag gemaakt van de software-backlog: er is te weinig geschoold personeel om aan de vraag naar software te voldoen. Veel succes verwacht men wanneer softwareontwikkelaars niet steeds het wiel opnieuw proberen uit te vinden, maar software zodanig structureren en modulariseren dat deze herbruikbaar is bij tal van toepassingen.

4.3

Veranderingsanalyse en Systeemontwikkeling

In de vorige twee paragrafen is het ontwikkelen van een concreet informatiesysteem aan de orde geweest vanuit methodenperspectief en vanuit kwaliteitsperspectief. Aanzetten zijn behandeld voor het achterhalen van zowel functionele eisen als prestatie-eisen. Beide soorten vormen samen de logische eisen en zijn het startpunt van de systeemontwikkeling.


46



Wanneer men als informatie-analist geconfronteerd wordt met een ogenschijnlijk informatieprobleem in een organisatie. Is het verstandig eerst in algemene zin te verifieren of een nieuw of verbeterd informatiesysteem weI de oplossing is. Een methode die op dat punt ondersteuning biedt, is de methode ISAC, Information System work and Analysis of Change. Het ontwikkelen bij ISAC wordt onderverdeeld in drie hoofdstappen, te weten: 1. veranderingsanalyse; 2. systeemontwikkeling; 3. het invoeren van de mix van veranderingsmaatregelen. De veranderingsanalyse is bedoeld om expliciet te verifieren welke problemen moeten worden aangepakt binnen een organisatie. Dat hoeven niet per se informatieproblemen te zijn, maar kunnen ook problemen zijn op organisatorisch terrein of problemen binnen de bestuurde (technische) systemen. De systeem ontwikkeling voIgt op de veranderingsanalyse en omvat aIle aspecten en activiteiten die in de vorige paragrafen zijn beschreven ten aanzien van de ontwikkeling van een informatiesysteem. Uiteraard is dit pas aan de orde wanneer de veranderingsanalyse aangetoond heeft dat er daadwerkelijk sprake is van een informatieprobleem, wellicht naast andere problemen. De derde en laatste hoofdstap is het invoeren van de mix van veranderingsmaatregelen. Meestal gaat het om een combinatie van veranderingsmaatregelen voor het bestuurd systeem, het besturend orgaan (de organisatie) en de informatievoorziening (zie figuur 4.1). Veranderingsanalyse Veranderingsanalyse beoogt gestructureerd in kaart te brengen de huidige situatie (Ist) en de gewenste situatie (Soil). Hulpmiddel daarbij is een activiteitenschema (A-schema) of een rich picture. De opdeling van een A-schema in deelschema's (decompositie) blijkt in de praktijk lastig. Opdelingsrichtlijnen zijn daarbij: homogeniteit van functies, homogeniteit van kwaliteitseisen, gegevensonathankelijkheid en realiseerbaarheid. Systeemontwikkeling De fase systeemontwikkeling bestaat uit procesanalyse, logische gegevensstructurering en analyse van kwaliteitseisen. Procesanalyse beoogt in deelstappen en via allerlei technieken (Data Flow Diagrammen, beslissingstabellen en programrnastructuurdiagramrnen) het algoritme nauwkeurig in kaart te brengen. Logische gegevensstructurering beoogt stap voor stap de relevante gegevens in kaart te brengen, om dit uiteindelijk te vertalen naar opslag (databases), input en uitput (presentatie op papier of schermathandeling).

4.4

Doelmatigheid bij Informatiesystemen

Bij het ontwikkelen van informatiesystemen dient men zich niet aIleen af te vragen of een systeem voldoet aan allerlei functionele en kwaliteitseisen, maar tevens of de daarvoor benodigde middelen (mensen, apparatuur, financiele middelen en dergelijke) in een redelijke verhouding staan tot deze eisen. In de bedrijfseconomische theorie wordt dit aangegeven met het begrip doelmatigheid. Doelmatigheid wordt gedefinieerd als de verhouding tussen een resultaat (de baten) dat men bereikt versus de kosten die daarmee zijn gemoeid. Civility Amsterdam bv.

47



Kosten Kosten van een nieuw informatie systeem zijn onder te verdelen in: - ontwikkelkosten van een gegevensverwerkend systeem (ontwerpkosten, kosten van programmatuur, testen, opstellen procedures en gebruikershandboeken, laden of converteren van databases, e.d.); - gebruikskosten van een systeem, bij vervaging van een systeem, verminderd met gebruikskosten van het systeem dat wordt vervangen. Onder de gebruikskosten vallen o.a. kosten voor het gebruik van apparatuur, kosten verbonden aan het aanleveren van de benodigde inputgegevens (kosten datatypisten, kosten inputformulieren, etc.) en kosten voor het beheer zoals onderhoud aan programmatuur en documentatie; - organisatorische kosten, waaronder introductie- en reorganisatiekosten. Elk systeem vraagt middelen voor de introductie van het systeem bij de eindgebruikers (waaronder o.a. kosten opleiding en scholing). Daamaast gelden aanloopkosten om van het oude informatiesysteem over te schakelen naar het nieuwe. Indien het nieuwe informatiesysteem een andere organisatie vereist (en welk systeem doet dat niet), moet men de kosten van de benodigde reorganisatie expliciet meenemen in de kosten-batenanalyse, iets wat vaak wordt 'vergeten'. Ret schatten van ontwikkelkosten van een informatiesysteem wordt door een aantal factoren bemoeilijkt (bijvoorbeeld: systematische onderschatting, slechte definitie van wat een informatiesysteem nu precies is, gebrek aan normen en empirische gegevens en de foutieve aanname dat de inzet van mensen en doorlooptijd een lineair verband vertonen). De gebruikskosten kan men onderverdelen in, direct toewijsbare kosten en indirecte kosten. Voorbeelden van direct toewijsbare kosten zijn personeelskosten (systeemanalisten, programmeurs en operators) en diverse materiaalkosten. Zijn de directe kosten relatief eenvoudig te bepalen voor een bepaald informatiesysteem, anders ligt dit bij de indirecte kosten, waaronder kosten voor het gebruik van computerfaciliteiten en het beheer. De reden daarvoor is dat deze kosten meestal gemeenschappelijke kosten zijn, immers, computerfaciliteiten worden veelal niet voor een toepassing aangeschaft en de beheerorganisatie beheert meestal meerdere systemen. Wil men deze gemeenschappelijke kosten gaan toerekenen naar diverse informatiesystemen, dan kan dat aIleen op grond van verdeelsleutels. Haten

In de literatuur vindt men een aantal kwantitatieve modellen voor de berekening van de waarde van informatie. Een van de grondbeginselen van die modellen is dat informatie pas dan waarde heeft indien die informatie leidt tot een betere beslissing. Men veronderstelt daarbij een een-op-een-verband tussen informatie en beslissing (zie figuur 4.3a) bijvoorbeeld de beschikbaarheid in de afgelopen maand van een server is te laag (eenmalige informatie) er wordt een back-up voorziening aangeschaft (eenmalige beslissing). Nu is de praktijk vaak veel ingewikkelder dan hetgeen in figuur 4.3a is weergegeven. Veelal wordt een beslissing niet gebaseerd op slechts een soort informatie, maar op verschillende soorten (zie figuur 4.3b) bijvoorbeeld gebrekkige betrouwbaarheid, slechte performance en een dalend aantal gebruikers (verschillende informatiesoorten) leiden tot de beslissing dat er een nieuw systeem ontwikkeld moet worden.


48



Figuur 4.3 a. Een soort informatie een beslissing.

b. Meer soorten informatie een beslissing.

Nog moeilijker wordt de zaak als men het zogenaamde doorwerken breedte-effect van informatie in de beschouwing betrekt. Onder het doorwerkeffect van informatie verstaat men het feit dat bepaalde informatie niet alleen van invloed is op een eenmalige beslissing, maar op de keten van beslissingen die daarop voIgt (zie figuur 4.4 a) bijvoorbeeld door het invoeren van een nieuw systeem blijkt de netwerkcapaciteit onvoldoende te zijn en dient derhalve vergroot te worden. Onder het breedte-effect wordt verstaan dat een bepaald type informatie niet alleen zal doorwerken op een beslissing, maar op verschillende soorten (zie figuur 4.4 b).

Beslissing op tijdstip

Beslissing op tijdstip

To

T]

Figuur 4.4 a. Het doorwerkeffect van informatie.

Informatie

Beslissing A op tijdstip

TO

b. Het breedte-effect van informatie.

Ook het inschatten van de baten van een informatiesysteem is derhalve geen eenvoudige opgave. Dit wordt nog eens versterkt doordat naast kwantitatieve baten veelal kwalitatieve baten (bijv. psychologisch, strategisch en maatschappelijk nut) een belangrijke rol spelen [30].

4.5

Beheren van een Informatiesysteem

Beheren door faseren Er bestaan vele fasenindelingen voor het ontwikkelen van informatiesystemen. Doel van een dergelijke indeling is steeds het aanbrengen van duidelijke meetpunten (milestones) waarop men de tot dan toe bereikte resultaten evalueert en nagaat hoe men verder moet. Elke fase dient daarbij te worden afgesloten men een goede documentatie, waarin bereikt resultaten en te zetten vervolgstappen zijn vastgelegd.

Een fasering, toegespitst op het ontwikkelen van informatiesystemen, is de methode SDM (Systems Development Methodology). De diverse fasen zoals die bij SDM worden onderscheiden, zijn afgebeeld in figuur 4.5. Civility Amsterdam bv.

49



FaseO

Fasel

Fase2

Fase3

Fase4

Fase5

Fase 6

Informatieplanning

Definitiestudie

Basisontwerp

Detailontwerp

Realisatie

Uitvoering

Gebruik en beheer

Figuur 4.5 SDM fasering. De afgebee1de fasenindeling geeft slechts een globaal bee1d van de activiteiten die worden uitgevoerd bij het ontwikkelen van een informatiesysteem. Voor e1ke fase geeft SDM daarom een uitvoerige toe1ichting, waarin behande1d worden: de doe1stelling van de fase, een algemene samenvatting, een activiteitennetwerk en een beschrijving van de mijlpaalprodukten. Zie voor een meer uitgebreide beschrijving hoofdstuk 7. Beheersen door organiseren In principe zijn er drie hoofdsoorten van werken te onderkennen, nl. improviserend werken, projectmatig werken en routinematig werken. Improviserend werken verdient de voorkeur voor eenmalig optredende gevallen, waarbij men niet kan terugvallen op standaardprocedures en -routines. Routinematig werken daarentegen past goed bij zich steeds herhalende standaardgevallen, die men op grond van ingeslepen procedures en routines kan afhande1en.

Het ontwerpen en bouwen van informatiesystemen gebeurt vee1al niet op de improviserende, noch op de routinemanier binnen de normale organisatie, maar op de projectmatige manier. Daarbij construeert men een projectorganisatie als een (tijdelijk) samenwerkingsverband tussen personen uit diverse afdelingen van de organisatie, eventuee1 aangevuld met personen van buiten de organisatie. Projectmatig werken betekent beheersen naar vijf dimensies, nl. tijd, geld, kwaliteit, (project-)organisatie en informatie (lees: documentatie). Hoofdredenen om te kiezen voor een projectorganisatie bij het ontwikke1en van informatiesystemen zijn, de multi- en interdisciplinaire inslag van ontwikke1en, het eenmalige en tijdelijke karakter van ontwikkelen en de noodzaak van een goede besturing i.v.m. de aanzienlijke consequenties op diverse terreinen. Een projectorganisatie bestaat uit de volgende groepen, een beleidsgroep (algemene richtlijnen), een stuurgroep (concretiseren van de richtlijnen) en een projectgroep (uitvoering). Beheersen door documenteren Docurnentatie is te onderscheiden in drie soorten docurnentatie, systeem-, ontwerpen project-managementdocurnentatie. Hoofdargurnenten om een dergelijk onderscheid aan te brengen, zijn het verschil in gebruiksduur en het verschil in doelstellingen van de afzonderlijke soorten documenten.

De systeemdocurnentatie omvat al die beschrijvingen die direct te maken hebben met het geautomatiseerde informatiesysteem. Doe1 van een dergelijke documentatie is, het verschaffen


50



van inzicht in het systeem voor niet direct betrokkenen en het verscha.ffen van een handleiding voor het gebruik en beheer van een informatiesysteem.

De ontwerpdocumentatie omvat aIle inhoudelijke beschrijvingen van het informatiesysteem zoals die tijdens het ontwikkelingsproject tot stand zijn gekomen. Projectmanagementdocumentatie omvat aIle gegevens met betrekking tot het beheersen van het project. Doel van deze documentatie is dus het leveren van zinvolle informatie aan het management van het project (projectleider, stuurgroep).


51



H5 Oude situatie 5.1

De Infrastructuur

HetNetwerk De Gemeenschappelijke Datacommunicatie-infrastructuur Amsterdam (GDA) is opgebouwd rond een backbone, welke ligt tussen Civility hoofdkantoor (Amsterdam Zuidoost) en het stadhuis (Stopera, in het centrum van de stad). Binnen de infrastructuur van de GDA wordt onderscheid gemaakt tussen het basisnetwerk en de aansluitingen van de gebruikers op het toegangsnetwerk. Ret basisnetwerk bestaat uit de twee voornoemde knooppunten alwaar multiprotocol-routers staan opgesteld en uit snelle verbindingen tussen die knooppunt-routers. De gebruikersorganisaties worden hieraan 'stervormig' aangesloten, met behulp van remote opgestelde routers [23].

Een GDA aansluiting wordt gedefinieerd door zijn fysieke en logische eigenschappen (fysieke interface, aansluitsnelheid, ondersteunende protocollen). Via de aansluiting kunnen optioneel GDA-voorzieningen toegankelijk worden gemaakt die extra mogelijkheden bieden, zoals bijvoorbeeld een koppeling met het Civility-mainframe. De infrastructuur van GDA maakt de communicatie mogelijk van elk aansluitpunt naar elk ander aansluitpunt, waarbij alle protocollen en overige hierna gespecificeerde eigenschappen ondersteund worden voor de communicatie tussen elk mogelijk paar aansluitingen. De structuur van het basisnetwerk wordt gevormd door de twee knooppunten met elk een Cisco AGS+ en een Cisco 2503 router en de twee verbindingen van elk 2 Mbps daar tussen. Zie figuur 5.1. De beide verbindingen volgen hierbij een verschillende route door Amsterdam. Daarnaast is er op beide knooppunten een Cisco 4000 router met ISDN Basic Rate Interfaces (BRI) ge'installeerd opdat er back-up en Bandwidth On Demand (BOD) via ISDN geboden kan worden. Bij uitval van een van de vaste verbindingen gaat al het verkeer over de tweede. Indien beide 2Mbps-verbindingen uitvallen worden er 4 ISDN-BRI's ingezet. Voor de vaste verbindingen wordt zoveel mogelijk gebruik gemaakt van verbindingen van het GEB omdat deze goedkoper (64 Kb ca. 80% en 2 Mb ca. 60% van de PTT-tarieven) en minstens zo betrouwbaar zijn als die van de PTT. Van gewone kiesverbindingen wordt geen gebruik gemaakt omdat deze al snel te duur zijn (door de inzet van een kieslijn-beveiligingssysteem). Van ISDN wordt gebruik gemaakt voor back-up doeleinden en BOD. ISDN wordt niet toegepast als vervanging voor vaste verbindingen omdat het minder betrouwbaar is dan vaste verbindingen. Basisaansluiting Met een basisaansluiting wordt de Ethernet-LAN van de deelnemer gekoppeld aan de GDA, met een router die op de gebruikerslokatie wordt geplaatst. Hierbij worden zowel de DIX Ethernet versie II, de ISO 8802.2 (Logical Link Control) als de ISO 8802.3 (CSMA/CD) standaard ondersteund. Een basisaansluiting biedt datacommunicatie-mogelijkheden op basis van de volgende protocollen: * TCP/IP * IPx/SPX * DECnet (fase IV) Civility Amsterdam bv.

53



GDA

Token-ring LAN Klant Router

Ethernet ....:~=~;:;..:;~~

Werkplek Ethernet-LAN 2*2Mbps

ISDN-2

-"T"'"--~01..._-"""T"'"----..,.~=~+---.lr--GDAEthernet

Netwerk Management Machine

Figuur 5.1. Schematisch overzicht van het GDA. Civility Amsterdam bv.

54



Eigenschappen van de basisaansluitingen [9]:

* Capaciteit De router is met een digitale lijn, naar keuze met een capaciteit van 19K2bps, 64Kbps, 128Kbps of 256Kbps verbonden met het dichtstbijzijnde GDA-knooppunt. Deze capaciteit is de gegarandeerde maximale bruto throughput van de GDAbasisaansluiting. Bij de tijdgebonden 64Kbps aansluiting wordt een ISDN-aansluiting in ingezet. Bij de overige typen wordt gebruik gemaakt van een vaste huurlijn. De verbinding tussen de knooppunten Stopera en Civility (het basisnetwerk) heeft een capaciteit die minstens gelijk is aan de som van de capaciteiten van alle basisaansluitingen. * Back-up voorziening Bij de basisaansluitingen met een back-up voorziening, wordt ook een ISDNaansluiting ingezet. Doormiddel van deze ISDN-kieslijn kan bij uitval van de vaste lijn, de verbinding in stand worden gehouden. Het inzetten van deze back-up voorziening gebeurt geheel automatisch. Indien het GDA-knooppunt waarmee de vaste lijn is verbonden in zijn geheel uitvalt, verzorgt deze voorziening automatisch een verbinding met het andere knooppunt. * Bandwidth On Demand Bij de basisaansluitingen met BOD wordt de ISDN-aansluiting, naast back-up voorziening, ook ingezet indien de vaste lijn overbelast dreigt te raken, waardoor de capaciteit van de verbinding (van bijv. 19K2bps) tijdelijk met 64Kbps wordt verhoogd. Aansluitopties De basisaansluitingen worden geleverd in verschillende uitvoeringen. Standaard wordt een Ethernet-LAN gekoppeld aan de GDA. Hierbij kan gekozen worden uit verschillende fysieke koppelvlakken. Een Token-ring LAN aansluiting op het GDA is optioneel, evenzo een X.25 of SDLC (Synchronous Data Link Control) koppeling. Communicatieopties Aanvullend op de basisaansluiting kan een deelnemer een selectie maken uit diverse communicatie opties, bedoeld voor PC's die aan een LAN (zowel Ethernet als Token-ring) gekoppeld zijn en waarmee de deelnemer onder andere met een VAX, een TCP/IP-host ofhet Civility-mainframe wil communiceren. De beschikbare communicatieopties zijn:

* Remote terminal access, 3270 De optie 'Remote access 3270' levert deelnemers communicatie tussen PC's in het aangesloten LAN en een IBM mainframe (SNA-host of daarmee compatible installatie) gekoppeld aan een andere aansluiting, op basis van het IBM 3270 protocol. Het Civility mainframe is een belangrijk doelsysteem en is als standaard faciliteit met deze optie via de GDA bereikbaar. Daartoe zijn centrale gateway-faciliteiten binnen de GDA opgenomen. * Remote terminal access, VT220 Deze optie levert de gebruikers communicatie tussen PC's (en printers) in een aangesloten LAN en hostcomputers welke gekoppeld zijn via een andere GDA aansluiting en werken met terminal-protocols van het type VT220 of daarmee Civility Amsterdam bv.

55



vergelijkbaar (ANSI X3.46 standaard). Dit zlJn bijvoorbeeld, toepassingen op VAXNMS computers en veel UNIX systemen * Client voor TCP/IP Deze optie levert de deelnemers communicatie tussen een TCP/IP client-pakket op PC's in een aangesloten LAN en een TCP/IP-omgeving op een andere op de GDA aangesloten locatie. Voor de opties Remote terminal access VT220 en Client voer TCP/IP gelden (nog) geen Service Level afspraken [19]. Email-opties Elektronische post kan via de GDA worden verzonden aan Deelnemers van de GDA en via externe koppelingen aan gebruikers van externe netwerken. De GDA beschikt over een Email koppeling met Internet. Elektronische post binnen GDA wordt Email-optie genoemd, elektronische post via externe koppelingen naar de naam van het gekoppelde netwerk bijvoorbeeld Internet Email. Er kan boven op de basisaansluiting voor de volgende Email opties gekozen worden:

* Email postbus Als optie wordt aan de deelnemers een Email postbus geboden. Deze GDA-dienst is toegankelijk voor individuele gebruikers en is vanuit de aangesloten LAN-omgevingen te benaderen. Er worden mogelijkheden geboden om met gekoppelde mailomgevingen van bedrijven, diensten en stadsdelen die deel uitmaken van de gemeente Amsterdam en via Internet met externe organisaties, berichten uit te wisselen. Voor de GDA is een centraal domein ingericht (Primary Domain) waarin het centrale adressenbestand is opgenomen. Ook zijn binnen dit domein de gateways geplaatst naar andere omgevingen. * Email transit De GDA biedt naast het mail-systeem voor individuele of groepen gebruikers ook de .Email transit' optie. Met deze optie wordt de mogelijkheid van koppeling van een lokaal Email-systeem met het centrale GDA Email-systeem geboden. Betreft het een Email systeem dat niet gebaseerd is op GroupWise, dan kan er via een gateway gekoppeld worden. Voor bijna aIle bovenstaande diensten geldt dat deze in het met de deelnemer overeengekomen Service Level Agreement zijn opgenomen, met daarin o.a. normen voor betrouwbaarheid en beschikbaarheid van deze diensten. De realisatie van de genoemde diensten vind plaats met behulp van de technische infrastructuur die is onder te verdelen in de volgende soorten objecten [34]: - Database-programmatuur - Basisprogrammatuur: * Basisprogrammatuur voor besturing * Beveiligingsmiddelen * Ontwikkelhulpmiddelen - Apparatuur * Verwerkingsapparatuur * Invoerapparatuur Civility Amsterdam bv.

56



* Uitvoerapparatuur * Achtergrondgeheugens * Voor- en nabewerkingsmiddelen * Telematica-apparatuur - Datacommunicatiefaciliteiten * Communicatieprogrammatuur * Datacommunicatie-apparatuur * Transmissiemedia - Standaardpakketten * Pakketten voor persoonlijke toepassingen * Pakketten voor grotere systemen Voor de concrete technische invulling van de GDA-diensten op objecten componentniveau zie bijlage 2. Applicaties De applicaties staan, in bijna aIle gevaIlen, centraal bij Civility opgesteld en zijn via het GDA beschikbaar voor de gebruikers. De applicatieprogrammatuur, ondersteunende databases (bijvoorbeeld: Oracle, DB2, lngres etc.) en onderliggende Operating Systems (AIX) draaien op midrange apparatuur (RS/6000). Voor een schema zie figuur 5.2.

RS/6000 RS/6000

of Novell server

RS/6000

gebruikers

Ethernet

"---------.....y----~/

"-----==-~~~/ 'V"

GCEI

Klant

Ethernet

Figuur 5.2 Schematische overzicht bereikbaarheid applicaties.

5.2

Het Service Level Management

Service Level Management (SLM) zijn de processen rond het maken en bewaken van formele overeenkomsten (SLAs) over de hoeveelheid (kwantiteit) en kwaliteit van de ITdienstverlening met de leverancier en de afnemer van de IT-dienstverlening. Voordelen van Service Level Management zijn: * bereiken van een specifiek, consistent, meetbaar service niveau * uitbalanceren van de service niveaus die de gebruikers willen tegen de kosten van het aanbieden daarvan Civility Amsterdam bv.

57



* kostenbesparing door meer accurate specificaties * verbeteren van de productiviteit van de gebruikers als resultaat van betere IT-diensten

* het hebben van objectieve service meetgegevens voor het opheffen van meningsverschillen over service levels

* reduceren van de kans op onvoorspelbare eisen Service Level Management is gericht op de totstandkoming, borging en controle van de kwaliteit en kwantiteit van de dienstverlening van een IT-service organisatie. Rierbij wordt rekening gehouden met veranderende bedrijfsbelangen, gebruikersbehoeften en technologische ontwikkelingen. Ret resultaat van het proces service level management is een Quality of Service die tenminste overeenkomt met de niveaus vastgelegd in het Service Level Agreement tussen de afnemer en de IT-dienstverlener. Op basis van deze geschreven overeenkomst is het mogelijk om de prestatie van de dienstverlening af te stemmen op de verwachting van de afnemers tegen een afgesproken prij s. De taken van service level management zijn binnen Civility verdeeld over de groepen Facilities Management Services (FMS) en Produktie & Beheer (PB) zie ook hoofdstuk 2. Ret proces service level management bestaat, bij Civility, uit de volgende taken: * Definieren van de service-niveaus (FMS) * Onderhandelen met de afnemers van de IT-services (FMS) * Vastleggen en bijstellen van de service level agreements (FMS) * Volgen en bewaken van de service-niveaus (PB) * Evalueren van de geleverde service (PB) De taken van de service level management zijn: * Opstellen en onderhouden van de service catalogus (FMS) * Verzamelen van service level requirements en opstellen van de service levels (FMS) * Formuleren, onderhandelen en onderhouden van een SLA-structuur (FMS) * Vertalen van de service levels uit de overeengekomen SLA naar operationele service (Service Level Manager) * Rapporteren over de prestatie van de service aan klanten en IT-management (SLM) * Regelmatig bijeenkomsten organiseren met de vertegenwoordigers van de IT-service klanten om de juistheid van de service levels te toetsen (FMS) * Initieren van activiteiten die noodzakelijk zijn voor verbetering of onderhoud van de service levels (FMS + SLM) * Escalatie naar groepshoofd PB wanneer niveaus niet gehaald worden (SLM)

5.3

De Service Level Agreements

Ret doel van service level overeenkomsten is het op papier vastleggen van de afspraken tussen, en daarmee de rechten en plichten van, de dienstverlener en de afnemer. In de beginjaren van het uitbesteden van automatiseringsdiensten werden dergelijke afspraken zelden gemaakt, hierdoor ontstond tijdens de uitvoering vaak een 'meningsverschil', tussen klant en uitvoerder, omtrent de uit te voeren taken en de kwaliteit daarvan. Door het gebruik van SLAs weten beide partijen wat ze van elkaar mogen verwachten en staat dat ook op schrift.


58



Tussen Civility en de Deelnemer is een 'Overeenkomst GDA-diensten' gesloten. Het Service Level Agreement (SLA) is een bijlage van de 'Overeenkomst GDA-diensten'. In het SLA zijn de kwaliteitsnormen voor de GDA-diensten en het beheer van deze diensten vastgelegd. Naast dit SLA is er het Dossier Afspraken en Procedures (DAP). Hierin zijn op detailniveau de exteme procedures en rapportages rond de GDA-diensten beschreven. De in het SLA en het DAP vastgelegde eisen en specificaties zijn een resultaat van overleg tussen de opdrachtnemer (Civility), de opdrachtgever (de gemeente Amsterdam) en de toekomstige klanten. Het SLA wordt beheerd door Civility. Wijzigingen op het SLA worden met de opdrachtgever besproken en na goedkeuring van beide partijen door Civility in het SLA aangebracht. Het Gebruikersplatform GDA (een soort gebruikersbelangenvereniging) heeft hierbij een adviserende taak [19]. Voor de andere diensten die Civility levert worden de SLAs gedefinieerd door de Facilities Management Services, na onderhandelingen met de afnemers van de IT-services. In de afgesloten Service Level Agreements komen diverse items aanbod. De te leveren Dienst, een korte omschrijving van te bieden functionaliteit. Beschikbaarheid, bestaande uit de openstellingstijden en de minimaal te realiseren beschikbaarheid, uitgedrukt in een percentage per tijdseenheid (bijvoorbeeld: per dag, week, maand of jaar). De beschikbaarheid wordt soms ook uitgedrukt in de gemiddelde tijd tussen twee tekortkomingen (MTBF) en de gemiddelde tijd welke nodig om het euvel te verhelpen (MTTR). Een andere variatie voor het weergeven van de beschikbaarheid is de gemiddelde downtime per gebruiker per tijdseenheid. Performance, voor een applicatie de responstijd en voor een netwerkfaciliteit de vertragingstijd. Capaciteit, van de databanken, in Megabytes, de verbindingen, in kilobits per seconde, en het aanta1 (gelijktijdige) gebruikers. Het gebruik van de Helpdesk, de openingstijden en de reactietijd, eventueel afhankelijk van een op te geven urgentiecode. Voor de Helpdesk functie kan ook vastgelegd worden wat de maximale afhandelingstijd mag zijn en wanneer naar een hoger niveau geescaleerd moet wordt. Andere items die in een SLA aanbod kunnen komen zijn de afspraken voor gevallen als Problemen, Wijzigingen en Calamiteiten. Ook Beveiliging en Aansprakelijkheid komen in de SLAs van Civility aanbod. Voor het daadwerkelijk goed kunnen functioneren van de gemaakte afspraken moet er een vorm van controle plaatsvinden. Deze controle dient de afgesproken kwaliteitsnormen te vergelijken met het gerealiseerde service niveau. De uitkomst hiervan wordt middels een rapport verspreid onder de daarvoor in het SLA genoemde instanties.

5.4

De Service Level Rapportages

Voor zowel het GDA als voor de applicaties (NUS, GISP, WVG etc.) werd er periodiek een service level rapport geproduceerd. Voor nagenoeg aIle applicaties werd gerapporteerd over de gemelde incidenten en de status daarvan. Beperkt gerapporteerd werd er over het capaciteitsgebruik en de gerealiseerde beschikbaarheid. Aangaande de overige service level items werd er nauwelijks gerapporteerd. Het overgrote deel van de rapportage werkzaamheden gebeurde met de hand. Voor GDA bestond er wel een, gedeeltelijk geautomatiseerd, rapportage systeem.


59



Het oude rapportage systeem voor het GDA De behaalde prestaties van de geleverde diensten over het GDA Netwerk vonnen het belangrijkste onderdeel waarover gerapporteerd dient te worden door Civility. De nonnen zijn in het Service Level Agreement (SLA) opgenomen. De rapportage is daarmee een essentiele communicatie-schakel tussen Civility en de afnemer van de geleverde dienst(en) in de volledig operationele situatie. Voor de deelnemer is de rapportage een verslag van wat er gebeurd is de afgelopen maand. Bovendien geeft het aan waarom al of niet aan de nonnen is voldaan. Voor beide partijen heeft de rapportage toegevoegde waarde, enerzijds presenteert Civility zich, en anderzijds wordt die infonnatie geleverd waar behoefte aan is [10]. 'De rapportages hebben als doel de gerealiseerde prestaties van de dienstverlening zoals neergelegd in het SLA, op hoofdlijnen te confronteren met de overeengekomen of te verwachten nonnen' [20] . De produkten die uit het oude rapportage proces kwamen: * Rapportages voor elke GDA aansluiting (iedere deelnemer krijgt maandelijks een rapportage) * Rapportages voor de opdrachtgever vanuit de gemeente Amsterdam (ook maandelijks) In het rapportage proces waren drie fasen te onderscheiden, het vergaren van de rowe gegevens, na filtering en bewerking ontstaan dan bewerkte en broikbare gegevens deze werden m.b.v. Excel 5.0 en WP 5.2 verwerkt tot een rapport. Zie figuur 5.3. Filtering & Bewerking

ISTAPI~ Ruwe gegevens

Excelleesbaar Per aansluiting

t

mnd

>

STAP2

Per dienst

Bewerkte en bruikbare gegevens

Rapportage opmaken en printen

Figuur 5.3 Het Service Level Rapportage proces. De filter en bewerkingsstap (stap 1), waarin de rowe gegevens worden gefilterd en bewerkt, was nagenoeg volledig geautomatiseerd. De inlees- en verwerkingsstap (stap 2), waarin de gegevens in Excel 5.0 werden gelezen, verwerkt in WP en aangevuld met extra relevante infonnatie, was niet geautomatiseerd. De oude rapportage bevatte de volgende rapportage items [10]: * Management Samenvatting * Beschikbaarheid * Capaciteitsbeheer * Probleembeheer * Wijzigingsbeheer * Bijlagen


60



Management Samenvatting Iedere maand wordt er een samenvatting van de meest opmerkelijke voorvallen gemaakt. Vooral die zaken die niet conform de afspraken zijn verlopen komen hier aanbod. Het betreft zowel het gehe1e netwerk als ook de deelnemers afzonderlijk, eventueel aangevuld met extra informatie over de GDA aansluiting. Ook beheer op het tactische vlak is onderdeel van deze samenvatting. Bovendien zal in de maand december een jaarlijkse samenvatting worden gemaakt met hierin de gesignaleerde trends, ontwikke1ingen en onderwerpen die in het volgende jaar anders worden aangepakt. Bescbikbaarbeid In dit hoofdstuk worden beschikbaarheidsgegevens van een centrale faciliteit zoals de toegang tot de externe netwerken en de GDA diensten behande1d. De gegevens over de beschikbaarheid van de LAN koppelpunten worden opgesomd in een tabel (voor de opdrachtgever) of grafisch weergegeven (deelnemer). De beschikbaarheid is onderverdeeld in vaste openstellingstijden (rna tim vrij van 7:00 22:00 um) en overige men (excl. Maintenance window, vrij 22:00 - zat 22:00 uur). Zowel de beschikbaarheid van de 'GDA aansluiting', de 'koppeling met extern netwerk' als van de 'GDA diensten' worden weergegeven. Afgenomen capaciteit 'In het hoofdstuk capaciteitsbeheer wordt de benutte hoeveelheid capaciteit behandelt. De beschikbare capaciteit wordt de Committed Information Rate (CIR) genoemd. Deze CIR waarde geeft aan wat de maximale transmissiesnelheid is van het aansluitpunt. Bij voldoende hoge belasting van deze aansluiting zal, mits afgesproken, de BOD aansluiting in werking treden (64Kbps ISDN). Bij uitval, om wat voor reden dan ook, zal de back up verbinding opkomen. Drie onderdelen worden hier gerapporteerd. De afgenomen gemidde1de (per um) en maximale capaciteit. Het verkeer per protocol zal pas kunnen worden gerapporteerd wanneer de nieuwe versie van de netwerksoftware ge"installeerd is. Dit geldt ook voor het gebruik van de BOD en Back up opties [to].' Hierover werd dus niet gerapporteerd. Probleemafhandeling In dit hoofdstuk worden de oorzaken beschreven waardoor van de geste1de normen is afgeweken, tevens wordt er een nadere uitleg gegeven van het in actie komen van de BOD en de Back up voorzieningen. Verder wordt deze informatie aangevuld met de prestaties van, en de storingsafhandeling door de Helpdesk. Wijzigingsbebeer, het huidige aantal aansluitingen wordt hier midde1s een diagram getoond. Beveiliging (bijlage A van bet rapport), indien er zich veiligheidsbedreigende situaties voor hebben gedaan worden die in deze bijlage geme1d. Actualisering gebruikers- en bebeerdersdocumentatie (bijlage B van bet rapport), vanwege het grote aantal documenten wordt er in deze bijlage een vermelding gemaakt van de laatste versies. Maintenance window (bijlage C van bet rapport), beheer- en onderhoudstaken worden verricht tijdens de daarvoor afgesproken tijdsintervallen. In deze bijlage wordt verme1d op welke wijze de maintenance window is aangewend voor deze taken. Civility Amsterdam bv.

61



5.5

De Knelpunten

Voor het afstemmen van de overeen te komen service levels moet de mogelijkheid van objectieve rapportage over de behaalde service niveaus, en eventuele (oorzaken van) problemen die dat in de weg stonden, mogelijk zijn. Dit betekent dat het afspreken van bepaalde service niveaus aIleen zinvol is als hierover ook kan worden gerapporteerd. Hiervoor is derhalve inzicht nodig in de rapportage mogelijkheden, deze zijn onvoldoende bekend. Het ontwikkelen van een rapportage systeem voor elke applicatie afzonderlijk is een te kostbare aangelegenheid. De oplossing zou kunnen zijn het ontwikkelen van een rapportage systeem voor aile applicaties. Hierbij stuiten we echter op de grote diversiteit, qua structuur en inhoud, van de aanwezige SLAs. Een meer generieke service level overeenkomst voor aIle diensten is een oplossing, edoch het duurt voor enkele contracten nog jaren voordat het SLA herzien zal worden (hier moet de opdrachtgever dan ook nog accoord mee gaan). De oude situatie was verre van perfect de knelpunten zatten vooral in de omslachtigheid waarmee aIle gegevens verwerkt werden en de diversiteit van de systemen waaruit de gegevens gehaald moeten worden. Daamaast moet rekening worden gehouden met het gegeven dat niet aIle componenten in het netwerk zijn ingericht op het verzamelen en vrijgeven van beheerinformatie. Hierdoor werd de rapportage: * Onjuist (er werd op de verkeerde plaats gemeten) * Onvolledig (niet alles wat in het SLA stond werd gemeten) * Ondoorzichtig (rapportage methode en techniek waren onduidelijk) * Tijdrovend (veel handwerk) * Inflexibel (nieuwe deelnemers en diensten moeilijk te implementeren) Voor de deelnemers rapportage 'was het allemaal nog wel te doen' aldus de gebruiker van het oude rapportage systeem. De rapportage bestemd voor de opdrachtgever moet een overzicht geven van de performance per deelnemer. Voor het samenvoegen van de gegevens van aIle deelnemers moesten, tegelijkertijd, 62 afzonderlijke (een per deelnemer) bestanden geopend zijn. Dit was erg omslachtig en vroeg om problemen. Het totale IT-beheer bij Civility kende de volgende knelpunten [5]:

*

Complexiteit van beheer Door de grote verscheidenheid aan informatie systemen, platforms en het ontbreken van standaards is het beheren van deze omgeving zeer complex en arbeidsintensief geworden. Gezien de complexiteit is de aanwezigheid van een goed opgeleide en in vele gevallen gespecialiseerde systeembeheerder noodzakelijk om de infrastructuur operationeel te houden. Standaardisatie is een manier waarop de complexiteit van de infrastructuur verminderd en het beheer vereenvoudigd kan worden.

*

De beheersomgeving is reactief Door het onvoldoende beschikbaar en niet goed ingericht zijn van beheershulpmiddelen is de huidige (nov. 1996) werkwijze reactief. Door invoering van eenproactieve en proces gerichte werkwijze met ondersteuning van voldoende hulpmiddelen kan de kwaliteit van de dienstverlening worden bevorderd.


62



*

Beveiligingsproblemen bij GDA Binnen GDA wordt een beveiligingsniveau gegarandeerd aan de gebruikers. Deze beveiliging wordt gegarandeerd door toepassing van IP-filtering in de routers. Met het toenemende aantal routers dreigt dit onbeheersbaar te worden.

*

Beheersomgeving per contract Per contract (NUS, GISP, GDA etc.) wordt op dit moment (nov. 1996) een specifieke beheertools en -structuur bedongen. Er zijn twee Netview systemen. Er zijn meerder scripts in gebruik voor de invulling van specifieke beheertaken binnen deze contracten. Deze situatie is niet hanteerbaar meer bij uitbreiding van het aantal contracten. Beter is dit beheer als een generieke service aan te bieden. Dit wordt nog versterkt doordat er contract afhankelijkheden ontstaan (NUS gaat over GDA lopen). Deze generieke service dient flexibel genoeg te zijn om het merendeel van klant specifieke wensen in te kunnen vullen.


63



H6

Gewenste situatie

6.1

IT-beheer bij Civility

De kern van de missie van Civility Amsterdam b.v. luidt: 'het leveren van automatiseringsdiensten volgens de kwaliteitseisen overeengekomen met de klant '. Hiervoor zijn de volgende drie basiselementen nodig: klanten, personeel en materieel. Het hebben (en houden) van klanten is het belangrijkste element. Klanten kan men krijgen door het aanbieden van automatiseringsdiensten met een goede jJrijs/kwaliteit verhouding. Hiervoor zijn dus een zo laag mogelijke prijs en een zo hoog mogelijke kwaliteit vereist. Deze eisen zijn echter tegenstrijdig, dus zal een compromis (met de klanten) gesloten moeten worden. Een lage prijs is aIleen mogelijk als de kosten laag zijn en een hoge kwaliteit is uitsluitend mogelijk door de inzet van gekwalificeerd personeel en goed materieel. Personeel is (op dit moment) schaars, hiervoor moet dus, naast het bieden van goede secundaire voorwaarden, betaald worden (personeelskosten). Materieel is beduidend minder schaars, maar voor goed materieel moet ook betaald worden (materieel kosten).

De twee soorten kosten waaruit een automatiseringsdienst bestaat zijn ontwikkelkosten en kosten voor beheer. Hierbij dient opgemerkt te worden dat de totale kosten voor beheer meestal aanzienlijk hoger liggen dan voor het (eenmalige) ontwikkelen. Op beide kosten kan, met behoud van kwaliteit, slechts bespaart worden door het zo efficient mogelijk inzetten van personeel en materieel. Hier geldt dat de personeelskosten, met name voor beheer, hoger zijn dan die voor het materieel. Het verbeteren van de efficientie van het middel materieel is onder andere mogelijk door standaardisatie, dit komt vaak ook de kwaliteit ten goede. De efficientie van het personeel kan verhoogt worden door enerzijds eenvoudige en/of tijdverslindende taken te automatiseren. Anderzijds door de inzetbaarheid te verhogen, bijvoorbeeld door een meer generieke beheerstructuur (ITIL, zie hoofdstuk 6.2) en ontwikkelmethoden (SDM, zie hoofdstuk 7.1 en verder). Het opzetten van een generieke beheerstructuur is mogelijk door zoveel mogelijk overeenkomsten te creeren tussen de diverse applicaties, service niveau overeenkomsten (zie hoofdstuk 6.3), service niveau rapportages (zie hoofdstuk 6.4) etc. Hierdoor moet het mogelijk zijn om met de beperkte middelen meer klanten te voorzien van automatiseringsdiensten met een goede prijs/kwaliteit verhouding. Waarmee een concrete invulling van de bedrijfsmissie is bereikt. Op korte termijn dient de efficientie, kwaliteit en de schaalbaarheid van de beheeromgeving verbeterd te worden. Dit kan enerzijds bereikt worden door de complexiteit van de infrastructuur zelfte beperken anderzijds door een generiek Netwerk en Systems Management (NSM) framework te definieren [5]. Door de grote verscheidenheid aan informatie systemen, platforms en het ontbreken van standaards is het beheren van deze omgeving zeer complex en arbeidsintensief geworden. Civility Amsterdam bv.

65



Gezien de complexiteit is de aanwezigheid van een goed opgeleide en in vele gevallen gespecialiseerde systeembeheerder noodzakelijk om de infrastructuur operationeel te houden. Standaardisatie is een manier waarop complexiteit van de infrastructuur verminderd en het beheer vereenvoudigd kan worden.

I

Efficientie, kwaliteit en schaalbaarheid verbetering IT-beheer GCEI

I I Vermi~deren complexiteit mfrastructuur

I

I

I

Generiek NSM framework

I

I Systemen & Netwerken

I

I

I

Off-line bewaking

Beperking beheerinsp.

Figuur 6.1

I

I

I Service Level Rapportage

Verbetering User-beheer

I Gecontroleerde distirbutie

Werkplek omgeving

I

I

Verbetering Support faciliteiten

Werkplek onathankelijk heid

Verbeteren van het IT-beheer bij Civility.

Om aIle binnen Civility aanwezige objecten (de onderdelen van de IT-beheer infrastructuur) te bewaken, is een generieke methode vereist om beheerinformatie op te vragen. Zo zullen events in het informatiesysteem verschillende acties oproepen. Sommige events zijn aIleen interessant voor opname in logboeken ter verwerking in management rapportage, andere events vereisen nadere bestudering of onmiddeIlijke actie. Het is voor de bewaking van de systemen in de nacht van belang dat er een beheersysteem aanwezig is die automatisch bepaalde opdrachten kan uitvoeren bij het ontvangen van bepaalde meldingen. Bij dringende meldingen kan het beheersysteem eventueel de opdracht krijgen de semafoon van de dienstdoende systeembeheerder te activeren. Door het automatiseren van standaard beheertaken kunnen fouten worden voorkomen en mensuren worden bespaard. Er wordt vooral gedacht aan het preventief controleren van logfiles, essentiele systeem kentaIlen, etc. Automatisering van deze werkzaarnheden met het definieren van vervolg acties bij overscheiding van bepaalde drempelwaarden kan veel tijd besparen. Het is belangrijk dat goede filters en drempels gedefinieerd worden, zodat aIleen relevante informatie doorgegeven wordt aan de centrale systeembeheerder. Hierdoor kunnen systeembeheerders zich concentreren op de kritische informatie. Het gebruikers administratie proces vormt een forse inspanning in de dagelijkse operationele beheerwerkzaarnheden. Middels autorisatie formulieren moeten nieuwe gebruikers aangemaakt worden of van bestaande gebruikers rechten worden aangepast. Veelal dient dit op een aantal plaatsen uitgevoerd te worden. Te denken valt hierbij aan AIX, NT, Novell, Civility Amsterdam bv.

66



Mainframe, Data bases en applicatie omgevingen. De werkzaamheden bestaan hierbij uit het aanmaken van gebruikers en paswoorden, het aanpassen van autorisatiestructuren, het aanmaken van homedirectories etc.

6.2

Gestructureerd IT-beheer met ITIL

Inleiding ITIL Door de Britse overheid is de vraag naar een gestructureerde IT-organisatie omgezet in een daadwerkelijke actie. In samenwerking met de Central Computing en Telecom Agency (CCTA) is een bibliotheek opgezet om de IT-organisatie gestructureerder te kunnen laten functioneren: de Information Technology Infrastructure Library (ITIL). ITIL kan worden beschouwd als de beschrijving van een op de exploitatie van de ITinfrastructuur toegespitst kwaliteitssysteem [17]. Ten behoeve van de IT-dienstverlening wordt een aantal noodzakeUjke processen onderscheiden en beschreven. De kwaliteit van de dienstverlening en de toegevoegde waarde voor de afnemers staan hierbij centraal: * IT-diensten die tegemoet komen aan de behoeften van de klant(en), dit resulteert in klanten die tevreden zijn; * minder kans op het niet kunnen voldoen aan de eisen van de organisatie ten aanzien van IT-diensten; * betere comrnunicatie- en informatiestromen tussen de IT-organisatie en de klant(en); * medewerkers van de IT-organisatie beschikken over duidelijke richtlijnen ten aanzien van hun werkprocessen; * grotere produktiviteit en optimaal gebruik van vaardigheden en ervaring. Daarnaast profiteert de klant van het gebruik van ITIL binnen de organisatie. Hij is ervan verzekerd dat: * IT-diensten geleverd worden volgens gedocumenteerde procedures en de mogelijkheid bestaat om op deze procedures een audit uit te voeren; * er afspraken gemaakt worden over de eisen die gesteld worden aan de IT-dienst; * gedetailleerde informatie beschikbaar is over de kosten aan de IT-diensten; * monitorgegevens beschikbaar zijn over de afspraken die gemaakt zijn in de dienstenniveau-overeenkomsten. ITIL-tactisch Op tactisch niveau wordt het dienstenniveau bepaald en vastgelegd. Aan de ene kant dienen we te weten welke IT-diensten we leveren, aan de andere kant moeten we over deze diensten afspraken maken met de afnemers. De contacten met afnemers van de IT-diensten worden gestructureerd en met toeleveranciers worden afspraken gemaakt zodat het dienstenniveau dat met de afnemers is overeen gekomen ook door externe leveranciers wordt ondersteund. De kwaliteit van de diensten wordt met name bepaald door de beschikbaarheid en performance van een IT-dienst. Tenslotte dienen maatregelen genomen te worden om de dienstverlening voort te kunnen zetten nadat zich een calamiteit heeft voor gedaan. De service Delivery Set van ITIL behandelt een aantal tactische processen voor het beheer van informatiesystemen. Deze set beschrijft onder andere de volgende processen (zie ook fig. 6.2): Civility Amsterdam bv.

67



Beschikbaarheidsbeheer (Availability Management) Beschikbaarheidsbeheer houdt zich bezig met de beschikbaarheid van diensten. Ret moet bijvoorbeeld bekend zijn op welke tijdstippen onderhoud wordt gepleegd op het systeem. Ook het reserveren van tijd voor het herstellen van gegevens na een storing valt onder Beschikbaarheidsbeheer. Capaciteitsbeheer (Capacity Management) Capaciteitsbeheer houdt zich bezig met het ter beschikking hebben van voldoende capaciteit, nu en in de toekomst, tegen gerechtvaardigde kosten. Calamiteitenplanning (Contingency Planning) Calamiteitenplanning beschrijft hoe de dienstverlening weer zo snel mogelijk op gang gebracht moet worden nadat de dienstverlening van de IT-organisatie door een calamiteit is aangetast. Kostenbeheer (Cost Management) Kostenbeheer houdt zich bezig met het identificeren en bewaken van kosten en het eventueel doorbelasten van deze kosten aan de diverse klanten. Elke actie binnen een IT-organisatie brengt kosten met zich mee. Dienstenniveaubeheer (Service Level Management) Om tot een goede dienstverlening te kunnen komen, dienen afspraken gemaakt te worden tussen de IT-leverancier en de afnemers van deze diensten. Dienstenniveaubeheer houdt zich hiermee bezig. De afspraken worden vastgelegd in dienstenniveau-overeenkomsten (SLA). Op deze wijze weten alle betrokken partijen wat hun rechten en plichten zijn.

Beheer van de IT dienstverlening: afspraken en dienstverlening

I I

Dienstenniveaubeheer

I I

t

Uitbesteden beheer (FM)

I I

Onderhouds beheer

I

Capaciteitsbeheer Beschikbaarheidsbeheer

y

Kosten beheer

r.

I

Calamiteitenplanning Beveiligingsbeheer

t I

Operationele processen

I

I

Figuur 6.2 Beheer van de IT dienstverlening op tactisch niveau.


68



Onderhoudsbeheer (Third Party Maintenance) Het doel van onderhoudsbeheer is het plannen en beheren van onderhoudscontracten. Uitbesteden beheer (Facilities Management) Ook een bedrijf dat alles uitbesteedt zal nog een aantal zaken moeten plannen en controleren. Dit proces houdt zich bezig met de relatie tussen beide organisaties. Beveiligingsbeheer (Security Management) Hieronder valt alles wat te maken heeft met de beveiliging van de IT-infrastructuur (wordt nog niet binnen ITIL beschreven).

Voor de belangrijkste processen voIgt hier een uitgebreidere beschrijving: Beschikbaarheidsbeheer Onderzoek heeft uitgewezen dat veel organisaties niet in staat zijn te functioneren na uitval van hun computersystemen. Bedrijfsprocessen worden steeds afhankelijker van IT-diensten en in de meeste gevallen is het ondenkbaar dat men zou moeten terug vallen op een niet geautomatiseerd systeem. Om de primaire processen van de organisatie zo min mogelijk te storen moeten diensten beschikbaar zijn op het moment dat de klant er gebruik van moet maken. Hoe minder storingen voorkomen, hoe lager de kosten zijn en dat is beter voor de organisatie. Men moet kunnen vertrouwen op de aangeboden systemen en diensten. Wanneer een gebruiker een systeem niet vertrouwt zal hij het ook niet gebruiken. Dit gaat weer ten kosten van de efficiency waardoor het primaire proces van de organisatie wordt verstoord. Beschikbaarheidsbeheer geeft aan welke middelen nodig zijn voor optimale beschikbaarheid. Deze middelen dienen zo effektief mogelijk aangewend te worden waardoor de kosten worden beperkt. Het doel van Beschikbaarheidsbeheer is het optimaal pIannen, managen en controleren van de beschikbaarheid van IT-diensten. Dit kan gerealiseerd worden door onder andere de volgende acties: * verbeteren van de betrouwbaarheid * verbeteren van de beschikbaarheid * Overzicht en controle over de beschikbaarheid * behoeften afstemmen op de mogelijkheden De algehele beschikbaarheid van een dienst wordt bepaald door de beschikbaarheid van de onderdelen, hardware, netwerken, software en omgeving. De beschikbaarheid wordt berekend door de werkelijke tijd die de dienst beschikbaar is geweest te delen door de afgesproken beschikbare tijd, vermenigvuldigd met 100%. Andere performance grootheden (bijvoorbeeld responstijden, vertragingstijden, throughput etc.) zijn in hoofdzaak afhankelijk van de capaciteit en vallen derhalve ook onder dat beheersaspect. Capaciteitsbeheer In het kader van kostenbeheersing dient er in een IT-organisatie op de juiste wijze omgegaan te worden met IT-middelen. Dit is vergelijkbaar met de manier waarop een organisatie zorgt dat er voldoende produktiemiddelen zijn. Een organisatie moet zorgen dat de capaciteit van de produktiemiddelen toereikend is om de geplande activiteiten te ondersteunen. Hierbij dient Civility Amsterdam bv.

69



rekening gehouden te worden met eventuele pieken. Voor Capaciteitsbeheer geldt hetzelfde pnncipe. Voor een optimale ondersteuning van de bedrijfsprocessen dient Capaciteitsbeheer op elk moment de gewenste capaciteit te kunnen leveren. Door de voortdurende ontwikkeling met betrekking tot nieuwe technologieen, wijze van informatievoorziening, inzicht en gebruik blijft het noodzakelijk om periodiek te onderzoeken of de gebruikte middelen nog steeds in staat zijn om de bedrijfsprocessen te ondersteunen, ook in de nabije toekomst. Het Performance Management zoals dat terug te vinden is in bijvoorbeeld het OSI Management Framework, kent in ITIL geen eigen plaats. Vaak wordt het performance aspect (responstijden, vertragingstijden en aantal hertransmissies) van een netwerkdienst ondergebracht bij het capaciteitsbeheer. Calamiteitenplanning Er zijn veel situaties denkbaar waarbij de IT-dienstveriening kan wegvallen (brand, wateroveriast, diefstal, terrorisme). De gevolgen van het uitvallen van de IT-dienstveriening kunnen dermate ernstig zijn dat het van groot belang is maatregelen te treffen om de ITdienstverlening met minimale overlast en tijdveriies weer op gang te brengen.

De meeste bedrijfsprocessen zijn afhankelijk van geautomatiseerde ondersteuning. Vit onderzoek is gebleken dat 90% van de bedrijven, waar de informatievoorziening uitvalt, binnen vij! dagen failliet is [17]. Een calamiteit, is het niet meer beschikbaar zijn van een IT-dienst waardoor de informatieverstrekking geheel of gedeeltelijk wegvalt. Wanneer een organisatie getroffen wordt door een calamiteit kan dit grote gevolgen hebben voor het bedrijfsproces. Om dit te voorkomen moeten organisaties ervoor zorgen dat de continu'iteit van het bedrijfsproces gewaarborgd is. De kosten van het herstellen van een calamiteit kunnen enorm zijn. Door het nemen van voorzorgsmaatregelen kunnen de herstelkosten teruggedrongen worden. Calamiteitenplanning is bedoeld om deze maatregelen vast te leggen, te toetsen, te testen en aan te passen aan de veranderingen die in een IT-organisatie plaatsvinden. Kostenbeheer Steeds meer bedrijven veranderen in business-unit georienteerde organisaties. Deze businessunits worden afgerekend op de kosten die gemaakt worden om de activiteiten uit te voeren. Hierdoor ontstaat een verzakelijking tussen klanten en IT-organisatie met betrekking tot de afname van IT-diensten. Klanten zijn in het algemeen best bereid om voor IT-diensten te betalen. De prijs die voor deze diensten betaald moet worden dient dan wel afgestemd te zijn op wat gangbaar is op de markt, hierdoor wordt het noodzakelijk dat de IT-organisatie de kosten inzichtelijk maakt voor de klant.

Door de verzakelijking wordt steeds vaker gewerkt met budgetten. De wijze waarop met budgetten wordt omgegaan verandert; daar waar vroeger een budget opgemaakt moest worden om in het nieuwe jaar gegarandeerd te zijn van hetzelfde budget wordt steeds vaker gebruik gemaakt van de variabelen die het budget voor het komende jaar bepalen. Zowel voor IT als voor de klant geeft dit de mogelijkheid om efficienter om te gaan met de financiele middelen. Civility Amsterdam bv.

70


Structureren van IT-beheer met ITIL, ontwikkeling van een Service Level Rapportage systeem met SOM

Andere redenen waarom kosten inzichtelijk gemaakt moeten worden en waarom gewekt wordt met doorbelasting naar de klant zijn: * De klant bewust laten worden van de mate waarin hij gebruik maakt van ITondersteuning; * terugverdienen van investeringen; * marktconforme prijsstelling; * concurrentie-overwegingen. Dienstenniveaubeheer Het gebruik van automatiseringsmiddelen neemt nog steeds toe. Klanten raken steeds meer op de hoogte van de mogelijkheden van automatisering. Daarom vragen klanten steeds meer functionaliteit van de gebruikte informatiesystemen. Om aan de vraag van de klant te kunnen voldoen dient bij de IT-organisatie bekend te zijn wat de klant wil. Niet aan elke eis of wens kan of mag invulling worden gegeven. Het proces Dienstenniveaubeheer is ingericht om de behoefte van de klant af te stemmen op de mogelijkheden die de IT-organisatie kan bieden.

Op deze wijze wordt een zakelijke manier van dienstverlening tussen de klant en de ITdienstverlener verkregen. Klant en IT-organisatie sluiten in overleg overeenkomsten af, zodat iedereen weet welk niveau van dienstverlening geboden wordt en onder welke voorwaarden. Hierdoor is het mogelijk om de diensten op een zakelijke manier aan te bieden. Om dit te bereiken moet de IT-organisatie vooraf vaststellen op welke wijze diensten geleverd kunnen worden en welke niveauverschillen daarin gehanteerd worden. Hiervoor moet een dienstencatalogus worden opgezet. Om er zeker van te zijn dat de door de IT-organisatie geleverde ondersteuning afgestemd is op de behoefte van de klant dienen beide partijen aan te geven welke verwachting men van elkaar heeft. Het is in het belang van de organisatie dat deze afstemming zodanig is dat alle middelen optimaal ingezet en gebruikt worden. Aan de zijde van de klant is de IT-organisatie een van de leveranciers van produkten en diensten. De klant wenst de IT-organisatie ook steeds vaker als zodanig te benaderen. Om hierbij niet direct in te springen op het concept 'U vraagt, wij draaien' wordt hierbij rekening gehouden met de mogelijkheden die de organisatie aangeeft. Aan de zijde van de IT-organisatie is de klant een van de vele klanten die gebruik maakt van de geleverde diensten. Voor de IT-organisatie betekent dit dat meerdere afspraken nagekomen dienen te worden waarbij rekening gehouden wordt met diverse niveaus van dienstverlening. Wanneer een goede afstemming plaatsvindt wordt dit vastgelegd in een overeenkomst zodat beide partijen elkaars verwachtingen onderkennen en beide partijen zich tot doel stellen zich aan de afspraken te houden. De dienstenniveau-overeenkomsten dienen regelmatig herzien te worden om na te gaan of de gemaakte afspraken nog steeds haalbaar zijn. De klant speelt hierin ook een belangrijke rol, want ook zijn eisen en wensen zijn aan verandering onderhevig. Dienstenniveaubeheer bewaakt de gemaakte afspraken. Afwijkingen in de dienstverlening dienen gerapporteerd te worden.


71



ITIL-operationeel Op operationeel niveau worden de diensten werkelijk gerealiseerd. Hierbij dienen zo min mogelijk verstoringen in de dienstverlening op te treden en is het tevens een vereiste om de dienstverlening aan te passen aan de veranderende behoeften van de klanten. Er dient dus een optimale afstemming gevonden te worden tussen enerzijds de stabiliteit van het systeem en anderzijds de flexibiliteit van het systeem om zich aan te passen aan de voortdurend wijzigende behoeften van de klanten. De Service Support Set van ITIL behandelt een de operationele processen. Zie ook figuur 6.3. Operationele processen: flexibiliteit en stabiliteit

Relatiebeheer leveranciers

Wijzigingsbeheer

t Probleem beheer

Helpdesk

r.

t

r--.

Configuratiebeheer

t Programmatuur beheer Installatie en acceptatie van apparatuur

Onderhouds~ beheer

~

•

Omgevingsbeheer

t Computerbeheer I Netwerkbeheerl Lokaal beheer

Figuur 6.3 Operationele processen in een IT-beheer omgeving Configuratiebeheer (Configuration Management) Een organisatie moet in staat zijn haar bedrijfsmiddelen te beheren, zeker als deze middelen van vitaal belang zijn voor de bedrijfsvoering. IT en de middelen die daarbij gebruikt worden nemen een steeds belangrijkere plaats in. Veel IT-organisaties werken al met een of andere vorm van Configuratiebeheer. Vaak worden wijzigingen in de IT-infrastructuur echter niet meteen geregistreerd en soms wordt registratie helemaal vergeten. In de meeste gevallen vindt de registratie van IT-middelen plaats met behulp van een Configuratie-Management Database (CMDB). Naast de activiteiten om de database betrouwbaar te houden, heeft Configuratiebeheer ook de taak om de andere processen te voorzien van informatie over de IT-infrastructuur. Helpdesk De toename van het gebruik van de door de IT-organisatie geboden diensten en een verschuiving van eenvoudige programma's naar uitermate gecompliceerde transactiegestuurde systemen heeft tot een hogere werkdruk geleid binnen de IT-organisatie. Gebruikers die niet


72



tevreden zijn over de dienstverlening van de IT-organisatie moeten een centraal punt hebben om hun vragen en klachten kwijt te kunnen: de Helpdesk. Wanneer er een verstoring in de infrastructuur optreedt die het niveau van de ITdienstverlening verlaagt, een incident, moet deze bij de Helpdesk gemeld worden. Op deze wijze kan namelijk centraal inzicht verkregen worden in de aantallen, gevolgen en oplossingen van incidenten. Incidentverloop Detectie & Registratie Classificatie

Incident

& toewijzing

Beheer

&

Voortgang

Figuur 6.4 Incidentverloop. Probleembeheer (Problem Management) In elke organisatie komen fouten in de infrastructuur VOOL Ook al werken we met de meest betrouwbare voorzieningen binnen een IT-organisatie, de dienstverlening zal op de een of andere manier toch verstoord kunnen worden. Om een stabiele omgeving te verkrijgen moeten fouten (en de oorzaak daarvan) worden weggenomen. Binnen de IT-infrastructuur is Probleembeheer hiervoor verantwoordelijk.

--.

--+ Wijzigingsvoorstel BeoordeJen en

~en

C

Bouw~

-----'Testen

--.

--.

Implementeren -

--.

L....------------------------Evalueren

Afsluiten

I

Figuur 6.5 Wijzigingstraject.


73



Wijzigingsbeheer (Change Management) Elke wijziging in de infrastructuur is een potentiele bedreiging voor de stabiliteit van het systeem. Door gebruik te maken van gestandaardiseerde methoden en technieken voor het uitvoeren van wijzigingen worden deze onder controle gebracht. De kans, dat een verstoring van de dienstverlening plaatsvindt door een gewijzigd configuratie-item, wordt dan kleiner.

Wijzigingen komen niet aIleen voor in programmatuur en apparatuur, maar ook in documentatie, overeenkomsten en procedures. Elke wijziging die invloed heeft op het geleverde dienstenniveau dient onder controle gebracht te worden. Zie figuur 6.5 voor een schematische voorstelling van het wijgigingstraject. Andere operationele processen die door ITIL worden onderscheiden: Programmatuurbeheer (Software Control & Distribution) Programmatuurbeheer beheert aIle programmatuur-items en zorgt ervoor dat aIle nieuwe programmatuur gecontroleerd wordt ingevoerd. Lokaal beheer (Management of Local Processors & Terminals) Steeds meer IT-middelen worden geplaatst buiten de IT-organisatie en komen deels onder controle van de klant. Denk hierbij onder andere aan de steeds krachtiger wordende PC's. Business-managers komen steeds meer tot de conc1usie dat IT-middelen te belangrijk worden voor het primaire proces van de organisatie om door technisch specialisten (IT-organisatie) te worden beheerd. Men wil het zelf onder controle hebben. Ret doel van lokaal beheer is het door middel van procedures er voor zorgen dat gebruik van IT-middelen, buiten de ITorganisatie, worden gecoordineerd. Lokaal beheer houdt zich bezig met installatie van hard- en software in de IT-infrastructuur bij de gebruiker. Installatie van grote gedistribueerde systemen en 'downsizing' van mainframe naar PC vallen niet binnen dit proces. Installatie en acceptatie van apparatuur (Computer Installation & Acceptance) Dit Proces bevat de richtlijnen voor organisaties met betrekking tot het plannen en beheren van de installatie en acceptatie van computer apparatuur in de IT-infrastructuur. Computerbeheer (Computer Operations) Computerbeheer houdt zich bezig met het beheren van computer hardware en systeem software, die nodig zijn voor het leveren van de diensten. Netwerkbeheer (Network Management) Dit proces is specifiek gericht op het beheer van communicatie-netwerken. Bijvoorbeeld een telefoonsysteem of een dienst welke gebruik maakt van het computemetwerk. Ret belang van beheer van telecommunicatienetwerken is, dat: - Steeds meer organisaties afhankelijk worden van IT-diensten die beschikbaar zijn via een netwerk. - Netwerken steeds complexer worden en dus moeilijker beheersbaar. - Steeds meer nieuwe eisen aan de infrastructuur worden gesteld en netwerkbeheer moet daar flexibel mee om kunnen gaan. - Ret leveren van kwalitatief goede IT-diensten is mede afhankelijk van de netwerken. - Tevredenheid van de klanten.


74



Omgevingsbeheer (Environmental sets) De verzamelnaam voor alle processen die zich bezighouden met de IT-omgeving. Dit is aan de ene kant de klantomgeving (omgevingsfactoren voor personal computing) en aan de andere kant de omgeving die nodig is voor een rekencentrum (airconditioning, stroomvoorziening, koelinstallatie, lokatie hardware, etc.).

6.3

Generieke Service Level Agreements

Door het uniformeren (qua structuur en inhoud) van de Service Level Agreements is het eenvoudiger om het daarbij horende beheer generiek in te richten en de rapportage te standaardiseren. Een SLA bevat (zie ook hoofdstuk 5) een beschrijving van de functionaliteit van de bewuste applicatie en de kwaliteitsniveaus van de applicatie zelf en van het beheer van deze applicatie. De structuur van een Service Level Agreement kan opgehangen worden aan de volgende ITIL processen: beschikbaarheidsbeheer, capaciteitsbeheer (met performance aspecten), Helpdesk, probleembeheer, wijzigingsbeheer, configuratiebeheer, beveiligingsbeheer, calamiteitenplanning, onderhoudsbeheer en documentatiebeheer. Deze processen vangen samen alle SLAitems zoals die nu bestaan. De inhoud van de SLAs moeten overeen gaan komen op zowel de grootheden (rapportage items zoals definities van beschikbaarheid, reactie tijd, oplossingstijd etc.) als eenheden (normen, bijvoorbeeld beschikbaarheid in procenten per maand). Zie ook bijlage 4.

6.4

Het Rapportage systeem

Verschillende kennisbronnen zijn aangeboord om te bepalen welke eisen en/of wensen er bestaan voor een dienstenniveau-rapportage (Service Level Report, SLR) systeem. De geraadpleegde bronnen zijn literatuur, interne rapporten, overeenkomsten (SLAs en DAP) en personen die direct met het GDA of applicaties en de daarbij behorende rapportages te maken hebben. Literatuur In de geraadpleegde literatuur (veelal engelstalig) over Netwerkmanagement behandeld het Service Level Rapport onder de noemer 'Performance Measurement'. Rapportage items welke regelmatig hierin voorkomen zijn [1], [2], [3], [4] en [17]: * Responce time I delay (vertragingstijden van het netwerk) * Quality of Service, * Congestion (stagnatie) * Availability (beschikbaarheid) * Performance history (oudere gegevens, ter vergelijking) * Thresholds and Exeptions (drempelwaarden en uitzonderingsgevallen) * Accuracy (nauwkeurigheid of mate van foutloosheid) * Throughput (doorvoersnelheid) * Utilization (gebruik)


75



Voor het zelfde item wordt soms een verschillende definities gebruikt, hier volgen enkele algemene definities: Beschikbaarheid De definitie van beschikbaarheid luid: 'the fraction of time during which i1 software component or system is functioning acceptably' .

*

'fraction of time '; de beschikbaarheid van een component kan worden uitgedrukt als de Mean Time To Failure (MTTF) van die component gedeeld door de Mean Time Between Failures (MTBF) van die component. Er geldt dat de MTBF gelijk is aan de MTTF plus de Mean Time To Repair (MTTR). In formulevorm:

Availability = MTTF/MTBF

* 100% = MTTF/(MTTF+MTTR) * 100%

Availability is ook uit te drukken in termen van servicetijd (S), de openstellingstijd van een dienst, en Downtijd (D): Availabilty = (S-D)/S

* 100%

Merk op dat het in dit verband niet gaat om kalendertijd, maar om tijd die valt binnen de service-uren. Ais een systeem kapot gaat buiten de service-uren, wordt de tijd tussen het moment van falen en het begin van de service-periode niet meegerekend bij de Time To Repair. Daamaast moet de Time To repair niet te letterlijk worden genomen: als een systeem na een failure door op nieuw opstarten weer 'functioning acceptably' is, is het dus 'gerepareerd' in de context van beschikbaarheid.

* 'a software component or system '; het is goed mogelijk de beschikbaarheid van een systeem op te splitsen in de beschikbaarheid van verschillende onderdelen van het systeem. Zo kan de ene applicatie op een bepaald moment wel beschikbaar zijn, maar de andere niet. Ook kan de applicatie misschien op de ene werkplek weI beschikbaar zijn en op de andere niet. Bij het bepalen van de uiteindelijke beschikbaarheid van alle te onderhouden software en hardware zullen de beschikbaarheids 'scores' van de verschillende onderdelen samen genomen moeten worden. De eenvoudigste manier om dit te doen is door af te spreken dat een systeem down is zodra een of meer van de componenten niet beschikbaar zijn. Dit is meestal het geval in situaties waarin de componenten afzonderlijk geen functie vervullen voor de gebruiker, zoals de onderdelen van een PC (monitoer, toetsenbord, harde schijt). Ais de afzonderlijke componenten weI een functie vervullen, bijvoorbeeld verschillende onderdelen van een applicatie die apart kunnen worden gebruikt, kunnen er rekenregels worden afgesproken om de beschikbaarheid van de onderdelen om te rekenen naar een beschikbaarheid voor het hele systeem. Echter, als de gebruikers belang hyebben bij de beschikbaarheid vcan elk van de onderdelen van een systeem is het misschien verstandiger per onderdeel de beschikbaarheid af te spreken.

* 'functioning acceptably'; een systeem is volgens de definitie beschikbaar als het acceptabel functioneert. Een onderhoudsorganisatie zal dus met haar klant moeten afspreken wanneer een systeem acceptabel functioneert en wanneer niet. In principe kan het acceptabel functioneren worden vastgelegd in termen van de componenten van een (hardware- of software-)systeem. We kunnen bijvoorbeeld afspreken dat een PC beschikbaar is als zowel Civility Amsterdam bv.

76



de monitor als het toetsenbord als de interne onderdelen (processor, geheugen, harddisk) beschikbaar zijn. Maar, uiteindelijk moeten we het acceptabel functioneren van een component toch afspreken zonder dat te doen in termen van de onderdelen van die component. Mogelijkheden hiervoor zijn: * beschikbaarheid definieren in termen van de specificaties van het systeem: een systeem is niet beschikbaar als het niet volgens de specificaties functioneert; * in termen van de bedrijfsfuncties die het systeem ondersteunt: een systeem is niet beschikbaar als de functies die het systeem dient uit te voeren of te ondersteunen niet voldoende kunnen worden uitgevoerd; * de gebruiker bepaalt wanneer het systeem niet beschikbaar is, met andere woorden, zodra de gebruiker aangeeft niet langer met het systeem te kunnen werken, is het systeem niet beschikbaar. Vaak is het inzichtelijker om niet over beschikbaarheid te praten maar over nietbeschikbaarheid, bijvoorbeeld uitgedrukt in uren downtijd per jaar. Een beschikbaarheid van 99,9% of van 99,99% lijkt niet veel te verschillen, maar uitgedrukt in uren per jaar kan het gaan om 500 uur, respectievelijk 50 uur downtijd. Vooral bij de communicatie met de klant zou dit kunnen helpen. Het opstellen van een meetprogramma is een iteratief proces. Het is (veelal) a priori niet duidelijk welke gegevens belangrijk zijn. Een mogelijkheid is dan om zoveel mogelijk vast te leggen. Dat vergt veel investering, en maakt analyses lastiger. Beter is het om een meetprogramma klein en voorzichtig op te starten, en op basis van eerste resultaten te besluiten tot bijstellingen ofuitbreiding [40]. Responstijd: In de meerderheid van de gevallen verstaat men onder de 'customer responce time' de tijd die verstrijkt tussen het indrukken van de enter-toets en de ontvangst van het laatste responskarakter op het aangesloten apparaat. Zie tevens figuur 6.6. Voor rapportage doeleinde zijn er tenminste drie niveaus van relevante responstijden: * Totale responstijd * Netwerk vertragingstijd * Verwerkings-knoopunten vertraging

De volgende wensen werden geuit in diverse interne rapporten en overeenkomsten. Een belangrijk onderdeel van het outsource contract (SLA) tussen Civility en de klanten is de rapportage van beschikbaarheidscijfers over verschillende informatiesysteem componenten. In de oude situatie (nov. 1996) vond service level reporting plaats door middels verschillende tools, op verschillende niveaus informatie te verzarnelen [5]. Een betere ondersteuning kan bestaan uit een expert-systeem dat de gerealiseerde prestaties van het informatiesysteem direct relateert aan de met de klant overeengekomen service levels. Die relatie maakt het mogelijk om enerzijds proactief te reageren op verstoringen in het netwerk en anderzijds de klant te rapporteren over de kwaliteit van het informatiesysteem. Hierdoor wordt trendanalyse betreffende het informatiesysteem mogelijk. Een geautomatiseerde Service Level Reporting zorgt er ook voor dat de gerapporteerde cijfers, objectief, te reproduceren en toetsbaar zijn [5].


77



User Characters User Time Think Time

Entering Time Input

L

Queuing Time

\

~

Subsystem Service

Service e Tt

i I.

)me

V

Output

J ~

r

Responce Time

" System Responce Network Time End-User Time System Characters

Responce Oec.l (First Character)

DeC 2 (Last Character)

Dec. 3 (Keybord Unlock)

Figuur 6.6 Gebruikelijke responstijd definitie. De rapportages hebben als doel de gerealiseerde prestaties van de dienstverlening zoals neergelegd in het SLA, op hoofdlijnen te confronteren met de overeengekomen of te verwachten normen [20]. Eisen aan het Rapportage systeem bekeken vanuit IIIL: ITIL (op tactisch niveau) Beschikbaarheidsbeheer (Availability Management) Houdt zich bezig met de beschikbaarheid van diensten, bijvoorbeeld door het plannen van onderhoudsperiodes en het reserveren van tijd voor het herstellen van de gegevens vallen hier onder. Hierover dient het volgende gerapporteerd te worden, de norm (SLA) van de beschikbaarheid en de gerealiseerde beschikbaarheid. Tevens moet een diagram in de rapportage opgenomen te worden met oude en nieuwe gegevens om zo het herkennen van trends mogelijk te maken. In de documentatie behorende bij het SLR systeem moeten tevens de procedures te vinden zijn die naar de oplossing leiden van de volgende problemen. Wat moet er gebeuren als de gerealiseerde beschikbaarheid chronisch onder de norm ligt? Hoe zit het met de beschikbaarheid van het SLR systeem zelf? Capaciteitsbeheer (Capacity Management) Het ter beschikking hebben van voldoende capaciteit, nu en in de toekomst, tegen gerechtvaardigde kosten. Hierover dient het volgende gerapporteerd worden, de gebruikte capaciteit en hoe deze staat tot de beschikbare capaciteit. Procedures voor de volgende problemen: Hoe houd je in de gaten of de omgeving de nieuwe klanten en/of diensten nog weI aankan, de responstijden niet te groot worden? Wat is de te volgen procedure wanneer er problemen m.b.t. de capaciteit worden gesignaleerd?


78



Dienstenniveaubeheer (Service Level Management) Er dienen afspraken met de afnemers van diensten gemaakt te worden over de te bieden service niveaus, zodat alle betrokken partijen weten wat hun rechten en plichten zijn. Deze staan vermeldt in het SLA en het DAP. Beveiligingsbeheer (Security Management) Hieronder valt alles wat te maken heeft met de beveiliging van de IT-infrastructuur (wordt nog niet binnen ITIL beschreven). In de documentatie komt te staan aan welke beveiligingsnormen het SLR systeem moet voldoen en welke procedures daar borg voor staan.

ITIL (op operationeel niveau) Configuratiebeheer (Configuration Management) Dit proces brengt enerzijds de IT-infrastructuur onder controle door de componenten vast te leggen (de Configuratie-Items) die gebruikt worden bij de totstandkoming van de ITdienstverlening, anderzijds verzorgt dit proces de informatievoorziening over de ITinfrastructuur aan de andere processen. Informatie rond de toestand en ontwikkelingen van de infrastructuur, de configuratie items betrokken bij een wijziging en de mutatiegraad van de infrastructuur, moet in een SLR opgenomen worden. Helpdesk Het proces dat gericht is op afhandeling van verstoringen (incidenten) in de ITdienstverlening. Rapportage van het aantal incidenten, uitgesplitst naar dienst, impact, categorie en gebruikersgroep; de gemiddelde en maximale storingstijd en de verdeling van de storingstijd. Probleembeheer (Problem Management) Het proces probleembeheer zorgt ervoor dat fouten in de IT-infrastructuur worden weggenomen of voorkomen. Bestede tijd aan onderzoek en diagnose, een korte beschrijving van reeds ondernomen acties en nog te ondernemen acties, dienen in de rapportage opgenomen te worden., In de procedures bij het SLR systeem komt te staan wie wat moet doen bij welke problemen. Wijzigingsbeheer (Change Management) Alle wijzigingen in de IT-infrastructuur moeten aangemeld worden bij wijzigingsbeheer. Dit proces zorgt er verder voor dat deze wijzigingen op een systematische manier onder controle worden gebracht zodat aan wijzigingen gerelateerde problemen voorkomen worden. Rapportage van uitgevoerde wijzigingen en de resultaten daarvan. In de documentatie moet duidelijk staan wie de eventuele wijzigingsaanvragen verwerkt en wie eventuele wijzigingen kan aanvragen. Calamiteitenplanning (Contingency Planning) Over de oorzaken en de gevolgen van opgetreden calamiteiten dient gerapporteerd te worden. Zaken als verloop van de uitwijkprocedure en de back-up zijn hier een onderdeel van.

In de maandelijkse rapporten dient volgens overeenkomst, Dossier Afspraken en Procedures (DAP) het volgende gerapporteerd te worden: Civility Amsterdam bv.

79



* gemelde incidenten (omschrijving, nummer, duur en status). * geconstateerde problemen (omschrijving, nummer, duur en status). * bereikbaarheid Service-desk (openstellingsuren, binnenkomende en doorverbonden gesprekken, aantal GDA meldingen, aantal gesprekken in 'long wait', binnenkomende lijnen met aIle toestellen in gesprek, gemiddelde wachttijd en tijdens wachten afgebroken binnenkomende lijnen). * beschikbaarheid (koppelingen met exteme netwerken, GDA-opties, het netwerk als geheel). * capaciteitsbeheer (een keer per kwartaal: maximale capaciteit in percentages van de eIR waarde, per protocol de mate van bezetting). De rapportage dient binnen vijf werkdagen na de laatste werkdag van de maand verstuurd te worden aan de deelnemers en de opdrachtgever. Indien van een deelnemer meerdere aansluitingen tot een contract behoren wordt een rapport gemaakt, waarin de overzichten van al deze aansluitingen zijn opgenomen. De meetgegevens worden gedurende minimaal een jaar bewaard. De volgende wensen zijn afkomstig van enkele direct betrokkenen, de wensen zijn geYnventariseerd door middel van overleg en inleving. Opdrachtgever, gemeente Amsterdam De opdrachtgever verlangt van een rapport een duidelijk overzicht van het totaal. Hij wil inzicht hebben in de gerealiseerde performance en deze vergelijken met de (mede door hem) gestelde normen. Tevens is het belangrijk om te zien welke diensten er allemaal afgenomen worden door de deelnemers. Ook de opgetreden problemen in het netwerk, de oorzaken hiervan en de daarop genomen acties zijn voor de opdrachtgever van belang. De opdrachtgever moet namelijk weten hoe het produkt in de markt staat om zo eventueel nuttige wijzigingen te bedenken. Deelnemer De deelnemer koopt een bepaalde dienst en is derhalve geYnteresseerd in het antwoord op de vraag of hij waar voor zijn geld krijgt. Per contract is er een contactpersoon aangesteld, aangezien die persoon niet altijd een louter technische achtergrond heeft (maar bijv. een commerciele) wordt er met verschillende ogen naar de rapportages gekeken. De rapportages moeten zodoende vanuit verschillende standpunten een compleet beeld geven van hetgeen zich rond hun GDA-aansluiting afspeelt. Enkele vragen die er zoal gesteld worden door de deelnemers zijn: Welke betrouwbaarheid heb ik gekregen t.o.v. waar ik voor betaald heb? Wat heb ik gebruikt aan capaciteit en diensten, heb ik meer ofminder diensten nodig? Wat waren de oorzaken van de door mij ondervonden problemen en wat is/wordt er aangedaan? Hoe vaak zijn de door mij aangeboden diensten gebruikt en door wie? Hoofd - PH Het hoofd van de afdeling Midrange Verwerking - Produktie&Beheer is geYnteresseerd in wat er aan de deelnemers is geleverd en hoe dit zich verhoudt ten opzichte van het SLA. De invoering van een goed werkend Service Level Rapportage systeem moeten bijdragen aan het proactief reageren op storingen en het mogelijk maken capaciteitsbeheer. Tevens moet het


80



SLR bijdragen aan het verrninderen van het aantal incidenten en het sneller opgelost worden van de incidenten. Op deze manier wordt namelijk het gerealiseerde Service Level verhoogd.

Projectleider - GDA De volgende punten werden tijdens het gesprek naar voren gebracht: * inforrnatie rond Bandwidth On Demand en Back up, hoe vaak en hoelang worden deze diensten gebruikt; * wat doe je als de Netwerkmanagement Machine uitvalt met het gemis aan meetgegevens; * duidelijke toelichting bij de gepresenteerde gegevens; * een aantal apparaten wordt nog niet actiefbewaakt (3270 Gateway, centrale Email omgeving, Nameservers, koppelingen met externe netwerken en de relay host opnemen); * aanbieden van Internet in de toekomst, wat moet hier van in rapportage op genomen worden * gebruikersvriendelijk, 'een druk op de knop'. Projectleider - VIB (Verbetering van bet IT Bebeer) 'Het realiseren van een systeem dat de gerealiseerde prestaties van het inforrnatiesysteem direct relateert aan de met de klant overeengekomen service levels. Die relatie maakt het mogelijk om enerzijds proactief te reageren op verstoringen in het netwerk en anderzijds de klant te rapporteren over de kwaliteit van het informatiesysteem. Hierdoor wordt trendanalyse betreffende het inforrnatiesysteem mogelijk. ' 'Een geautomatiseerde Service Level Reporting zorgt er ook voor dat de gerapporteerde cijfers, objectief, te reproduceren en toetsbaar zijn.' 'Inventariseer problemen en ken hier een prioriteit aan toe, kijk hierbij ook naar rapportages voor andere diensten dan het GDA (deze moeten in een later stadium ook worden verbeterd). Probeer niet al te afuankelijk te worden van een bepaald netwerkmanagement systeem, zoals Netview (IBM/Tivoli TME-IO). Service Level Manager - GDA (gebruiker rapportage systeem) De SLM van het GDA, oftewel de gebruiker van het rapportage systeem maakte de volgende wensen kenbaar: * de beschikbaarheid van Email in de rapportage opnemen * afgenomen capaciteit aan seriele poort meten en niet aan ethemet zijde * het gebruik van ISDN (BOD & Back up) in de rapportage opnemen * in de gepresenteerde diagrammen ook de gegevens van voorgaande (zes) perioden opnemen * de beschikbaarheid v.d. Gateway in de rapportage opnemen * incidenten gestructureerd opnemen in de rapportage * gegevens rond change management in de rapportage opnemen * inforrnatie rond toegangsregelingen GDA-gebruikers onderling (?) * zoveel mogelijk automatisch genereren van het rapportage, nu erg arbeidsintensief * EENVOUD, dus het tegenovergestelde van het oude systeem

Klanten in bet algemeen Klanten zijn in het algemeen gernteresseerd in de rapportage items/aspecten: - bevestiging van zijn/haar waameming; - oorzaak van tekortkomingen (niet in technische details); - wat gaat er aan gedaan worden, oplossingstraject; - met ingang van wanneer de aanpassingen ingevoerd; - status van openstaande problemen en wijzigingen. Civility Amsterdam bv.

81



Algemene eisen aan een rapportage systeem. De volgende eisen gelden in zijn algemeenheid aan een rapporterend informatiesysteem, zie ook tabel 4.1: Correct, de gepresenteerde gegevens moetenjuist zijn. Duidelijk, de gepresenteerde gegevens moeten eenvoudig te begrijpen zijn. Flexibel, het systeem moet eenvoudig aangepast kunnen worden aan nieuwe wensen. Reproduceerbaar, in verband met archivering. Gebruikersvriendelijk, goede documentatie en weinig repeterende handelingen, dus hou het eenvoudig en automatiseer zoveel als mogelijk. Volledigheid, er wordt met verschillende ogen naar het rapport gekeken, voor iedereen moet er instaan wat hij nodig heeft om beslissingen te kunnen maken. Trends, bijvoorbeeld door naast nieuwe gegevens ook enkele oude gegevens afte drukken.

De volgende situatie zal worden nagestreefd in het verdere verloop van dit project. Ret zodanig verbeteren van de rapportages, welke komen uit de Netwerk Management Machine (NMM) en aangesloten computersystemen dat er een eenvoudig, duidelijk en volledig rapportage systeem ontstaat. Om dit mogelijk te maken wordt er met begrippen, documentatie normen en probleem benaderingen zoals beschreven in ITIL gewerkt.

H etGDA en de applicaties

Meten van de Performance v.d. componenten

Rapportage afdrukken, een per deelnemer en een voor de opdrachtgever

~

Verzamelen performance gegevens

De Rapporten

~ Functies binnen het Service Level Rapportage systeem

~

Gegevens opsplitsen naar: dienst, aansluiting en klant

Gegevens bewerken zodat ze begrijpelijk gepresenteerd kunnen worden

,-------

Gegevens bewerken zodat ze in een Spread Sheet gebruikt kunnen worden

Figuur 6.7 Functiemodel van het Service Level Rapportage systeem. De eenvoud van het SLR systeem moet bewerkstelligd worden door een modulaire opbouw, goede documentatie en duidelijke procedures. De duidelijkheid moet toenemen door, betere uitleg bij de gepresenteerde gegevens, opname van historische gegevens, genormeerd en gerealiseerd service niveau duidelijk af te beelden en correcte meetgegevens in zinvolle grafieken te zetten. Ret rapporteren over de beschikbaarheid en de gebruikte capaciteit van aIle afgenomen diensten (en opties) en belangrijke netwerkelementen komt de volledigheid ten goede. De procedures rond geconstateerde afwijkingen in het rapportage systeem (bijv. na uitval van de Netwerk Management Machine) worden ook in de uitvoering opgenomen, net als de Civility Amsterdam bv.

82


~


bruikbaarheid in de toekomst (bijv. nieuwe diensten zoals Internet). De, binnen het SLR systeem, te onderscheiden functies zijn weergegeven in figuur 6.7. De ontwikkeling van het rapporterende informatiesysteem komt in hoofdstuk 7 aan bod.

6.5

Toekomstvisie op IT-beheer

Vanuit de gebruikers Door de wensen van de gebruiker in een IT-beheerorganisatie als uitgangspunt te nemen kunnen we iets zeggen over de toekomst van het IT-beheer. Eerst moeten we dus te weten komen wat de wensen zijn van de gebruiker. Hiervoor is literatuur onderzoek gedaan dat de volgende (algemene) gebruikerswensen naar voren bracht [1], [3], [24], [26], [28] en [29]. Hieronder staan de diverse wensen genoemd en worden ze in het kort behandeld.

Het verzekerd zijn van een continue dienst, gekarakteriseerd door een hoge beschikbaarheid en korte responstijden, ondanks groei en verandering. Gebruikers zijn gernteresseerd in het onderhouden van een overeengekomen niveau van diensten. Dit kan leiden tot verbinden van de apparatuur van eindgebruikers met lokale en/of op afstand opgestelde rekenfaciliteiten door punt-punt, meerpunts communicatie verbindingen of door het gebruik van LANs, WANs of meer specifieke communicatie oplossingen. Beheersbaarheid op dit niveau vraagt om krachtige meettechnieken in zowellogische als fysieke componenten van de IT-infrastructuur. Veranderende technologie en groei mogen het serviceniveau niet aantastten. Gebruikers willen beschikken over mogelijkheden tot het zoveel mogelijk automatisch herstellen, opvangen en omzeilen van falende netwerk elementen door integratie van fysieke en logische netwerkelementen. Vroegtijdige detectie en goede alarm correlatietechnieken kunnen helpen bij het snel maken van een probleem diagnose. Met als resultaat dat de juiste strategie voor het repareren, opvangen en omzeilen van falende componenten snel geselecteerd en germplementeerd kan worden. Kunstmatige intelligentie kan een sleutelrol gaan spelen in deze activiteit. De gebruikers willen de mogelijkheid hebben om voluit te kunnen werken zelfs als belangrijke netwerkelementen het hebben begeven. Krachtige back-up componenten en procedures voor zowel de fysieke als de logische segmenten van het netwerk moeten ertoe bijdragen dat de diensten zonder kwaliteitsverlies beschikbaar blijven tijdens het oplossen van het incident. Van het netwerkmanagement wordt verwacht dat het de herstel activiteit, als onderdeel van het 'fault management', leidt en overziet. Gebruikers willen beschikken over toepassingen voor het bewaken van, en stellen van diagnoses bij, condities die niet voldoen aan de behoefte van alle netwerkgebruikers, inclusief de systeemsoftware en applicaties. Niet alleen de fysieke en de logische componenten maar ook een deel van de serversoftware, database activiteiten en toepassingen moet hierbij inbegrepen worden. Door dit te doen kan echt end-to-end netwerkmanagement aan de gebruikers geboden worden. Real time of bijna real time analyse van de netwerkperformance. De gebruikers verlangen real time of bijna real-time informatie voor het vaststellen van performance trends en drempelwaarden. Vroegtijdige herkenning van 'bottlenecks' in de performance en acties om Civility Amsterdam bv.

83



dit te corrigeren (belasting verdeling, parameter veranderingen en het selecteren van altematieve routes) kunnen helpen bij het herstellen van de service levels tot het verwachtingsniveau. Krachtige meettechnieken met weinig overhead en dataverzameling gecombineerd met efficiente real time verwerking zijn hier noodzakelijke gereedschappen. Een eenvoudige interface met de menselijke operator, hem voorzien van niet overtollige foutmeldingen. Gebruikers vragen om de eliminatie van de grote aantallen verschillende leverancier specifieke console-apparatuur, interfaces, presentatie hulpmiddelen en operationele procedures. Gebruikers verwachten ten eerste een 'general purpose' platform, ondersteund door de meerderheid van leveranciers. In een later stadium, gebeurtenis (event) en alarm bevestiging, onderlinge verhoudingen en tenslotte staat integratie tussen verschillende systemen op het vragenlijstje van de gebruiker. Voorzien in een krachtige netwerkmanagement database voor het ondersteunen van de uitvoering, administratie, analyse en planning. Gebruikers kijken uit naar een centrale informatie-opslagplaats als zijnde de ultieme oplossing. Van deze opslagplaats of management information base (MIB) wordt verwacht dat alles opgeslagen kan worden betreffende, componenten, procedures, reglementen, projecten etc. Gebruikers verwachten dat het MIB een relatie of object georienteerde database wordt. Deze database moet vervolgens gaan dienen als basis voor het documentatiesysteem. Gebruikers willen een snelle, continue reactie op wijzigende netwerktoepassingen, deelnemers, apparaten, tarieven en diensten. Dynamische aanpassing aan de zich continu wijzigende omgeving is een belangrijk onderdeel dat de netwerkmanagement uitgaven stuurt. In afwachting van de ontwikkeling van een centraal informatie-opslagmedium zullen gebruikers een compromis kiezen en een 'gidsen-dienst' aanschaffen. Deze 'gidsen-dienst' dient dan als een paraplu met daaronder alle bestaande databases en dossiers. Gebruikers vragen om een verbetering van de beveiliging van het netwerk maar ook van het netwerkmanagementsysteem. Door correcte toewijzing van budgetten aan het beveiligen van toepassingen, systemen, transmissiemedia en apparatuur kan het beveiligingsniveau een hoger stadium bereiken dan daarvoor. Van netwerkmanagement produkten wordt verwacht dat ze bewakings-, automatische alarmering, afscheidings- en paswoord mogelijkheden bieden. Netwerkmanagementsysteem beveiliging is ook een belangrijk onderwerp door zijn centrale en strategische rol in een IT-ondersteunde organisatie. Voor het overzien van de uitgaven en het beheersen van de kosten vragen gebruikers te zijner tijd toegang tot rekeninginformatie. Hiervoor is het van belang om in toenemende mate nauwkeurige en eenvoudig te verwerken rekeninggegevens te vergaren. Het is te voorzien dat, op een bijna real time basis, door de leveranciers per standplaats een nauwkeurige kostenindicatie aan de gebruikers beschikbaar zal worden gesteld. Implementatie van generieke toepassingen. Gebruikers zijn feitelijk opzoek naar generieke applicaties voor afzonderlijke toepassingen, groepen van functies en instrumenten. Dergelijke toepassingspakketten worden door de gebruiker ingekocht of gehuurd. Gebruikers vragen een steeds hoger integratieniveau, wat leidt tot geYntegreerd netwerkmanagement. Dit betekent integratie-oplossingen voor communicatiemethoden, Civility Amsterdam bv.

84



meervoudige netwerkarchitecturen, verwerkingssystemen, netwerkelementen, geografische gebieden, groepen van aanbieders en prive, virtueIe en publieke netwerkmanagementinstrumenten heen. Gebruikers neigen naar een voorkeur voor een centrale netwerkmanagement oplossing, met implementatie van bepaalde lokale (gedistribueerde) functies welke op hun beurt weer centraal gecontroleerde worden. In het bijzonder, wensen gebruikers een oplossing voor het op afstand beheren van LANs met behulp van enke1e verspreide bewakingsmoge1ijkheden. Opgemerkt dient te worden dat deze gebruikerswens een golfbeweging kent tussen centralisatie en decentralisatie. Uitbesteden van het IT-beheer. Dit is niet zozeer een nieuwe strategie ais weI een tendens die zich verder zal voortzetten. Aangezien voor veel bedrijven de informatiestromen van levensbelang zijn, is en blijft dit een beslissing waar zorgvuldig mee omgegaan dient te worden. Er wordt niet zozeer een produkt ingekocht van een IT-dienstverlener als weI een vertrouwensrelatie aangegaan tussen het bedrijf in kwestie en de IT-organisatie. Om toch een stuk houvast te hebben kan een service level agreement worden gebruikt. Profiteren van de prijs tendensen, gebruikers die hun IT-beheer al voor lange tijd uitbesteed hebben zien hoe de prijzen dalen en willen hier van meet profiteren door in de contractonderhande1ingen betere afspraken te maken. Dit is ook mogelijk, door het feit dat de IT-markt verschuift van een aanbieders-markt (leveranciers dominant) naar een kopers-markt (kopers kunnen steeds meer vragen voor het ze1fde geld door de toegenomen concurrentie in de IT-branch). Procesinvulling Naast dit literatuur onderzoek naar de wensen van de gebruiker zijn ook publicaties bestudeerd van de GartnerGroup, dit is een grote 'IT-watcher' die alle be1angrijke trends en ontwikke1ingen in de IT-wereld voIgt en hierdoor enorm veeI bruikbare kennis in huis heeft. [11-16, 21, 22]. Met name voor de procesinvulling van het IT-beheer zien zij een grote toekomst.

IT-personeel dat verantwoorde1ijk is voor een netwerk moet bekend zijn met de achtergrond en historie van de huidige methoden en psychologie die de netwerk organisaties sturen. De basis heeft zijn worte1s in hoe een organisatie handelt en hoe ze haar medewerkers beloont. Een organisatie opbouwen rond een procesbenadering, mits passend bewaakt en beschouwt, zal resulteren in een organisatie die kosten effectief en meer afgestemd op haar kianten is. Een beschouwing van deze procesbenadering tegen een achtergrond van de organisatiebenadering zal de zaak verduidelijken. * Een proces kan gemeten worden in klant termen, een organisatie kan dat niet. * Processen zijn gefocusseerd op service, een organisatie op gewin of mate van controle. * Processen kunnen geautomatiseerd worden, organisaties niet. * Service levels kunnen toegepast worden op een proces, niet op een organisatie. * Proces beschrijvingen hebben meer betekenis voor een klant dan organisatie missie verklaring.


85



Intrinsieke voordelen van de procesbenadering: * Elk proces kent een dienstverlener en een dienstafnemer die het bestaan van dat proces geldig maakt. * Elk proces is een rode draad door de organisatie, die een verbinding vormt tussen de dienst aanbieder en afnemer van een dienst. * De organisatiestructuur zal de vorm van het proces volgen, in plaats van politieke en mate-van-controle overwegingen. * Op de klant gebaseerde metriek kan worden ingevoerd voor elk proces. * De ontwikkeling van elk proces kan geevalueerd worden. Organic

2000

s

Service Architecture

I

Expert Engine Integrated Change

Correlation

e

Policy driven

I

c

I Monitoring Integrated I Exception I Proactive Monitoring Planning

u r

i I

Integrated Object Architecture

Business Policy driven integrated intelligent distributed object model

y

Proactive S e

Services (internal, external)

1996-7

c

Integrated

Integrated

Integrated

System

Change

Operations

Data Manag.

Admini.

u r

Proactive, Integrated

i I

Strategic NSM Platform(s)

y

Reactive Service-desk / Helpdesk

1995

Problem

System

LAN

Baseling

Monitoring

Operations Change

Productivityoperations

Select Strategic NSM Platform(s) Fire fighting Alerts 1994 LANIWAN monitoring

.......... '"

PC-Helpdesk

Reactive, Problem solving

I .

Old Platform

Bron: Gartner Groep

Figuur 6.8 Ret NSM tijdspad. Bruikbare technieken IT-beheerorganisaties verlangen een toename van de operationele productiviteit door beheersing van het aantal personeelsleden hun opleidingsniveau en het aantal te beheren sites. Door een serieus te kort aan gekwalificeerd personeel worden organisaties gedwongen te zoeken naar oplossingen om met een stabiel aantal personeelsleden de groei en de ondersteuning van nieuwe toepassingen te lijf te kunnen. Ook wordt er onderzoek gedaan naar de vraag of artificiele intelligentie als een significante methode voor het ondersteunen van mensenwerk is, zodat voorzien kan worden in een consistente hulpbron bij probleem


86



vaststelling. Een van de scenario's voor de volgende eeuw is een 'lights-out network control center.' Het pad naar die realiteit zal gaan langs automatische en onbediende handelingen. De beste methode voor het waarmaken van hoge service niveaus is het ontwikkelen van een artificieel intelligent (A.L), neuraal gestuurd Netwerk Management System (NSM), die automatisch het netwerk hersteld, de systemen repareert en de gebruiker op de hoogte stelt tot aan welk niveau de SLA is beantwoord. We noemen dit proactieve NSM, zie figuur 6.8. De multiplatform NSM markt groeit met meer dan 30% per jaar tot zo een $9.5 miljard in het jaar 2000. NSM pakketten zijn een-verkoper, multidisciplinaire oplossingen die zijn ge'integreerd, meestal door een of meer management raamwerken. Zakelijke NSM pakketten hebben de potentie om met de organisatie mee te groeien, zowel in het aantal servers en clienten als in heterogeniteit. Voordelen van pakketten ten opzicht van multipunt oplossingen (elk subprobleem een eigen oplossing) zijn integratie tegen lagere kosten en met minder NSM aanbieders te maken hebben. Een nadeel is dat brede pakketen nooit de leidende produkten in alle discipline bezitten. Dit heeft als resultaat dat IT-organisaties niet binnen de komende vijf jaar one-stop NSM shopping mogen verwachten. Organisaties kunnen beter kijken naar het verkrijgen van pakketten voor een deel van hun NSM plan en achterblijvende of missende functies inkopen van onafhankelijke software bedrijven (ISV's: Independent Software Vendor) met goede puntoplossingen. Voor een overzicht van aanbieders van NSM-pakketten, zie figuur 6.9 en tabel 6.1. Challengers

Leaders

Com~uter.

AsSOCiates

Platinum.

Ability to Execute

.HP

.IBMlTivoli

Boole & 8Ilbbage. Amdahl" Peregrine:.

·NCR

OpenVision.

NIche Players

.New Dimension

• Bull ISM

VIsIonaries

- - Completeness of Vision

~

Figuur 6.9 Enterprise NSM systemen. Waarschijnlijk de meest belovende benadering van het managen van multivendor omgevingen probleem is gelegen in het concept van 'intelligent agents'. Dit is speciale software die ge'installeerd is op de te managen machines in een LAN of WAN, welke gebruikt wordt voor het verzamelen van performance informatie in een standaard formaat en het vroegtijdig acties uitvoeren volgens vooraf bepaalde procedures. Aangezien deze 'agents' alleen specifieke informatie items naar de managementconsole zenden, is dit een efficienter proces dan het continue 'pollen' van elk station om zo een bericht van een gebeurtenis naar de centrale management machine te kunnen sturen. Deze benadering minimaliseert het verkeer op het netwerk, zodat er minder bandbreedte wordt gebruikt.


87



Een inteiligente 'agent' op elk te managen machine verzamelt en verwerkt managementinformatie omtrent activiteiten als CPU gebruik, harddisk bezetting, I/O belasting en andere systeemhandelingen. De bewaakte waarden komen meestal uit bronnen als de systeem of toepassings-'logfiles', SNMP-traps (Simple Network Management Protocol) of klant specifieke bewakingstoepassingen. Door het gebruik van drempels en filters wordt aileen de vedangde informatie verzameld, van de verschillende management 'agents' en doorgegeven aan een managementtoepassing. Bij het bewaken van belangrijke systeem- en toepassingswaarden t.o.v. drempelwaarden, kan de managementtoepassing voorzien in een vroegtijdige waarschuwing van zich ontwikkelende problemen en daarop gepaste acties nemen om zo te voorkomen dat dergelijke condities zich voordoen. Bijvoorbeeld, een harddisk (van een gebruiker) die 90% vol is, genereert automatisch een Email bericht waarin staat dat de gebruiker overbodige files elders moet opslaan of verwijderen. Vendor

Sterke punten

Uitdagingen

Amdahl

* Service and Support * Data Center relationships * IT relationships * Revenu stream * Agent technology acquired from Legent * Strong management team * European channels & support * Object-based technology * Eurpean support * Telecommunications focus * Network management installed base * Professional services

* Ramping up support on Bull ISM

Computer Associates Boole & Babbage Bull HP

NCR New Dimension

* Object-based, integrated technology * Robust channels * Professional services * Data center relationships * Competitive point solutions

Open Vision

* Competitive point solutions

Peregrine

* Competitive point solutions * Experience with change and

Platinum Technology

problem management * Channels * Competitive point solutions

IBM/Tivoli

* Mixed reputation * Traditional Unicenter scalability * Integration of acquired products * Translating mainframe automation success to CIS * North American channels and Support * Third-party application support * Late with network management architecture * Translating success with network into systems management * Platform support (leverages hardware sales) * Reputation eroding * Integration of acquired products * Platform support (leverages hardware sales) * Narrow product suite- foccused on job scheduling. Automation and security

* Channels * Narrow product suite * Narrow product suite - limited to problem and network performance management

* Channels * Integration of acquired products * Delivery of overall architecture

Tabel 6.1 Enterprise NSM pakketten, Sterktepunten en Uitdagingen De ontwikkelingen op Inter/Intranet gebied laat de NSM-beheer omgeving niet ongemoeid. Volgens een aantal leveranciers is client/server technologie alweer achterhaald en gaan we over naar een vorm van lichte clients (domme terminals) op basis van WEB-browser producten inclusief Java programmatuur. Hiermee is dan ook de belangrijkste gebruikersinterface op Inter/Intranet, de WEB-browser bepaald. Leveranciers van NSM produkten hebben ontwikkelingen opgestart om de gebruikers interface van een NSM middels een WEB-browser te kunnen benaderen. Van het Helpdesk pakket Pro-Helpdesk (van ProHn Automation) bestaat inmiddels een WEB variant. Naast het gebruik van Inter/Intranet technieken voor IT-beheer, zuilen in de nabije toekomst ook veel van dergelijke Inter/Intranet services beheerd moeten gaan worden. Te denken valt Civility Amsterdam bv.

88



aan WEB, News, Mail, Index, Proxy, FTP-services en Firewall beveiliging. Er is dan ook een Task Force opgericht waarin bijna aIle grote leveranciers vertegenwoordigd zijn. Hun doelstelling is om beheer standaards te definieren waarmee dergelijke services beheerd kunnen worden. Kostentrends In de IT-branch zijn bepaalde kostentrends waarneembaar welke zich op middellange termijn zullen handhaven [3] en [29]. Zie figuur 6.10. Bij het analyseren van data- en telecommunicatie netwerk kosten, laten de resultaten een continue afname in de kosten van de apparatuur en een toename van de communicatiekosten zien. De kosten voor apparatuur dalen mede door de grootschalige integratie op hardwareniveau en gedeeltelijk door standaardisatie op softwareniveau. De toename van de communicatiekosten laat zich verklaren als uitvloeisel van de trend naar gedistribueerde verwerkingsfaciliteiten en databases welke er namelijk voor zorgt dat een enorm aantal stand-alone machines met elkaar verbonden dienen te worden. Dat hier nog geen eind aankomt blijkt wel uit onderzoeken die bevestigen dat steeds meer PC's en LANs met elkaar verbonden worden, door middel van een grote verscheidenheid aan netwerk oplossingen (WAN, Internet etc.). Ret alarmerende feit is echter dat de personeelskosten snel aan het toenemen zijn. De oorzaak hiervan kan gevonden in de volgende trends. Netwerken worden zelden of nooit kleiner of minder complex, dit verlangt steeds meer personeel. Een hoger opleidingsniveau van het personeel gaat automatisch gepaard met hogere salarissen voor dat personeel. Het uitbreiden van de dienstverlening aan de gebruikers vraagt om nog meer mensen, met name op het operationele vlak.

Costs Equipment Facili 'es

People Time

Figuur 6.10 Kosten trends. Aan uitbesteding is een aantal voordelen verbonden, zoals kostenreductie door het op effectieve wijze benutten van de schaalvergroting en het gebruik van in dienstverlening binnen de informatietechnologie gespecialiseerde bedrijven. Daamaast ziet men op de markt een groei in de uitbesteding van datacommunicatie, waarbij - mede gezien de complexiteit van het beheer - de schaalvergroting bij de fysieke infrastructuur een aanzienlijke kostenreductie kan opleveren.


89



H7 Ontwikkeling Service Level Rapportage systeem 7.1

Netwerk en Systemen Management bij Civility

Netwerk en Systemen Management (NSM) diensten bestaan uit de samenhang van functies om 'networked systems' te laten werken en beheren. Het inrichten van effectieve NSM dienstverlening voor een klant bestaat meestal uit de volgende drie stappen [5]: 1. pre-implementatie, bestaat uit het ontwerpen en plannen van de benodigde functies; 2. NSM operations bestaan uit processen zoals incident en probleem management en netwerk monitoring; 3. Distributed Systems Management, de optimalisering van de netwerken en systemen met services zoals capacity planning, back-up en recovery etc. Bij Civility zijn meerdere contracten met meerdere klanten overeengekomen. Per contract is een doorsnede te maken van de NSM-functies en de te beheren objecten. In de Civility situatie wordt de eerste stap (pre-implementatie) over het algemeen uitgevoerd door de afdelingen MV-FM en MV-Engineering. De tweede stap (NSM operations) vormt het kern proces van de afdelingen MV-PB en de Service-desk. De derde stap (Distributed Systems Management) zou eveneens door de afdeling MV-PB verzorgt moeten gaan worden. Ter ondersteuning van de dienstverlening zijn beheerhulpmiddelen noodzakelijk die ervoor zorgen dat de dienstverlening met een goed prijs/prestatie niveau uitgevoerd kunnen worden. Dit kan gerealiseerd worden door een NSM-beheer strategie uit te zetten, bijvoorbeeld het overgaan van reactief naar proactief. Zie ook figuur 6.8 voor het complete NSM tijdspad. Het doel is van een reactieve situatie naar een proactieve te komen, uiteraard met een schuin oog naar het organisatiegedreven beheer. De Gartner groep noemt een drietal activiteiten die van belang zijn om van een reactieve beheerorganisatie te komen tot een proactieve situatie: 1. het ontwikkelen van een NSM-beheer architectuur, het selecteren en standaardiseren op NSM platformen; 2. het inrichten van een Service-desk strategie, waarbij taak gericht werken omgevormd wordt tot proces gericht, service levels gedefinieerd en vastgesteld worden; 3. het selecteren en inrichten van diverse third-party managementapplicaties als ondersteuning van de gedefinieerde processen. De drie activiteiten worden hier achtereenvolgens verder uitgewerkt. Indien het huidige produkt portfolio bekeken wordt van de diverse fabrikanten op NSM gebied (figuur 6.9), dan onderscheidt Gartner twee richtingen. De zogenaamde basisplatforms (frameworks) geschikt voor het beheren van minisystemen en netwerken, ook weI enterprise management genoemd en anderzijds produkten die geschikt zijn voor het beheer van de werkplekomgeving (PC), ook wel domain management genoemd. Enterprise NSM frameworks zijn o.a.: (zie ook tabel6.1) HP Openview, Tivoli/IBM TME 10, Bull ISM en Computer Associates Unicenter. Deze enterprise frameworks bieden vaak de mogelijkheid om specifieke oplossingen te realiseren op basis van standaard Applicatie Program Interfaces (API's) die gebruik maken van zogenaamde middleware functies. Voorbeelden van dergelijke middleware functies zijn o.a. het doorgeven van 'events', Civility Amsterdam bv.

91



beveiliging en autorisatie, gegevens database (configuratie). Middels deze middleware laag kan een vorm van integratie gecreeerd worden tussen software-hulpmiddelen met verschillende functionaliteit. Een software produkt als Ciscoworks kan niet stand-alone gebruikt worden, maar werkt op basis van dergelijke middleware lagen. LAN management suites zijn o.a.: Microsoft SMS, Symantec, Intel LANDesk, McAfee Sabre, Brightworks. Ook IBM en HP hebben beheerhulpmiddelen in deze categorie met weliswaar beperkte functionaliteit. Binnen Civility is er ervaring met IBM Systemview produkten. Voor zowel het NUS als het GDA contract zijn dergelijke produkten aangeschaft. Uit de reeks Systemview produkten heeft Civility de volgende produkten aangeschaft: * Netview, een produkt voomamelijk gericht op Netwerk Management; * ADSM, een produkt gericht op Storage Management; * Systemsmonitor, een produkt gericht op het beheren van AIX systemen; * D-Smit, een produkt gericht op configuratie van AIX systemen; * DM-Manager, een produkt gericht op distributie van software naar clients en server. Het lag dus voor de hand om in eerste instantie te kijken of er verder gebouwd kon worden met deze hulpmiddelen. IBM heeft in het tweede kwartaal 1996 de firma Tivoli overgenomen. Tivoli staat bekend om zijn management framework gericht op Distributed System Management (DSM). Het Tivoli produkt wordt ook geroemd om zijn object oriented middleware laag volgens de CORBA standaard. Een standaard die met uitzondering van Microsoft door veel leveranciers ondersteund wordt. De doelstelling van IBM is om beide produktlijnen te laten sarnensmelten tot een produkt lijn: TME-IO. Hier is in de zomer van 1996 mee begonnen en de verwachting is dat deze omvangrijke herbouw tot zeker zomer 1997 zal duren. In de tussenliggende periode worden interim releases uitgebracht met beperkte integratie. Op basis van de huidige en de gewenste situatie bij Civility is gestart met de implementatie van de Tivoli/IBM TME 10 Netwerk en Systemen Management beheerfrarnework. Hierdoor ontstaat voor de beheeromgeving de structuur als gegeven in figuur 7.1. Process Managers

Tactisch

Operationeel

Task Managers~

___...JU Element Managers

~:E-Jddleware Sen-ices OB-2, WEB, Oracle, Mail

U'-----I

Applications NUS,GISP, WVG,GOA

.

Networks

Environment

TCPIIP,IPX, Routers, Hubs

building

Power

Figuur 7.1 Structuur van de IT-beheeromgeving bij Civility.


92



Binnen het 'projectplan Verbeteringen IT-Beheer' (VIB) is een aantal verbeterpunten aangegeven die noodzakelijk is voor de gewenste situatie. Zie ook hoofdstuk 6, met name figuur 6.1. Ais gevolg van het management besluit: 'Start met een beperkte invoering (minimale financiele impact) voor Civility intern, wacht met een volledige invoering totdat er op Roccade facilitair niveau meer duidelijkheid is', is er een fasering in het project aangebracht. Gekozen is hierbij voor de cyclische methode van faseren. Cyclische fasering wordt gekenmerkt door het ontwikkelen van oplossingen, zoals die op dat moment gezien worden in het licht van de dan bekende eisen. Deze oplossingen worden vervolgens getoetst aan de praktijk. Naarmate nieuwe eisen en ideeen voor oplossingen boven komen, wordt een volgende ontwikkelslag uitgevoerd. Nieuwe eisen zouden in dit geval veroorzaakt kunnen worden door verdergaande samenwerking binnen het Roccade facilitair centrum voor Midrange Verwerking. Mogelijke nieuwe ontwikkelingen die meegenomen kunnen worden zijn de snel voortschrijdende intranet technieken. Uitgaande van de cyclische fasering, dienden de doelstellingen voor de eerste fase te worden bepaald. De projectgroep VIB heeft in overleg met de stuurgroep een prioriteitstelling aangebracht in de verbeter punten. Deze prioriteitstelling zag er als voIgt uit, zie tabel 7.1. Prioriteit

Gewenste situatie Verminder de Complexiteit van de infrastructuur Generiek Netwerk en Systems management Framework Off-line bewaking Beperking Operationele Beheerinspanning Service Level Reporting (SLR) Verbetering User-beheer Verbetering test en Acceptatie, software versie beheer Gecontroleerde Distributie Verbetering Supportfaciliteiten Werkplekonathankelijkheid

Tabel 7.1

geen VIB item I 2 2 4 2a3 4 3 geen VIB item geen VIB item

Prioriteitstelling verbeter punten IT-Beheer.

Uit deze prioriteitstelling is duidelijk op te maken dat de voorkeur uitgaat naar het definieren van een generiek Netwerk en Systems Management Framework. De financiele consequenties van de invoering van het geselecteerde product (TME-I0 Tivoli) blijken echter dermate hoog te zijn dat dit strijdig is met de uitspraak 'Start met een beperkte invoering (minimale financiele impact) voor Civility intern, wacht met een volledige invoering totdat er op Roccade facilitair niveau meer duidelijkheid is'. Om deze reden is dit verbeter punt uit de doelstelling van fase 1 verwijderd. Wat wel, met minimale financiele consequenties realiseerbaar is, is de integratie van de twee in gebruik zijnde beheersystemen, zowel het GDA als het NUS maken gebruik van Netview. De items 'Off-line bewaking', 'Beperking operationele beheerinspanning' en 'Service level Reporting' worden meegenomen in de eerste project fase. De te realiseren doelstelling is als voIgt onder de verdelen, integreren van de beheeromgeving, van reactief overgaan naar proactief beheer, van element- naar taakgericht, en van taak naar proces/procedure gericht beheer en het duidelijk kwantificeren van de geleverde prestaties aan de klanten (SLR). Civility Amsterdam by.

93



7.2

Het Informatiemodel

Een onderdeel bij het ontwikkelen van een informatiesysteem is het opstellen van conceptuele informatiemodellen van een besturingssituatie. In deze modellen wordt aangegeven voor welk management en voor welke beslissing informatie nodig is, waarom en wanneer. Alvorens in te gaan op het informatiemodel, wordt eerst het besturingsparadigma voor deze specifieke situatie besproken. Zie naast figuur 7.2 ook paragraaf 4.1. Omgeving

:Overleg

SLA

Service Level Rapportage

Besturend orgaan .. .I3::~~u.u.~I.~~~ ...

Externe gegevens

Output

Informatiesysteem

gegevens

Bestuurlijke informatie

Interne gegevens

Bestuurd systeem

Figuur 7.2 Het besturingsparadigma toegesneden op het Service Level Rapportage systeem. Het bestuurd systeem: het totaal aan procedures, soft- en hardware nodig voor het, met een bepaald service level, leveren van de (automatiserings-) diensten die overeengekomen zijn of worden met de klanten (SLA). De output van het bestuurd systeem omvat de geleverde diensten. De interne gegevens zijn gegevens over de toestand van het bestuurd systeem op de diverse tijdstippen. Het besturend orgaan: dat deel van de Civility organisatie welk betrokken is bij het beleid, bestuur of beheer. Dit zijn bijvoorbeeld het groepshoofd MV-PB, de projectleider van een bepaalde nieuwe dienst, de Service Level Manager, de afdeling Engineering en Facilities Management of een geautomatiseerd beheersysteem (NSM). De acties die het besturend orgaan neemt dienen de kwaliteit van de output te conformeren aan de overeengekomen niveaus. Deze service levels worden middels overleg bepaald en vast gelegd in Service Level Agreements (SLA). Het informatiesysteem: omvat en distilleert uit de beschikbare gegevens (opgeslagen in diverse databases en kennisbronnen, zoals Netview, Pro-Helpdesk en de bestuurlijke gegevens), informatie en geeft dat als bestuurlijke informatie door aan het besturend orgaan en als Service Level Rapporten aan de omgeving. Civility Amsterdam bv.

94



De Omgeving: waaronder de deelnemers en de opdrachtgever van de aan te bieden diensten. De input die zij geven aan het bestuurd systeem, kan men opdelen in gewenste (gebruik van de applicaties) en ongewenste (verstoringen van het bestuurd systeem). De externe gegevens welke binnen komen bij het bestuurlijk informatie systeem, bestaan o.a. uit Incidenten en Wijzigingen aangegeven door de gebruikers of de opdrachtgever. Voor zover de gegevens relevant zijn voor het besturend orgaan worden die als informatie doorgegeven en terug gemeld aan de omgeving middels de Service Level Rapportage.

Het informatiesysteem (black box) bestaat uit, gegevens, verwerking, informatie, procedures, apparatuur, programmatuur en mensen. Het is nu de bedoeling om de externe gegevens, interne gegevens en de bestuurlijke gegevens (input) met behulp van het informatiesysteem (SLR-systeem) om te zetten in Rapporten en Bestuurlijke informatie (output). Het bedrijfs(informatie)model (in de literatuur worden er verschillende namen gebruikt) dient aan te geven hoe het informatiesysteem de bedrijfsvoering in het relevante bedrijfsonderdeel ondersteunt. In feite worden hier twee zaken in kaart gebracht; het bedrijfsmodel geeft de bedrijfsvoering weer en het bedrijfsinformatiemodel de informatievoorziening ten behoeve van die bedrijfsvoering. De keuze om beide modellen hier tot een invalshoek samen te voegen berust op het feit dat voor de twee soorten modellen dezelfde soorten technieken worden gebruikt. Deze technieken maken bijvoorbeeld onderscheid tussen bedrijfsprocessen en informatieprocessen en tussen materiele stromen en informatiestromen. Bij veel bedrijven bestaan de primaire bedrijfsprocessen zelf uit informatievoorzieningsprocessen, zoals bij banken, verzekeringsmaatschappijen en vele overheidsorganen. Deze invalshoek is vooral van belang voor de opdrachtgevers, voor de verschillende soorten gebruikers, voor organisatiedeskundigen en voor informatie-analisten. Een bedrijfsmodel geeft een beeld van het objectsysteem, dat wil zeggen van dat deel van het bedrijf dat als het probleemgebied wordt beschouwd waarop de bouw van een nieuw of een te vemieuwen informatiesysteem is gericht. Het objectsysteem wordt bestudeerd om kennis te verkrijgen over de bedrijfsdoelen, de bedrijfsactiviteiten, de wijze van besturen en de organisatorische inrichting om die doelen te bereiken. Het bedrijfsinformatiemodel geeft een beeld van de rol van de informatievoorziening daarbij. Het bedrijfs(informatie)model bestaat dus uit een vereenvoudigd model van het bedrijf met een sterke orientatie naar de rol van het informatiesysteem daarin. Het bedrijfs(informatie)model bevat ook de eisen die aan het informatiesysteem gesteld kunnen worden, te weten de functionele eisen (de informatiebehoeften), de prestatie-eisen (kwaliteitseisen) , de resource-eisen en de eisen met betrekking tot de werkomgeving (ergonomische-eisen). Een informatiemodel geeft concreet een beeld van [33]: 1. de doelstelling van het (deel van het) bedrijf 2. de activiteiten die er plaats vinden 3. de relevante objecten in het bedrijf 4. de bestuurlijke opzet van het bedrijf 5. de gewenste communicatie tussen activiteiten 6. de problemen die er spelen 7. de bijdrage die informatiesystemen dienen te leveren bij de oplossing van de problemen en het bereiken van de doelstellingen van het bedrijf, zoals: • voldoen aan de informatiebehoeften Civility Amsterdam bv.

95



• bevorderen van de communicatie tussen personen, organisatorische eenheden en bedrijfsactiviteiten • verbetering van de besluitvorming 8. de eisen die daarbij aan het informatiesysteem worden gesteld 9. de consequenties van het voorgestelde informatiesysteem. 1. De doelstelling van het (deel van het) bedrijf. De missie van Civility Amsterdam b.v. luidt: 'Het verlenen van automatiseringsdiensten in de vorm van competence centers voor midrange-verwerking, sociale diensten, vastgoed en DIS/Worliflow systemen. '

Het kwaliteitsbeleid van Civility Amsterdam b.v. luidt: 'Wi} leveren aan onze klanten maatwerk informatie systemen volgens de voorafafgesproken gewenste kwaliteit. ' De missie voor de sector Midrange Verwerking (MV) luidt: 'Met voorspelbare kwaliteit en kosten uitvoeren van de verwerking van iriformatievoorziening op midrange systemen in een netwerk met intelligente werkplekken. ' De missie van MV-Produktie en Beheer (PB) is als voIgt gedefinieerd: 'Het operationeel beheren van de technische infrastructuur van interne en externe klanten waarbi} gebruik gemaakt wordt van de ITIL-methodiek en waarbi} het streven is dit door middel van remote beheer te realiseren. ' MV-PB streeft emaar haar diensten qua flexibiliteit en prijs marktconform aan te bieden. Dit wordt gerealiseerd door gebruik te maken van op dat moment beschikbare beheeroplossingen van een hoge kwaliteit. 2. De activiteiten die er plaats vinden. De sector Midrange Venverking voert de volgende activiteiten uit: Offerte-aanvragen verwerkingsactiviteit Middels deze activiteit worden offerte-aanvragen verwerkt tot offertes. Gegevens en berekeningen van een offerte worden opgeslagen bij het bedrijfsbureau en bij Facilities Management Services (FMS). Opdracht voorbereidingsactiviteit Binnen de voorbereidingsfunctie worden binnengekomen opdrachten gepland, voorbereid en afspraken gemaakt met de klant. Deze functie wordt ingevuld door de groepen FMS, Applicatie Services (AS), MV-Engineering (Eng) en MV-PB. MV-PB heeft hier aIleen een adviserende ro!. Uitvoer van deze functie naar de klant zijn de SLA (Service Level Agreement), DAP (Dossier Afspraken en Procedures) en de planning van de uit te voeren opdracht. Opdracht uitvoer en beheeractiviteit Binnen de uitvoeren beheerfunctie wordt het benodigde materiaal, materieel en personeel ingezet om de opdracht uit te voeren. Verstoringen op de te leveren diensten komen deze activiteit binnen in de vorm van incidenten. Door gebruik te maken van het benodigde materiaal, materieel en personeel wordt een oplossing geboden aan de opdrachtgever conform de in de SLA opgenomen afspraken. Het afsluiten van de SLA tussen Civility en de Civility Amsterdam bv.

96



opdrachtgever activeert deze uitvoeren beheeractiviteit. De activiteit wordt verzorgt door de groepen FMS, AS, MV-Eng en MV-PB. Zie figuur 7.3. De groep MV-PB kent drie belangrijke activiteiten: 1. Ret verhelpen van storingen en vragen met betrekking tot de IT-infrastructuur 2. Routinematig beheren van de IT-infrastructuur van interne en externe klanten 3. Ret op projectmatige basis invoeren van verbeteringen in de IT-infrastructuur. Deze verbeteringen en uitbreidingen worden opgeleverd door MV-Eng en dienen voor invoering in produktie geaccepteerd te worden door MV-PB. Offerte aanvragen

- - - - - •

Offerte aanvragen verwerken

Offerte I- -

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

..

IOfferte gegevens Opdrachten

Opdrachten voorbereiden Informatie

SLA, DAP, planning

- ------ --- -

----~

Voorbereide opdrachten

Materiaal

Materieel

Opdrachten uitvoeren en beheren

Personeel

Incidenten

-

Uitgevoerde opdrachten

-----------

-~

Verwerkt materiaal

----Gebruikt materieel - - - - - - - - - - - -~ -------~

Benut personeel

- ----------~ Oplossingen

-- ---- ---- -

--~

Figuur 7.3 Vereenvoudigd functiemodel. 3. De relevante objecten in het bedrijfsonderdeel. De Klant, de (betalende) afnemer van de diensten. De Opdrachtgever, de gemeente Amsterdam is de opdrachtgever van b.v. het GDA.

De Helpdesk, het aanspreekpunt voor klanten met vragen, klachten, problemen etc. De 'calls' die zij binnen krijgen worden verwerkt in een ProHelpdesk omgeving. De Relpdesk is verantwoordelijk voor bepaalde eenvoudige operationele taken. Produktie, verantwoordelijk voor aIle operationele dagelijkse werkzaamheden t.b.v. de service, levert informatie. Service Level Managers, borgt het serviceniveau door het coordineren en bewaken van de service. Helpdesk Manager, borgt het serviceniveau door het bewaken van incidentoplossingstrajecten. Problem Manager, borgt het serviceniveau door het coordineren en bewaken van probleemoplossingstrajecten. Change Manager, borgt het serviceniveau door het coordineren en bewaken van het wijzigingstraject. FMS, spreekt service niveau af met de klant en maakt afspraken over afwijking hiervan. Engineering, zorgt voor taktische aspecten van de serviceinrichting en -configuratie. Projecten, levert op projectmatige basis IT-diensten. Hoofd van de afdeling MV-PB, is verantwoordelijk voor de aansturing en beslissingen op tactisch niveau. Het Civility-LAN, het interne netwerk waar aIle werkplekken onderling mee verbonden zijn. Het GDA, de infrastructuur waarmee de gemeente instellingen met elkaar verbonden zijn. Applicaties, de diensten die aan de klanten verkocht zijn, en waarvan het Civility Amsterdam bv.

97



beheer in handen is van de afdeling MV-PB. Hardware, hier draaien de applicaties op. Databases, hierin zijn naast applicatie gerelateerde gegevens ook beheergegevens inopgeslagen (bijvoorbeeld de configuratie van de hardware in de CMDB). Normbestanden, hierin staan de overeengekomen niveaus van de verschillende kwaliteits-items. Netwerk Management machine, beheert automatisch de onderliggende hardware en verzamelt performance gegevens. 4. De bestuurlijke opzet van het bedrijfsonderdeel. De organisatie is min ofmeer als een matrix organisatie ingericht. Per 'klantcontract' (dienst) is de organisatie een Service Level Manager (SLM) benoemd. Haaks daarop staat een indeling gebaseerd op technische of beheer specialisatie (LAN, WAN, VMS, CMDB, Uitwijk ...). Zie naast figuur 7.4 ook figuur 3.2. Process Managers

Tactisch

Operationeel '-------'

u

Task Managers

U ~~:-M~dleware U'--__I....................•

ITIL

NM-Iaag

r--Element Managers

Systems

Sen'ices

Applications

Networks

AIX, NT, Win9S, Novell, WFW

DB·2, WEB,

NUS,GISP, WVG,GDA

TCPIIP, IPX, Routers. Hubs

Oracle, Mail

Environment Power building

}NEM-Jaag

Figuur 7.4 Bestuurlijke opzet van het bedrijfsonderdeel MV-PB. 5. De gewenste communicatie tussen de activiteiten. Facilities Managers (FM) hebben als taak, het contact onderhouden met de klant. Middels overleg met de klanten en de Civility organisatie dienen zij de klanten te informeren over het diensten aanbod en de Civility organisatie over de informatieproblemen die er bij de klanten spelen. Om dit goed te kunnen doen, en daar op offertes uit te brengen, dienen zij op de hoogte te zijn van het actuele diensten aanbod, en de kwaliteit daarvan. Het afstemmen van de mogelijkheden van apparatuur en systeemprogrammatuur op de wensen van de klant en voor bereiden van opdrachten zijn de activiteiten van de groep Engineering. De concrete (informatie technische) wensen van de klanten en de technische mogelijkheden van de hard- en software en de afdeling PB moeten inzichtelijk zijn voor de Engineering groep. Produktie en Beheer is verantwoordelijk voor, heeft als taak, de verwerking en het beheer van applicaties op de midrange omgeving. Binnen MV heeft met name MV-PB als taak het afhandelen van verstoringen in de produktie-omgeving (incidenten). De aan deze afdeling toegewezen incidenten worden opgelost indien mogelijk. Indien dit niet mogelijk is, worden deze incidenten doorgerouteerd naar een van de andere afdelingen, afhankelijk van de aard van het incident. De oplossing wordt doorgegeven aan de Dispatch-desk.


98



De communicatie binnen de afdeling Produktie en Beheer is, vanuit de ITIL-methodiek, onder te verdelen in de volgende categorieen: Kostenbeheer houdt zich bezig met het identificeren en bewaken van kosten en het eventueel doorbelasten van deze kosten aan de diverse klanten. Elke actie binnen een IT-organisatie brengt kosten met zich mee, de budgetten en de gemaakte kosten moeten gecommuniceerd worden. Service Level Management (SLM). Om tot een goede dienstverlening te kunnen komen, dienen afspraken gemaakt te worden tussen de IT-Ieverancier en de afnemers van deze diensten. De Service Level Manager houdt zich hiermee bezig. De afspraken worden vastgelegd in Service Level Agreements (SLA). Op deze wijze weten alle betrokken partijen wat hun rechten en plichten zijn. Ret gerealiseerde niveau moet gerapporteerd worden, met name de volgende twee operationele processen dienen in een service level rapport aanbod te komen: 1. Beschikbaarheidsbeheer houdt zich bezig met de beschikbaarheid van diensten. Ret moet bijvoorbeeld bekend zijn op welke tijdstippen onderhoud wordt gepleegd op het systeem. Ook het reserveren van tijd voor het herstellen van gegevens na een storing valt onder beschikbaarheidsbeheer. 2. Capaciteitsbeheer houdt zich bezig met het ter beschikking hebben van voldoende capaciteit (om de gewenste performance te kunnen realiseren), nu en in de toekomst, tegen gerechtvaardigde kosten. Inzicht in de beschikbare capaciteit en de benutte capaciteit, met trends als voorspellend instrument, is hier gewenst. Conjiguratiebeheer. Een organisatie moet in staat zijn haar bedrijfsmiddelen te beheren, zeker als deze middelen van vitaal belang zijn voor de bedrijfsvoering. IT en de middelen die daarbij gebruikt worden nemen een steeds belangrijkere plaats in. In de meeste gevallen vindt de registratie van IT-middelen plaats met behulp van een Configuratie-Management Database (CMDB). Naast de activiteiten om de database betrouwbaar te houden, heeft Configuratiebeheer ook de taak om de andere processen te voorzien van informatie over de IT-infrastructuur. Helpdesk. Gebruikers die niet tevreden zijn over de dienstverlening van de IT-organisatie moeten een centraal punt hebben om hun vragen en klachten kwijt te kunnen: de Relpdesk. Wanneer er een verstoring in de infrastructuur optreedt die het niveau van de ITdienstverlening verlaagt (QoS), een incident, moet deze bij de Relpdesk gemeld worden. Op deze wijze kan namelijk centraal inzicht verkregen worden in de aantallen, gevolgen en oplossingen van incidenten. Binnen Civility is de ReIpdesk (ook weI Service-desk genoemd) opgesplitst in een Call- en een Dispatch-desk. De Call-desk maakt de IT-afdeling toegankelijk voor afnemers van de ITdiensten door te functioneren als dagelijks contact met betrekking tot het gebruik van de ITinfrastructuur. De Call-desk registreert alle gesignaleerde incidenten, De Dispatch-desk beheert het volledige oplossingstraject van alle zich voordoende incidenten, Dit omvat het doorrouteren en bewaken van de voortgang. De Dispatch-desk koppeit de oplossing terug naar de kiant.


99


Structureren van IT-beheer met ITIL, ontwikkeling van een Servicelevel Rapportage systeem met SDM

Probleembeheer. In elke organisatie komen fouten in de infrastructuur voor. Ook al werken we met de meest betrouwbare voorzieningen binnen een IT-organisatie, de dienstverlening zal op de een of andere manier toch verstoord kunnen worden. Om een stabiele omgeving te verkrijgen moeten fouten (en de oorzaak daarvan) worden weggenomen. Binnen de ITinfrastructuur is Probleembeheer hiervoor verantwoordelijk. De problemen komen via de Helpdesk bij de afdeling PB of naar Engineering naargelang de aard van het probleem. Wijzigingsbeheer. Elke wijziging in de infrastructuur is een potentiele bedreiging voor de stabiliteit van het systeem. Door gebruik te maken van gestandaardiseerde methoden en technieken voor het uitvoeren van wijzigingen worden deze onder controle gebracht. De kans, dat een verstoring van de dienstverlening plaatsvindt door een gewijzigd configuratie-item, wordt dan kleiner. Wijzigingen komen niet alleen voor in prograrnmatuur en apparatuur, maar ook in documentatie, overeenkomsten en procedures. Elke wijziging die invloed heeft op het geleverde dienstenniveau dient onder controle gebracht en daarvoor gecommuniceerd te worden. Zie bij lage 3 voor het takenoverzicht van MV in tabel vorm.

6. De problemen die er spelen. Produktie en Beheer kent op communicatie gebied de volgende problemen, de onvolledige documentatie van in gebruik te nemen diensten, de complexiteit van het beheer bemoeilijkt een eenduidige communicatie, het reactief zijn van de beheeromgeving en te weinig (of te laat) inzicht in wat er gaande is. Voor uitgebreidere omschrijving van de knelpunten zie hoofdstuk 5.5. Beschikbaarheidsbeheer, de precieze beschikbaarheidscijfers zijn niet bekend, het inzicht in de 'zwakke schakels' moet zo ontbeerd worden. Capaciteitsbeheer, er is onvoldoende inzicht in de beschikbare en gebruikte capaciteit en de performance die daar uit voortvloeit. Service Level Management (SLM), er is weinig inzicht in het gerealiseerde kwaliteitsniveau (performance, voortgang wijzigingsaanvragen en status van problemen), hierdoor kan aan de klanten (en opdrachtgever) niet teruggekoppeld worden welke Quality of Service gerealiseerd IS.

Configuratiebeheer. Niet alle IT-middelen zijn (eenduidig) opgenomen in een ConfiguratieManagement Database (CMDB) en er is bijvoorbeeld geen grafische representatie van (een deel) van de IT-infrastructuur. Helpdesk. Het inzicht in de aantallen, duur, gevolgen en oplossingen van incidenten wordt nog onvoldoende de organisatie ingebracht. Daarnaast zijn er teveel fout door gerouteerde incidenten, de voortgang kan nog beter teruggekoppeld worden naar de klanten. Wijzigingsbeheer. Elke wijziging die invloed heeft op het geleverde dienstenniveau (QoS) dient onder controle gebracht en daarvoor gecommuniceerd te worden.

Door de privatisering van de ondememing wordt het maken van winst ook een doel (alleen dan kan continu'iteit gewaarborgd worden). Hierdoor wordt het wenselijk de kosten om laag te brengen en de inkomsten te verhogen. Het verhogen van de inkomsten is uitsluitend mogelijk Civility Amsterdam bv.

100



door aan meer klanten meer produkten te verkopen. Het verlagen van de kosten is mogelijk door het standaardiseren en automatiseren van (beheer)taken. Zie hiervoor ook hoofdstuk 6.1. 7. De bijdrage die een Service Level informatiesystemen dient te leveren, bij de oplossing van de problemen en het bereiken van de doelstellingen van het bedrijf (zie hiervoor ook hoofdstuk 6.1), zoals: • Voldoen aan de informatiebehoeften De klanten en de opdrachtgever krijgen nog onvoldoende informatie om te kunnen beoordelen of er voldaan is aan de 'vooral algesproken gewenste kwaliteit.' Bovendien missen zij de informatie die moet leiden tot beslissingen omtrent uitbreiding dan weI inkrimping van het uit te besteden (automatiserings-) dienstenpakket. MV-PB heeft behoefte aan voorspellende informatie (bijvoorbeeld door doorgetrokken trends) om te kunnen beslissen over uitbreiding van bepaalde bronnen. Het hoofd van de afdeling MV-PB en de SLM zijn gernteresseerd in wat er aan de deelnemers is geleverd en hoe dit zich verhoudt ten opzichte van het SLA. De invoering van een goed werkend Service Level Rapportage systeem moeten bijdragen aan het proactief reageren op storingen en het mogelijk maken van capaciteitsbeheer. Tevens moet het SLR bijdragen aan het verminderen van het aantal incidenten en het sneller opgelost worden van de incidenten. Op deze manier wordt namelijk het gerealiseerde Service Level verhoogd. • Bevorderen van de communicatie tussen personen, organisatorische eenheden en bedrijfsactiviteiten Het te ontwikkelen systeem moet bijdrage aan een bredere bekendheid rond items als beschikbare capaciteit, huidige problemen, door te voeren wijzigingen en het te behalen/behaalde Service Level. • Verbetering van de besluitvorming Correcte en duidelijke informatie rond de actuele en te verwachten problemen moet leiden tot betere beslissingen, en daaruit voortvloeiend een hogere kwaliteit. 8. De eisen die daarbij aan het informatiesysteem worden gesteld. De wensen van de deelnemer worden hier nogmaals behandeld, voor de overige eisen/wensen zie hoofdstuk 6.4. De deelnemer koopt een bepaalde dienst met een bepaalde prijs/kwaliteit verwachting en wil weten of hij 'waar voor zijn geld krijgt'. Per contract is bij de klant een contactpersooll aangewezen, aangezien die persoon niet altijd een technische achtergrond heeft (maar bijv. een commerciele) wordt met verschillende ogen naar de rapportages gekeken. De rapportages moeten zodoende vanuit verschillende standpunten een compleet beeld geven van hetgeen zich rond hun GDA-aansluiting en andere van Civility afgenomen diensten afspeelt. Enkele vragen die er zoal gesteld (kunnen) worden door de deelnemers zijn: Welke beschikbaarheid heb ik gekregen t.o.v. waar ik voor betaald heb? Wat heb ik gebruikt van de beschikbare capaciteit en diensten, heb ik meer of minder diensten nodig? Wat waren de oorzaken van de door mij ondervonden problemen en wat is/wordt er aangedaan? Hoe staat het met de wijzigingen die ik heb aangevraagd?


101



9. De consequenties van het voorgestelde informatiesysteem. De consequenties van een Service Level Rapportage systeem belasten de volgende drie middelen tijd, geld en de organisatie. De beschikbare tijd en gelden voor de inzet van diverse bronnen (mensen, hard- en software) voor dit project is niet separaat vast gelegd. Het ontwikkelen van een SLR-systeem is een onderdeel van het 'project Verbeteren IT-Beheer' (VIB). Het wordt echter wenselijk geacht dat het nieuwe systeem (op den duur) minder tijdrovend is en aanpassingen of uitbreidingen goedkoper zijn. De invloed op de organisatie mag niet leiden tot een hogere werkbelasting van de betrokkenen (b.v. door automatiseren). WeI zal er sprake zijn van verandering in werkmethoden en procedures, edoch, zonder dat organisatorische of andere veranderingen noodzakelijk zijn. De verantwoordelijkheid voor diverse acties die dienen als input of ondersteuning van het systeem, moeten in de bestaande structuur vallen (zie hiervoor ook bijlage 3).

7.3

Het Logisch ontwerp

Het logisch ontwerp (conceptueel, functioneel ontwerp of model zijn namen die hiervoor ook gebruikt worden) is een model van het informatiesysteem zoals de gebruikers dit zien. Met behulp van dit model (of ontwerp) kunnen zij constateren of het systeem voldoet aan de door hen gestelde eisen. Naast gebruikers zullen ook diverse groepen informatici zoals informatieanalisten, ontwerpers en bepaalde soorten beheerders en controle-functionarissen in dit model geYnteresseerd zijn. Hoewel dit model gebruikers inzicht geeft in welke gegevens het systeem moeten worden ingevoerd, opgeslagen en verwerkt en in welke informatie hen door het systeem wordt verstrekt, kan daamaast een bedrijfs(informatie)model belangrijk zijn. Een informatiesysteem is immers geen doel op zich, maar zal aan realisatie en besturing van bedrijfsactiviteiten moeten bijdragen, zie vorige paragraaf. Het logisch ontwerp geeft aan hoe het systeem eruitziet en zich gedraagt zonder uitspraken te doen over de technische en fysieke uitvoering. Het verschilt van het informatiemodel doordat het meer een oplossing dan een behoefte modelleert. Meerdere afdelingen kunnen bijvoorbeeld dezelfde informatiebehoeften hebben. Het is dan voldoende om de gevraagde functie eenmaal te ontwikkelen, waama alle afdelingen deze kunnen gebruiken. Ook zullen gegevens in het functioneel model anders worden geordend, namelijk zodanig dat alle gegevens slecht enkelvoudig worden opgeslagen. Dit beperkt de kans op inconsistenties en verbetert de onderhoudbaarheid. Meer concreet geeft hetfunctioneel model / logisch ontwerp een beeld van: 1. de doelen van het informatiesysteem, dat wil zeggen de informatie die het moet leveren, de verwerkingen die het moet uitvoeren en de gegevens die het moet bewaren 2. (a) de functies die de gevraagde informatie leveren of daarbij een ondersteunende rol vervullen en (b) de regels volgens welke dat gebeurt. 3. (a) de wijze van interactie met gebruikers en/of andere informatiesystemen, (b) de samenstelling van in- en uitvoer en (c) de juiste verspreiding van de informatie 4. de structuur en status van de te verwerken gegevens 5. de randvoorwaarden die gesteld kunnen worden 6. de toekenning van verantwoordelijkheden en bevoegdheden aan de betreffende organisatorische eenheden.


102



1. De doelen van het informatiesysteem. Het informatiesysteem dient rapportages te genereren, 'deze rapporten hebben als doel de gerealiseerde prestaties van de dienstverlening, zoals neergelegd in het SLA, op hoofdlijnen te confronteren met de overeengekomen ofte verwachten normen. ' Het informatiesysteem (black box) bestaat uit, (oude)gegevens, verwerking, informatie, procedures, apparatuur, programmatuur en mensen. Het is nu de bedoeling om de input bestaande uit: externe gegevens (incidenten en wijzigingen), interne gegevens (afkomstig van performance metingen) en de bestuurlijke gegevens (status van wijzigingen en problemen) met behulp van het informatiesysteem (SLR-systeem) te verwerken tot eenvoudig te interpreteren output: Rapporten en Bestuurlijke informatie. De verschillende items waarover moet worden gerapporteerd zijn opgenomen in bijlage 4. Per item wordt aangegeven hoe vaak deze gerapporteerd zal moeten worden, aan wie en uit welke omgeving de informatie is onttrokken. Alle gegevens dienen tenminste eenjaar te worden bewaard 2a. De volgende functies zijn binnen het SLR systeem te onderscheiden: 1. 2. 3. 4. 5. 6. 7.

het vragen om gegevens; het accepteren van gegevens; het opsplitsen, selecteren en aggregeren van gegevens; de oude gegevens van voorgaande perioden toevoegen; de ontstane informatie verwerken in grafiek en/oftabel vorm; tot slot het samenvoegen van de items tot een rapport per klant; plaatsen op lntra-/lnternet ofhardcopy maken.

Zie figuur 7.5 voor een schematisch functiemodel van het gewenste informatiesysteem. De beschikbaarheidsgegevens en andere rapportage items van de gebruikte applicaties (zoals NUS, GISP, Stadspas etc.) dienen in aparte rapportages te worden opgenomen. Zie hiervoor ook bijlage 4. Interne, externe en bestuurlijke gegevens

Vragen om gegevens

Resultaten plaatsen op Internet

~

~

Accepteren ell opslaan van gegevens

~

Rapporten en bestuurlij ke informatie

Oude gegevens

Opsplitsen, selecteren en aggregerell van gegevens

'\

Samellvoegen van de items tot een rapport per klant

~

De ontstane informatie verwerken in grafiek en/oftabel vorm

I

Figuur 7.5

Functiemodel van het Service Level Rapportage systeem.


103



2b. De regels waaraan de aangeleverde gegevens zicb dienen bouden, zijn: Interne gegevens, (meetgegevens) dienen tijdig (binnen twee werkdagen na het einde van de rapportage periode), compleet en in een standaard formaat beschikbaar te zijn (performance gegevens van de netwerkdiensten en systemen in een database). Externe gegevens, (incidenten) dienen tijdig (binnen twee werkdagen na het einde van de rapportage periode), compleet en in een standaard formaat aangeleverd te worden, dan wel beschikbaar te zijn, (Helpdesk gegevensbestand). Deze laatste moeten tevens voorzien zijn van een duidelijke omschrijving (plaats van optreden, aan- en afmeldtijd, status en mogelijke oorzaken). Bestuurlijke gegevens, (problemen en wijzigingen met eventuele opmerkingen) aanvullende informatie over problemen, wijzigingen, calamiteiten etc. dienen door de verantwoordelijke objecten (service level manager) binnen twee werkdagen na het einde van de rapportage periode, voorzien van een duidelijke omschrijving, te zijn aangeleverd in een standaard formaat (bijv. op flop of Email). De normbestanden horen hier ook bij. Acceptatie van de aangeleverde gegevens vindt plaats als ze voldoen aan de gestelde eisen. Voldoen de gegevens niet aan de eisen dan zal er overleg moeten plaats vinden (SLR-systeem operator, SLM, hoofd PB, opdrachtgever) om de verdere gang van zaken vast te stellen.

Het verwerken van de gegevens tot informatie moet leiden tot een eenvoudige representatie van de te rapporteren items. De informatie moet geschikt zijn voor verdere bewerkingen en dient opgeslagen te kunnen worden, zodat ze in volgende rapporten kunnen dienen als oude gegevens. De begeleidende tekst, tabellen en grafieken moeten begrijpelijk zijn en een consequente opmaak kennen. Ze moeten per contract opgemaakt worden en samen te voegen zijn voor een totaaloverzicht. De ontstane rapporten moeten zowel via post (hardcopy), Email als Internet/Intranet kunnen worden verstuurd (aan de contactpersonen en opdrachtgever), of anderszins beschikbaar te zijn. Dit binnen vijfwerkdagen na het verstrijken van de rapportage periode.

3a. De wijze van interactie met gebruikers en/of andere informatiesystemen. De wijze van interactie tussen gebruikers en/of andere informatiesystemen dient zoveel als mogelijk electronisch te geschieden. Ais dit niet mogelijk is moeten er duidelijke procedures beschikbaar zijn.

3b. De samenstelling van in- en uitvoer. De invoer bestaat uit menselijke handelingen, bij het opstarten van het rapportage proces moet de gebruiker gevraagd om de periode waarover gerapporteerd moet worden. Daarnaast bestaat de invoer uit gegevensstromen (Helpdesk-omgeving, beheersystemen en informatie van de service level manager). De uitvoer bestaat uit teksten, tabellen en grafieken met daarin de gerealiseerde prestaties van de dienstverlening ten opzichte van de overeengekomen of te verwachten normen. Civility Amsterdam bv.

104



3c. Verspreiding van de informatie. De ontstane rapporten moeten zowel via de post (hardcopy), Email als Internet/Intranet kunnen worden verstuurd aan de contactpersonen en opdrachtgever. Dit binnen vijf werkdagen na het verstrijken van de rapportage periode.

4. De structuur en de status van de te verwerken gegevens. Interne gegevens zoals die voor beschikbaarheid en capaciteit dienen de volgende structuur te bevatten: datum, tijd, naam meetobject, status: up/down, gebruik: capaciteit. De interne gegevens worden gebruikt voor de performance informatie aangaande de technische infrastructuur. Externe gegevens van incidenten en wijzigingen dienen de volgende structuur te bevatten: datum en tijd aanmelding, datum en tijd afmelding, naam gebruiker (contract), omschrijving incident/wijziging, status: afgehandeld/plaats in organisatie, gemiddelde en maximale behandeltijd. De externe gegevens worden gebruikt voor informatie over de organisatorische aspecten van de dienstverlening. Bestuurlijke gegevens, de normbestanden dienen de volgende structuur te bevatten: datum, tijd, norm I of II en per contract het type verbinding. Problemen en eventuele opmerkingen dienen de volgende structuur te bevatten; datum, tijd, omschrijving van het probleem, status. De bestuurlijke gegevens moeten verwerkt worden tot de gevraagde management informatie.

Rapportage over beschikbaarheidsbeheer, Civility verschaft een maal per maand (bij GDA) aan de Deelnemer en de Opdrachtgever een (schriftelijke) rapportage over het beschikbaarheids-beheer betreffende de afgenomen diensten. De deelnemer ontvangt, voor zover op hem van toepassing informatie over de beschikbaarheid en betrouwbaarheid van: - het GDA-aansluitpunt; - de koppelingen met externe netwerken en, - de Communicatie- en Email-opties. Voor de Opdrachtgever bevat de rapportage informatie over de beschikbaarheid en betrouwbaarheid: - het netwerk als geheel - de koppelingen met externe netwerken en, - de Communicatie- en Email-opties. Rapportage over capaciteitsbeheer, Civility verschaft een maal per maand aan de Deelnemer en de Opdrachtgever een (schriftelijke) rapportage over het capaciteitsbeheer betreffende de GDA. De deelnemer ontvangt per aansluiting een overzicht van: - de maximum capaciteit in percentages van de CIR waarde - en per protocol de mate van bezetting Voor de Opdrachtgever bevat de rapportage informatie over: - de maximum capaciteit in percentages van de CrR waarde van alle aansluitingen


105



Rapportage over capaciteitsbeheer Externe koppeling (GEMnet, Internet), Civility verschaft een maal per kwartaal aan de Opdrachtgever een (schriftelijke) rapportage over het capaciteits-beheer Externe koppeling: - de maximum capaciteit in percentages van de CIR waarde - en per protocol de mate van bezetting Rapportage over probleembeheer, Civility rapporteert een maal per maand, indien er problemen zijn geconstateerd, (schriftelijk) aan de Deelnemer en de Opdrachtgever over het probleem-beheer betreffende de GDA netwerk, de aansluiting(en) en de Communicatieopties. De rapportage bevat, per afgenomen faciliteit: - naam GDA-dienst - probleem omschrijving - probleem nummer - datum melding - datum afmelding - status Rapportage over de Service desk, een maal per maand wordt aan de Opdrachtgever (schriftelijk) gerapporteerd over de bereikbaarheid van de Service desk. De rapportage bevat: - openstellingsuren - het aantal binnenkomende en doorverbonden gesprekken - het door de Service desk geregistreerde aantal GDA meldingen - het aantal gesprekken in 'long wait' (opnemen na drie keer overgaan) - binnenkomende lijnen met aIle toestellen in gesprek - gemiddelde wachttijd van de binnenkomende gesprekken - tijdens wachten afgebroken binnenkomende lijnen Rapportage over incidentenbeheer, Civility rapporteert een maal per maand, indien er incidenten zijn gemeld, (schriftelijk) aan de Deelnemer en de Opdrachtgever over het incidentenbeheer betreffende het GDA netwerk, de aansluiting(en) en de communicatieopties. De rapportage bevat, per afgenomen faciliteit: - naam GDA-dienst - incident omschrijving - incident nummer - datum melding - datum afmelding - status De rapportage items voor het vaststellen van de Quality of Service van de andere Civility diensten zijn te vinden in bijlage 4. Ook hier komen beschikbaarheid, capaciteit en Helpdesk aan bod. Aangezien voor het beschikbaar stellen van de applicaties gebruik wordt gemaakt van het GDA zal de performance van het GDA door werken in die van de applicaties.

5. De randvoorwaarden die gesteld kunnen worden. Indien van een Deelnemer meerdere aansluitingen tot een contract behoren wordt een rapport gemaakt, waarin de overzichten van al deze aansluitingen zijn opgenomen. Voor het Civility Amsterdam bv.

106



projectkader rond het SLR-systeem zie de hoofdtukken 6.1 en 7.1 betreffende het verbeteren van het IT-beheer (VIB-project) bij Civility. Gestreefd wordt naar een generiek rapportage systeem voor aIle, ook voor de nog te ontwikkelen, applicaties en netwerkdiensten. Zodoende kan het zelfde proces gebruikt worden voor het bepalen en presenteren van de gerealiseerde kwaliteitsniveaus.

6. Verantwoordelijkheden en bevoegdheden van organisatorische eenheden. Helpdesk, verantwoordelijk voor bepaalde eenvoudige operationele taken. Signaleert, registreert en routeert incidenten, bewaakt de afhandelingstermijnen en koppelt de afhandeling terug naar de klant. Registreert wijzigingsaanvragen en informeert gebruikers over WIJZlgmgen.

Produktie, verantwoordelijk voor aIle operationele dagelijkse werkzaamheden ten behoeve van de service (beschikbaarheid en capaciteit) en levert hierover informatie. Is alert op potentiele bedreigingen voor de continuYteit van de dienstverlening. Verantwoordelijk voor back up, restore en logische toegangsbeveiliging tevens coordinator bij uitwijk. 8LM, borgt het serviceniveau door het coordineren en bewaken van incidentoplossings-

trajecten. Coordineert de gebruikersvoorlichting aangaande het wijzigingsproces. Bewaakt de SLA afspraken (beveiliging, beschikbaarheid en capaciteit) en rapporteert hierover. Helpdesk Manager (HM), borgt het serviceniveau door het coordineren en bewaken van het incidentoplossingstraject, zorgt voor escalatie naar hoofd Engineering en rapporteert. Problem Manager (PM), borgt het serviceniveau door het coordineren en bewaken van probleemoplossingstrajecten. Bewaakt de stabiliteit van het produktieproces door trends in incidenten te signaleren. Signaleert en registreert problemen, initieert, coordineert en bewaakt het probleemproces en levert daarover rapportages. Change Manager(CM), borgt het service niveau door het coordineren en bewaken van wijzigingstrajecten. Bewaakt de impact die interne en externe wijzigingen op het produktieproces kunnen hebben. FMS, spreekt service level af met de klant en maakt afspraken over afwijking hiervan. Verantwoordelijk voor afspraken met betrekking tot produktie die niet is gedekt door het SLA. Beoordeelt kosten aspecten van 'aanpassingen' en communiceert met klanten op tactisch niveau.

Engineering (Eng), zorgt voor tactische aspecten van de service inrichting en service configuratie. Levert ondersteuning aan het produktieproces door optimale inrichting, configuratie en hulpmiddelen. Verzorgt de 2de -lijns ondersteuning met betrekking tot het oplossen van incidenten. Verantwoordelijk voor oplossingen op langere termijn voor de beschikbaarheid en de capaciteit van de diensten. Zie ook bijlage 3.


107



7.4

Het Technisch ontwerp

Een technisch ontwerp beschrijft de interne werking van het systeem dat de in het functionele model gewenste functionaliteit mogelijk moet maken, echter onafhankelijk van de te gebruiken middelen. Met name de technische ontwerpers, systeemontwerpers en technisch beheerders zullen in dit model zijn geYnteresseerd. De scheiding tussen het functionele en het technische model maakt het de technisch ontwerpers van het informatiesysteem mogelijk om verschillende alternatieve technische oplossingen voor het realiseren van dezelfde functionaliteit onderling te vergelijken, waardoor het meest efficiente en best onderhoudbare systeem kan worden gekozen Ret technisch ontwerp (of model) beschrijft, zonder dat rekening wordt gehouden met de technologie waarmee het systeem gerealiseerd gaat worden, hoe het informatiesysteem wordt georganiseerd. Aangegeven wordt: 1. hoe de te bewaren gegevens in het systeem worden georganiseerd; 2. hoe de verschillende functies en/of onderdelen daarvan worden gerealiseerd met behulp van systeemdelen; 3. welke delen van het systeem worden geautomatiseerd en welke delen met de hand zullen moeten worden uitgevoerd; 4. de programmaspecificatie van deze processen; 5. de logische verdeling van databases en gegevensverwerking over vestigingen; 6. de toegang tot de gegevens; 7. de randvoorwaarden, zoals beveiliging, gewenste performance e.d. 1. Organisatie van de te bewaren gegevens in het systeem. Gegevensstructuur. Ret doel is de structuur en de onderlinge verbanden te bepalen van de gegevensverzamelingen, die in het kader van het te ontwikkelen informatiesysteem nodig zijn en weI inclusief alle gegevenselementen (attributen) waaruit deze zijn opgebouwd. Deze structuur is onafhankelijk van de zienswijze van de gebruiker. De volgende uitgangspunten worden hierbij gehanteerd [37]: * zorgdragen dat die gegevens worden opgeslagen die nodig zijn om te voldoen aan de informatiebehoeften van nu en zo mogelijk ook in de toekomst; * voorkomen dat overtollige gegevens worden opgeslagen, of dezelfde gegevens meerdere malen; * zorgen voor eenduidige naamgeving, betrouwbaarheid etc. * het vaststellen van onderlinge verbanden.

Voor elk afzonderlijk gegeven (attribuut) dient te worden vastgesteld: * de betekenis (omschrijving); * de unieke naam, eventueel met synomemen (homoniemen mogen echter met voorkomen); * de 'eigenaar', dat wil zeggen: waar ontstaat het, wie is daarvoor verantwoordelijk, wie mag het wij zigen; * het gebruik, wie mogen het gebruiken en onder welke voorwaarden; * de verbanden met andere gegevens; * de schrijfwijze(n), grootte, aantallen, doel, wijze van opslag etc. 10) Welke gegevens moeten opgeslagen worden? De gerapporteerde performance gegevens moeten inzicht geven in de gerealiseerde kwaliteit van de dienstverlening, zoals de klant deze Civility Amsterdam bv.

108



ondervindt. De samenhang van de objecten, die invloed uitoefenen op de performance en daarmee op de rapportage daarover, is geschetst in het schema van figuur 7.6. In de rapportages moeten acties en status van de diverse ITIL-beheerprocessen aanbod komen, mits van toepassing moet de kwaliteit daarvan vergeleken worden met de overeengekomen kwaliteitsnormen.

rl

I

Klant

I Overleg

SLA

Facility Management _ .................................

Change Management

Service Level Rapportage Bestuurlijke informatie

SLR

Externe gegevens

Output

Helpdesk

Bestuurlijke gegevens

...... - ...........................

Netwerkbeheersysteem

Problem Management ...................................

Service Level Management Input

I~

1

Geautomatiseerde acties

Interne gegevens

Stuuracties

Applicatie

I I

Figuur 7.6 Performance en rapportage bernvloedende objecten. De Klant voert, met een bepaald klantgedrag, acties (input) uit die na verwerking door de Applicatie, met een bepaalde kwaliteit (performance), tot de gewenste resultaten (output) moeten leiden. De soort output en de kwaliteit daarvan is middels Overleg tussen Klant en FMS overeengekomen en vastge1egd in het SLA. De SLM bewaakt de kwaliteit en initieert eventuele Stuuracties, om deze te verbeteren. De diverse ITIL processen (Facility, Change, Problem Management etc.) zorgen voor de andere beheeraspecten (zie ook hoofdstuk 6.2). Met behulp van, onder andere 'polling' en 'traps', kan de status van de beheerobjecten die invloed op de performance hebben worden bepaald en vervolgens opgeslagen in het netwerkbeheersysteem (interne gegevens), zie figuur 7.6. Aan het einde van een rapportage periode worden de beschikbaarheid- en de capaciteitsparameters per te rapporteren item berekend. Door het aangeven van re1aties tussen overeenkomstige gegevens van de diverse beheerobjecten is het mogelijk de gerealiseerde kwaliteitsniveaus per dienst (applicatie) en/of per klant te bepalen. Binnen het te beheren systeem zijn ondermeer de volgende beheerobjecten te onderscheiden: servers, databases, CPU's, harde schijven, routers, verbindingen en applicatie software. De applicatie zorgt, vroeg of laat, voor vragen, klachten, veranderingen en problemen bij de Klant. Deze externe gegevens komen bij de Helpdesk terecht, die deze gegevens weer doorgeeft aan het daarvoor bestemde ITIL-proces. Samen met de rapportage over de Civility Amsterdam bv.

109



gerealiseerde service levels vormt dit de bestuurlijke informatie voor de beheer organisatie. Zoals vermeldt kan een applicatie worden voorgesteld als een samenstelling van beheerobjecten, de schematische opbouw van een applicatie is afgebeeld in figuur 7.7. Vergelijking van dit figuur met figuur 7.6 laat zien dat de Ius Klant-input-applicatie-output-Klant vervangen is door een bidirectioneel communicatie netwerk. Aan de ene kant bevindt zich de klant (de gebruikers) aan de andere kant de beheerorganisatie, alwaar de applicatie 'draait' en wordt beheerd. RS/6000

Communicatie

RS/6000

of Novell server

GDA RS/6000 gebruikers

Ethernet

'v"""

'--....._ - - - ~--=--_/ 'v"""

Civility

Klant

Figuur 7.7 De schematische opbouw van een applicatie. Elk onderdeel van een applicatie is te zien als een beheerobject, zo een object (zie figuur 7.8) is van invloed op de performance. Om nu de performance op applicatie niveau te bepalen moet de performance van de afzonderlijke objecten bekend zijn. Door het definieren van samenstellingen van objecten is het mogelijk de gerealiseerde kwaliteit van verschillende rapportage items per rapport (klant) te bepalen. Beheerobject operaties

Figuur 7.8

meldingen

Schematische voorstelling van een beheerobject.

Een beheerobject is met de volgende termen te beschrijven: * Operaties, uitgevoerd op het object. * Gedrag, hetgeen dat voIgt als response op de operaties. * Attributen, de eigenschappen of karakteristieken van het object. * Meldingen, voortgebracht door het object. Om inzicht te krijgen in de omvang van en de samenhang binnen het te beheren systeem, zijn de objecten, waaruit de applicaties bestaan, gernventariseerd naar soort en aantal (zie bijlage 6 en figuur 7.9). Aangaande de performance van deze objecten dient op verschillende niveaus rapportage plaats te vinden, van componentniveau (CPU belasting, harddisk bezetting) tot Civility Amsterdam bv.

110



applicatieniveau (beschikbaarheid). Doordat binnen rapportages verschiIlende abstractieniveaus zijn te onderscheiden, is dat ook het geval op het gebied van de gegevensverzameling. Op de volgende abstractieniveaus kan gegevensverzameling plaatsvinden: 1. direct op rapportage item niveau, door aIleen aan die onderdelen te meten waarover gerapporteerd dient te worden; 2. op beheersniveau (beheerobjectniveau), meten aan die (beheer-)objecten die zelfstandig zijn te onderscheiden, bijvoorbeeld door naamgeving of contracten met derden, binnen het te beheren systeem; 3. op componentniveau, meten aan aIle componenten (bijvoorbeeld CPU, harddisk, geheugen, interfaces, lijnen, software pakketten, etc.) die onderdeel uitmaken van het systeem. Aan de geschetste niveaus voor gegevensverzameling klevende volgende voor- en nadelen: 1. de voordelen van gegevensverzameling op rapportage item niveau zijn de eenvoud (er hoeven nauwelijks ingewikkelde berekeningen op de gegevens losgelaten te worden), de relatief kleine gegevensstroom die verwerkt moet worden en de hoeveelheid beheerinformatie die verzonden wordt blijven tot een minimum beperkt. Door voortschrijdend inzicht kan een item, waar nodig, verder uitgesplitst worden en verdeeld in afzonderlijke nieuwe items. Bet niveau is toereikend voor rapporten voor de klant, de facilities manager en de service level manager. Bet nadeel van gegevensverzameling op dit niveau is, dat bij het constateren van een te lage Quality of Service de precieze oorzaak (de bottleneck) onbekend is. 2. de voordelen van gegevensverzameling op beheersniveau zijn de ontwikkeling van het beheersysteem en het rapportage systeem kunnen parallellopen (binnen het VIB-project), gegevens nodig voor het beheer worden ook verwerkt tot rapportages. Bet geeft inzicht in de zwakke schakels (objecten) binnen de diensten en applicaties. Bet niveau is toereikend voor het probleembeheer. De nadelen van gegevensverzameling op dit niveau, de complexiteit en diversiteit van de gegevensstromen die verwerkt dienen te worden tot een uniforme gegevensrepresentatie lijden tot een omvangrijke database en complexe berekeningen. Voor enkele rapportage items zal blijken dat het abstractieniveau te hoog of te laag ligt, aanpassing kan dan nodig zijn. 3. het voordeel van gegevensverzameling op componentniveau is het transparant zijn van het te beheren systeem, de performance van elk onderdeel is bekend, hierdoor wordt het mogelijk de oorzaak van eventuele problemen direct te localiseren. Bet niveau van deze rapportage is toereikend voor het onderhoudsbeheer, de technisch specialisten en troubleshooters. De nadelen zijn de hoge mate van complexiteit van het te beheren systeem, dit lijdt tot een complex en duur beheersysteem. De zeer omvangrijke gegevensstromen dienen verwerkt, bewerkt en opgeslagen te worden, dit stelt zware eisen aan het rapportage systeem. Elke wijziging binnen het te beheren systeem dient niet alleen in de CMDB opgenomen te worden maar houdt ook een wijziging in het rapportage systeem in. Gegevensverzameling op rapportage niveau (l) is, in het algemeen, te prefereren bij het ontwikkelen van een eerste rapportage systeem. Beginnen met een eenvoudig systeem dat enkellevert waar om gevraagd is: 'rapporteren van behaalde service levels', en later is uit te breiden met nieuwe functionaliteiten of te verdiepen, bijvoorbeeld invloed op de performance van specifieke objecten bepalen, wanneer daar behoefte en mogelijkheden voor zijn. Dit is de Civility Amsterdam bv.

III



opzet van het oude rapportage systeem.

KlantWerkplek Klantserver ISDN voor back-up .

~

Verbinding

Knooppunt Router Ethernet _-,._ _-+-__..,....

Stopera

ISDN voor back-up

~

2*2Mbps + back-up

Civility Ethe et

-.,....-.. . .

~_I.-_.,....---~~~~I.-_

...

- GDA Ethernet

GemNet

Figuur 7.9 Samenhang van de objecten in het te beheren systeem. Bet verzamelen van gegevens op componentniveau is ideaal bij een hoge mate van standaardisatie binnen, en stabiliteit van, het te beheren netwerk. Voor IT-beheer, op de schaal van MV-PH, is het meer een toekomst perspectief dan reele optie. Dit heeft zowel met de kosten, in geld en inspanning, als met de veranderingssnelheid van het netwerk te maken.


112



Het hier te ontwikkelen rapportage systeem is niet los te zien van andere ontwikkelingen en veranderingen in de beheeromgeving en -structuur, waarin het beheer met name op objectniveau wordt beschouwd. De klant koopt netwerkdiensten en systeemapplicaties met een bepaalde kwaliteit, terwijl het beheer gebeurd op objecten en componenten. De keuze is derhalve gevallen op het verzamelen van gegevens op objectniveau (waar nodig op componentniveau) en deze gegevens door eenduidige definities (aangeven van relaties) te koppelen aan een rapportage item en daarvoor middels berekeningen een cijfer te presenteren. De rapportage items hebben betrekking op verschillende abstractieniveaus, de volgende niveaus worden onderscheiden: 1. Applicatieniveau, bijvoorbeeld de beschikbaarheid van het GISP on-line systeem, beschikbaarheid van het GDA als geheel of de responstijd van het NFS. 2. Dienstenniveau, bijvoorbeeld de beschikbaarheid van Email, beschikbaarheid van een GDA-aansluiting of gebruik van back-up en bandwidth on demand. 3. Objectniveau, bijvoorbeeld de beschikbaarheid van de centrale print faciliteit van WVG, afgenomen capaciteit van een verbinding ofhet aantal gelijktijdige gebruikers van server. 4. Componentniveau, bijvoorbeeld de CPU belasting of harddisk bezetting. Attributen als de beschikbaarheid (MTBF en MTTR) en het capaciteitsgebruik (CPU belasting, harddisk bezetting, bandbreedte, gebruikersgedrag, vertragings- en responstijden etc.) karakteriseren het kwaliteitsaspect van een component, object, dienst of applicatie. De volgende onderverdeling van attribuutsoorten wordt in de rest van dit ontwerp aangehouden: * beschikbaarheidsgegevens (downtijden, MTTR en MTBF); * capaciteitsgegevens (afgenomen bandbreedte, CPU belasting en harddisk bezetting); * responstijden (verwerkingstijden van applicaties en netwerkvertragingstijden); * gebruikersgedrag (totaal aantal en gemiddeld aantal gelijktijdige gebruikers). Beschikbaarheidsgegevens, rapportage items aangaande de beschikbaarheid van applicaties, diensten en opties (zie tabel 7.2) worden berekend vanuit de beschikbaarheid van de betrokken objecten. Voor het bepalen van de objecten betrokken bij een item moet eerst bekend zijn wat er precies onder dat item verstaan wordt, de items dienen duidelijk te worden gedefinieerd en afgebakend. De definities zijn opgenomen in bijlage 5. Voor de berekening van het uiteindelijke resultaat moeten formules bepaald worden die rekening houdend met de samenhang en onderlinge verbanden tussen de betrokken objecten en de beschikbaarheid daarvan. Applicaties Diensten Objecten 3270 Gateway GDA aansluiting GDA als geheel ISDN back-up lijnen Koppeling GemNet NUS on-line systeem Koppeling Internet GISP on-line systeem Email faciliteiten Stadspas on-line systeem WVG centrale printfaciliteit WVG on-line systeem NFS on-line systeem BWV on-line systeem Tabel 7.2 Rapportage items aangaande beschikbaarheid.

Componenten

-

Normen naamgeving, binnen een groot netwerk als de GDA en daarop aangesloten applicaties is het van groot belang om afspraken te maken over naamgeving en adressering. Het deel van Civility Amsterdam bv.

113



deze normen, dat van belang is voor de lokale beheerders, is vastgelegd in een boekje 'Normen naamgeving'. Voor zover van toepassing wordt van deze norm gebruik gemaakt. Voor de benaming van applicatieonderdelen wordt de betreffende documentatie gebruikt. De beschikbaarheid van een systeemdeel kan uitgedrukt worden in een percentage, totale downtijd of in de grootheden 'mean time to repair' en 'mean time between failures'. Al deze presentatie vormen kunnen bepaald worden als men, per item, de tijden weet waarop een systeemdeel 'down' ging (onbeschikbaar) en weer 'up' kwam (beschikbaar). Van de volgende systeemdelen wordt achtereenvolgens de opbouw bepaald (beheerobjecten) de definitie van beschikbaarheid, voorzover niet te halen uit bijlage 5, en de berekening daarvan: GDA aansluiting, koppeling GemNet, koppeling Internet, Email faciliteiten, 3270 Gateway, ISDN back-up/BOD lijnen, on-line applicatiesystemen en de centrale printfaciliteit. Backbone netwerk Knooppunt Paalbergweg Cisco router 25xx GD Etheme

Knooppunt Stoper ISDN-2B back-up r. ...... -- .............

. ......................... ;

2 Mb vast

anar23

Cisco router 25xx

Cisco router 25xx ancr03

ISDN-2B back-up r.

...................................

.... .........................

2 Mb vast

anar22

DA themet

Cisco router 25xx ancr02

Figuur 7.10 Schematische samenstelling van het Backbone netwerk. De 'backbone', zie figuur 7.10, is beschikbaar als communicatie mogelijk is tussen de GDA Ethernet segmenten op de locaties Paalbergweg en Stopera. Dit kan worden bepaald door vanaf de Iocatie Paalbergweg de bereikbaarheid van routers ancr02 en ancr03 (Cisco 25XX) te bepalen, als tenminste een van beide bereikbaar is, is de backbone beschikbaar. Dit is gegevensverzameling op rapportage niveau, het is ook mogelijk de beschikbaarheid van de Backbone vanuit het objectniveau te bepalen. Onderstaande formule kan hiervoor gebruikt worden. Backbone = (Routeranar23 * Routerancr03 * (vaste verbinding2Mb + ISDN Back-uP2-64Kb)) + (Routeranar22 * Router.ncr02 * (vaste verbinding2Mb + ISDN Back-up2-64Kb )).

Op component niveau kunnen de diverse interfaces (seriele, Ethernet, token-ring en/ofBRI) in een router nader worden beschouwd. Een 'basisaansluiting', zie figuur 7.11, zonder back-up is beschikbaar als vanuit het GDA Ethernet segment waarop de klant is aangesloten communicatie met de klantrouter kan plaatsvinden (backbone niet inbegrepen). Dit is de enge definitie, een definitie in ruimere zin: een basisaansluiting is beschikbaar als vanuit beide knooppunten communicatie met de klantrouter kan plaatsvinden (backbone weI inbegrepen). Civility Amsterdam bv.

114



GDA basisaansluiting

."

..- ...... Klant-LAN·.

Knooppuntrouter GDA Ethernet

.... Klantrouter

Cisco

: :

Cisco

25xx f-

of AGS+

25xx I - -

: Vaste verbinding

:

:

-

: :

,

Kla~t °iocat"ie

Knooppunt locatie

Figuur 7.11 Schematische samenstelling van een basisaansluiting. Bepaling van de beschikbaarheid van een basisaansluiting volgens de enge definitie kan gebeuren door vanuit de beide GDA Ethernet segmenten de daarop aangesloten klantrouters proberen te bereiken. Bepaling van de beschikbaarheid van een basisaansluiting in mime zin kan gebeuren door vanuit een GDA Ethernet segment de klantrouters proberen te bereiken. Voor de klanten aangesloten op het andere knooppunt levert dit direct de beschikbaarheid. Voor klanten aangesloten op het knooppunt waar vanaf gemeten wordt, moet de beschikbaarheid van de backbone ook in de uiteindelijke berekening opgenomen worden. De beschikbaarheid van een basisaansluiting vanuit het objectniveau bepalen, kan met onderstaande formule: Basisaansluiting = (Backbone) * (GDA Ethernet segment * RouterKnooppunt * Verbindingvast * RouterKlanJ.

GemNet koppeling anar25 GOA Ethernet

Cisco

25xx

IP

GemNet router

f------'

X25

Knooppunt Paalbergweg

Figuur 7.12 Schematische samenstelling van de koppeling met het GemNet. De 'GemNet koppeling', zie figuur 7.12, is beschikbaar als vanafhet GDA Ethernet segment op de locatie Paalbergweg communicatie met het GemNet kan plaatsvinden. De beschikbaarheid kan worden bepaald door te controleren of de GemNet-router te bereiken is. De beschikbaarheid van de GemNet koppeling vanuit het objectniveau bepalen, kan met onderstaande formule: GemNet koppeling = GDA Ethernetpaa,bergweg * Routeranar2S


115

* (Verbinding1p + VerbindingX2s) * RouterGemNet.



Internet koppeling GOA Ethernet

B1auwe zone

anar26

Rode zone

Cisco

anarl3 Cisco

25xx

25xx FirejWall


Figuur 7.13

Schematische samenstelling van de koppeling met het Internet.

De 'Internet koppeling', zie figuur 7.13, is beschikbaar als vanafhet GDA Ethernet segment op de locatie Paalbergweg communicatie met het Internet kan plaats vinden. De beschikbaarheid kan worden bepaald door te controleren of de Internetaansluiting (Router anar13) te bereiken is. De beschikbaarheid van de Internet koppeling vanuit het objectniveau bepalen, kan met onderstaande formule: Internet koppeling = GDA EthernetPaalbergweg

* Routeranar26 * EtNblauw * FireWall * EtNrood * RouteranarlJ' Klant-LAN

Email faciliteiten

Klantrouter

1------1 GOA Ethernet

Cisco

25xx

Email Postbus

TR-GDA Prod. Klant-LAN GroupWise mail server GOA

1-----1 Cisco I------t AGS+

Cisco

25xx

anafOl

client

anarOl Klant locatie

Email Transit

Figuur 7.14 Schematische samenstelling van de Email faciliteiten. De Email berichten, van buiten het GDA, voor een transit client komen binnen via de Internet koppeling binnen en gaan na verwerking door de centrale faciliteiten, via het GDA netwerk, naar de mail server bij de klant. De Email berichten voor een postbus client worden opgeslagen op de GDA mail server, tot de client zijn postbus via het GDA ophaalt. De 'Email transit' optie en de .Email postbus' optie, zie figuur 7.14, zijn beschikbaar als de centrale Email faciliteiten beschikbaar zijn. De beschikbaarheid van de centrale faciliteiten kan Civility Amsterdam bv.

116



bepaald worden door te controleren of er vanaf de GDA mail server Email verzonden en ontvangen kan worden. De beschikbaarheid van de centrale Email faciliteiten vanuit het objectniveau bepalen, kan met onderstaande forrnule: Email = GDA EtNpaalbergweg * DNS,nafll3

Inbelvoorziening

* Relay Hostanaf04 * RouteranarOl * TR-GDAprod. * Mail Server GDAanaflll

GDA Inbelfaciliteiten

GDAEthemet GDAServlce segment

ISDNpool I - Cisco

gdag02

AGS+ Modem pool anarOl gdag03


Figuur 7.15 Schematische samenstelling van de inbelvoorziening. De 'Inbelvoorziening' is een nieuwe dienst die bestemt is voor 'kleine' GDA gebruikers. In plaats van een router en een huurlijn, kan er op het GDA ingebeld worden. Twee opties zijn mogelijk (1) de klant belt via een modern (bijvoorbeeld met 28k8) of (2) met een ISDN lijn. De inbelvoorziening, zie figuur 7.15, is beschikbaar als de centrale inbelvoorzieningen en de koppeling met het GDA Ethernet beschikbaar zijn. De beschikbaarheid van de Inbelvoorziening vanuit het objectniveau bepalen, kan met onderstaande forrnules: Inbelvoorzieninggewone lijn = GDA EtNp",bergweg * Router,narOl

* Modem poolgd,go3

Inbelvoorziening ISDN lijn = GDA EtNpaalbergweg * RouteranarOl

* ISDN poolgdago3

3270 Gateway

Cluster controller

GDAEthernet TR-GDA Prod.

\ '--

Cisco AGS+

IBM-

channel

3174

V T A

IBM-mainframe

M LORGeR

I

SNAGW

anarOl anaf02


Figuur 7.16 Schematische samenstelling van de 3270 Gateway.


117



De 'remote terminal access 3270' optie, zie figuur 7.16, is beschikbaar als vanuit het GDA Ethernet segment op de locatie Paalbergweg kan worden gecommuniceerd met het IBM mainframe op die zelfde locatie. De beschikbaarheid van de 3270 Gateway kan worden bepaald door te meten of VTAM bereikt kan worden. De beschikbaarheid van de Internet koppeling vanuit het objectniveau bepalen, kan met onderstaande formule: 3270 Gateway = GDA EtNpaa,bergweg * Routeranartll

* TR-GDA Prod. * SNA-GWanaroz * CiusterControllerL08GCR

Bij de basisaansluitingen met een 'back-up voorziening' wordt een ISDN-aansluiting ingezet. Door middel van deze ISDN-kieslijn, zie figuur 7.17, kan bij uitval van de vaste lijn de verbinding in stand worden gehouden (situatie 1). Het inzetten van deze back-up voorziening gebeurt geheel automatisch. Indien het GDA-knooppunt waarmee de vaste lijn is verbonden in zijn geheel uitvalt, verzorgt deze voorziening automatisch een verbinding met het andere knooppunt (situatie 2). Knooppuntrouterx

ISDN lijnen voor back-up en BOD

Klant-LAN

GOA Ethemetx

Klantrouter

Cisco

25xx GOA Ethernety

Knooppuntroutery

Een knooppunt locatie Cisco 4000 f - - - - - - - - - - - - ' ISDN-lB verbindingy

Klant locatie De andere knooppunt locatie

Figuur 7.17 Schematische samenstelling van de ISDN lijnen voor back-up en BOD. Een basisaansluitingen met een back-up voorziening is beschikbaar als met tenminste een knooppunt kan worden gecommuniceerd. De beschikbaarheid kan worden vastgesteld door vanaf beide knooppunten te bepalen welke klantrouters bereikbaar zijn. Wil men centraal, vanaf de locatie Paalbergweg, de beschikbaarheid van alle klantrouters bepalen dan moet de Netwerk Management Machine (NMM) ook met ISDN back-up worden uitgerust. Ais het knooppunt op locatie Paalbergweg uitval kan de NMM via de back-up verbinding het andere knooppunt bereiken en van uit daar bepalen welke routers bereikbaar zijn. De beschikbaarheid van een basisaansluitingen met een back-up voorziening vanuit het objectniveau bepalen, kan met onderstaande formule: Basisaansluiting met back-up = Normaal (zie basis aan sluiting zonder back-up) + situatie 1 + situatie 2. Situatie I = GDA Ethernet segmentx * RouterCisco 4000 X Situatie 2 = GDA Ethernet segmenty


* Back-up verbinding,sDNnaarX * RouterKlant.

* Routercisco4000Y * Back-up verbinding,sDNnaarY * RouterKlant.

118



Het 'totale GDA netwerk', zie ook figuur 7.9, is een samenstelling van bovengenoemde systeemdelen. De beschikbaarheid berekenen van het Netwerk als totaal moet een reeel beeld geven van de beschikbaarheid (AV, Availability) zoals de gebruikers deze gezamenlijk ervaren. De volgende uitgangspunten worden gehanteerd: * aile gebruikers zijn even belangrijk, onafhankelijk van de afgenomen capaciteit, plaats, aantal werkplekken etc.; * de koppelingen met externe netten, Internet, Email, GemNet maar ook het Mainframe tellen ailemaal even zwaar; * de backbone is voor aile gebruikers even belangrijk; AVgem basisaansluitingen * AV backbone

AVGDA

=

AVgem basisaansluitingen

= (

AV backbone

=

AVgem koppelingen

= ( L AV koppelingen ) / # koppelingen.

* AVgem koppelingen.

L AV basisaansluitingen ) / # basisaansluitingen.

backbone

De 'applicaties' GISP, Stadspas, NFS, BWV en WVG (met print faciliteit) zijn voor de klanten beschikbaar als de applicatie werkt en via het GDA bereikbaar is. De applicatie is beschikbaar als het frame, RS6000-node, harde schijven, database en software - kortom de componenten - beschikbaar zijn. Het bepalen van de beschikbaarheid van een applicatie, zie figuur 7.18, wordt opgehangen aan de beschikbaarheid van de RS6000 node, dit is het hart van de applicatie, de centrale print faciliteiten en verbindingen daar tussen. On-line applicatiesystemen

~

//~·~~;i'~~~i~'·'·'·'\\\.,.

...

•

.

j .):' ; " i Civil.1.! RS6000 ity j node Ether ii

anarO I Cisco AGS+

! i

database

!

net

I

anar23

ancr03

jj

.I

j

..Jl..,

SP/2 frame

.•.•.

_ _._

_.......

\

.

.- -.

"', .,\

"""""'. •...........'~'

Cisco, 4000 GDA Ethernet •. Stopera

.l!.:

!

:.:b:.:.:.:

GDA Ethernet anarXX ~ . ':' -' GDA Paalbergweg' Cisco 25xx ',' Back-up •••••

. ..,/

. i

Klant locatie

0 " " " " " " " " " " " " " " " " " " " " " " " " " ' " • • • ••

;

3

'

:..:

._

.

',;j. : ~1Klan~

Cisco 25xx

L.

_ .__

,

• , ' , Cisco', ; 4000 " .. ", j Back-u~, " : '. I, !

A~~+

:yocatle

m~XX

~.~.:r~~

[ .

.

.

Klant locatie

Figuur 7.18 Schematische samenstelling van de applicaties en de bereikbaarheid daarvan. Centrale print faciliteiten: De centrale print faciliteit voor RS6000 gebruikers (WVG valt daar onder) wordt verzorgd door het Line Printer Deamon (LPD). Een WVG gebruiker geeft print opdracht op RS6000, deze RS6000 stuurt print opdracht door naar zijn spooler queue. Een printer waar LPD op draait leest de queue uit en verwerkt de printjobs. De printer heeft een eigen ip adres, en is met SNMP te managen.


119



Tevens is een centrale print faciliteit beschikbaar die rechtstreeks aan de RS6000 hangt, deze wordt gebruikt door GISP. De beschikbaarheid van een applicatie vanuit het objectniveau bepalen, kan met onderstaande formule: Applicatie = NodeRS6000 * Ethenetcivility (* Centrale print faciliteit)

De bereikbaarheid van een applicatie op de locatie Paalbergweg is voor verschillende klanten anders, de klanten kunnen hiervoor opgedeeld worden in drie groepen, zie figuur 7.18: a. klanten (±10 stuks) aangesloten op dezelfde router als de applicatie; b. klanten (±10 stuks) aangesloten op hetzelfde knooppunt maar op een andere router; c. klanten (±40 stuks) aangesloten op de andere locatie. De bereikbaarheid kan bepaald worden door centraal vanaf het GDA Ethernet segment op de locatie Paalbergweg de klantrouters proberen te bereiken, het succes hiervan is een maat voar de bereikbaarheid. De bereikbaarheid van een applicatie met of zonder een back-up voorziening vanuit het objectniveau bepalen, kan met onderstaande formules (AV = availability): AV van a =

RouteranarOl

AV van b = RouteranarOl * GDA EtNpaalbergweg * RouterKlant * «RouteranarXX * Verbindingvast) + (Routercisco 4000/anarXX * Back-up verbindingIsDN)) AV van c =

RouteranarOl * GDA EtNpaalbergweg * RouterKlant * (Backbone * GDA EtNstopera * «RouterancrXX * VerbindingvasJ + (Routercisco4000/ancrXX * Back-up verbinding1sDN)) + ( Routercisco4000/anarXX * Back-up verbindingIsDN )).

De gemidde1de bereikbaarheid van de applicaties wordt hiermee:

~axAV~+~bxAV~+~cxAV0

Gemiddelde Bereikbaarheid = -'----~'----'--------'-"'--------' totaal aantal aansluitingen

NUS is een applicatie met een eigen netwerk, zie figuur 7.19, dat in de toekomst migreert naar de GDA infrastructuur. Voor het huidige systeem bestaat er een rapportage proces, waar men tevreden over is. Aangezien het NUS netwerk overgaat naar de GDA kunnen de zelfde definities als voor het GDA en de overige applicaties overgenomen worden. Mocht blijken dat een of meer NUS diensten niet te vangen zijn binnen de bestaande structuur, wat nu nog niet te overzien is, moeten aanvullende definities worden opgeste1d. De beschikbaarheid van het huidige NUS systeem wordt vastgesteld op basis van uitval van de RS6000-computers (servers) op de locaties; de uitval van individuele werkplekken of printers worden niet meegerekend.


120



NUS

SDAC04 SDAC03 SDA 02

Civility-LAN

Router anarOI

I

Mainframe

Nus test

[

SDAC 1

I SFXCOI I

SFYCOI

I

I

I

Router SFYROI

~

Orly plaza router & RS6000

Civility

router & RS6000

I

Router SFYR02

Router SFYR03

~

Dost router & RS6000

Zuid

Baarsjes I

router &

router &

RS6000

RS6000

Watergr.m. router & RS6000

Rivierenbu. router & RS6000

Bamjes2 router

I Vlaardingenl router & RS6000

~

Klant locatie

Osdorp router & RS6000

Router SFYR04

Oud-West 1 router & RS6000

De Pijp router & RS6000

Raadhuisst. router & RS6000

Plein 40/45 router & RS6000

I

~

Noord router & RS6000

I Router SFYR05

~

Centrum router & RS6000

Dud-West 2 router

I

Reigersbos router & RS6000

Karspeldreef router & RS6000

I Zeeburg router & RS6000

I

I

router &

Westerpark router &

RS6000

RS6000

Delftlandpl

Figuur 7.19 Schematische samenstelling van het NUS netwerk. Capaciteitsgegevens, van de rapportage items aangaande de capaciteit van applicaties en diensten, maar ook van objecten en componenten (zie tabel 7.3) dient bekend te zijn: de definitie, naamgeving en berekeningswijze.

Applicaties

Diensten

Objecten

Aantal transacties Volume databank

Verkeer per protocol Gebruik BOD

Afgenomen lijncapaciteit CPU belasting Harddisk bezetting

Tabel 7.3

Componenten

-

Rapportage items aangaande capaciteitsgebruik.

'Aantal transacties' (per applicatie), tijdens het ontwikkelen van een applicatie moet een schatting van het aantal transacties gemaakt worden om de (verwerkings-)capaciteit van die applicatie te dimensioneren. In de service level agreements komt de performance van een applicatie aanbod, hiervoor kan het noodzakelijk zijn vooraf te bepalen voor hoeveel transacties (in aantallen per tijdseenheid) een dergelijke overeenkomst geldig is. Ais van zo een voorwaarde sprake is, is het noodzakelijk om het daadwerkelijke aantal transacties te kunnen rapporteren. In de huidige SLA's van Civility-applicaties en -diensten is van dergelijke voorwaarden niet of nauwelijks sprake, derhalve ontbreekt het aan definities en normen voor een goede transactiespecificatie. Onder deze omstandigheden is het niet zinvol het rapportage item 'aantal transacties' in het technisch ontwerp op te nemen dan weI verder uit te werken. Zie ook gebruikersgedrag. 'Volume van de databanken' (per applicatie), het merendeel van de applicaties maakt gebruik van databanken (databases). Voor het tijdig aanpassen van de capaciteit van de databanken is Civility Amsterdam bv.

121


Structureren van IT-beheer met ITIL. ontwikkeling van een Service Level Rapportage systeem met SDM

het noodzakelijk inzicht te hebben in het benodigde volume. De vullingsgraad, het aantal beschikbare records en de omvang in bytes kunnen gebruikt worden als eenheden voor dit rapportage item. 'Verkeer per protocol' (ODA), De volgende protocollen worden ondersteund door de ODA: a) IPX/SPX voor bijvoorbeeld Novell b) DECnet voor VAX-computers c) TCPlIP voor UNIX-computers d) X25 middels een aparte poort op de remote klantrouter e) LAT via LAT naar TCP/IP translatie. De volgende protocollen worden indirect ondersteund door de ODA: a) SNA middels een gateway via IPx/SPX. b) SNA middels een gateway via DECnet. Om het verkeer per protocol te kunnen vergelijken dient de zelfde eenheid gebruikt te worden (met de zelfde inhoud qua aantallen bits of bytes); eventueel omgerekend tot een percentage van het totale verkeer. 'Afgenomen lijncapaciteit' (ODA), de basisaansluiting biedt een gegarandeerde transportsnelheid, de Committed Information Rate (CIR), voor de toegangslijn tot de ODA infrastructuur (de uitgaande lijn van de klantrouter, zie figuur 7.11), die voor aansluitingen met een enkelvoudige lijn wordt bepaald door de toegepaste lijnsnelheid. De CIR waarden, aangegeven in kilobits per seconde, betreffen de bruto hoeveelheden te transporteren data per tijdseenheid, inclusief de protocoloverhead van de transport-protocollen en het management verkeer. 'Oebruik bandwidth on demand' (ODA), de Bandwidth On Demand optie wordt op drie verschillende wijzen gebruikt: 1. de optie BODl betreft een configuratie waarbij een ISDN-verbinding als extra wordt opgezet wanneer de vaste verbinding meer dan een bepaald percentage wordt belast. 2. de optie BOD2 betreft een configuratie waarbij een ISDN-verbinding wordt opgezet wanneer een specifieke sessie wordt ge'initieerd. 3. de optie BOD3 betreft een configuratie met twee vaste verbindingen die elk een vooraf bepaald deel van het netwerkverkeer op zich nemen. Beide vaste verbindingen wordt voorzien van back-up over ISDN. Uitsluitend het gebruik van optie BODl wordt verwerkt in de capaciteitsrapportage. Wordt er bij de ODA-aansluiting gebruik gemaakt van een vaste verbinding dan zal er bij deze optie via ISDN een extra verbinding naar een knooppuntrouter worden opgezet wanneer de vaste verbinding meer dan een bepaald percentage wordt belast; dit percentage wordt standaard ingesteld op 60%. Daalt deze belasting onder de 20% dan wordt de ISDN-verbinding weer uitgeschakeld. De genoemde percentages zijn exponentieel gewogen gemiddelden over 5 minuten. De bandbreedte van de ISDN-verbinding is maximaal 64 kbps (1 enkel B-kanaal). Wanneer de knooppuntrouter voor ISDN onbereikbaar is wordt een verbinding met een tweede (inbel) router (op het andere knooppunt) opgezet. Opgemerkt dient te worden: Civility Amsterdam bv.

122



Load-balancing over de vaste en de ISDN-verbinding wordt alleen ondersteund voor IPverkeer waarbij ook de vaste verbinding een bandbreedte heeft van 64 Kbps (net als ISDN), m.a.w. aansluittype 2.3b. Bij aanluittype lAb' 19 Kb vast met 64 Kb tijdgebonden + BOD' zal na het inschakelen van ISDN het verkeer over die ISDN-verbinding gaan lopeno De ISDN-verbinding wordt ook opgezet wanneer de vaste verbinding uitvalt (back-up). 'CPU belasting' (per node), de centrale processor unit is het hart van de verwerking, rapportage over de belasting hiervan geeft inzicht in een mogelijke oorzaak van performance problemen van applicaties. Een vuistregel voor de CPU-belasting zegt dat deze, om geen grote negatieve invloed op de performance te hebben, niet structureel boven de 80% mag liggen. Hierbij dient opgemerkt te worden dat de belasting van een CPU afhankelijk is van het soort gebruik. Gegevens over de wachtrij (grootte van de run-queue) voor een server (CPU) en de bezetting van de server (load) samen, geven een representatiever beeld van de capaciteit van eenCPU. 'Harddisk bezetting', de capaclteltsgegevens (het gebruikte en het beschikbare deel, in megabytes) van een harde schijf moet gerapporteerd worden om tijdig acties te kunnen ondernemen, zoals de schijf schonen, vervangen door een grotere ofhet plaatsen van een extra schijf. Responstijden, een item dat steevast voorkomt in een Service Level Agreement maar zeer in een client-server omgeving moeilijk objectief te bepalen is (zie ook tabel 7.4). Voor het bepalen van de transactie- en responstijden kunnen drie verschillende methoden worden gebruikt. 1. Het met een stopwatch, over de schouder van de gebruiker heen kijkend, timen van de responstijd. Dit wordt of een maal per rapportage periode gedaan of als er bij een klant (structureel) klachten zijn. 2. Door het regelmatig meten aan een representatieve verbinding, welke uitsluitend voor dat doel gebruikt wordt. 3. Door gebruik te maken van het Application Response Measurement (ARM) Application Programming Interface (API). Dit is een recente API (aangekondigd in juni 1996) ontwikkeld door Tivoli (met IBM) en Hewlett Packard, die het mogelijk maakt op het niveau van individuele transacties een applicatie te bewaken.

Applicaties

Diensten

Verwerkings- en/of Responstijden transactietijden Tabel 7.4 Rapportage items aangaande responstijden.

Objecten

Componenten

Vertragingstijden

-

Elke methode heeft voor en nadelen. De 'stopwatch' methode (1) heeft als voordeel dat de responstijden worden gemeten die de klant op dat moment waarneemt. Bovendien ziet de klant dat er aan zijn klacht serieus aandacht wordt besteed. Het nadeel is dat het een moment opname is, als de meting op vrijdagmiddag plaatsvindt zal misschien blijken dat er geen problemen zijn. Terwijl de zelfde meting op maandag ochtend zou laten zien dat de responstijden niet meer voldoen aan de service niveau overeenkomst. Daarnaast is deze methode erg arbeidsintensief.


123


Structureren van IT-beheer met IIIL, ontwikkeling van een Service Level Rapportage systeem met SDM

De 'representatie' methode (2) heeft als voordeel dat deze met relatief geringe investeringen (materieel en arbeid) gerealiseerd kan worden. Het nadeel is het feit dat moeilijk is vast te stellen of de bemeten verbinding inderdaad representatief is voor alle gebruikers. De Application Response Measurement methode (3) heeft als voordel dat voor elke klant op transactie niveau de performance en responstijden bepaald kunnen worden. Het nadeel van deze methode is investering die moet worden gedaan. Om een beeld te geven van de mogelijkheden van deze nieuwe methode, die zeker voor de toekomst perspectief biedt, voIgt hier een beschrijving. De Application Response Measurement (ARM) Application Programming Interface (API). Business applicaties zijn vandaag de dag kritische elementen voor nagenoeg elk bedrijf of organisatie. Antwoord geven op de vraag of de applicaties naar behoren functioneren is de belangrijkste taak van systemen management. In de tijd van host georienteerde systemen waren deze technieken ruimschoots voorhanden. Maar deze technieken zijn echter niet bruikbaar voor gedistribueerde applicaties. Door de snelle overgang naar gedistribueerde applicaties, zijn ontwikkelingen opgestart om deze tekortkomingen te verhelpen. Het resultaat van een van deze ontwikkelingen is de Application Response Measurement (ARM) API, die voorziet in een eenvoudige manier om voor gedistribueerde applicaties kritische informatie te geven over business transacties, vanuit het perspectief van de bedrijfsvoering. Met deze informatie kan de systemen management software, meten en rapporteren aangaande service level agreements, vroegtijdig waarschuwen voor matige performance, operators op de hoogte stellen of automatische routines opstarten zodra een transactie niet op tijd klaar is, en helpen met het isoleren van de plaats waar deze vertragingen optreden. Voor het bewaken van applicatie transacties zijn verschillende technieken beschikbaar. Door het evolueren van applicatie architecturen van host georienteerd tot netwerk georienteerd met verschillende logische lagen waarop de uitvoering in verschillende systemen plaats heeft, zijn de bruikbare technieken ook veranderd. Drie applicatie architecturen worden hier onderscheiden host georienteerd, eenvoudig gedistribueerd en complex gedistribueerd. In host georienteerde applicaties, in het bijzonder degene die gebruik maken van SNA LU2 sessies, zijn twee goede bewakingsoplossingen beschikbaar. Deze technieken zijn de Terminal monitor en de Netwerk monitor, zie figuur 7.20. 1. Een terminal monitor die gebruik maakt van een protocol als de 3270 data stroom Response Time Monitoring (RTM) protocol, kan de tijd meten die een transactie nodig heeft vanuit het perspectief van de gebruiker. Dit kan doordat de sessie gelocked wordt op het moment dat de gebruiker de <enter> toets indrukt tot het moment dat de respons op de transactie beschikbaar is. Dit wordt gerepresenteerd door D-A in figuur 7.20. 2. Een netwerk monitor, zoals de IBM's Netview Performance Monitor, is gestationeerd op de host met daarop de applicatie. De netwerk monitor observeert alle data verzonden door de access methode (zoals VTAM). Door inzicht in het onderliggende sessie protocol weet de netwerk monitor wanneer een transactie wordt ontvangen door de host om doorgegeven te worden aan de applicatie en wanneer de respons wordt verzonden door de applicatie naar Civility Amsterdam bv.

124



de terminal (C-B).Als de outbound boodschap naar de terminal wordt bevestigd, heeft de netwerk monitor ook een schatting van de netwerktijd (dit is (B-A)+(D-C)). De benadering is E-C = (D-C) + (E-D). Een voordeel van deze techniek ten opzichte van de terminal monitor is, de mogelijkheid om de totale gebruiker responstijd onder te verdelen in een netwerk en een applicatie deel, wat kan helpen bij probleemanalyse.

Access ApplicaMethode tie Network monitor Domme terminal

Sessie gelocked

A

Start van de transactie •

D .. ~ _ _~re~sp:..:.o=ns~_ _ acknowledgement -----"------..

D-A = user responstijd

Figuur 7.20

B ~ Transactie C..--J verwerkt E

C-B = applicatie tijd E-C = netwerktijd (ongeveer) E-B = user responstijd (ongeveer)

Technieken voor het bewaken van applicatie transacties.

Zowel de terminal monitor als de netwerk monitor bewakingstechnieken van host georienteerde applicaties, steunen op twee fundamentele eigenschappen van dit soort applicaties: de gebruikers terminal sessie wordt 'gelocked' tot een transactie compleet is en een transactie past een-op-een op een transactie zoals die door het netwerk wordt gezien. In het algemeen kunnen deze aannamen niet gemaakt worden bij gedistribueerde applicaties. Het systeem is vaak een multi-tasking werkstation, capabel in het parallel uitvoeren van verschillende acties. Elke door een gebruiker te onderscheiden transactie veroorzaakt mogelijk verspreiden over het netwerk meerdere transacties, daardoor is er niet langer een een-op-een relatie tussen een gebruikerstransactie en een netwerktransactie. Er is echter een klasse van gedistribueerde applicaties waarvoor de aannamen, op welke de host georienteerde technieken zijn gestoeld, ook gelden, tenminste sluitend genoeg om te voorzien in een volwaardige oplossing. Deze applicaties gebruiken gewoonlijk eenvoudige client-server transacties, met minimale processing in de client, hier eenvoudig gedistribueerde applicaties genoemd. In deze gevallen, kan een netwerk monitor een functie verzorgen vergelijkbaar met een netwerk monitor in een host georienteerde omgeving. Dit soort probes wordt vaak geYmplementeerd als deel van een agent die de RMON-2 specificaties geYmplementeerd of een vergelijkbare functie. Door de complexiteit van de logica binnen een client-server applicatie (complex gedistribueerd) is de enige acceptabele oplossing, het participeren van de applicatie in de management oplossing, door elke transactie te laten informeren aan een applicatie monitor. Dit kan gedaan worden door de applicatie de ARM API bij begin en einde van elke transactie te laten oproepen. De applicatie monitor meet de transacties die de gebruiker waarneemt, dit is het belangrijkste.


125



Als de responstijden niet voldoen aan de verwachting, is de veroorzaker moeilijk te achterhalen. Door het instrumenteren van sub-transacties als aanvulling op de hoofd transacties zichtbaar voor de gebruiker, is inzicht mogelijk in de plaatsen waar de meeste tijd wordt doorgebracht. Dit terrein wordt nu nog slechts gedeeltelijk ingevuld door de ARM API, maar veel werk wordt besteed aan het verder invullen van deze mogelijkheid voor de toekomst, inclusief het volgen van transacties door meerdere servers verspreid over de gehele organisatie. Er zijn twee soorten transacties die in het algemeen de grootste voordelen opleveren wanneer ze worden bemeten. In volgorde van belangrijkheid: 1. transacties die zichtbaar zijn voor de gebruiker of die een belangrijke functie voor het bedrijf vertegenwoordigen; 2. transacties die afhankelijk zijn van exteme diensten, zoals database operaties of een Remote Procedure Call (RPC). Gebruikersgedrag, gegevens omtrent het gebruikersgedrag zijn van belang voor het capaciteit management en het kostenbeheer. Voor de diverse rapportage items zie tabel 7.5.

Applicaties

Objecten

Componenten

Aantal aangesloten Aantal aangesloten gebruikers. gebruikers. Aantal actieve gebruikers. Aantal actieve gebruikers.

Aantal gelijktijdige gebruikers. Inlog frequentie.

Schijfruimte per gebruiker. CPU belasting per gebruiker.

Aantal gelijktijdige gebruikers. Capaciteitsgebruik per gebruiker (aantal malen ingelogd, gemiddelde inlogtijd, etc.).

Totaal ingelogde tijd.

Diensten

Aantal gelijktijdige gebruikers. Capaciteitsgebruik per gebruiker.

Netwerk belasting per gebruiker

Tabel 7.5 Rapportage items aangaande gebruikersgedrag. Voor het registreren van het gebruikersgedrag en vervolgens de rapportage daarover moet eerst bekend zijn wat er berekend moet worden. In de huidige overeenkomsten tussen Civility en de afnemers zijn geen afspraken gemaakt over gebruikersgedrag of de rapportage en afrekening daarover. Omdat in de toekomst misschien weI dergelijke afspraken (moeten) worden gemaakt, worden hier de huidige mogelijkheden en die van de nabije toekomst omtrent dit punt behandeld. Aangezien de ARM API opgeroepen wordt voor elke transactie, en iedere transactie en gebruiker (optioneel) wordt geYdentificeerd, is een zeer nauwkeurige beeldvorming mogelijk van de werkelijke systeembelasting. Foute schattingen van de werkelijke systeembelasting is een van de grootste bijdragen aan een inadequate capaciteitsplanning. Deze informatie kan ook gebruikt worden voor 'charge-back' verrekening. Het realiseren van service levels over de tijd kan erg moeilijk zijn. Nieuwe applicaties kunnen ontwikkeld en ingezet worden. Gebruikers kunnen worden opgevoerd of afgevoerd. De mate van gebruik per applicatie stijgt en daalt naargelang de vraag van de markt. Netwerk onderdelen en systemen worden vervangen. Communicatieverbindingen worden uitgebreid.


126



Door het delen van de verwerkingsinfrastructuur is elke verandering van invloed op de service levels van al haar gebruikers. De oplossing moet voorzien in informatie waarop alle capaciteitsplanning oplossingen zijn gebaseerd: een profiel van het systeembelasting gebruik ('workload usage'). Op transactie niveau kan de ARM agent het aantal transacties bijhouden. Deze aantallen kunnen onderverdeeld worden naar individuele gebruikers en individuele systemen, afhankelijk van de samenhang en overeenkomsten binnen de instrumentatie in de applicaties. Gebruik van deze gegevens vermijdt gissingen naar het applicatie gebruik. De zelfde belastinginformatie noodzakelijk voor capaciteitsplanning is ook te gebruiken voor het kostenbeheer (account management). Kostenbeheer is verantwoordelijk voor, wie hoeveel van welk type transacties mag laten uitvoeren. Deze informatie kan geleverd worden door de ARM API, en de informatie kan verzamelt en gerapporteerd worden per gebruiker of groepen van gebruikers.

Ib) Hoe moeten deze gegevens opgeslagen worden? De volgende top-down benadering, voor het behandelen van de gegevensorganisatie, wordt gehanteerd: werkplekken, directory-structuur, filestructuur, gegevensstructuur en attribuutgegevens. Elke service level manager van een applicatie of netwerkdienst moet de beschikking hebben over een rapportage functie, te gebruiken vanaf de werkplek. Zie tabel 7.6 voor een overzicht van het aantal SLM-ers.

Applicatie NUS GISP BWV WVG NFS Stadspas N etwerkdienst GDA Civility-LAN Kantoorautomatisering Civility-LAN Werkplekfaciliteiten Totaal

Aantal SLM-ers 2 1 1 1/3

Vs' Vs'

1 1Jl# 1Jl#

.of

.#

7 samen 1.

Tabel 7.6 Werkplekken met rapportage functionaliteit. De standaard directory structuur wordt als voIgt opgezet, zie figuur 7.21. De directory structuur. In de root van de beheermachine, met daarop de performance gegevens, bevindt zich de directory ApplicatieNaam hieronder bevindt zich in ieder geval een directory met de naam 'rapport'. In de directory 'rapport' staan de sub-directories RapportagePeriode. In het geval van een maandelijkse rapportage periode en een bewaartermijn van een jaar (de meest voorkomende) is een overzicht afgebeeld in figuur 7.21. Binnen een sub-directory RapportagePeriode wordt een onderverdeling, ook weer in directories, aangehouden naar de Civility Amsterdam bv.

127


. Structureren van IT-beheer met ITIL, ontwikkeling van een ServiceLevel Rapportage systeem met SDM

bestemmingen van de rapportages (bijvoorbeeld klanten, opdrachtgever, SLM of FMS). De directory RapportagePeriode 'nieuw' bevat tevens de sub-directory 'template', met daarin de opmaak van de standaardrapporten. De bestemmingsdirectories bevatten de volgende bestanden: normbestand, verwerkingsbestanden en het uiteindelijke rapport.

e computer 3.5-inch diskette (A) r:;:J·e Ms-dos_6 IC:) E'.Hi3 Appticat g..1iJ Rapport :..1iJ Apr

Tekstdocument Microsoft E.ce~werk . Microsoft Word-docu . Internet Document ( .

!:=~~~

:.1iJ

Feb

j..1iJ s1iJ

Maa

i:=~~~

Mei

' .. fi] Fms i L.Jl1i1J : ~.Jl1i1J , LJl1i1J

Klanlnaa Opdrgev Sim

6·fi] Nieuw !

i··Jl1i1J

Fms

:···~1mID

;'" fi] 0 pdrgev ifi] Sim Lfi] Templale :.. fi] Nov

.

L.Jl1i1J

E\-J.1iJ

:8fl ;.... fi]

Okl Sep

Dos Mijn documenlen

Figuur 7.21 Directory structuur. De filestructuur van zowel de templates, de normbestanden, verwerkingsbestanden (de meetgegevens) als de uiteindelijke rapporten dient zoveel als mogelijk opgezet te zijn volgens de ITIL-structuur. Tevens dient consequent gebruik gemaakt te worden van de ITIL terminologie. De volgende ITIL-processen kunnen in een rapportage aanbod komen Beschikbaarheidsbeheer, Capaciteitsbeheer, Helpdesk, Probleembeheer, Wijzigingsbeheer, Configuratiebeheer, Beveiligingsbeheer, Calamiteitenplanning, Onderhoudsbeheer en Documentatiebeheer. De definities van de ITIL-termen dienen als bijlage bij het Service Level Agreement te zijn opgenomen, definities, berekenen rapportage-wijze moeten hierin ook worden opgenomen. De template-bestanden bevatten de opmaak, standaardteksten, tabeIlen, grafieken van de uiteindelijke rapporten. Een normbestand bevat de klantgegevens, configuratie gegevens en de normen. Verwerkingsbestanden bevatten de performance gegevens die afkomstig zijn uit de diverse bronnen. De scoop van dit technisch ontwerp beperkt zich tot de gegevens uit de netwerkbeheersystemen. In het uiteindelijke rapport document worden aIle gegevens samen gebracht en middels tekst, tabel en grafiek gepresenteerd. Deze documenten worden vervolgens verzonden naar de diverse bestemmingen. Elke periode dienen de volgende soorten gegevens (attributen) het systeem ingebracht te Civility Amsterdam bv.

128



worden: Periode gegevens: periode naam, jaartal, aantal werkdagen, zon- en feestdagen. Klant gegevens: klant naam, adres, afgenomen diensten, configuratie. Performance gegevens: normen, oude gegevens, nieuwe gegevens (beschikbaarheid, betrouwbaarheid, capaciteitsgebruik, responstijden en gebruikersgedrag). De periode en klant gegevens worden automatisch samengevoegd tot de maandelijkse normbestanden, wijziging hierin kunnen door de SLM aangevraagd worden bij de maker van de normbestanden. De gegevens van de norm bestanden komen uit de configuratie managementdatabase (CMDB) en de service level agreement (normen), samen vormen zij de bestuurlijke gegevens (zie figuur 7.6). De externe gegevens die vanuit de klanten de Helpdesk bereiken, worden niet in dit technisch ontwerp meegenomen. De gegevens die verwerkt dienen te worden tot rapportage informatie bevinden zich in een andere omgeving (waarmee nog geen koppeling is gelegd) dan het beheersysteem. Wel dienen beide rapportdelen, voor het bereiken van de klant, samengevoegd te worden. De performance gegevens zijn afkomstig uit de netwerkmanagement machine, interne gegevens vanuit de netwerkapplicaties. Hier wordt in het kort ingegaan op de opslag vorm, die de gegevens geschikt maakt voor rapportage doeleinden. Een onderverdeling wordt gemaakt naar de vier eerder genoemde attribuutsoorten: beschikbaarheidsgegevens, capaciteitgegevens, responstijden en gebruikersgedrag. Tevens komt het punt aggregatie niveau van de data verzameling aanbod. Beschikbaarheidsgegevens, deze gegevens moeten zo opgeslagen worden dat van elk rapportage item de beschikbaarheid en betrouwbaarheid bepaald kan worden. Hiervoor zijn de tijdstippen nodig, waarop een item onbeschikbaar (begin MTTR, einde MTBF) en weer beschikbaar werd (begin MTBF, einde MTTR). Capaciteitsgegevens, deze gegevens dienen zo opgeslagen te worden dat per rapportage item vastgesteld kan worden in hoeverre er gebruik van gemaakt is. Van het item 'volume databanken', moet aan het einde van een rapportage periode de vulgraad vast gesteld kunnen worden. Van het item 'verkeer per protocol', moet het percentage bepaald worden van de bijdrage van elk protocol aan het totale verkeer. Van het item'afgenomen lijncapaciteit', moet de throughput (tijdens kantooruren) gerapporteerd kunnen worden. Van het item 'CPU belasting', moet vast gesteld kunnen worden wat de gemiddelde belasting was tijdens de rapportage periode. Van het item 'harddisk bezetting', moet aan het einde van een rapportage periode de vulgraad vast gesteld kunnen worden. Van het item 'gebruik BOD', moet het aantal maal dat deze dienst is geactiveerd en voor hoe lang, gerapporteerd kunnen worden. Responstijden, deze gegevens dienen zo opgeslagen te worden dat per rapportage item (applicatie of dienst) de transactietijd bepaald kan worden. Het gemiddelde en de variatie van deze tijden of het percentage dat boven een bepaalde drempelligt, zijn rapportage vormen die middels service level agreements kunnen worden overeengekomen. Voor de eerste vorm moeten aIle transactietijden bekend zijn, voor de tweede aIleen het aantal drempeloverschreidingen in een periode en het totaal aantal transacties binnen die periode.


129



Gebruikersgedrag, deze gegevens dienen zo opgeslagen te worden dat per applicatie of dienst het gebruik (per individuele of van groepen gebruikers) vastgesteld kan worden. Data aggregatie, de service level rapporten dienen periodiek opgeleverd te worden, wekelijks, maandelijks etc. Ret verzamelen van de gegevens gebeurd periodiek, met bijvoorbeeld polling (elke 5 minuten), of probleem georienteerd, door middel van bijvoorbeeld traps. Deze gegevens worden samengevoegd tot het einde van een rapportage periode, dan worden er (statistische) berekeningen op los gelaten door het rapportage systeem. De resultaten van de berekeningen vormen de informatie die in de rapporten opgenomen wordt. De gegevens kunnen niet tot het einde der tijden opgeslagen worden door geheugen beperkingen, bovendien verliezen de gegevens hun kracht door dat ze gedateerd raken. Door het ontwerpen van aggregatie niveaus kunnen de gegevens (na verwerking tot informatie) verwijderd worden, de informatie kan gebruikt worden als input voor een hoger aggregatie niveau. Figuur 7.22 geeft een overzicht van de mogelijke aggregatie stappen. Opgemerkt dient te worden dat niet alle stappen geYmplementeerd of doorlopen behoeven te worden, dit is afhankelijk van de wensen van de klanten en de daarmee overeengekomen SLA's.

Figuur 7.22 Aggregatie niveaus in de tijd. De keuze van de aggregatie niveaus is afhankelijk van de technische mogelijkheden en van de wensen (SLA's) van de klant. Wel kan vast gesteld worden dat rapportages per week en per maand, veel meerwerk bezorgen. Met gebruik van de ARM API zou de volgende oplossing tot de mogelijkheden behoren. De agent verzamelt detail gegevens voor real-time probleem analyse. De data wordt weggeschreven in de vorm van een samenvatting naar de sequentiele file aan het einde van elk interval (in het algemeen elke 10-15 minuten). Er is een record voor elke transactie voor elke gebruiker voor elke applicatie, voor zolang als er activiteiten worden waargenomen tijdens het interval. Voor lange termijn rapportage is dit detailniveau zelden noodzakelijk. Ret rapportage systeem maakt samenvattingen van de data op een uur, dagelijkse en maandelijkse (en jaarlijkse) basis. De administrateur (SLM) bepaalt hoe lang elk gegevenstype bewaard wordt. Civility Amsterdam bv.

130



Maar zelfs dit niveau van detaillering kan nog te veel zijn voor rapportage doeleinden. Het kan zinvoller zijn samenvatting te maken in andere dimensie dan de tijd. Bijvoorbeeld, naar applicatie, systeemde1en of groepen gebruikers.

2. Realisatie van de verschillende functies en/of onderdelen daarvan met behulp van systeemdelen. Systeemrealisatie ([37] bIz. 45-58). De volgende strategie wordt gevolgd, (a) bepalen van de moge1ijke oplossingen en de gevolgen daarvan, (b) voorkeur aangeven voor de benodigde faciliteiten en tenslotte (c) het evalueren van de mogelijke oplossingen en selecteren. a) bepalen van de mogelijke oplossingen en de gevolgen daarvan. Op basis van het functioneel ontwerp wordt een aantal mogelijke oplossingen ontworpen en bepaald welke gevolgen dit heeft voor de organisatie, werkomgeving en benodigde faciliteiten als apparatuur en programmatuur. De mogelijke oplossingen zijn van een aantal factoren afhankelijk: * de kenmerken van het systeem: prestatie-eisen, aantal transacties, omvang gegevensverzame1ingen en raakvlakken met andere systemen; * het doel van het systeem: functies en aard van het systeem (operationeel of beIeidsondersteunend); * de aanwezige infrastructuur: in organisaties waar reeds computerfaciliteiten aanwezig zijn, ligt een keuze van deze1fde soort voor de hand; * de uitgangspunten van de studie; bijvoorbeeld indien beschikbaar dient van een applicatiepakket gebruik gemaakt te worden. Het zoeken naar en ontwikke1en van oplossingen is een creatief proces en daardoor vaak tijdrovend. Het zelf ontwikke1en van oplossingen is met name moeilijk en kostbaar als men op dit terrein weinig of geen ervaring heeft. Het onderzoeken of een applicatiepakket een zinvolle oplossing is, mag niet verwaarloosd worden [37].

Kenmerken van het rapportage systeem. Door de complexiteit en de geografische spreiding van de huidige computersystemen is het niet langer mogelijk slechts een technologie of een systeem te beheren en zodoende het antwoord te kunnen geven op de voor een bedrijf be1angrijkste vraag: doen onze applicaties wat er van hen verlangt wordt? Het effectief en efficient beheren van al deze elementen is net zo belangrijk als het ontwikkelen van de applicaties en de onderliggende structuur. De nieuwe applicatie architectuur verlangt nieuwe benaderingen van systemen management. Systemen management was in hoofdzaak betrokken bij het beheren van systemen, databases en netwerken. Nu moet ook gekeken worden naar de applicaties en de bedrijfsonderdelen voor welke deze een sleutelrol vervullen. Performance management is betrokken bij, het bewaken van een applicatie en de directe omgeving tijdens de werking daarvan, het ondememen van stappen om de problemen te corrigeren en het maken van plannen om in de toekomst problemen te voorkomen. • Periodiek controleren van een applicatie en de infrastructuur waar deze van afhankelijk is, is een goede methode voor het detecteren van problemen terwijl deze de kop op steken of voor problemen beginnen te zorgen.


131


. Structureren van IT-beheer met ITIL, ontwikkeling van een Service Level Rapportage systeem met SDM

• Real-time beheren van de enorme hoeveelheden data uit een complexe omgeving vraagt om automatische verwerking. De data moet worden gefilterd, gecorreleerd met andere data en acties automatisch uitgevoerd. In het algemeen is de beste benadering voor bewaking, een combinatie van het bewaken van enkele sleutel items in zowel de infrastructuur als applicaties, en een meer intensere bewaking aIleen als er problemen ontstaan. Andere kenmerken van het rapportage systeem. zijn: • op het moment dat aIle gegevens beschikbaar zijn, moet middels een-druk-op-de-knop het proces gestart worden en zonder verdere tussenkomst ('s nachts) de rapporten genereren. De informatie die uit deze gegevens gedestilleerd is moet tenminste een jaar bewaard blijven. De 'ruwe' meetgegevens mogen pas na controle van de rapporten worden verwijderd; • de verwerking mag niet langer dan 8 uur in beslag nemen; • het rapportage systeem moet bij voorkeur kunnen werken op de reeds bestaande infrastructuur (ofbinnen de nieuwe beheerstructuur verzorgt door het VIB project passen); • de rapportage items uit de diverse omgevingen moeten op de zelfde wijze beschikbaar zijn (het zelfde formaat) en qua presentatie een vergelijkbare opmaak hebben (grotendeels grafisch); • het aantal uit te voeren transacties en de omvang van de gegevensverzamelingen zijn per applicatie verschillend. Met name de GDA rapportage is erg omvangrijk, een netwerk opgebouwd uit honderden objecten, waarvan periodiek een aantal gegevens opgevraagd en opgeslagen wordt, met ruim 60 klanten en dus ook rapporten; • met andere systemen bestaan de volgende raakvlakken de standaard werkplek functionaliteit (MS-office: Word en Excel, en Internet Explorer als web browser) diverse databases (Oracle, DB2) met daarboven het netwerkbeheersysteem (IBM/Tivoli Netview, TME-IO en Sentry) en de Helpdesk omgeving (nu nog Prolin's ProHelpdesk). Het doel van het rapportage systeem is het produceren van rapporten, deze rapporten hebben als doel de gerealiseerde prestaties van de dienstverlening, zoals neergelegd in het SLA, op hoofdlijnen te confronteren met de overeengekomen of te verwachten normen. De rapporten dienen als basis voor het overleg tussen de FMS en de klant over de invulling en de kwaliteit van de dienstverlening. Daamaast moet het de beheerorganisatie inzicht verschaffen in de performance van de diverse ITIL processen, met name service level management. Tot slot moet de rapportage dienen als informatie voor het probleem en het configuratie beheer. De reeds aanwezige infrastructuur is onder te verdelen in de volgende categorieen hardware, software en netwerkfaciliteiten, zie tabel 7.7. Aangezien een applicatie afhankelijk is van een veelheid aan componenten binnen de infrastructuur, zoals systemen, databases en netwerken, is het mogelijk de applicatie indirect te bewaken door de infrastructuur componenten met probes uit te rusten. Een probe is een software routine die management data verzamelt. Alhoewel dit de traditionele benadering is voor applicatiebeheer, zijn er meerdere redenen waarom probes die uitsluitend de infrastructuur bewaken inadequaat kunnen zijn: • de probes voor het bewaken van de infrastructuur zijn niet capabel voor het bewaken van de benodigde items; Civility Amsterdam bv.

132



• de probes hebben geen toestemming om het item te bewaken (genereren te veel verkeer); • in een complexe omgeving zijn problemen vaak niet te relateren aan een component, maar juist aan de interactie daar tussen; • elk gegeven infrastructureel probleem belnvloed verschillende applicaties op verschillende wijze, om hierin onderscheid te kunnen maken moet de probe een zekere mate van intelligentie bezitten en onderscheid tot op applicatie niveau kunnen maken.

Infrastructuur Hardware

Intern: Werkplek PC met harde schijf, geheugen en printer

Software

MS-Office, Email en Inter- en Intranet browser.

Netwerkfaciliteiten

LAN-aansluiting

locatie Paalbergweg Routers, midrange computers (RS6000) en IBM mainframe. Tevens koppelingen met Internet Helpdesk & CMDB (ProHelpdesk), Netwerk en Systemen Management (Netview, Sentry en SMS) Databases (Oracle en DB2), Applicatie software (GISP, NFS, Stadspas, etc. Civility-LAN, GDA-tokenring, diverse Ethernet segmenten (waaronder GDA)

Extern (bij klant) Routers met Remote MONitoring probes

Rmon-software (Frontier)

GDA-aansluiting, Internet, Email en GemNet via GDA (optioneel)

Tabel 7.7 De reeds aanwezige infrastructuur. De volgende uitgangspunten spelen een rol: * een generieke opzet van het netwerkbeheer en rapportage systeem; * ITIL-methodiek toepassen (waar mogelijk); * eenvoudig uit te breiden qua functionaliteit, nieuwe applicaties en klanten; * eenvoudige opzet van het systeem en hoge graad van automatisering; * samenwerking met andere rapportage systeem onderdelen (Helpdesk-rapportage), uniforme output; * er dient zoveel als mogelijk van de aanwezige beheersystemen gebruik gemaakt te worden; * indien mogelijk dient van een applicatiepakket gebruik gemaakt te worden; * kosten niet hoger dan strikt noodzakelijk. In de toekomst, bij het gebruiken van de ARM API door applicaties, zijn drie stappen te onderscheiden voor het bewaken van de performance van een applicatie. 1. De eerste stap is het definieren van de belangrijkste transacties, bekeken vanuit het bedrijfsbelang. 2. De tweede stap is het aanpassen van de programmatuur voor het inpassen van de ARM API oproepen. 3. De derde stap is het vervangen van de hulplibraries uit de ontwikkelaars gereedschapsset door een ARM-ondergeschikte agent en bijbehorende management applicaties. Voor applicatieontwikkelaars (AS) zijn de volgende hulpmiddelen beschikbaar, voor het gebruiken van de ARM API door applicaties:


133


Structureren van IT-beheer met ITIL, ontwikkeling van een Service.Level Rapportage systeem met SDM

1. de specificatie van de API is beschreven in een API Guide. Alle zes de oproepen en de respectieve1ijke parameters zijn in detail beschreven en gedocumenteerd in een stijl verge1ijkbaar met C; 2. een ontwikkel gereedschapsset is beschikbaar op CD-ROM ofkan gedown10ad worden van een website (http://www.tivoli.com/tivevery/download.html). De ARM API heeft alleen nut als applicaties er daadwerkelijk gebruik van maken (door het op te roepen), bepaalde ontwerp criteria werden rigoureus gevolgd tijdens het ontwerp van de API: • De API is eenvoudig in het gebruik. Het aantal oproepen is laag en nog lager is het aantal benodigde parameters. Het kan opgeroepen worden vanuit veel verschillende programmatalen en van applicatie ontwikkel hulpmiddelen mag verwacht worden dat ze in de toekomst standaard de API ondersteunen. • De looptijd overhead is erg laag, ongeacht of er al of niet gegevens verwerkt behoeven te worden. Alle implementaties van de API die nu bestaan voldoen aan deze voorwaarde. De overhead is niet nul, maar we1 erg klein en is niet significant verge1eken met de grote voorde1en van het gebruik van de API. • De API is ontworpen om uitgebreid te worden met behoud van de oude functionaliteiten. Dit houdt in dat iedereen die zijn applicatie de ARM API laat oproepen verzekerd wordt dat bijwerken van de applicatie niet nodig is voor het behouden van de huidige management moge1ijkheden, zelfs als de API wordt uitgebreid. Het gebruiken van de nieuwste mogelijkheden zal een optie zijn. De volgende oplossingen zijn mogelijk: 1. Het bewerken van de performance gegevens, zoals deze worden verzameld met het netwerkbeheersysteem en opgeslagen in een database, met zelf ontwikkelde programmatuur. Deze vervolgens verwerken tot informatie met behulp van een spreadsheet en hier de opmerkingen en overige rapportage items met behulp van een tekstverwerker aan toevoegen. Tenslotte de rapporten als geprinte exemplaren op de post, als attachment met Email of na bewerking, door een homepage ontwerp-programma, via Intranet ter beschikking stellen aan de afnemers. Gevolgen voor organisatie, werkomgeving en benodigde faciliteiten. Het gevolg hiervan is dat (ingewikkelde) programmatuur en scripts ontwikke1d dienen te worden, door de eigen organisatie (AS). Een ander gevolg is dat diverse stappen in het rapportage systeem uit gevoerd worden door verschillende pakketen, als een pakket veranderd bestaat de kans dat het hele systeem moet worden aangepast. Voor de werkplek en de benodigde faciliteiten is de impact beperkt, doordat zoveel als moge1ijk van bestaande faciliteiten gebruik gemaakt kan worden. 2. Het gebruiken van de rapportage faciliteiten van het netwerkbeheersysteem zelf, voorzover deze aanwezig dan we1 beschikbaar is. Een uitvloeise1 hiervan is dat rapportage items uit een andere omgeving (ander beheersysteem ofbijvoorbee1d He1pdesk) op een andere wijze gemaakt worden. Waarna beide de1en samen gevoegd moeten worden in bijvoorbeeld een tekstverwerker of een homepage ontwerp-programma, om dezelfde vormgeving te verkrijgen. Gevolgen voor organisatie, werkomgeving en benodigde faciliteiten. De rapportage faciliteit moet worden aangeschaft en scripts voor gegevens verzameling geschreven. Vanaf de werkplek moet de informatie binnen het beheersysteem benaderd kunnen worden, hiervoor kunnen aanpassingen of aanschaf van een tool noodzakelijk zijn. Voor de overige faciliteiten is de impact gering, de rapportage faciliteit draait op het zelfde beheermachine. Civility Amsterdam bv.

134



3. Ret gebruiken van standaard rapportage tool, waarin de gegevens uit de diverse bronnen samengevoegd worden en vervolgens bewerkt tot informatie. De output staat daama in diverse uitvoerformaten ter beschikking. Ret gevolg hiervan is dat zo een tool aangeschaft moet worden en vervolgens ingericht naar de wensen van de gebruikers. De tool moet op de werkplek van bijvoorbeeld de service level manager te gebruiken zijn. b) voorkeur aangeven voor de benodigde faciliteiten. Ret doel is om voor de te kiezen oplossing aan te geven welke faciliteiten bij voorkeur moeten worden gebruikt en tevens om nu te controleren of deze ook tijdig ter beschikking kunnen staan. De keuze van deze faciliteiten (computerapparatuur, programmatuur en dergelijke) hangt af van de te kiezen oplossing, maar anderzijds wordt deze oplossing weer beYnvloed als aan bepaalde faciliteiten de voorkeur wordt gegeven. Dit is bijvoorbeeld met name het geval wanneer: * reeds bepaalde faciliteiten voor andere informatiesystemen in gebruik zijn; * naar een bepaalde werkomgeving wordt gestreefd, omdat daarvoor reeds kennis in huis is; * men binnen een bepaalde technische infrastructuur wil of moet werken. Inventarisatie bestaande en beschikbare faciliteiten (hardware en software met specificaties), zie tabel 7.8. Item

Opmerkingen

Specificaties Hardware

Werkstation voor rapportage Pentium 100MHz, 16(32)Mb intern, 1Gb harde schijf, 14" monitor en LAN aansluiting Netwerk Management IBM SP machine, 2* dual 604 processor Machine cards, 2* 256Mb intern, 2* 2,2 Gb harde schijfen, Ethernet en Token-ring adapters Printer ± 10 pagina's per minuut, 600 dpi

voor GDA rapportage VIB-project, Netwerk en Systemen Management software moet hierop gaan draaien. voor GDA rapportages

Software Netwerk management Gedistribueerde management Router configuratie software RMON software Database Helpdesk Systems management tekstverwerker spreadsheet Email-programma web browser homepage designer

Tabel 7.8

VIB-project VIB-project

Netview 4.0 Sentry

CiscoWorks 3.0 Frontier Oracle 7.X, Sybase X.X, Prolin Helpdesk MS-SMSX MS-Word 97 MS-Exce197 Exchange Internet Explorer Frontpage Beschikbare faciliteiten.

VIB-project uitsluitend voor CMDB doelen VIB-project contract loopt bijna af voor management LAN werkplek 2000 project werkplek 2000 project werkplek 2000 project werkplek 2000 project Intranet manager

Met de boven genoemde infrastructuur en faciliteiten (zie respectievelijk tabel 7.7 en 7.8) moet worden gewerkt, de aanschaf van een speciale rapportage tool is reeds gedaan (Crystal Reports professional 5.0 van SEAGATE). In verband met het project verbetering IT-beheer (VIB) is te verwachten dat van diverse de software pakketten een nieuwe release wordt aangeschaft. Voor het netwerkbeheer wordt naar het nieuwe IBM/Tivoli product TME-IO gekeken. De nieuwe tool(s) voor het ondersteunen van de Relpdesk en de CMDB moet nog geselecteerd worden. Civility Amsterdam by.

135



c) evalueren van de mogelijke oplossingen en selecteren. Het doel is een keuze te maken tussen de mogelijke oplossingen op basis van vooraf vastgestelde selectiecriteria. De invalshoeken van waaruit de criteria kunnen worden opgesteld zijn onder andere die van de gebruiker, de informaticus, de controle en de opdrachtgever. De criteria kunnen worden onderverdeeld in criteria waaraan de oplossing in ieder geval moet voldoen en criteria die minder belangrijk zijn. Matrix met oplossingen versus diverse criteria, zie tabel 7.9. Oplossing 1 Oplossing 2 Oplossing3 Criteria

zelftool ontwikkelen

Interne tools

--

+ + ++ + +

Gebruiksvriendelijkheid Realiseerbaarheid (moeilijkheidsgraad) Kosten voor realisatie Tijd nodig voor realisatie Flexibiliteit qua input formaten Flexibiliteit qua uitput formaten Flexibiliteit qua presentatie vormen Generiek toepasbaar Uitbreidbaarheid Kwaliteit van de rapporten Mogelijkheden van toevoegen andere rapportages Duurzaamheid

-

-

-

-

+ + + ++ ++ + ++ + + +

-

+/-

+

++ + + +/-

+/+

Eindoordeel

standaard rapportagetool ++

+ +

Tabel 7.9 Selectie van de te realiseren oplossing. Oplossing 1 lijkt veeI op de oude methode van de GDA-rapportages, aIleen dan in een nieuw jasje, maar blijft de zelfde nadelen hebben. Oplossing 2 beperkt de uitvoer mogelijkheden door de afhankelijkheid van de rapportage faciliteit van het beheersysteem, welke niet vast staan en kunnen veranderen met uitbrengen van nieuwe versies. Oplossing 3 wordt ook gebruikt voor de rapportage van uit de Helpdesk omgeving (incidentgegevens).

3. Te automatiseren delen van het systeem en delen die met de hand zullen moeten worden uitgevoerd. Procesbeschrijving ([37] biz. 94-102). Doel is het beschrijven van de processen, dat wil zeggen: de wijze waarop (bepaalde) functies van het nieuwe systeem moeten worden uitgevoerd. De gebruiker heeft niet aIleen de taak en de verantwoordelijkheid om de informatiebehoeften te bepalen, maar dient ook in principe vast te stellen door middel van welke processen deze informatiebehoeften gestalte krijgen. Binnen het rapportage systeem zijn diverse functies te onderscheiden, zie figuur 7.23. Naast de functies binnen het systeem, zijn er ook functies die het systeem ondersteunen. Voorbeelden van dergelijke ondersteunende functies zijn: leveren invoergegevens, Civility Amsterdam bv.

136



verspreiden uitvoer, wijzigen templates (onderhoud), wijziging normbestanden, invoer nieuwe klanten en invoer nieuwe functionaliteiten. Interne, externe en bestuurlijke gegevens

Resultaten plaatsen op Internet

Vragen om gegevens

~

Accepteren en opslaan van gegevens

~

~ Oude gegevens

Opsplitsen. selecteren en aggregeren van gegevens

Figuur 7.23

Rapporten en bestuurlijke informatie

'\

Samenvoegen van de items tot een rapport per klant

~

De ontstane injormatie verwerken in grafiek en/oftabel vorm

Functies binnen het rapportage systeem.

Voar aIle functies moet een beschrijving komen van het ondersteunende proces, dat is, de wijze waarop functies uitgevoerd dienen te worden. Het beschrijven van deze processen is in eerste instantie onafhankelijk van de keuze of deze processen met de hand dan weI automatisch plaatsvinden; dit laatste geschiedt op basis van bepaalde keuzecriteria. Zie tabel 7.10. Criteria Aantallen transacties en mutaties Aantallen te nemen beslissingen Volume gegevensverzamelingen Gewenste betrouwbaarheid Personeelskosten Frequentie van verwerking Gewenste antwoordtijden Probleem definieerbaar Proces herhalend van karakter Invoer eenduidig en betrouwbaar Wijzigen beslissingsregels voortdurend

Automatisch (programma)

Handmatig (procedure)

groot groot groot hoog hoog hoog kort ja ja ja neen

klein klein klein laag laag laag lang neen neen neen ja

Tabel 7.10 Keuzecriteria automatisch of handmatig. De procedure voor de functie 'het vragen om gegevens', is afhankelijk van de bron waaruit de gegevens gewonnen dient te worden. De volgende bronnen zijn te onderscheiden, logfiles, event meldingen, monitoring probes, etc. Voor het ontsluiten van de bronnen, die zich bevinden in onder andere, routers en computersystemen, zijn verschillende methoden beschikbaar, zoals het zetten van traps en het uitvoeren van polling. Per bron zal afstemming moeten plaatsvinden tussen de gewenste gegevens en de management mogelijkheden. Hiervoor kan gebruik gemaakt worden van bijlage 7, hierin is een tabel opgenomen met de volgende dimensies: beheer objecten / benodigde gegevens / gegevens bronnen / mogelijke benader wijzen / output vorm. Civility Amsterdam by.

137



De functie 'het accepteren van gegevens " onderzoekt of de aangeleverde data voldoet aan de opbouw zoals deze is vastgelegd. Gekeken moet worden naar, herkomst (identiteit), formaat en gegevenssoort. De functie 'het opsplitsen, selecteren en aggregeren van gegevens " de gegevens worden gefilterd. Door middel van bijvoorbeeld een tekst script wordt uit de aangeboden gegevens de nodige gegevens geplukt. Deze gegevens worden opgesplitst naar applicatie, dienst, object, componenten en rapportage item (zie ook punt la). Na het verstrijken van een rapportage periode worden de gegevens geselecteerd en daarop berekeningen (zie punt 4) los gelaten, om zo een hoger aggregatie niveau te bereiken. De functie 'de oude gegevens van voorgaande perioden toevoegen " voert de performance gegevens in van de vorige perioden, zodat er aan de hand van de rapportage een trend analyse kan plaats vinden. De functie 'de ontstane informatie verwerken in grafiek en/oftabel vorm " zorgt ervoor dat de informatie zo wordt gepresenteerd dat deze eenvoudig te interpreteren is. Een voorbeeld rapportage is te vinden in bijlage 8. Deze bijlage bevat tabellen met de volgende dimensies: applicatie / bestemming rapport / gewenste leveringsvorm / inhoud van het rapport (welke rapportage items) / presentatie vorm van de items. De functie 'het samenvoegen van de items tot een rapport per klant " verzamelt per rapport de informatie die voor dat rapport is bestemd. Rapport definities met inhoud zijn te vinden in bijlage 8. De functie 'plaatsen op Intra-/lnternet of hardcopy maken " verzorgt de uitvoer van de rapporten naar de bestemming van de betreffende rapporten. Antwoord moet gegeven worden op de volgende vraag: 'Wat moet waarheen en op welke manier?' (zie bijlage 8). Beeldscherm- en lijst-indelingen ([37J bIz. 112-115), van te automatiseren functies. Zodra bekent is op welke wijze de processen gaan plaatsvinden, kan begonnen worden met de ontwikkeling van de mens-machineraakvlakken. Ret doel is alle raakvlakken die de mens met het systeem zal hebben, door middel van de in- en uitvoer nader te detailleren. Ret mensmachineraakvlak vormt voor de gebruikers het belangrijkste deel van het informatiesysteem. Is dit raakvlak gebruikersvriendelijk ontwikkeld, dan vormt de acceptatie door, en de motivatie van, de gebruiker meestal geen probleem. In een modem informatiesysteem kunnen deze raakvlakken veelzijdig zijn en bestaan ze niet alleen uit dialogen door middel van het beeldscherm, toetsenbord en/ofmuis, maar ook uit een veelheid van soorten documenten.

Op basis van het functioneel ontwerp worden nu de specificaties van de beeldscherm- en lijstindelingen van de programma's beschreven. De specificaties dienen dusdanig te worden beschreven, dat ze ook kunnen worden opgenomen als deel van de toekomstige handleiding. Uiteraard geldt dit vooral voor de dialogen en de daarbij behorende beeldschermindelingen. De volgende tien richtlijnen voor het specificeren van schermindelingen zijn hierbij in acht genomen: 1. Keuze uit te voeren dialoog moet duidelijk zijn. 2. Scherm mag niet te vol zijn. Civility Amsterdam bv.

138



3. 4. 5. 6. 7. 8. 9.

Scherm moet overzichtelijk zijn. Scherm opbouw dient logisch te zijn. Scherm opbouw dient zo rustig mogelijk te zijn. Scherm moet herkenbaar zijn. Schermovergang moet geleidelijk gaan. Duidelijk verband leggen tussen formulier en bijbehorend scherm. De diverse schermen binnen een applicatie dienen zoveel mogelijk consistent te zlJn.

10.Laat de gebruiker niet in onzekerheid. Invoeren van opmerkingen, door de SLM, aangaande de diverse ITIL rapportage items, wijzigingen in (norm) gegevens invoeren, foutmeldingen en opstarten rapportage proces zijn de processen die een (invoer)scherm vereisen. De schermopbouw is afhankelijk van het te gebruiken standaard pakket, de functionaliteiten van het pakket zijn nog niet bekend. Procedures enformulieren ([37] biz. 106-111), van met de hand uit te voeren functies. De onderdelen van het informatiesysteem, die door de mens ('met de hand') zullen worden verricht, inclusief de daarbij te gebruiken formulieren, worden hier nader gespecificeerd. Procedures beschrijven in dit kader de handmatige, de menselijke taken; programma's bevatten de instructies, die door de computer moeten worden uitgevoerd. Een programma is voor de computer echter een noodzaak, voor de mens is de aanwezigheid van een geschreven procedure niet altijd een noodzaak. Vit oogpunt van uniformiteit van werken en het kurmen instrueren en opleiden van medewerkers, verdient het echter de voorkeur de menselijke taken ook goed vast te leggen. Door deze procedures goed te overwegen en te beschrijven, en weI voorafgaande aan het specificeren van de programmatuur, wordt tevens voorkomen dat de mens (de procedure) zich moet aanpassen aan de computer (het programma). In veel gevallen vormt het gebruiken van bepaalde formulieren een onderdeel van de procedure, evenals het specificeren van deze formulieren. De aan procedures verbonden nadelen, zoals de onvrijheid van handelen en het kurmen leiden tot verstarring, moeten daartegen worden afgewogen. In het algemeen kan worden gezegd, dat de menselijke taken die rechtstreeks verband houden met het toevoeren van gegevens naar de computer, in ieder geval in procedures moet worden vastgelegd. Rierover mag geen verschil van mening bestaan; dit moet eenduidig zijn, de computer mist nu eenmaal het onderscheidingsvermogen van de mens. Mogelijke procedures zijn: * invoerprocedures * correctieprocedures * handleidingen Ret opstellen en uitwerken van procedures vereist kennis op het gebied van arbeidskunde, werkmethoden en kennisoverdracht. Ret is daarom verstandig dit te doen in overleg met de toekomstige gebruikers van die procedures. Bij het maken van procedures moet gelet worden op: volledigheid, begrijpelijkheid en doelmatigheid. De ondersteunende functies bij het rapportage proces zullen voor het overgrote deel handmatige acties zijn: Civility Amsterdam bv.

139



* * *

* *

Invoeren van de nieuwe klanten in het rapportage proces. Nieuwe functionaliteiten inpassen in het rapportage proces. Onderhoud rapportage proces van bestaande aansluitingen (mutaties), wijzigen templates en wijziging normbestanden. Gegevens leveren afkomstig van andere systemen als input voor het rapportage proces. Verspreiden output.

Invoeren van een nieuwe klant houdt in dat een reeks van gegevens over de aansluiting en de diensten (met eventuele opties) bekend moet zijn en doorgegeven aan, met name, de afdeling PB. Het betreft de volgende gegevens, in willekeurige volgorde: * de naam deelnemer * de routernaam * aansluittype * afgenomen (GDA) diensten en opties * de aansluitdatum * de datum van start van de rapportages (houdt verband met het in beheer nemen en houden van de aansluiting) * de contactpersoon * adressen (postadres, Email adres, telefoonnurnmer, faxnummer) * wijze waarop de rapporten aangeleverd moeten worden. Nieuwe functionaliteiten Bij implementatie van nieuwe diensten of functionaliteiten, zoals toegang tot externe netwerken dient het rapportage proces daarop te worden aangepast. Allereerst een analyse van de te rapporteren items en eventueel de automatiseringsslag initieren en aansturen. Daama dient het handboek te worden bijgewerkt. Wijzigingen in bestaande klantgegevens en aansluitingen Wanneer zich veranderingen voordoen die betrekking hebben op het rapportage proces, zoals de contactpersoon, het aansluittype, de afgenomen diensten (en opties) moet ook de rapportage daarop worden aangepast. Toeleverende informatie bronnen Deze actie is belangrijk voor het genereren van de rapportages. Deze actie vormt namelijk de input van het gehele rapportage proces. Input van systemen als het netwerkbeheersysteem, de Pro-Helpdesk en andere informatie bronnen, die ook personen (service level manager, change manager, probleemmanager etc.) kunnen zijn. Verspreiden output De gegenereerde rapporten moeten naar de klanten verstuurt worden, of (uitsluitend) door hen in te zien zijn. Hiervoor moet van de bestemmingen de naam en het adres (postadres, Email adres of IP-adres) bekend te zijn. Voor bestemmingen die via het GDA, Intranet of Internet bereikbaar zijn bestaat de mogelijkheid de verspreiding te automatiseren.

De precieze procedures moeten nog worden ingevuld en zijn onder andere afhankelijk van de functionaliteiten van het te gebruiken software pakket.


140



4. De programmaspecificatie van deze processen. Specificeer programmatuur ([37] bIz. 120-124). Het specificeren van de te ontwikkelen programmatuur is bijzonder belangrijk als het daadwerkelijke programmeren door anderen gebeurd. Afspraken (gebruik van bepaalde standaards) wie wat moet doen, in welke tijd en tegen welke prijs moeten dan worden gemaakt en dat kan alleen goed geschieden op basis van deze specificaties. Wordt het maken van programmaspecificaties en het programmeren door een persoon gedaan, dan is de kans groot dat deze werkzaarnheden niet strikt gescheiden (kunnen) worden, maar door elkaar lopeno Het gevaar is dan wel groot dat er geen exteme specificaties worden gemaakt, wat bij grote, complexe programma's zalleiden tot problemen bij de ontwikkeling en tot nog meer problemen bij het onderhoud. De vorm en inhoud, van de verwerkingsprogrammatuur en scripts welke gemaakt dienen te worden, hangen tevens af van de te gebruiken beheersoftware en rapportage tool. De specificatie van de programmatuur voor de diverse processen wordt hier beschreven met behulp van definities, berekenwijze (formules) en uitvoer vorm (tabellen en grafieken). Zie ook bijlagen X en Y. 5. De logische verdeling van databases en gegevensverwerking. OpsIagstructuur ([37] bIz. 116-119 & 267). Het doeI is het ontwerpen van de fysieke wijze van opslag van de gegevens op de gekozen informatiedragers, uitgaande van de gegevensstructuur, het informatiemodel en de eisen op het gebied van prestaties, beveiliging, privacy en dergelijke. Bij het ontwerpen van de opslagstructuur moet tussen deze aspecten en de mogelijkheden en beperkingen van de apparatuur en programmatuur een synthese, soms echter een compromis, worden gevonden. Het bepalen van de opslagstructuur heeft te maken met zaken als: * in welke volgorde de records in een bestand moeten worden opgeslagen (bijvoorbeeld sequentieel of direct toegankelijk); * in welke volgorde en hoe de gegevens in de records moeten worden gerangschikt (bijvoorbeeld veldlengte, alfanumeriek); * de aantallen en de grootte van de gegevens, dat wil zeggen het bepalen van de benodigde opslagcapaciteit; * de keuze van de informatiedrager (bijvoorbeeld vaste schijt); * de gewenste verwerkingstijden en antwoordtijden; * naar welke gezichtspunten men informatie wenst (gewenste toegangspaden) en hoe frequent; * aanwezige apparatuur en programmatuur. * het bepalen van de veiligheidsmaatregelen, zoals het maken van kopieen, het gebruik van herstartfaciliteiten etc. * welke autorisatiemogelijkheden zullen worden gebruikt, bijvoorbeeld uit het oogpunt van pnvacy. 6. De toegang tot de gegevens. Te onderscheiden zijn logische toegangsbeveiligingsmaatregelen op het niveau van: netwerksysteem routers centrale Email 3270 Gateway Name servers Civility Amsterdam bv.

141



ISDN externe aansluitingen Gemnet en Internet. diensten Logische toegangsbeveiliging is de kern van de informatiebeveiliging van de GDA. In een omgeving als de GDA is het namelijk noodzakelijk om medewerkers van diverse organisaties toegang te geven. Binnen een deelnemende organisatie zijn uiteenlopende bevoegdheden en verantwoordelijkheden te onderscheiden. Niet iedereen mag kennisnemen van gegevens, laat staan wijzigen. Belangrijk in de logische toegangsbeveiliging is het beheer van userid's en het wachtwoordbeheer. Voor wachtwoorden zijn algemene regels aangegeven in het Handboek Informatiebeveiliging. Netwerkmanagementsysteem (NMS) Gebruik wordt gemaakt van een RS/6000 met AIX. De groep Produktie en Beheer van de sector Midrange Verwerking is verantwoordelijk voor het beheer van het NMS. De volgende programmatuur is aanwezig: Netview CiscoWorks Frontier (speciaal voor Rmon-probes). Met CiscoWorks wordt het actieve beheer uitgevoerd terwijl Frontier en Netview onder meer dienen voor het waarnemen en detecteren van problemen. De toegang tot het NMS zelf is via de AIX-beveiliging geregeld. Onderhoud op het NMS is slechts mogelijk via het console op de computerzaal. Netview, CiscoWorks en Frontier kunnen aIleen vanaf de X-terminals worden gebruikt. Beveiliging tegen management-verkeer Het GDA-netwerk is afgeschermd voor management-verkeer (SNMP) vanuit de deelnemende netwerken, doordat een wachtwoordbeveiliging wordt toegepast voor management (SNMP GET en PUT) opdrachten. Naast deze paswoordbeveiliging wordt tevens access-beveiliging toegepast met behulp van een toegangslijst. In deze toegangslijst staat het adres van het beheerssysteem, de nameserver bij Civility en de nameserver van het Stadhuis. Externe koppelingen (GemNet, Internet) Voor externe aansluitingen wordt gebruik gemaakt van een Firewall. Een procedure is aanwezig waarin bepaald kan worden dat bij een externe koppeling sprake moet zijn van een firewall en ook het beveiligingsniveau van de firewall. De implementatie van een extern koppeling wordt projectmatig aangepakt, hierbij komt ook de beveiliging aan de orde. Diensten De beveiliging van een applicatie is een verantwoordelijkheid van de desbetreffende aanbieder van de dienst. Dit wordt per organisatie en per applicatie geregeld. Op applicatieniveau is niet aIleen de toegang tot de applicatie van belang, maar vooral het afschermen van bevoegdheden en gegevens. Het gaat er niet om op elk niveau optimaal de logische toegang te regelen. Het is veel doeltreffender de maatregelen op de diverse niveaus goed op elkaar af te stemmen. Overigens is dit in algemene zin in een netwerkomgeving zoals de GDA een complexe taak.


142



PrograDlDlabeheer Beheer van programmatuur geschiedt volgens IT'lL-procedures. De programmatuur betreft: standaardprogrammatuur als Netview, CiscoWorks, Frontier, Groupswise 4.1, 3270 gateway, Nameserver maatwerk als programmatuur voor SLA rapportage. De in produktie zijnde programmatuur wordt ge:registreerd in de Configuration Management Data Base en bewaard in een programma-bibliotheek. De bewaartermijn is 2 jaar.

7. De randvoorwaarden, zoals beveiliging, gewenste perforDlance e.d. De huidige weten regelgeving zoals de Wet computercriminaliteit, de Wet persoonsregistratie en de Verordening Persoonsregistratie zijn ten aanzien van de invulling van concrete beveiligingsmaatregelen zeer vaag, zodat geen houvast wordt geboden voor een beveiligingsplan GDA. In art. 8 van de Wet persoonsregistratie staat bijvoorbeeld: De houder draagt zorg voor de nodige voorzieningen van technische en organisatorische aard ter beveiliging van een persoonsregistratie tegen verlies of aantasting van de gegevens en tegen onbevoegde kennisneming, wijziging of ve:rstrekking daarvan. Gelijke plicht rust op de bewerker voor het geheel of gedeelte van de apparatuur die hij onder zich heeft. Behalve de diensttakken/stadsdelen zal bij GDA ook Civility aan de volgende eisen dienen te voldoen: aIleen toegang tot gegevens (invoeren, wijzigen en verwijderen) door bevoegde functionarissen. geen verstrekking aan onbevoegde personen. voldoen aan Verordening Persoonsregistratie. systematische registratie van gebruik van het netwerkbeheersysteem. Pogingen tot overtreding van bevoegdheden dienen te worden gesignaleerd, geregistreerd en gerapporteerd. complete audit/management trail van netwerkbeheersysteem. deelnemer moet kunnen vaststellen dat de aangeboden mutaties voor wat betreft instellingen van routers en het netwerkbeht:ersysteem juist, volledig en tijdig worden verwerkt. sluitende procedure voor testen en accepteren van programmatuur. procedures voor voldoende beveiligingskopie,en (back-up) van het netwerkbeheersysteem

UitvalNMS Binnen de escalatie-procedure voor het Netwt~rk Management Systeem (NMS) zal de leverancier om ondersteuning worden gevraagd. Voor de betrokken RS6000 is met de leverancier (IBM) een onderhoudscontract afgesloten waarbij opgenomen is, dat in geval van problemen dit binnen 8 (werk-)uren is opgelost, eventueel door de hele RS6000 te vervangen. Naast een onderhoudscontract ten aanzien van het RS6000 systeem zijn voor het Netwerk Management Systeem geen bijzondere reservelback up voorzieningen getroffen. Tijdens de periode dat de reparatie wordt uitgevoerd is rapportage niet mogelijk en dient het beheer 'met de hand' te worden uitgevoerd. Daarnaast wordt er een back up van het NMS bewaard, zowel intern als extern, opdat ook bij calamiteiten het NMS weer kan worden gernstalleerd.


143



Ret uitvoeren van het operationeel beheer van informatiesystemen geschiedt bij Civility volgens de ITIL-procedures. ITIL is daarmee ook van toepassing voor de GDA. Ret handboek Service Support ITIL bevat een beschrijving van de volgende procedures: configuratiebeheer wijzigingsbeheer programmatuurbeheer Relpdesk (incidentbeheer) probleembeheer. In het SLA is bepaald dat door Civility omtrent de dienstverlening wordt gerapporteerd aan de Projectmanager GDA en aan de deelnemers. In het DAP zijn de volgende periodieke rapportages vermeld: incidenten probleembeheer servicedesk Beschikbaarheidsbeheer capaciteitsbeheer. Verder zijn er de volgende incidentele rapportages over: documentatie incidenten probleemafhandeling aansluitprocedure security incidenten. De plaats van het SLR systeem in de beheerinfrastructuur is schematisch weergegeven in figuur 7.24. Netwerken Systemen l"lo.;~~ Management machine

Applicatie Server

Applicatie Server

Service Level Rapportage systeem

~LM SQL' database

Router

~

<:::::>Q""""CR:2:0u:;s;t~er-r_r__

r4I1

gebruiker

~

RMon Server

Remote MONitoring probe op gebruikerslocaties

Stuctured Query Language

Figuur 7.24 Schematisch overzicht van de management systemen.


144



7.5

De Implementatie Case

De Implementatie fase valt in vier delen uiteen, te weten: 1. de realisatie; 2. het testen; 3. conversie en invoering; 4. gebruik en beheer. De realisatie ([37] H3), ofwei de bouw en implementatie vormt, met documentatie, de schakel tussen het technisch ontwerp en het fysieke model. Een fysiek model is eveneens een model van de interne werking van het systeem, maar afhankelijk van de middelen (media). De scheiding tussen technisch ontwerp en fysiek model kan handig zijn omdat apparatuur in de informatica vaak een korte levensduur heeft. Komt er inderdaad aantrekkelijke nieuwe apparatuur met dezelfde soort werking beschikbaar, dan kan men flexibel reageren en het systeem met betrekkelijk weinig inspanning opnieuw implementeren. Het fysieke model dient dus vooral de belangen van beheersers en onderhoudspersoneel. Het beheer van het informatiesysteem dient ondersteund te worden met documentatie, handboek, procedures, checklists etc. Testen ([37] biz. 127-129), het goed testen van een systeem kost dikwijls veel tijd en energie, een goede voorbereiding en planning is zeker vereist. Het testen valt in twee procedures uiteen, namelijk: • de systeemtest; dit is een middel van de systeemontwerpers om te controleren of het gerealiseerde systeem inderdaad functioneert volgens de technische specificaties i.e. het technisch ontwerp. • de acceptatietest waarbij de gebruikers zich ervan overtuigen dat het systeem voldoet aan hun specificaties i.e. het functioneel ontwerp. De verantwoordelijkheid voor de systeemtest ligt, gezien het voorgaande, dan ook bij de systeemontwerpers; die voor de acceptatietest bij de gebruikersorganisatie. Dat neemt niet weg dat een groot gedeelte van de voorbereidingen van de acceptatietest ook door de systeemontwerpers kan worden uitgevoerd. Het testen omvat in beide gevallen het gehele systeem, dat wil zeggen, inclusief procedures, handleidingen en dergelijke. Uiteraard kunnen de gebruikers moeilijk de 'binnenkant' van het systeem controleren, zoals de kwaliteit van de programma's en de daarbij behorende (programma)documentatie. Dit onderdeel laten beoordelen door diegenen die met het toekomstig (programmatechnisch) onderhoud worden belast, moet daarom zo moge1ijk worden ingepland. Indien reeds een applicatiebeheerder is aangewezen, kan deze met name de handleidingen controleren op juistheid, leesbaarheid en volledigheid. Conversie en invoering ([37] H4), het in gebruik nemen van een nieuw systeem vereist meestal de nodige voorbereidingen en aanpassingen. In sommige gevallen kost dit meer tijd dan de eigenlijke systeemontwikke1ing. Dit is dan ook de reden dat met de voorbereidingen tijdig begonnen moet worden.


145



Indien een applicatiepakket ais (deel)oplossing wordt verkozen, kan direct na de definitiestudie reeds met d voorbereidingen begonnen worden. Besluit men tot eigen systeem ontwikkeling, dan kan dit plaatsvinden ais de contouren van het nieuwe systeem gestalte hebben gekregen, dat wil zeggen tijdens of na het maken van het technisch ontwerp. Het starten van de echte invoeringswerkzaamheden kan eerst beginnen ais men weet hoe de diverse functies verricht zullen worden en hoe de nieuwe gegevensverzamelingen eruit zullen moeten zien. Men krijgt dan een indruk hoe de diverse taken uitgevoerd moeten worden, hetgeen zal resuiteren in (concept) taakbeschrijvingen. Het nieuwe informatiesysteem vereist meestal dat de gegevens(verzamelingen) in een andere vorm en/of een andere informatiedrager worden opgesiagen. De gebruikersdocumentatie (handieidingen, bedieningsinstructies) moeten soms aan specifieke omstandigheden en personen aangepast worden en ter beschikking worden gesteld aan aIle betrokkenen. Gebruik en beheer ([37] H5), de systeemontwikkeling is afgesioten met de acceptatie van het systeem; na de feiteIijke invoering is het systeem overgedragen en in gebruik genomen. In de praktijk bIijkt helaas vaak nu pas, hoe het systeem werkelijk functioneert en komen er fouten en gebreken naar boven, die men niet heeft verwacht. Bovendien moet het systeem dikwijis worden aangepast aan gewijzigde omstandigheden, bijvoorbeeld door wettelijke voorschriften, concurrentie en dergeIijke.

De activiteiten die erop gericht zijn om het in het gebruik genomen systeem goed te Iaten functioneren, worden ook weI het systeembeheer genoemd. Een goed beheer is noodzaak; zonder dit zal ook een goed systeem niet goed functioneren of zelfs volledig mislukken. Om een goed gebruik en beheer te waarborgen kan men de ITIL methodiek gebruiken.


146



H8 Conclusies en Aanbevelingen 8.1 Conclusies Binnen een organisatie, en daarmee ook in een beheerorganisatie, kan men drie niveaus van verantwoordelijkheden onderkennen: strategisch-, tactisch- en operationeelbeheer. Kenmerkend voor deze drie niveaus is dat, respectievelijk, in toenemende mate sprake is van programmeerbare beslissingen en de daaruit voortvloeiende behoefte aan meer gedetailleerde en gestructureerde informatie. Bovendien geldt dat in het algemeen de berichtgeving op strategisch niveau met een veel grotere tijdsdimensie werkt dan op operationeel niveau. ITIL is een kwaliteitssysteem dat een structuur aanreikt voor het inrichten van de tactische en operationele processen binnen een IT-beheerorganisatie. Binnen de tactische processen speelt het service level management een sleutelrol, terzijde gestaan door onder andere het beschikbaarheidsbeheer, het capaciteitsbeheer en het beveiligingsbeheer. Het tactische proces service level management wordt ondersteunt door en krijgt informatie van operationele processen als de Helpdesk, probleem-, configuratie, onderhouds- en netwerkbeheer. Het service level management is verantwoordelijk voor het maken en bewaken van de formele overeenkomsten aangaande de kwaliteit en kwantiteit van de IT dienstverlener met de afnemer. Voor het afstemmen van de overeen te komen service levels moet het produceren van een objectieve rapportage over de behaalde service levels, en eventuele (oorzaken van) problemen die dat in de weg stonden, mogelijk zijn. Voordelen van service level management, ondersteund door een goed service level rapportage systeem, zijn: • bereiken van een specifiek, consistent, meetbaar service niveau; • uitbalanceren van de service niveaus die de gebruikers willen tegen de kosten van het aanbieden daarvan; • kostenbesparing door meer accurate specificaties; • verbeteren van de productiviteit van de gebruikers als resultaat van betere IT-diensten; • het hebben van een objectieve service meetgegevens voor het opheffen van meningsverschillen over service levels; • reduceren van de kans op onvoorspelbare eisen. Gegevens voor het maken van een service level rapportage worden onttrokken aan de operationele processen, een van de belangrijkste daarvan is het netwerkmanagement. Voor het zoveel mogelijk automatisch genereren van service level rapporten dient een informatiesysteem ontwikkeld te worden dat gegevens verzamelt en verwerkt tot duidelijke en correcte rapporten. Zo een systeem is onderdeel van het bestuurlijke aspect van geautomatiseerde werkpleksystemen. Dat aspect kan men verdelen in drie afzonderlijke delen, te weten: • een bestuurd systeem, zijnde het deelsysteem dat moet worden bestuurd; • een besturend orgaan, zijnde de persoon of groep personen die stuurt. Terzijde ZlJ opgemerkt dat ook een machine besturend orgaan kan zijn;


147



• een bestuurlijk informatiesysteem, zijnde het deelsysteem dat op grond van gegevens van het bestuurde systeem zelf (interne gegevens) of van gegevens over de omgeving (externe gegevens) informatie vastlegt en produceert voor het besturend orgaan. Om nu een bestuurlijk informatiesysteem te ontwerpen zal men allereerst zo scherp mogelijk moeten afbakenen wat het bestuurd systeem is, welke omgeving daarbij geldt en wie besturend orgaan is (i.e. afbakening systeemgrenzen), een goed hulpmiddel hierbij is het besturingsparadigma. Ret ontwikkelen van een informatiesysteem is in belangrijke mate een kwestie van modelleren. Dat modelleren gebeurt volgens de Systems Development Methodology in parallelle en successievelijke werkstappen, namelijk: • het opstellen van een informatiemodel, hier komen aan bod de structuur van het bedrijf, de problemen die er spelen en de bijdrage die het systeem dient te leveren aan de oplossing daarvan en onder welke voorwaarden dat moet gebeuren; • het functioneel ontwerp, hier komen aan bod de functies die binnen het systeem zijn te onderscheiden en volgens welke regels er interactie plaatsvindt; • het technisch ontwerp, dit ontwerp bevat alternatieve technische oplossingen, met dezelfde functionaliteit, voor de organisatie van het informatiesysteem; • de implementatie fase, verder onder te verdelen in realisatie, testen, conversie en invoering en gebruik en beheer. Elk onderdeel van een applicatie is te zien als een beheerobject, zo een object is van invloed op de performance. Om nu de performance voor elke klant afzonderlijk op applicatie niveau te bepalen moet de performance van de afzonderlijke objecten bekend zijn. Door het definieren van samenstellingen van objecten is het mogelijk de gerealiseerde kwaliteit van verschillende rapportage items per rapport (klant) te bepalen. De rapportage items hebben betrekking op verschillende abstractieniveaus, de volgende niveaus, van hoog naar laag, zijn te onderscheiden: 1. Applicatieniveau, bijvoorbeeld de beschikbaarheid van het GISP on-line systeem, beschikbaarheid van het GDA als geheel of de responstijd van een on-line systeem zoals het NFS. 2. Dienstenniveau, bijvoorbeeld de beschikbaarheid van Email, beschikbaarheid van een GDA-aansluiting of gebruik van back-up en bandwidth on demand. 3. Objectniveau, bijvoorbeeld de beschikbaarheid van de centrale print faciliteit van WVG, afgenomen capaciteit van een verbinding of het aantal gelijktijdige gebruikers op een server. 4. Componentniveau, bijvoorbeeld de CPU belasting of harddisk bezetting. Door de complexiteit van de infrastructuur en de diversiteit van de te leveren rapportage items is het niet mogelijk een van de op dit moment beschikbare standaardpakketten te gebruiken als oplossing voor het realiseren van aIle vereiste functionaliteiten. Voor het verzamelen en opslaan van de benodigde netwerken systeemmanagementgegevens zijn weI standaard applicaties te gebruiken (NSM-pakket), aangevuld met zelf te schrijven scripts. Ook het afleveren van de uiteindelijke rapporten op internet, via email of als gedrukt exemplaar bij de klanten kan gerealiseerd worden met behulp van een standaardpakket (rapportage tool).


148



Echter voor de verwerking van de grote hoeveelheden managementgegevens tot correcte en duidelijke (eenvoudig te interpreteren) rapportage items, zal het systeem moeten beschikken over een snel en intelligent verwerkingsprogramma dat de gegevens opsplits, selecteert en aggregeert. Tevens moeten scripts geschreven worden voor de te gebruiken standaardpakketten en het koppelvlak tussen de diverse functies.

8.2 Aan bevelingen Het opzetten van een generieke beheerstructuur is mogelijk door zoveel mogelijk overeenkomsten te creeren tussen de diverse applicaties, service niveau overeenkomsten en service niveau rapportages. Hierdoor is het mogelijk Om met beperkte middelen meer klanten te voorzien van automatiseringsdiensten met een goede prijs/kwaliteit verhouding. Waarrnee een concrete invulling van de bedrijfsmissie is te bereiken. Alleen generieke Service Level Agreements (SLAs) kunnen leiden tot generieke rapportages. Door het hebben van een generieke rapportage is het mogelijk een rapporterend informatiesysteem te ontwikkelen dat met slechts geringe aanpassingen geschikt is te maken voor het produceren van rapporten voor nieuwe applicaties en/ofklanten. Door het uniformeren (qua structuur en inhoud) van de Service Level Agreements is het eenvoudiger om het daarbij horende beheer generiek in te richten en de rapportage te standaardiseren. Een SLA bevat een beschrijving van de te leveren kwantiteit door de bewuste applicatie en de kwaliteitsniveaus van de applicatie zelf en van het beheer van deze applicatie. De inhoud van de SLAs moeten overeen gaan komen zowel op de gebruikte grootheden (eenduidige definities van beschikbaarheid, betrouwbaarheid, responstjjd, etc.) als eenheden (bijvoorbeeld, beschikbaarheid per maand uitgedrukt in procenten). Tevens is het erg raadzaam de openingstijden van de diverse applicaties te laten samenvallen zodat van alle componenten bekend is op welke tijden deze beschikbaar moeten zijn en het bepalen daarvan moet beginnen. De structuur van een Service Level Agreement kan opgehangen worden aan de volgende ITIL processen: beschikbaarheidsbeheer, capaciteitsbeheer (met performance aspecten), Helpdesk, probleembeheer, wijzigingsbeheer, configuratiebeheer, beveiligingsbeheer, calamiteitenplanning, onderhoudsbeheer en documentatiebeheer. Deze processen vangen samen alle SLAitems zoals die nu bestaan. Het maken en bijhouden van een overzicht van de te beheren datacommunicatie infrastructuur, de aangesloten systemen en de door de klanten afgenomen diensten zal bijdragen aan het inzicht in de gevolgen voor de klanten bij uitval van een of meer componenten. Rapport genererende applicaties voor het bepalen van de gerealiseerde kwaliteit door het netwerkmanagement komen steeds meer in ontwikkeling. Binnen niet al te lange tijd kunnen pakketen verwacht worden die voldoen aan de (deel-)eisen die in dit rapport gesteld zijn. Het is derhalve raadzaam deze ontwikkeling in de gaten te houden, om zo het te maken maatwerk pakket dat waarschijnlijk hoge onderhoudskosten met zich mee brengt te vervangen door een standaard applicatie. Civility Amsterdam bv.

149



Literatuur [1] 'Integrated Network and System Management' Hegering, Heinz-Gerd and Abeck, Sebastian. Addison-Wesley Publishing Company, 1994. [2] 'LANs to WANs - Network Management in the 1990s' Muller, Nathan J. and Davidson, Robert P. Artech House, 1990. [3] 'Communication Networks Management' Terplan, Komel. second edition, Prentice Hall, 1992. [4] 'Aspecten van Datacommunicatie' Raamsdonk, Robert van. IBM Nederland N.V. december 1991. [5] 'Projectplan "Verbetering IT Beheer" VIB' Niersman, G. GCEI Amsterdam, concept (0.3) 13 december 1996. [6] 'Incidentafhandeling' Simons, H.L.J.J. GCEI Amsterdam, 1 oktober 1996. [7] 'Jaaroverzicht GCEI 1995, Automatisering is mensenwerk' GCEI Informatieplanning en Automatisering Amsterdam, 1996. [8] 'GDA Technisch bekeken' GCEI Amsterdam, versie 1.1 september 1996. [9] 'GDA Produkten en Tarieven' GCE! Amsterdam, versie 1.0 september 1996. [10] 'Handboek bij het maken van GDA rapportages' Ramjankhan, Zaid. GCEI Amsterdam, versie 0.2 1 April 1996. [11] 'NSM Services: The Rhetoric and the Reality' Hayden, B. Strategic Analysis Report, NSM, GartnerGroup, 13 March 1996. [12] 'Tivoli Extends TME to Manage Internet Technologies' Scott, D., Price, C. Research Note, NSM, GartnerGroup, 29 April 1996.


151



[13] 'Moving Toward Process-Bassed Network Orginizations' Cooperman, J. Research Note, NBM, GarterGroup, 19 April 1995. [14] 'Ensuring That NSM Tools Bought Today Are Usable Tomorrow' Keyworth, B. Top VIEW, NSM, GartnerGroup, 29 August 1996. [15] 'Positioning Enterprise NSM Suites' Scott, D. Research Note, NSM, GartnerGroup, 24 June 1996. [16] 'A Guide to NSM Disciplines and Players' Hallawell, A. Top VIEW, NSM, GartnerGroup 24 June 1996. [17] 'ITIL Essentials' Pink Elephant Education & Development bv, Voorburg Nederland, 5 april 1995. [18] 'Handboek Service Support' Hollander, J en Jong, A. de et al. GCEI-MV, Amsterdam, 9 oktober 1996. [19] 'Service Level Agreement, Gemeenschappelijke Datacommunicatie infrastructuur Gemeente Amsterdam' GCEI Amsterdam, versie 1.1 september 1996. [20] 'Dossier Afspraken en Procedures, Gemeenschappelijke Datacommunicatie Infrastructuur Amsterdam' GCEI Amsterdam, versie 1.1 september 1996. [21] 'Systems Management: The Emerging Role of Intelligent Agents' Muller, Nathan J. Strategic Information Resources, www.ddx.com. 1996. [22] 'Networked Systems Management Operations' Hecht, B. Gartner Group, Inc., England, 1994. [23] 'GDA Systeem documentatie' GCEI-MV, Amsterdam, Vol 1-5, 22 november 1996. [24] 'Network Services Management, IT Infrastructure Library' Rudd, Colin., and Shilling, Alan. CCTA, Gildengate House, Norwich, England, 1994.


152



[25] 'Network Management Standards, The OSI, SNMP and CMOL Protocols' Black, Uyless. McGraw-Hill, 1992. [26] 'Management en organisatie van automatiseringsmiddelen' Looijen, M. Kluwer Bedrijfswetenschappen, Deventer Nederland, 1989. [27] 'Informatie Management' Achterberg, 1. VU Uitgeverij, Amsterdam 1986. [28] 'Service Level Management, IT Infrastructure Library' IT Infrastructure Management Services, CCTA, Norwich, 1993. [29] 'Een Service Level Agreement dat bijdraagt aan de kracht van de organisatie' Economic Point of View, Amsterdam, Een casestudy: het Kadaster. [30] 'Bestuurlijke informatiesystemen en automatisering' Bemelmans, T.M.A. Kluwer bedrijfswetenschappen, zesde druk, 1994. [31] 'Volledig Communicatie-georienteerde Informatiemodellering (FCO-IM)' Bakema, Guido; et al. Kluwer bedrijfswetenschappen, eerste drukjuli 1996. [32] 'Exploitatie van automatiseringsmiddelen' Looijen, M. Kluwer, Deventer, 1986. [33] 'Technieken voor Informatieanalyse' Kramer, K. Cap Gemini Publishing B.V. Rijswijk, 1992. [34] 'Beheer van informatievoorziening' Delen, G.P.A.J. en Looijen, M. SDM reeks, Cap Gemini Publishing B.V. Rijswijk, 1992. [35] 'Network Management Architectures' Pras, A. CTIT Ph. D-thesis series No. 95-02, Enschede The Netherlands, 1995. [36] 'Beheersaspecten van de Energievoorziening en Telecommunicatienetten' Antal, M. Faculteit Elektrotechniek, Dictaat 5756, Technische Universiteit Eindhoven,januari 1995.


153



[37] 'Systeemontwikkeling op kleinere schaal met SDM' Eilers, H.B. Academic Service, Schoonhoven, 1989. [38] 'Ontwerpen van informatiesystemen' Essink, L. en Romkema, H. Academic Service, Schoonhoven, 1989. [39] 'Systeemontwikkeling volgens SDM' Eilers, H.B. Academic Service, Den Haag, 1980. [40] 'De SLA Specificatiemethode' Copyright: Cap Gemini, Utrecht; Uitgever: Academic Service, Schoonhoven 1997. Enkele geraadpleegde Web-sites: - http://www.tivoli.comln_gemltivgem.html - http://www.tivoli.comln_appsman/armwhitepaper.html - http://www.tivoli.com/products/netview/nvpaper.html - http://www.networking.ibm.comlnpmlnpmover.html - http://www.prolin.comlprolin.htm - http://www.crystalinc.comlCreports/default.htm - http://www.can.ibm.comlmainframe/software/sysman/p47.html - http://www.cisco.comlwarp/public/734/cworks/425yp.htm


154



Epiloog Gedurende de eerste weken van mijn afstudeerperiode liep ik regelmatig tegen het feit op, dat ik te weinig wist van bedrijfskunde en (bestuurlijke) informatica. Deze kennis had ik weI nodig om de organisatie en de processen daarin te kunnen begrijpen. Dit probleem heb ik getackeld, op naar mijn inzien erg academische wijze, door middel van een uitgebreide literatuur studie. Na deze studie wist ik waarom er een matrix organisatie binnen GeEI MVPH bestaat, wat het doel is van Informatie Technologie (IT) en Informatie Systemen (IS) en wat er zoal komt kijken bij het automatiseren van bedrijfsprocessen. Het belangrijkste, voor mijn opdracht althans, wat ik geleerd had was de te volgen aanpak om tot een kwalitatief goed resultaat te komen van het door mij te ontwikkelen Service Level Rapportage systeem. Echter er moet ook met andere factoren rekening worden gehouden, een vaak aangehaalde formule hiervoor, is: Succes = Kwaliteit

* Acceptatie

Kwaliteit waarborgen door: 'Wil men nu een informatiesysteem opzetten dat relevante informatie produceert, dan zal men eerst de eisen aan dit systeem moeten inventariseren. Het ontwikkelen van een informatiesysteem is in belangrijke mate een kwestie van modelleren. Dat modelleren gebeurt in parallelle en successievelijke werkstappen. Te weten: het opstellen van een Informatiemodel, het Logisch Ontwerp en het Technisch Ontwerp. Na het modelleren start de implementatie fase, op te delen in de Bouw, het Testen en tot slot Conversie en Invoering.' Een systeem kan nog zo perfect zijn opgezet, als gebruikers niet bereid zijn om zo'n systeem te accepteren, dan is het ontwikkelingsproject geheel of gedeeltelijk mislukt. Waar hangt nu de mate van acceptatie van een systeem van af? Sterk vereenvoudigd geldt dat dit afhangt van de aard van de verandering en van de veranderingsstrategie die men kiest. Met betrekking tot de aard van de verandering worden in de literatuur verschillende niveaus onderscheiden: - eerste niveau: verandering in werkmethoden en procedures zonder dat organisatorische of andere veranderingen noodzakelijk zijn. - tweede niveau: veranderingen die vragen om een andere organisatie en dus om een rolaanpassing van de betrokken mensen (structuurverandering). - derde niveau: veranderingen die vereisen dat mensen zich anders gaan gedragen, er andere waarde-oordelen op na houden (cultuurverandering). Het behoeft weinig betoog dat hoe hoger het niveau wordt van een verandering, hoe meer er rekening gehouden moet worden met mogelijk verzet en weerstand, zeker als een dergelijke verandering van bovenaf wordt gedicteerd. Welke veranderingsstrategien kan men nu volgen bij het ontwikkelen van een informatiesysteem? De volgende mogelijkheden worden onderscheiden:


155



- ontwerp na consultatie: het ontwerp van een nieuw of verbeterd informatiesysteem wordt gemaakt en 'verkocht' door specialisten op dit terrein, zij het na consultatie van de diverse betrokkenen. - ontwerp via vertegenwoordiging: het ontwerp wordt in hoofdzaak opgesteld door vertegenwoordigers vanuit de gebruikersorganisatie. Specialisten op informatieterrein vervuIlen in deze ten hoogste de rol van katalysator. Daarnaast zijn ze verantwoordelijk voor de technische aspecten van een ontwerp. - ontwerp via consensus; bij deze benadering worden de ontwerpbeslissingen genomen door aIle betrokkenen. Een team van ontwerpers, bestaande uit gebruikers en specialisten, werkt deze beslissingen uit in diverse alternatieven, waarna opnieuw aIle betrokkenen worden geraadpleegd. Acceptatie waarborgen door: Afhankelijk van het probleem heb ik zelf de beslissing genomen of heb mogelijkheid een of twee toegepast. Tenslotte wil ik iedereen bedanken die direct of indirect heeft bijgedragen aan het voltooien van dit project en daarmee mijn studie. De volgende personen wil ik nog effen bij naam noemen vanwege hun wel erg grote bijdrage, Dhr. F. van den Dool, Henk Simons, de medewerkers van de afdeling MV-PH en mijn kamergenoten Sarwat, Jacques en Maarten. Ook de steun van achteren verzorgt door mijn huisgenoten van 'Huize Hoogh Hemelschzicht' in Eindhoven, MarieIle en Arno, bedankt, het was een buiten gewoon inspirerende tijd. Voor mijn generatie- en studiegenoten, die nog moeten afstuderen of net afgestudeerd zijn: 'Veel Succes en Geen Gedonder!'


156



Bijlage 1: Afkortingen met verklaring ACL AM API AS ASE

AV BER BER BM BOD

BRI CCITT CCTA CI CIR CM CM CMIP CMIS CMO CMDB DAP DNS DSM Eng FM FM FMS FTP GCEI GDA GISP GSD GW HM lAB ICMP

IEC IEEE IETF ILM IP IS IS ISAC

Access Control List Accounting Manager Application Programming Interface Application Services Application Service Element Availability Basic Encoding Rules Bit Error Rate Business Manager Bandwidth On Demand Basic Rate Interface Comite Consultative Internationale de Telegraphique et Telephonique Central Computing en Telecom Agency Configuratie Item Committed Information Rate Change Manager Configuration Manager Common Management Information Protocol Common Management Information Service Change Management Overleg Configuratie Management Database Dossier Afspraken en Procedures Domain Name Server Distributed System Management Engineering Facility Manager Fault Manager Facilities Management Services File Transfer Protocol Gemeentelijk Centrum voor Electronische Informatie voorziening Gemeenschappelijke Datacommunicatie-infrastructuur gemeente Amsterdam Gemeentelijk Informatiesysteem Salaris en Personeel Gemeentelijke Sodale Dienst Gateway Helpdesk Manager Internet Activities Board Internet Control Message Protocol International Electrotechnical Commission Institute of Electrical and Electronics Engineers Internet Engineering Task Force Intermediate Level Manager Internet Protocol Informatie Systeem International Standard Information System work and Analysis of Change


157



ISDN ISO IT ITIL ITU-T LAN MAN MF MF MIB MIS MTBF MTBSI MTOR MTTD MTTR MV NBM NCP NE NEF NEM NM NPA NSM NUS OS OSF OSI PB P&B PC PDU PM PM P&O PvA Q&A QAF QoS RFC SAP SAT SDLC SDM SLA SLM

Integrated Services Digital Network International Organization for Standardization Informatie Technologie Information Technology Infrastruture Library International Telecommunication Union - Telecommunication Standardization Sector Local area Network Metropolitan Area Network MainFrame verwerking Mediation Function Management Information Base Management Information Service Mean Time Between Failure Mean Time Between System Incidents Mean Time Of Repair Mean Time To Diagnosis Mean Time To Repair Midrange Verwerking Network Business Management Network Control Program Network Element Network Element Function Network Element Manager Network Management Network Participation Agreement Netwerk en Systemen Management Nieuw Uitkeringen Systeem Operating Systemen Operations System Function Open Systems Interconnection Produktie en Beheer ZiePB Personal Computer Protocol Data Unit Performance Manager Problem Manager Personeel en Organisatie Plan van Aanpak Quality and Assurance Quality Adaptor Function Quality of Service Request For Comment Service Access Point Systeem Acceptatie Testen Synchronous Data Link Control Systems Development Methodology Service Level Agreement Service Level Manag(er)(ment)


158



SLR SM SM SMAE SMF SMI SMTP SNA SNMP(v2) SNO SSCP TCP TLM TME

TMN UDP VIB VTAM WAN WSF WVG

Service Level Report Security Manager Service Management Systems Management Application Entity Systems Management Function Structure of Management Information Simple Mail Transfer Protocol Systems Network Architecture Simple Network Management Protocol (version 2) Service Niveau Overeenkomst Systems Services Control Point Transmission Control Protocol Top Level Manager Tivoli Management Environment Telecommunications Management Network User Datagram Protocol Verbetering IT Beheer Virtual Telecommunication Acces Method Wide Area Network Work Station Functions Wet Voorzieningen Gehandicapten


159



Bijlage 2: Invulling van bet GDA & NSM (d.d.31-12-96) Het Basisnefwerk - Cisco routers; AGS+, 4000,2503 met lOS software versie 10.+ - Huurlijnen, twee stuks, van 2 Mbps (G703) - ISDN-2 (2B+D), 16 stuks voor Paalberweg en 8 stuks voor Stopera.

Basisaansluitingen - Cisco routers 2503 - Huurlijnen van 19k2, 64k, 128k of256k (digiline) - ISDN-2 (2B+D) voor back up en BOD

Centrale faciliteiten Centrale Email faciliteiten GroupWise 4.1 van Novell, op een Netware 3.12 server, opgenomen in het GDA tokenring. Met inbel-faciliteiten: GroupWise Asynchrone Gateway, Digiboard communicatie adapter en V32bis inbel-modem van Anchor.

3270 Gataway faciliteiten Voor de centrale 3270 Gateway faciliteiten wordt gebruik gemaakt van Attachmate gateway's gebasseerd op DOS PC's dan wel Netware voor SAA, gei"nstalleerd op een Netware 3.12 server. Deze gateway's worden opgenomen in het GDA tokenring en communiceren met de SNA-host via een IBM local 3174 controller welke voorzien is van het 3270 gateway feature. Voor de communicatie tussen de client en de gateway wordt IP als standaard protocol gebruikt. Tussen de gateway's en de 3174 controller wordt het SNA LLC2 protocol gehanteerd. Name Servers Voor de centrale Name Servers binnen de GDA zullen tenminste twee op DNS gebasseerde Name Servers worden gei"nstalleerd, welke bovendien als back up voor elkaar dienen. Op ieder knooppunt zal tenminste een Name Server worden ingericht. Deze dienst is volgens de documenten RFC 1033, RFC 1034 en RFC 1035 opgebouwd. Het leveren van een DNS voor het GDA geldt alleen voor het IP protocol. Een voorwaarde is wel dat de client-systemen geschikt zijn gemaakt voor het DNS mechanisme. Indien dit niet mogelijk is kan ruet gebruik gemaakt worden van de DNS. Het beheer zal door MV-Netwerken worden verzorgt. Iedere Diensten aanbieder van GDA diensten kan in de DNS opgenornen worden. Directory Service De Directory Service binnen de GDA wordt gefaseerd ingevoerd. In eerste instantie zal deze gebaseerd zijn op de directory van de Centrale GroupWise omgeving. In een latere fase zal deze functionaliteit ondergebracht worden in een Directory Service gebaseerd op X.500.


161



Communicatie opties Remote terminal-access 3270 Voor de communicatie optie 'Remote terminal-access 3270' wordt gebruik gemaakt van EXTRA!, voor DOS en Windows van Attachmate. Remote terminal-access VT220 Voor de communicatie optie 'Remote terminal-access VT220' wordt gebruik gemaakt van een van de volgende implementaties: - LAN WorkPlace - Reflection 2 - Reflection 2+ - PathWorks

voor DOS voor DOS voor Windows voor DOS

van Novell van WRQ van WRQ van Digital

met de bijgeleverde IP-stack met de IP-stack van LAN WorkPlace voor DOS met de IP-stack van LAN WorkPlace voor DOS met de bijgeleverde DECnet-stack

Client voor TCP/IP Voor de communicatie optie 'Client voor TCP/IP' wordt gebruik gemaakt van een van de volgende implementaties: - LAN WorkPlace

- PC/TCP

voor DOS voor DOS voor Windows voor OS/2

van Novell van FTP van FTP van FTP

met de bijgeleverde IP-stack met de bijgeleverde IP-stack met de bijgeleverde IP-stack met de bijgeleverde IP-stack

Email-opties Email postbus (IPX-protocol) Voor de optie .Email postbus' wordt gebruik gemaakt van de DOS en Windows client software van Novell's GroupWise 4.1. Email transit (IP-protocol) Voor de optie .Email transit' wordt gebruik gemaakt van de Message Server van Novell's GroupWise 4.1. Het te koppelen Email systeem dient zo nodig uitgebreid te worden met een gateway die de koppeling met GroupWise 4.1 verzorgt.

Netwerk Systemen Management De netwerkmanagement functies behoren niet tot de voor gebruikers direct toepasbare functies maar zijn van onmiskenbaar belang voor het kunnen leveren van de beloofde service levels. Als hulpmiddel voor de ondersteuning van de netwerkmanagement functies is een netwerkbeheersysteem ingericht, bestaande uit de volgende componenten: - RS6000 machine, AIX, X-terminals - NetView managementsysteem - CiscoWorks software - Rmon software - NetView Nodemanager - SNMP Trap-manager - CiscoWorks database - Rmon database


162


(J

~

=

~:

~ ;I>

S

.... '"

...i=l-

0

8 0" ~

~

~

lkar02.

0-

\;J

r--' I I I I I I I I

I I I I I I I I

II I I

grar02

I

0

r-

r--·

r--'

r--'

osar01 loar01

I I I I I I I I I I I I I I I I I I I I

I

dabr01 sdrr01 anbr11 wvhr01 wvjr01 wvkr01 Imar01

I

::s ~

~

l'1>

~

(JQ

<:

§

(\l

0

::s (IJ

...<: 0

n' (\l

l(\l' <:

!!. ~

.g 'g

it

(JQ

0

c:

::s

< ::s

';"i

0

.....

l'1>

0

0"

r

::r

0

~

....,

n

S' §:

~

S

S V;.

tr1

<:

§

l'1> .... .....

n

(\l ::;.

::s

...

(\l

....

0 0

::r

....,

<: 0 ;;l ::;.

...

0 0

shillr03

-

2'

n

.....

""l

wlar02 - Inar01 dsfr01 liar01 laarl>2 sdar01 swdr01 dbrr01 biarl>2 bicr01 bidr01 pkbr01 dser01 \Wgr01 \Wer01 \Wcr01 wvfr01

-00-

ISDN

Unix system en

2...

= =

Serieel

•

(IJ

~ ~

Ethernet

Cisco muler

IbarD1 polrD1 rwar01

~ ~

I

I

I

'" '< I

Verbindi'"gen naar


~

NameServer am sterd a nl.nl (secondary)

0

ISDN

ISDN

0

S S 0

....

(IJ

I:'

s:

(')

~

3:

~

0 0

> e

"'0 "'0

GOA IrtJslfa;i1ilElilEln

..,..... CIl

Cisco routor

(l)

Po

3

= = .... =

L08GCR

_

ANAF02/05

f;j"

o

GOA

~

Service segment

Unix ~yslllll1ltn

~

-., ~ ~

C"

TokcnRing

~

Ethernet

~

Serieel

IJCl

----- ISDN

~

C/J

a n

..,l: ..,

(l) (l)

i:l

<:

§

..... ...., , f;j" (l)

.". (l) (l)

..,

e..... (l)

..... ...., .....

r

vbar01

0 i:l

~

~

:>;"

Verbildilgen naar knoq:>punt Stadhuis

...-

..,.

0'1

I I I

Ethernet GeEI

(l)

~

lJQ

I I

<:

I

IlO

i:l (l) (l)

i:l C/J (l)

~ 0" (l)

t""' <:

(l)

g.

....,

:;>::l

(l)

n

go
.". Cl>

~

::;::-

~

~.

::;"

tTl

5"

§: 0

<:

(l)

i:l

IlO

Beheer-

systeem

I I I

I

ggdl1l1 faOOO

dgbr01 f8.127

IzarQ1

I I I I I I I I

sbarOl- J wvirQl

"0 "0 0

I I I I I I I I I

:4 IlO

lJQ

(l)

CIl

'< CIl

..... (l)

I

I I I I I I I

etlar01 ElbarOl·-1

(l)

GamNat

e e..... (l)

Internet

C/J

t:I

~

Het verbeteren van IT-beheer met behulp van ITIL, implementatie van een Service Level Rapportage systeem.

Bijlage 3: Takenoverzicht MV Processen Sen'ice

Produklie

fllcidelll-proces

Probleem-proces

Produktie Helpdesk Verantwoordelijk voor Verantwoordelijk voor aile operationele bepaalde eenvoudige dagelijkse operationele taken werkzaamheden I.b.v. de service, levert infonnatie Voert dagelijkse Voert eenvoudige operationele operationele handelingen uit handelingen uit

Signaleert, registreert en routeert incidenten en bewaakt de afhandelingstennijnen koppelt de afhandeling terug naar de klant en escaleert naar HM Levert bijdrage aan signalering van problemen naar PM

Signaleert, analyseert en lost incidenten op, en escaleert naar SLM en/of PM, koppelt oplossing terug naar de Helpdesk Levert bijdrage aan signalering van problemen naar PM, analyse en oplossing van problemen

SLM Borgt het serviceniveau door het coordineren en bewaken van de service Bewaking van aile operationele dagelijkse werkzaamheden I.b.v. de service Bewaakt incidentafhandeling, alsmede escalatie naar FM, PM en klant

lorgt voor coordinatie van analyse en oplossing van problemunicatie met FM en klant op operationeel niveau Coordineert uitvoering en implementatie. Adviseert CMO m.b.1. wijzigingen. Dient rfc's in ter verbetering v.d. service. lorgt voor acceptatie

Registreert wijzigingsaanvragen. Infonneert gebruikers over wijzigingen

Implementeerd wijzigingen

fllllOl'alie-proces

Verbetert continue het leveren van de dagelijkse service

Verbetert continu het leveren van de dagelijkse service

Initieert innovaties

Registreert nieuwe software (inkoopmedewerker). Accepteert, distribueert en activeert software

Is verantwoordelijk dat de gegevens in de CMDB up-to-date zijn

GeEI, Amsterdam

Problem Manager Borgt het serviceniveau door het coordineren en bewaken van probleemoplossingstrajecten

Change Manager Borgt het serviceniveau door het coordineren en bewaken van wijzigingstrajecten

FMS Spreekt service niveau af met de klant en maakt afspraken over afwijking hiervan

Engineering Zorgt voor tactische aspecten van de service, inrichting en service configuratie

Bewaakt de stabiliteit van het produktieproces door trends in incidenten te signaleren

Bewaakt de impact die interne en exteme wijzigingen op het produktieproces kunnen hebben

Verantwoordelijk voor afspraken m.b.1. produktie die niet is gedekt door het SLA

Projecten Levert op projectmatige basis IT-diensten

Bewaakt incidentproces, Bewaakt incidentproces, zorgt voor escalatie naar zorgt voor escalatie naar Hoofd Engen HE rapporteert

Communicatie met klant op tactisch niveau

Levert ondersteuning aan het produktieproces door optimale inrichting, configuratie en hulpmiddelen Zae lijns ondersteuning m.b.1. oplossen incidenten

Levert bijdrage aan signalering van problemen naar PM

Signaleert en registreert problemen; initieert, coordineert en bewaakt probleemproces en levert rapportages

Beoordeelt kosten aspecten van probleemoplossingstrajecten en communicatie met de klant op tactisch niveau

Levert bijdrage aan signalering, analyse en oplossing van problemen. loekt workaround en beschrijft deze voor produktie

Biedt specialistische ondersteuning bij complexe problemen

Coordineert gebruikersvoorlichting

Dient rfc's in om problemen te verhelpen

Bewaakt, plant en stuurt het wijzigingsproces. Behandelt rfc's. Is voorzitter Change Management Overleg (CMO)

Realiseert wijzigingen, stelt implementatieplannen op, draagt de wijziging over aan produktie en zorgt voor documentatie en werkinstructies

Realiseert en implementeert op projectrnatige wijze grote wijzigingen

Definieert vanuit probleem-proces innovatiemogelijkheden

lorgt dat innovatie planmatig ingevoerd wordt en dat innovatie niet de dagelijkse produktie verstoort Bewaakt het samenstellings- en implementatietraject van nieuwe releases

Beoordeelt kosten aspecten van wijzigingstrajecten en communicatie met de klant op tactisch niveau. Dient rfc's in naar aanleiding van verzoeken van de klant Initieert innovatie op verzoek van de klant

Verbetert continue de serviceconfiguratie door initiatie en uitwerking van innovatie

Initieert en geeft leiding aan grotere innovatieprojecten

Test en stelt releases samen. Meldt nieuwe IT-items aan bij SLM

Bouwt releases

men, verzorgt com-

Wijzigillgsproces

Software Call/role en Dislribulie

Helpdesk Manager Borgt het serviceniveau door het coordineren en bewaken van incidentoplossingstrajecten

165

Bepaalt release strategie



Processen Configuratiebeheer

Helpdesk Zorgt voor de registratie van nieuwe IT-items

Produktie Structuur CMDB wordt vastgelegd en beheert door configuratie-manager

Uitwijk

Verzorgen communicatie met de klant

Bel'eiliging

Resetten logische toegangsbeveiliging

Is alert op potentiele bedreigingen voor de continurteit van de dienstveriening. Verantwoordelijk voor en coordineert de uitwijk (Uitwijkcoordinator) Verantwoordelijk voor back up en restore, beheer logische toegangsbeveiliging Bewaakt. Rapporteert en voert eenvoudige taken uit

Beschikbaarheids -proces

Bewaakt.Rapporteert en voert eenvoudige laken uit

Capacity-proces

Cost-proces

Registreert verbruikte uren

Registreert verbruikte

uren

SLM Meidl nieuwe ITitem aan bij Helpdesk. Is verantwoordelijk dat de gegevens in de CMDB up-to-dale zijn Verantwoordelijk voor het up-to-date zijn van de procedures

Helpdesk Manager Signaleert onvolkomenheden in de CMDB

Problem Manager

Coordineert gebruikers vooriichting, escaleert naar PM en Uilwijkcoilrdinator

Inilieert uitwijk in geval van een calamiteit. Vervanger Uitwijkcoordinator

Change Manager

Bewaakt en rapporteert over beveiliging ats afgesproken in SLA Bewaakt SLA afspraken en rapporteert afwijkingen BewaaktSLA afspraken en rapporteert afwijkingen Registreert verbruikte uren. Bewaakt de gemaakte uren wat betreft Produktie

FMS

Engineering Meldt nieuwe IT-item aan bij de SLM

Projecten Meldt nieuwe IT-ilem aan bij de SLM

Sluit uitwijkcontract. Onderhoud contact op taclisch niveau met de klanl i.g.v. uitwijk

Levert procedures en documentalie voor uitwijk

Levert procedures en documentatie voor uitwijk wanneer een project in produktie gaat

Spreekt beveiligingsniveau af. Onderhoud contact op tactisch niveau met de klanl i.g.v. beveiliging Levert informatie vanuit en naar de klant

Verantwoordelijk voor recovery. Ontwerpen beveiligingsslructuren en documenteert deze

Ontwerpen beveiligingsstructuren en documenteert deze

Levert informatie vanuil en naar de klant Regislreert verbruikte

Regislreert verbruikte

uren

uren

Regislreert verbruikle uren

Verantwoordelijk voor de koslen

Veranlwoordelijk voor oplossingen op langere termijn. Levert kennis, bedenkt optossingen Verantwoordelijk voor oplossingen op Jangere termijn. Levert kennis, bedenkt oplossingen Registreert verbruikte uren. Bewaakt de gemaakte uren wat betreft Eng

Registreert verbruikte uren. Bewaakt de gemaakte uren (projectleider)

Tabel 1 Takenoverzicht betreffende beheerprocessen binnen MV.

GeEI, Amsterdam

166



Bijlage 4: Service Level Rapportages voor Civility-diensten volgens ITIL-structuur. Legenda: ITIL-processen:

Beschikbaarheidsbeheer Capaciteitsbeheer Helpdesk Probleembeheer Wijzigingsbeheer Configuratiebeheer Beveiligingsbeheer Calamiteitenplanning Onderhoudsbeheer Documentatie

Bronnen:

Service Level Aggreement (SLA) Service Level Manager (SLM) NetView (NV) CiscoWorks (CW) Frontier (F) Systems Management Server (SMS) ConfigurationManagement DataBase (CMDB) ProHelpDesk (PHD)

Rapportageperiode:

Dagelijks (D) Wekelijks (W) Twee Wekelijks (2W) Vier Wekelijks (4W) Maandelijks (M) Kwartaal (K) Halfjaarlijks (H) Jaarlijks (J) Incidenteel (1)

Diensten:

GDA Bestemmingen: NUS GISP WVG Stadspas NFS BWV Civility-LAN Werkplekfaciliteiten Civility-LAN Kantoorautomatisering

GCEI, Amsterdam

167

Klant (K) Opdrachtgever (0) Facility Management Services (FMS) Service Level Manager (SLM)



Dienst: Gemeenschappelijke Datacommunicatie infrastructuur gemeente Amsterdam (GDA) ITIL Proces Beschikbaarheid

Capaciteit

Helpdesk

Probleembeheer Wijzigingsbeheer Configuratie

Beveiliging Calamiteiten Onderhoud Documentatie GCEI, Amsterdam

Item

Norm

Bron

Bestemming

Rapp.Periode

Openstellingstijden (norm I, daarbuiten norm II) Netwerk als geheel GDA aansluiting Koppeling met extern netwerk 3270 Gateway Email Overige Opties Afgenomen capaciteit (maximum -, gemiddeld -) Gebruik Bandwidth On Demand Verkeer per protocol Gebruikers (maximum en gemiddeld aantal gelijktijdige -) performance (reactietijden, vertragingstijden) Openstellingstijden Bereikbaarheid Gemelde incidenten Genormaliseerde incidenten (# incidenten I # gebruikers) Reactietijd (vanaf aanmelden tot starten met oplossen) Oplossingstijd (tijd nodig om tekortkoming te verhelpen) Afhandelingstijd (=MTTR: reactie- + oplossingstijd) Problemen met status en omschrijvinglopmerking Gebruik Back-up Aangevraagde wijzigingen Voortgang wijzigingen Afgenomen diensten Componenten met instellingen Programmatuur Aantal aansluitingen Authorisatie (overschrijdingen) Uitwijk (oorzaak) Planning (gebruik maintenance window) Laatste versies

ma-vrij van 7.00-22.00; za van 7.00-17.00 I: 98% II: 95% MTBF: 200 uur I: 99,5% II: 99% MTBF: 4000 uur I: 99% II: 98% MTBF: 2000 uur I: 99% II: 95% I: 99% II: 95% MTBF: 1000 uur

SLA/SLM NV NV NV NV NV NV NV/CW NV NV/CW NV

KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlO/FMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlO/FMS/SLM KlOIFMS/SLM KlO/FMS/SLM KlO/FMS/SLM KlO/FMS/SLM KlOIFMS/SLM

M/J M/J M/J M/J M/J MlJ

CIR, afhankelijk van basis aansluiting

zie SLA ma-za van 7.30-17.00

SLA/SLM

PHD PHD Afhankelijk van prioriteit, zie SLA PHD Afhankelijk van prioriteit, zie SLA PHD Afhankelijk van prioriteit, zie SLA PHD PHD/SLM NV PHD/SLM PHD/SLM type basisaansluiting met eventueel opties CMDB/SLM CMDB/SLM CMDB/SLM CMDB/SLM zie SLA en DAP SLM SLM di. 18.00-20.00 en van za.17.00 - ma.7.00 SLM SLM 168

M/J M/J M/J J M J

M/J Mil M/J M/J M/J M/J M/J I I M I I I I I I I



Dienst: Nieuw Uitkeringen Systeem (NUS) ITIL Proces Beschikbaarheid

Capaciteit

Helpdesk

Item

Norm

Bron

Bestemming

Rapp.Periode

Openstellingstijden van het on-line systeem Gerealiseerde beschikbaarheid (procentueel)

ma/wo/do/vr 7.00-19.00; di 7.00-17.30 90%/week; 93%/maand; 95%/kwartaal en 97%/jaar

SLA.lSLM NVIPHD

KJO/FMS/SLM KJOIFMS/SLM

M/J W/M/J

NV/PHD

NV NV NV NV

KJO/FMS/SLM KJOIFMS/SLM KJO/FMS/SLM KJOIFMS/SLM KJOIFMS/SLM KJOIFMS/SLM

Mil M/J M/J M/J MlJ J

SLA/SLM PHD PHD PHD

KJO/FMS/SLM KJO/FMS/SLM KJO/FMS/SLM KJO/FMS/SLM

Mil M/J MlJ M/J

PHD PHD PHD/SLM PHD/SLM PHD/SLM CMDB/SLM CMDB/SLM CMDB/SLM SLM

KJOIFMS/SLM KJO/FMS/SLM KJOIFMS/SLM KJO/FMS/SLM KJOIFMS/SLM KJOIFMS/SLM KJOIFMS/SLM KJO/FMS/SLM KJO/FMS/SLM

I I I I I I

SLM SLM

KJOIFMS/SLM KJOIFMS/SLM

I I

Gerealiseerde beschikbaarheid (MTBF, MTTR) Aantal transacties Volume databank CPU belasting Gebruikers (maximum en gemiddeld aantal gelijktijdige -) performance (verwerkingstijd) Openstellingstijden Gemelde incidenten Genormaliseerde incidenten (# incidenten I # gebruikers) Reactietijd (vanaf aanmelden tot starten met oplossen)

Beveiliging Calamiteiten

Oplossingstijd (tijd nodig om tekortkoming te verhelpen) Afhandelingstijd (=MTTR: reactie- + oplossingstijd) Problemen met status en omschrijving/opmerking Aangevraagde wijzigingen Voortgang wijzigingen Programmatuur Componenten met instellingen Authorisatie (overschrijdingen) Uitwijk enlofback-up (oorzaak en gevolg)

Onderhoud Documentatie

Planning (gebruik maintenance window) Laatste versies


GCEI, Amsterdam

95% van de on-line transacties binnen 3 sec. ma-vrij van 8.30 tot 17.30 uur

< 30 minuten na melding bij de Helpdesk voor storingen op werkplek, 15 min. voor overige storingen.

Gegevensverlies van maximaal van een dag

169

Mil M/J

M/J



Dienst: Gemeentelijk Informatiesysteem Salaris en Personeel (GISP) ITIL Proces Beschikbaarheid

Capaciteit

Helpdesk

Probleembeheer Wijzigingsbeheer

Configuratie Beveiliging Calamiteiten Onderhoud Documentatie

GCEI, Amsterdam

Item

Norm

Bron

Bestemming

Openstellingstijden van het on-line systeem Gerealiseerde beschikbaarheid (procentueel) Gerealiseerde beschikbaarheid (MTBF, MTTR) Aantal transacties Volume databank CPU belasting Gebruikers (maximum en gemiddeld aantal gelijktijdige -) performance (reactietijden, vertragingstijden)

rna. - vr. van 7.30-17.30 uur 95% (v.d. openstellingstijd) op jaar basis

SLA/SLM NV/PHD NV/PHD NV NV NV NV

K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM KlOIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM

Openstellingstijden Gemelde incidenten Genormaliseerde incidenten (# incidenten I # gebruikers) Reactietijd (vanaf aanmelden tot starten met oplossen) Oplossingstijd (tijd nodig om tekortkoming te verhelpen) Afhandelingstijd (=MTTR: reactie- + oplossingstijd) Problemen met status en omschrijving/opmerking Aangevraagde wijzigingen Voortgang wijzigingen Programmatuur Componenten met insteIIingen Authorisatie (overschrijdingen) Uitwijk en/ofback-up (oorzaak en gevolg) Planning (gebruik maintenance window) Laatste versies

95% van de on-line transacties binnen 3 sec. ma-vrij van 8.00 tot 17.00 uur

minder dan een half uur

binnen een maand (bij aanvraag door gebruiker)

Handboek Informatiebeveiliging A'dam Calamiteitenplan

170

Rapp.Periode Mil Mil Mil Mil Mil Mil Mil

J

SLA/SLM PHD PHD PHD PHD PHD PHO/SLM PHO/SLM

K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM

Mil Mil Mil Mil Mil Mil Mil I

PHD/SLM CMDB/SLM CMDB/SLM SLM SLM SLM SLM

K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM KlOIFMS/SLM

I I I I I I I



Dienst: Wet Voorzieningen Gehandicapten (WVG) ITIL Proces Beschikbaarheid

Capaciteit

Helpdesk


Beveiliging Calamiteiten Onderhoud Documentatie

GCEI, Amsterdam

Item

Norm

Bron

Bestemming

Openstellingstijden van het on-line systeem

ma-vrij van 8.00-18.00 op do. tot 21.00 uur op zat. Van 9.00 tot 12.00 uur.

SLA/SLM

K/OIFMS/SLM

Rapp.Periode MlJ

NVIPHD NVIPHD NV NV NV NV

K/O/FMS/SLM K/O/FMS/SLM K/OIFMS/SLM K/O/FMS/SLM K/O/FMS/SLM K/O/FMS/SLM K/OIFMS/SLM

MlJ M/J M/J MlJ M/J M/J J

SLA/SLM PHD PHD PHD PHD PHD PHD/SLM PHD/SLM PHD/SLM CMDB/SLM CMDB/SLM CMDB/SLM SLM SLM SLM SLM

K/O/FMS/SLM K/O/FMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/O/FMS/SLM K/O/FMS/SLM K/O/FMS/SLM K/O/FMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/O/FMS/SLM K/O/FMS/SLM KlOIFMS/SLM K/OIFMS/SLM

M/J MIJ MlJ MlJ MlJ M/J M/J I I M I I I I I I

Gerealiseerde beschikbaarheid (procentueel) Gerealiseerde beschikbaarheid (MTBF, MTTR) opties (centrale print faciliteit) Schijfruimte CPU belasting Gebruikers (maximum en gemiddeld aantal gelijktijdige -) performance (reactietijden, vertragingstijden)

Openstellingstijden Gemelde incidenten Genormaliseerde incidenten (# incidenten I # gebruikers) Reactietijd (vanafaanmelden tot starten met oplossen) Oplossingstijd (tijd nodig am tekortkoming te verhelpen) Afhandelingstijd (=MTTR: reactie- + oplossingstijd) Problemen met status en omschrijvinglopmerking Aangevraagde wijzigingen Voortgang wijzigingen Afgenomen diensten Componenten met instellingen Programmatuur Authorisatie (overschrijdingen) Uitwijk enlofback-up (oorzaak en gevolg) Planning (gebruik maintenance window) Laatste versies

uitgedrukt in MTBF en MTTR uitgedrukt in MTBF en MTTR min. xx Mb vrij max. xx % of xxxx seconden 95% van niet DIS on-line transact. < 4.5 sec. 95% van DIS on-line transact. < 20 sec. ma-vrij van 8.00-17.00 uur

minder dan een halfuur

binnen twee dagen (geen DIS);

171



Dienst: Stadspas ITIL Proces Beschikbaarheid

Capaciteit

Helpdesk

Item

Norm

Bron

Bestemming

Openstellingstijden van het on-line systeem Gerealiseerde beschikbaarheid (procentueel) Gerealiseerde beschikbaarheid (MTBF, MTTR) Schijfruimte CPU belasting Gebruikers (maximum en gemiddeld aantal gelijktijdige -) performance (reactietijden, vertragingstijden)

ma-vrij van 8.00-18.00

SLA/SLM NV/PHD NV/PHD NV NV NV

K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM

Rapp.Periode Mil Mil Mil Mil Mil Mil I

SLA/SLM PHD PHD PHD PHD PHD PHD/SLM PHD/SLM PHD/SLM CMDB/SLM CMDB/SLM CMDB/SLM SLM SLM

K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM

Mil Mil Mil Mil Mil Mil Mil 1 I M I I I I

SLM SLM

K/OIFMS/SLM K/OIFMS/SLM

I I


Openstellingstijden Gemelde incidenten Genormaliseerde incidenten (# incidenten 1# gebruikers) Reactietijd (vanaf aanmelden tot starten met oplossen) Oplossingstijd (tijd nodig om tekortkoming te verhelpen) Athandelingstijd (=MTTR: reactie- + oplossingstijd) Problemen met status en omschrijving/opmerking Aangevraagde wijzigingen Voortgang wijzigingen Afgenomen diensten Componenten met instellingen Programmatuur Authorisatie (overschrijdingen) Uitwijk eniofback-up (oorzaak en gevolg)




GCEI, Amsterdam

uitgedrukt in MTBF en MTTR min. xx Mb vrij max. xx % of xxxx seconden enkelvoudige transac. binnen 3 sec. verwerkt ma-vrij van 8.00-17.00

minder dan een half uur in de regel minder binnen 24 uur

Uitwijk binnen 2 dagen; maximaal gegevensverlies van een dag

172



Dienst: Nieuw Financieel Systeem (NFS) ITiL Proces Beschikbaarheid

Capaciteit

Helpdesk



GCEI, Amsterdam

Item

Norm

Bron

Bestemming

Rapp.Periode

Openstellingstijden van het on-line systeem Gerealiseerde beschikbaarheid (procentueel) Gerealiseerde beschikbaarheid (MTBF, MTTR) Schijfruimte CPU belasting Gebruikers (maximum en gemiddeld aantal gelijktijdige -) performance (reactietijden, vertragingstijden)

ma-vrij van 8.00-18.00

SLA/SLM NYIPHD NYIPHD NY NY NY

KJO/FMS/SLM KJOIFMS/SLM KJO/FMS/SLM KJO/FMS/SLM KJO/FMS/SLM KJOIFMS/SLM KJOIFMS/SLM

Mil Mil Mil Mil M/J M/J J

SLM/SLM PHD PHD PHD PHD PHD PHD/SLM PHD/SLM PHD/SLM CMDB/SLM CMDB/SLM

KJOIFMS/SLM KJOIFMS/SLM KJOIFMS/SLM KJO/FMS/SLM KJO/FMS/SLM KJO/FMS/SLM KJOIFMS/SLM KJO/FMS/SLM KJO/FMS/SLM KJO/FMS/SLM

Mil Mil M/J Mil M/J M/J Mil

CMDB/SLM

KJOIFMS/SLM KJO/FMS/SLM KJOIFMS/SLM KJOIFMS/SLM KJOIFMS/SLM

Openstellingstijden Gemelde incidenten Genormaliseerde incidenten (# incidenten I # gebruikers) Reactietijd (vanaf aanmelden tot starten met oplossen) Oplossingstijd (tijd nodig om tekortkoming te verhelpen) Afhandelingstijd (=MTTR: reactie- + oplossingstijd) Problemen met status en omschrijvinglopmerking Aangevraagde wijzigingen Yoortgang wijzigingen Afgenomen diensten Componenten met instellingen Programmatuur Authorisatie (overschrijdingen) Uitwijk eniofback-up (oorzaak en gevolg) Planning (gebruik maintenance window) Laatste versies

uitgedrukt in MTBF en MTTR min. xx Mb vrij max. xx % of xxxx seconden maximaal20 95% van de on-line transacties binnen 3 sec. ma-vrij van 8.00-17.00

minder dan een halfuur

maximale verlies van data is een dag

173

SLM SLM SLM SLM

KJOIFMS/SLM

I I M I I I I I I



Dienst: Basis Woonruimte Verdeling (BWV) voor de Stedelijke Woning Dienst (SWD) ITIL Proces Beschikbaarheid

Item

Norm

Bron

Bestemming

Rapp.Periode

Openstellingstijden van het on-line systeem

ma-vrij van 8.00-18.00 op do. tot 20.00 uur

SLA/SLM

K/O/FMS/SLM

M/J

NV/PHD NV/PHD

M/J M/J M/J MlJ M/J

SLM SLM

K/O/FMS/SLM K/O/FMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/OIFMS/SLM K/O/FMS/SLM K/O/FMS/SLM K/O/FMS/SLM K/OIFMS/SLM K/O/FMS/SLM K/O/FMS/SLM K/OIFMS/SLM K/O/FMS/SLM K/OIFMS/SLM K/O/FMS/SLM K/O/FMS/SLM K/O/FMS/SLM K/OIFMS/SLM

SLM SLM

K/O/FMS/SLM K/O/FMS/SLM


Gerealiseerde beschikbaarheid (procentueel) Gerealiseerde beschikbaarheid (MTBF, MTTR) Schijfruimte CPU belasting Gebruikers (maximum en gemiddeld aantal gelijktijdige -) performance (reactietijden, vertragingstijden) Openstellingstijden Gemelde incidenten Genormaliseerde incidenten (# incidenten I # gebruikers) Reactietijd (vanaf aanmelden tot starten met oplossen) Oplossingstijd (tijd nodig om tekortkoming te verhelpen) Athandelingstijd (=MTTR: reactie- + oplossingstijd) Problemen met status en omschrijving/opmerking Aangevraagde wijzigingen Voortgang wijzigingen Afgenomen diensten Componenten met instellingen Programmatuur Authorisatie (overschrijdingen) Uitwijk en/of back-up (oorzaak en gevolg)



Capaciteit

Helpdesk


GCEI, Amsterdam

NV NV NV ma-vrij van 7.30-17.00

minder dan een half uur

SLA/SLM PHD PHD PHD PHD PHD PHD/SLM

PHD/SLM PHD/SLM CMDB/SLM CMDB/SLM CMDB/SLM Uitwijk binnen 48 uur; maximaal gegevensverlies van een dag

174

J

M/J M/J M/J M/J MlJ M/J M/J I I M I I I I I I



Dienst: Werkplekfaciliteiten, Civility Local Area Network (Civility-LAN) ITIL Proces Beschikbaarheid

Item

Norm

Bron

Bestemming

Rapp.Periode

Openstellingstijden Kantoorautomatisering

werkdagen van 8:00 tot 18:00 uur; en op zon- en feestdagen van 10:00 tot 17:00. gemiddelde downtime: < 1 uur per werkplek per maand (~99,66%) MTBF: ?? MTfR: ??

SLNSLM

K/O/FMS/SLM

Mil

NV/SMSIPH

K/O/FMS/SLM

Mil

K/O/FMS/SLM

Mil

K/O/FMS/SLM K/O/FMS/SLM K/OIFMS/SLM K/O/FMS/SLM K/O/FMS/SLM

M/J M/J M/J M/J

Gerealiseerde beschikbaarheid (procentueel) Gerealiseerde beschikbaarheid (MTBF, MTTR) Capaciteit

Helpdesk


Schijfruimte CPU belasting Netwerk belasting Gebruikers (maximum en gemiddeld aantal gelijktijdige -) performance (reactietijden, vertragingstijden) Openstellingstijden Gemelde incidenten Genormaliseerde incidenten (# incidenten I # gebruikers) Reactietijd (vanaf aanmelden tot starten met oplossen) Oplossingstijd (tijd nodig om tekortkoming te verhelpen) Afhandelingstijd (=MTTR: reactie- + oplossingstijd) Problemen met status en omschrijving/opmerking Aangevraagde wijzigingen (type) Voortgang wijzigingen (status, doorlooptijd) Afgenomen diensten

D NV/SMS/PH D NV/SMS

NV/SMS maximaal 250 (huidig aantal gebruikers?)

maximaal 100 vragen

minder dan 1 uur maximaal ?? vervangen werkplekken/jr. maximaal ?? nieuwe werkplekkenljr.

NV/SMS NV/SMS SLA/SLM PHD PHD PHD PHD PHD PHD/SLM PHD/SLM PHD/SLM

CMDB/SMSI

K/O/FMS/SLM K/OIFMS/SLM

K/O/FMS/SLM K/OIFMS/SLM

K/O/FMS/SLM

J

M/J Mil Mil M/J M/J

K/O/FMS/SLM

MlJ

K/O/FMS/SLM

M/J

K/OIFMS/SLM

I I M

K/O/FMS/SLM K/O/FMS/SLM

SLM

CMDB/SMSI K/O/FMS/SLM

Componenten met instellingen


Programmatuur Ontwikkeling Authorisatie (overschrijdingen) Uitwijk en/ofback-up (oorzaak en gevolg)



GCEI, Amsterdam

SLM CMDB overzicht ontwikkelingen Vervangende werkplek binnen 1 uur na verstrijken max. afhandelingstijd

SLM SLM SLM SLM

175

K/O/FMS/SLM K/O/FMS/SLM K/OIFMS/SLM

I

K/O/FMS/SLM

I J I I

K/OIFMS/SLM K/OIFMS/SLM

I I



Dienst: Kantoorautomatisering, Civility Local Area Network (Civility-LAN) ITIL Proces Beschikbaarheid

Item

Norm

Bron

Bestemming

Rapp.Periode

Openstellingstijden Kantoorautomatisering Gerealiseerde beschikbaarheid (procentueel)

werkdagen van 8:00 tot 18:00 uur; 100%

SLA/SLM

NV/SMS/PH

KlOIFMS/SLM KlOIFMS/SLM

M/J M/J

Gerealiseerde beschikbaarheid (MTBF, MTTR)

MTBF: ?? MTTR: ??

NV/SMS/PH

KlOIFMS/SLM

M/J

KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM

M/J M/J M/J M/J J MlJ M/J M/J M/J MlJ Mil

KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM KlOIFMS/SLM

M/J M/J I I M I

D D Capaciteit

Helpdesk

Schijfruimte CPU belasting Netwerk belasting Gebruikers (maximum en gemiddeld aantal gelijktijdige -) performance (reactietijden, vertragingstijden) Openstellingstijden Gemelde incidenten Genormaliseerde incidenten (# incidenten I # gebruikers) Reactietijd (vanafaanmelden tot starten met oplossen) Oplossingstijd (tijd nodig om tekortkoming te verhelpen) Afhandelingstijd (=MTTR: reactie- + oplossingstijd)

NV/SMS NV/SMS NV/SMS maximaal 250 (huidig aantal gebruikers?) NV/SMS zie SLA maximaal 100 vragen

50% van de storingen binnen 1 uur, 80%

SLA/SLM PHD PHD PHD PHD PHD

< 4 uur en 100% < 8 uur. Probleembeheer Wijzigingsbeheer Configuratie


GCEI, Amsterdam

Problemen met status en omschrijving/opmerking Aangevraagde wijzigingen Voortgang wijzigingen Afgenomen diensten Componenten met instellingen Programmatuur Ontwikkeling Authorisatie (overschrijdingen) Uitwijk en/of back-up (oorzaak en gevolg) Planning (gebruik maintenance window) Laatste versies

PHD/SLM PHD/SLM PHD.lSLM

CMDB/SMS CMDB CMDB overzicht ontwikkelingen SLM SLM SLM SLM

176

J I I I I



Bijlage 5: Begrippen en Definities 3270 Gateway Met de optie Remote terminal access 3270 biedt de GDA aansluiting de mogelijkheid tot communicatie op basis van het IBM 3270 protocol tussen PC's in het aangesloten LAN en het IBM mainframe van Civility (SNA-host) wat eveneens gekoppeld is via de GDA. Aansluiting De aansluiting van een Deelnemer op de GDA zodat deze gebruik kan maken van GDAdiensten en Diensten (applicaties). Afgenomen capaciteit De bruto afgenomen capaciteit aan het GDA koppelpunt. Athandelingstijd De maximale tijd, die gelegen is tussen het moment dat een aanvraag bjj de Service Desk wordt geregistreerd en het moment dat de aanvraag is uitgevoerd en door de uitvoerder is afgemeld bij de Service Desk. Back-up verbinding De optie back-up betreft een configuratie waarbij een ISDN verbinding wordt opgezet wanneer de vaste verbinding uitvalt. Basisnetwerk Het basisnetwerk voorziet in de infrastructuur van een transport-netwerk waaraan de deelnemers middels de gedefinieerde GDA aansluit-typen gekoppeld kunnen worden. Daarnaast zijn binnen het basisnetwerk de centrale faciliteiten van de GDA ondergebracht. Beschikbaar Een faciliteit is beschikbaar indien deze volledig voldoet aan de specificaties zoals beschreven inhet SLA. Beschikbaarheid De beschikbaarheid is de mate waarin een (GDA-)dienst in staat is te voldoen aan de specificaties beschreven in het SLA op een bepaald ogenblik ofvoor een bepaalde tijdsduur. Betrouwbaarheid Betrouwbaarheid is de mate waarin een (GDA-)dienst in staat specificaties beschreven in het SLA voor een aangegeven tijdsduur.

IS

te voldoen aan de

Bandwidth On Demand gebruik 1. de optie BOD1 betreft een configuratie waarbij een ISDN verbinding als extra wordt opgezet wanneer de vaste verbinding meer dan een bepaald percentage wordt belast. 2. de optie BOD2 betreft een configuratie waarbij een ISDN verbinding wordt opgezet wanneer een specifieke sessie wordt ge'initieerd. 3. de optie BOD3 betreft een configuratie met twee vaste verbindingen die elk een vooraf bepaald deel van het netwerkverkeer op zich nemen. Beide vaste verbindingen wordt voorzien van back-up over ISDN. GeEI, Amsterdam

177


Calamiteit Fysieke gebeurtenis of situatie die onbeYnvloedbaar direct of indirect voor een bepaalde tijdsperiode aanleiding is tot een gehele of gedeeltelijke stagnatie van de dienstverlening. Bijvoorbeeld: brand, molest (terroristische aanslagen gewapend conflict, burgeroorlog, opstand, binnenlandse onlusten), aardbevingen, atoomkernreacties, overstromingen, enzovoort. Centrale print faciliteiten Het remote printen op de Civility locatie. Committed Information Rate (CIR) De basisaansluiting biedt een gegarandeerde transportsnelheid voor de toegangslijn tot de GDA infrastructuur, die voor aansluitingen met een enkelvoudige lijn per seconde) betreffen de bruto hoeveelheden te transporteren data per tijdseenheid, inclusief de protocol overhead van de transport-protocollen en het management verkeer. CPU belasting Belasting van een processor in een percentage ten opzichte van het maximum. DAP Dossier Afspraken en Procedures waarin operationele afspraken tussen Deelnemer en Civility gedetailleerd zijn vastgelegd ter nadere uitwerking van een SLA. Databank De omvang van de database. Deelnemer De Deelnemers zijn de organisaties die gebruik maken van de GDA voor de uitwisseling van gegevens en het gebruik van (GDA-)Diensten en het aanbieden van Diensten. Dienst De voor Deelnemers via de GDA beschikbaar gestelde applicaties. Dienstenaanbieder Dienstenaanbieder is een Deelnemer die via de GDA applicatie(s) beschikbaar stelt voor gebruik door de overige Deelnemers. Email faciliteiten De centrale Email faciliteiten binnen de GDA zijn gerealiseerd met behulp van een GroupWise omgeving waarbinnen de volgende componenten onderscheiden kunnen worden: een centrale GroupWise server, een GroupWise asynchrone gateway, een GroupWise SMTP gateway en de inbel-lijnen/modems.

Met de GDA Email optie m .Email Transit' wordt de koppeling verstaan van een lokaal Email systeem met de centrale GDA Email omgeving. Via een dergelijke koppeling kan een gebruiker elektronische berichten versturen naar postbus-gebruikers binnen het Centrale Email systeem of naar gebruikers van andere via deze transit optie aangesloten Emailsystemen/organisaties. GeEI, Amsterdam

178


Escalatieniveau Geeft aan welk echelon bij de incident/probleemafhandeling is ingeschakeld. Eerste echelon is centrale Service Desk, tweede echelon is operationeel beheer, derde echelon betreft specialisten intern en/of leveranciers van componenten, vierde echelon betreft contractmanager Civility. Escalatietijd De tijd die verstrijken mag voordat een hoger echelon wordt ingeschakeld. Feestdag Nieuwjaarsdag, koninginnedag, paasdagen, Hemelvaartsdag, pinksterdagen, kerstdagen en door de Gemeente Amsterdam vastgestelde feestdagen. GDA aansluiting Met een standaard basis aansluiting wordt het (Ethernet-)LAN van de te koppelen gebruikersorganisatie gekoppeld aan de GDA, met een router die op die locatie van de gebruiker wordt geplaatst. GDA als geheel De beschikbaarheid van het GDA als geheel is een bewerking op de beschikbaarheid van de afzondedijke LAN koppelpunten en een aantal toegangen tot externe netwerken. GDA-diensten Het leveren van faciliteiten voor datacommunicatie via een Gemeenschappelijke Datacommunicatie infrastructuur ten behoeve van de Deelnemers, inclusief de daarvoor benodigde verbindingen en apparatuur. Gebruiker Persoon die met toestemming van Deelnemer gebruik maakt van de ter beschikking gestelde GDA-diensten en applicaties van een Dienstenaanbieder. Gebruikers-responstijd De responstijd is het totaal van de vertragingstijden, welke door de diverse in het LAN en WAN opgenomen netwerkcomponenten en de systeemverwerkingstijd(applicatie) worden gegenereerd. Met andere woorden de tijd die vedoopt tussen het aanslaan van het laatste invoerteken en de ontvangst van het laatste uitvoerteken op een werkstation. Het laatste invoerteken is meestal het indrukken van de entertoets. Gelijktijdige gebruikers Het aantal gebruikers dat op een bepaald ogenblik van de zelfde faciliteit gebruik maakt. GemNet Gemeenschappelijk Netwerk, ontwikkeld in opdracht van Bank Nederlandse Gemeenten en de Vereniging van Nederlandse Gemeenten. Sindsjanuari 1995 operationeel. Harddisk bezetting Ruimte bezet in Mb ten opzichte van de beschikbare ruimte in Mb. GeEI, Amsterdam

179


ITIL ITIL (Information Technology Infrastructure Library). Methodiek waarin kwaliteitsrichtlijnen gedefinieerd zijn voor het organiseren en inrichten van het beheer van automatiseringshulpmiddelen, waaronder netwerken. Jaar Eenjaar is gelijk aan 12 kalendermaanden niet zijnde een kalenderjaar. Kalendermaand De eerste dag van de maand tot en met de laatste dag van maand waarbij de dagen uit 24 uur bestaan. Kalenderjaar Een jaar dat loopt van 1 januari tot en met 31 december van een bepaald jaar. Kantooruren Maandag tot en met vrijdag van 08:00 uur tot 17:30 uur uitgezonderd feestdagen. Koppeling externe netwerken De koppeling GDA/GemNet betreft het realiseren, implementeren en integreren van een GemNet aansluiting in de GDA, zodanig dat de faciliteiten van die GemNet aansluiting ook beschikbaar gesteld kunnen worden aan gebruikers van het GDA.

Beveiligde koppeling tussen het GDA netwerk en het Internet. Deze koppeling wordt beveiligd door een Firewall systeem. Bestaande uit twee routers en een bastion-host. De gebruikers van de GDA dienen zo maximaal mogelijk gebruik te kunnen maken van allerlei Internet diensten. Maintenance Window Het tijdvenster waarin het gepland uitvoeren van onderhoud mogelijk is. MTBF Mean Time Between Failure: de (gemiddelde) tijd tussen de meldingen van twee opeenvolgende tekortkomingen. MTTF Mean Time To Failure: de (gemiddelde) tijd tussen het opheffen van een tekortkoming en de melding van de volgende tekortkoming. MTTR Mean Time To Repair: de (gemiddelde) tijd tussen het melden van een tekortkoming en het opheffen van een tekortkoming. (MTTR = MTBF - MTTF). Onderhoud Adaptiefonderhoud Het aanpassen van componenten van het netwerk omdat de omgeving van die componenten gewijzigd is. Adaptief onderhoud kan o.a. worden veroorzaakt door Onderhoud aan een GeEI, Amsterdam

180


andere component van het netwerk of door gewijzigde regelgeving voor het bedrijfsproces dat wordt ondersteund. Functioneel onderhoud Het uitbreiden of wijzigen van de functionaliteit door nieuwe wensen. Correctiefonderhoud Het corrigeren van fouten in componenten van het netwerk. Er is sprake van een fout wanneer de feitelijke netwerk-dienstverlening afwijkt van de specificatie ervan. Perftctiefonderhoud Het verbeteren van prestaties van het netwerk. Wanneer de omvang of het belang van het netwerk toenemen is vaak perfectief Onderhoud nodig om het prestatieniveau van het netwerk te verhogen. Bij perfectief Onderhoud worden de vastgelegde eisen verder opgeschroefd. Preventiefonderhoud Het systematisch opzoeken en corrigeren van fouten of vervangen of bijstellen van apparatuuronderdelen voordat deze zichtbaar worden in de vorm van tekortkomingen.

On-line applicatiesysteem Onder een on-line applicatiesysteem wordt verstaan de koppeling met het GDA, de opgestelde centrale applicatiehardware en de benodigde centrale applicatiesoftware met eventuele databanken. Oplossingstijd De tijd die nodig is om een tekortkoming te verhelpen. Overeenkomst GDA-diensten Een contract afgesloten tussen Deelnemer en Civility, waarin o.a. opgenomen de te leveren GDA-diensten, de locatie waar de aansluiting is opgesteld, de kosten en de facturering van de dienstverlening en de duur van de overeenkomst. Rapportage-periode Periode waarover door Civility wordt gerapporteerd over de dienstverlening. Deze is voor de in de Service Level Agreement beschreven dienstverlening gelijk gesteld aan een kalendermaand. Reactietijd De tijd, binnen de openingstijd van de Service Desk, die gelegen is tussen het moment dat een probleem wordt voorgelegd en het moment dat een oplossingstraject (of een eerste indicatie over de voortgang hiervan) van het probleem wordt gestart. Responstijd Zie Gebruikers-responstijd. Service Level Agreement Het document waarin de Service Levels (kwaliteitseisen) voor de (GDA-)diensten zijn beschreven en waarin de specifieke afspraken over de door Civility uit te voeren beheer- en service-werkzaamheden zijn vastgelegd. Service Window Het tijdvenster waarbinnen de Service Desk beschikbaar is. GCEI, Amsterdam

181


Tekortkoming Het niet volledig voldoen van een GDA-dienst aan de specificaties beschreven in het Uitgangsmateriaal en of in het SLA op een bepaald ogenblik ofvoor een bepaalde tijdsduur. Transactie Het op een on-line applicatie aangeboden transactie welke verwerkt dient te worden. Urgentiecode Indicatie van de ernst van het probleem, gewogen op aspecten als niet actieve/beschikbare aantallen sessies. Vaste openstellingstijd De tijdsperiode waarin de (GDA-)diensten bewaakt beschikbaar zijn. Verkeer per protocol De belasting van een toegangslijn tot de GDA infrastructuur wordt periodiek (per protocol) gemeten. De gemeten protocollen zijn: IP, Novell IPX en DECnet. De bezetting wordt aangegeven in procenten van de CIR waarde. Versie Een gewijzigde en/of verbeterde uitvoering van programmatuur, systeemprogrammatuur of hardware. Vertragingstijd De tijd die nodig is om gegevens tussen twee aansluitingen van de GDA heen en terug (round trip delay) te transporteren. Verwerkingstijd De benodigde tijd voor het verwerken van een transactie op een on-line applicatiesysteem. Wijziging Het vervangen of toevoegen van documenten, programmatuur, systeem-sofiware of apparatuur.

GeEI, Amsterdam

182

Het verbeteren van IT-beheer met behulp van ITlL, implementatie van een Service Level Rapportage systeem.

Bijlage 6: Beheerobjecten Omschrijving

Type / Naamgeving

Domain Name Servers

PC met linux

Componenten

Aantal Rapportage (performance)

Central Processor Unit Hard Disk Servers

Applicatie (RS/6000) Central Processor Unit Hard Disk

Knooppunt Routers

Cisco AGS+ Seriele interface BRI interface (ISDN) Ethernet interface Token ring interface

Knooppunt Routers

Cisco 4000 Seriele interface BRI interface (ISDN) Ethernet interface Token ring interface

Knooppunt Routers

Cisco 25xx Seriele interface BRI interface (ISDN) Ethernet interface Token ring interface

Klant Routers

Cisco 25xx Seriele interface BRI interface (ISDN) Ethernet interface Token ring interface

GemNet Router Gateways Firewall Verbindingen

GCEl, Amsterdam

Cisco 25xx ??? (SNA, Mail, Mainframe) Vaste lijnen ISDN lijnen

Back up

183

2 2 4 ±30 ±40 ±60 3 ±40

±6 ±2 4

±48 4

± 17 ±24 ill ± 17

62+NUS 62+NUS ± 55 ±7 I 3 I 62+NUS

beschikbaarheid belasting (vrije) ruimte beschikbaarheid belasting (vrije) ruimte, gebruikersgedrag beschikbaarheid verkeer gebruik (back-up, BOD) beschikbaarheid beschikbaarheid beschikbaarheid verkeer gebruik (back-up, BOD) beschikbaarheid beschikbaarheid beschikbaarheid verkeer gebruik (back-up, BOD) beschikbaarheid beschikbaarheid beschikbaarheid verkeer gebruik (back-up, BOD) beschikbaarheid beschikbaarheid beschikbaarheid, verkeer beschikbaarheid, verkeer beschikbaarheid beschikbaarheid beschikbaarheid, gebruik (back-up, BOD)



ISDN lijnen EthemetLAN Token-ring LAN Hubs Databases Software Werkplekken (Civility-LAN) Civility-LAN Servers TOTAAL

BOD (load balancing) 9 4

GDA prod en test en Civility-LAN (Civility-LAN)

-

beschikbaarheid, verkeer beschikbaarheid, verkeer beschikbaarheid beschikbaarheid, omvang, gebruikersgedrag beschikbaarheid, gebruikersgedrag aantal

±700

HD=Hard Disk; CPU= Central Processor Unit;

Naamgeving: zoals vastgelegd in de documentatie van GDA, NUS, GISP, etc.

GCEI, Amsterdam

184



Bijlage 7: Gegevensverzameling Beheer objecten

Benodigde gegevens

Bronnen voor management gegevens

Benader wijze van de bronnen

Output vorm

Routers

Beschikbaarheid Gebruikte capaciteit Verkeer per protocol Beschikbaarheid Gebruikte capaciteit Verkeer per protocol Beschikbaarheid Gebruik (BOD of Back-up) Beschikbaarheid Gebruikte capaciteit Beschikbaarheid Beschikbaarheid Beschikbaarheid Beschikbaarheid Beschikbaarheid Beschikbaarheid Beschikbaarheid Beschikbaarheid Beschikbaarheid Gebruik Beschikbaarheid Belasting Belasting Bezetting

RMON probe database RMON probe database RMON probe database router (seriele interface) router (seriele interface) router (seriele interface) router (BRI interface) router (BRI interface) SNMP SNMP SNMP SNMP SNMP SNMP SNMP SNMP SNMP SNMP SNMP SNMP SNMP SNMP SNMP SNMP

pollen (performance indicatie: pingen) pollen pollen zie router zie router zie router zie router zie router

tekstfile tekstfile tekstfile tekstfile tekstfile tekstfile tekstfile tekstfile tekstfile tekstfile tekstfile tekstfile tekstfile tekstfile tekstfile tekstfile tekstfile tekstfile tekstfile tekstfile tekstfile tekstfile tekstfile tekstfile

Vulgraad Vulgraad Vulgraad Vulgraad

SNMP SNMP SNMP SNMP

Vaste verbindingen

ISDN Iijnen GDA Ethernet segment Token-ring Firewall Domain Name Server Relay host Mail server SNAgateway Cluster Controller Centrale printers RS6000 probes Inbelmodem CPU Harddisk

Oracle database DB2 database Ingres database Sybase database

GCEI, Amsterdam

pollen (performance indicatie: pingen) pollen (performance indicatie: pingen) pollen (performance indicatie: pingen) pollen (performance indicatie: pingen) pollen of deamon status (performance indicatie: pingen) pollen (performance indicatie: pingen) pollen (performance indicatie: pingen) pollen (performance indicatie: pingen) user logins by user (ulogins)/ users logged in (ulogintot) (TMEIO) pollen (performance indicatie: pingen) vmstat (Netview) iostat (Netview) percent space used (diskusedpct)/ space free (diskavail)/ space used (diskused) (TMEIO) kilobytes available in specified file system (wdiskspace) (TMElO) kilobytes available in specified file system (wdiskspace) (TMEIO) kilobytes available in specified file system (wdiskspace) (TME I0) kilobytes available in specified file system (wdiskspace) (TME 10)

185

tekstfile tekstfile tekstfile tekstfile



Bijlage 8: Rapport definities GDA Bestemming

Opleveringsvorm Rapportage items van bet rapport

Presentatie vorm v.d. items

SLM (aile klanten & opdrachtgever)

Intranet

(zie klanten & opdrachtgever)


FMS (aIle klanten

Intranet



Email / Papier

Beschikbaarheid LAN koppelpunten Netwerk als geheel

& opdrachtgever)

Opdrachtgever

van aIle gebruikers, cijfer (percentage) in tabel vaste openingstijd: cijfer (percentage), grafiek (vorige perioden & norm) en uitgedrukt in MTBF en MTTR. Overige tijden: cijfer (percentage), grafiek (vorige perioden & norm)

koppeling exteme netwerken 3270 Gateway Email postbus Email transit

Klant (Deelnemer)

Email / Papier

Capaciteit Afgenomen capaciteit Verkeer per protocol GebruikBOD Beschikbaarheid LAN koppelpunt

"

"

" " grafiek met gemiddelde en maximale waarde (per halfuur) gedurende de openingstijd. als percentage van het totaal, grafiek (vorige perioden) cijfer (aantal maal en gemiddelde tijdsduur), grafiek (vorige perioden)

vaste openingstijd: cijfer (percentage), grafiek (vorige perioden & norm) en uitgedrukt in MTBF en MTTR. Overige tijden: cijfer (percentage), grafiek (vorige perioden & norm)

koppeling exteme netwerken 3270 Gateway Email faciliteit

Capaciteit Afgenomen capaciteit Verkeer per protocol Gebruik BOD

GeEI, Amsterdam

" " " grafiek met gemiddelde en maximale waarde (per halfuur) gedurende de openingstijd. als percentage van het totaal, grafiek (vorige perioden) cijfer (aantal maal en gemiddelde tijdsduur), grafiek (vorige perioden)

187



GISP Bestemming

Opleveringsvorm Rapportage items van het rapport

SLM

Intranet

FMS

Intranet / papier


Beschikbaarheid

cijfer (percentage), grafiek (vorige perioden & norm) en uitgedrukt in MTBF en MTTR.

Bereikbaarheid

cijfer (percentage), grafiek (vorige perioden)

Volume databanken

Beschikbare geheugenruimte in Mb (diagram)

Beschikbaarheid

cijfer, grafiek (vorige perioden & norm) en uitgedrukt in MTBF en MTTR.

Bereikbaarheid


Volume databanken


NUS Bestemming



SLM

Intranet

Beschikbaarheid


Bereikbaarheid


Beschikbaarheid


Bereikbaarheid


Beschikbaarheid


Bereikbaarheid


Beschikbaarheid


Bereikbaarheid


FMS Opdrachtgever Klant

Intranet / papier Email / Papier Email / Papier

WVG Bestemming



SLM

Intranet

Beschikbaarheid


Bereikbaarheid


Volume databanken


CPU belasting

cijfer (als percentage v.h. totaal, in sec.), grafiek (vorige perioden)

GCEI, Amsterdam

188



FMS

Opdrachtgever

Intranet / Papier

Email / Papier

Beschikbaarheid


Bereikbaarheid


Volume databanken


CPU belasting

cijfer (aIs percentage v.h. totaal, in sec.), grafiek (vorige perioden)

Beschikbaarheid


Bereikbaarheid


Volume databanken


CPU belasting


NFS Bestemming


SLM

Intranet

FMS

Opdrachtgever

GCEI, Amsterdam

Intranet

Email / Papier


Beschikbaarheid


Bereikbaarheid


Volume databanken


CPU belasting

cijfer (als percentage v.h. totaal, in sec. ), grafiek (vorige perioden)

Beschikbaarheid


Bereikbaarheid


Volume databanken


CPU belasting


Beschikbaarheid


Bereikbaarheid


Volume databanken


CPU belasting


189



Stadspas Bestemming



SLM

Intranet

Beschikbaarheid


Bereikbaarheid


Volume databanken


CPU belasting


FMS

Opdrachtgever

Intranet

Email / Papier

Beschikbaarheid


Bereikbaarheid


Volume databanken


CPU belasting


Beschikbaarheid


Bereikbaarheid


Volume databanken


CPU belasting


BWV Bestemming



SLM

Intranet

Beschikbaarheid


Bereikbaarheid


Beschikbaarheid


Bereikbaarheid


Beschikbaarheid


Bereikbaarheid


FMS Opdrachtgever

GCEI, Amsterdam

Intranet / Papier Email / Papier

190



Bijlage 9: Rapportage tools Vendor

Product

Service-level metric

Ascend communications Inc. Alameda, calif. hUp://www.ascend.com BGSSyslems

Netclarity

Availability, reliability

Service-level monitoring

Scalability

Data export

Executive-level Price (console reports/ usage- application) based reports

SNMP MlB II, frame relay

Internal, external

5,000 devices

HP Openview

Yes/no

Internal

3,000 devices

Sunnet manager

No/no

S4,995 (HP Openview 4.1); S2,995 (Solaris); S995 (Windows NT) S24,5OO

MID; Bay and Cisco

Netsys Tools


Clear Slats Lite

Availability

extensions RMON I and II, SNMP MIBs I and II; Bay and Cisco extensions RMON I, SNMP MlBs I and II; frame relay MIB; Bay and Cisco extensions RMON I and SNMP MIB I

Ecoscope

Response time

Proprietary agent collection

Internal

N/A

Network Health


RMON I and II, SNMP MIBs I and II; frame relay MIB; proprietary probes;

Internal, external

2,500 devices

Bestview

Availability, response time

Waltham, Mass.

hup:/Iwww.bgs.com Cisco systems Inc. San Jose, Calif. hllp:/Iwww.cisco.com Clear Systems Inc. lIVing. Texas hup:/Iwww.c1earsyscom Compuware Corp. Farmington Hills, Mich. http://www.compuserve.com Concord CommunicatioRs Inc. Marlborough, Mass. hllp:/Iwww.concord.com

Data collection

Internal. external

1,000 devices

Ciscoworks

No/no

S80,OOO

Internal

200 devices

None

No/no

S900 (Windows NT); S2,995 (HP-UX and Sun Solaris)

third·party trouble ticketing applications and event correlation engines Optivity, Ciscoworks, Spectrum

No/no

S36,600

No/yes

$t5,OO, plus SIO,Ooo for Traffic Accountant and $250 per polled device

Bay, Cabletron. and Cisco extensions

Desktalk Systems In<.

TrendSNMP


Torrance, Calif.

hup:/Iwww.desklalk.
RMON I and II, SNMP MIBs I and II; frame relay MlB; Bay and Cis
3,000 devices

Internal, external

Crystal Reports, Excel,

Noino

S25,000

Nolno

SI,495

SQL

extensions

Hewlell-Pa
Netmetrix Reporter

Availability, reliability, response time

Netmetrix Division Colorado Springs, Colo.

RMON I and II, SNMP MIB I; proprietary

Internal

5,000 devices

HP Network Node manager

measureware database and operating system agents

hllp:/Iwww.hp.com Infovista Corp.

SLA Conformance

RMON I and II, SNMP MIBs I and II;

5,000 devices

SQL database

No/yes

S19,995

Management

Availability. reliability, response time

Internal, external

Redwood City, Cailf. hUp:/Iwww.infovista.com Jyra Researcb Inc. San Jose, Calif. hup:/Iwww.jyra.com ,,"spia Systems In<.

System Management

Response time

RMON, SNMP MIB I;

Internal, external

N/A

None

No/no

S6,500

Internal, external

5,000 devices

Netdirector, Frame Vision

No/no

S5.000, plus SIOO to $250 per polled device

Beaverton, Ore.

Architecture (SMA)

proprietary collection

Kaspia Network Monitoring System 1.1


Netscout Manager

Response time

RMONI and II

Internal, ex:ternal

5,000 devices

Crystal Reports

No/yes

$3,995 (Windows); S5,995 (Unix)

Service Level Manager


Internal

3,000 devices

None

No/no

S5,OOO

Routerpm 3.0

Availability

RMON I and II, SNMP MIBs I and II; Distributed Sniffer Systems SNMP MIBs I and II; frame relay MIB; Bay and

Internal. external

5,000 devices

Excd

No/no

S15,OOO, plus Sloo per polled device

Internal

N/A

None

No/no

S15.OO0

hUp:i/www.kaspia.com Netscout Systems Inc:.

RMON I, SNMP MIBs I and II; frame relay Mffi; Cisco ex.tensions

Chelmford, Mass. Hllp;/Iwww.frontier.com Network General Corp.

Menlo park, Calif. hup:/Iwww.ngc.com Network General Corp.

Cisco extensions

Optimal Networks Corp. Palo Alto, Calif. hUp://www,optimal.com

GeEI, Amsterdam

Application Expert

Response time

RMON I, proprietary collection, Shomiti

Surveyor, SMS, Novell LANanalyzer

191



Platinum Tec:hnology Inc. Oakbrook Terrace, III. http://www.platinum.com Solcom Sy.tem. Ine. Reston. Va. http://www.•olcom.co.uk Technically Elite San 10.e, Calif. http://www.tecelite.com Visual Networks Inc. Rockville, Md. http://www.visualnetworks.com

Network

monitoring

Wiretap

Response time

Proprietary agent collection

Internal

N/A

Platinum server Vision

No/no

$8,000

LANmaster

Response time

RMON I and II, SNMP MIBI

Internal

N/A

None

No/no

$6,500

Domainmeter 8000

Response time

RMON I and II, SNMP MIBI

Internal

N/A

None

No/no

$8,995

VisualOnramp


Internal, external

2,000 devices

Openvision

Yes/no

$2,100

Visual Uptime


SNMP MIB. I and II; frame relay MIB; proprietary probe SNMP MlBs I and II; frame relay MIB; proprietary probe/analyzers

Internal, external

2,000 devices

Openvision

Yes/no

$17,995

service packages

Ceatron DPL Co. Eden Prairie, Minn. http://www.centrondpl.com

On-Watch

Availability

RMON I and II, SNMP MIBs I and II

Internal. external

200 devices

None

No/no

from $85 per polled device'

International Network Services

Service Level Thresholder

Availability, reliability, response time

Internal, external

2,000 devices

None

Yes/no

Analysis Service

Availability

RMON I and II, SNMP MlBs I and II; frame relay MIB; Bay and Cisco extensions RMON I and II, SNMP MlBs I and II

Internal

1,500 devices

None

No/no

$2,500 per month for 25 polled devices; $10,000 per month for 1,500 polled devices· $55 per month per polled device·

Inc. Sunnyvale, Calif. http://www.ins.com Netops Corp. New Fairfield, Conn. hnp:l/www.operations.com

MIB = Management Information Base; N/A = Not Applicable; RMON = Remote Monitoring;

* = service packages are not priced according to console application.

Atkomstig uit: Data Communications, june 1997 (pagina: 84-91).

GCEI, Amsterdam

192


(standaard)

I

I

Paalbergweg 3, Postbus 12108, 1100 AC Amsterdam Z.O. Tel. 020-5902911 Fax 020-6976078

Rapportage

(ApplicatieNaam)

(PeriodeMaand PeriodeJaar)

(KlantNaam)

Naam service level manager Datum

GeEI Informatieplanning en Automatisering

Rapportage

(ApplicatieNaam)

(standaard)

Inhoudsopgave

1

Inleiding

2

Beschikbaarheidsbeheer

3

Capaciteitsbeheer

pagina nummer

Helpdesk

pagina nummer

Probleembeheer

pagina nummer

Wijzigingsbeheer

pagina nummer

Configuratiebeheer

pagina nummer

(eventueel)

Bij lage: Beveiligingsbeheer

pagina nummer

Bijlage: Calamiteitenplanning

pagina nummer

Bijlage: Onderhoudsbeheer

pagina nummer

Bijlage: Documentatie

pagina nummer


(productie datum)


Rapportage

(ApplicatieNaam)

(standaard)

Inleiding In dit document wordt gerapporteerd over de gerealiseerde service niveaus en de oorzaken van verschillen ten opzichte van de overeengekomen waarden. De definities, normen en meetmethoden van de rapportage items staan beschreven in het Service Level Agreement (SLA). De rapportage behandeld de kwaliteit van de dienstverlening over de periode (PeriodeMaand PeriodeJaar). De volgende kwaliteitsaspecten komen in deze rapportage aan bod Beschikbaarheidsbeheer, Capaciteitsbeheer, Helpdesk, Probleembeheer, Wijzigingsbeheer en Configuratiebeheer. In de bijlagen komen, mits relevant voor de boven genoemde periode, de volgende items aan bod Beveiligingsbeheer, Calamiteitenplanning, Onderhoudsbeheer en Documentatie. De rapportage betreft (AfgenomenDiensten).


de

afgenomen

(ApplicatieNaam)

2

diensten

met

opties

(productie datum)

GeEI Infonnatieplanning en Automatisering

(ApplicatieNaam)

Rapportage

(standaard)

Beschikbaarheidsbeheer In dit hoofdstuk wordt de beschikbaarheid van de (AfgenomenDiensten) beschouwd. Onder de (AfgenomenDiensten) wordt verstaan (DefinitieAfgenomenDienst). De (AfgenomenDienst) is beschikbaar als de volgende eisen voldaan is, . (AfgenomenDienst) (DienstNaam) Tabell

(Gerealiseerd) XX;X%

(Norm) XX;X%

In tabel 1 staat per afgenomen dienst vermeld de in het SLA overeengekomen norm voor de beschikbaarheid en de gerealiseerde waarde. De gemiddelde tijd dat de dienst ononderbroken beschikbaar (MTBF) en de gemiddelde tijd nodig om een storing te verhelpen (MTTR) zijn opgenomen in tabel 2. (AfgenomenDienst)

(Norm) MTBF XXXuur

(DienstNaam) Tabe12

MTTR XXXuur

(Gerealiseerd) MTTR MTBF XXXuur XXXuur

Uit de gegevens blijkt dat over de periode (PeriodeMaand) wel/niet voldaan overeengekomen beschikbaarheid.

IS

aan de

In grafiek 1 staat de gerealiseerde beschikbaarheid weergegeven van de afgelopen X perioden. beschikbaarheid 97 96 95 94 Q)

tll

93 J! l: Q) ...u 92 Q)

Q.

91 90 89 88 l:

.!!

.0

J!!

I1l I1l

E maand

Grafiek 1 (conclusie, oorzaken, bv. incidenten & problemen, gevolgen, oplossingstraject: Door 8LM).


3

(productie datum)


Rapportage

(ApplicatieNaam)

(standaard)

Capaciteitsbeheer In dit hoofdstuk wordt de afgenomen en beschikbare capaciteit van de (AfgenomenDiensten) beschouwd. Definitie rapportage items (gebruikerskarakteristieken, gebruik hardware, verbindingen) (Capaciteitsitem) Harddisk bezetting CPU belasting Volume databanken Afgenomen lijncapaciteit Verkeer per protocol GebruikBOD

(Norm, thresholds)

(Gerealiseerd, huidige waarde)

Tabe13 (uitleg van de items)

Grafiek 2. Harddisk bezetting.


4

(productie datum)


dec

nov

okt

gemiddelde vorig kwartaal

5.4% 13.2 % 51.0 % 30.4%

5.2 % 12.7% 49.6% 32.5%

5.1 % 13.1 % 52.2% 29.6%

5.0% 12.5 % 45.3 % 37.2 %

Proces USER SYSTEM IDLE WAIT

(ApplicatieNaam)

Rapportage

Tabel4. CPU belastmg Volume databanken vrij

12%

bezet

88%

Grafiek 3. Volume databanken Afgenomen Iijncapaciteit 100 90 80

_ _ maan

70

_ _ dins

a::

60

_ _ woen

c

50

_ _ dond

40

_ _ zate _:~~rij

(3

ca

>

::.Ie 0

30 I

20

zon

10 0 0 0

a

0 ~

0 0

(t;

0

(')

'i

0 0

cO

0

(')

r:..:

0 0

en

0

(')

a ....

0 0

0

(')

N

....

0 0

.... ....

(t;

.0

o cO

(')

....

0 0

a; ....

0 (')

en ....

o

....~N

o (') N N

tijd

Grafiek 4. Afgenomen lijncapaciteit


5

(productie datum)


Rapportage

(ApplicatieNaam)

Verkeer per protocol IPXlSPX 10%

LAT

13% X.25 8%

DECnet 17%

TCP/IP 52%

Grafiek 5. Verkeer per protocol Gebruik BOD 20

14:24

18 12:00

16 14

9:36

12

ic

"0

10

7:12

III III

8

~ III

~

I_

Reeks2

1

~Reeks11

4:48

6 4

2:24

2 0:00

0 c .!!!.

.a

J!! Maand

Grafiek 6. Gebruik BOD

(conclusie, oorzaken, bv. incidenten & problemen, gevolgen, oplossingstraject: Door SLM).


6

(productie datum)


Rapportage

(ApplicatieNaam)

Helpdesk (dejinitie) Overzicht gemelde incidenten met duidelijke omschrijving. Incident karakteristieken (aantal, tijden; MTTR, MTBF).

Probleembeheer (dejinitie) Overzicht problemen. Back-up en restore acties.

Wijzigingsbeheer (dejinitie) Aangevraagde, in geplande en uitgevoerde wijzigingen.

Configuratiebeheer (dejinitie) Wijzigingen in de configuratie, beschrijving van huidige. (eventueel)

Bijlage: Beveiligingsbeheer (dejinitie) Geconstateerde overtredingen, nieuwe autorisaties e.d.

Bijlage: Calamiteitenplanning (dejinitie) (Bijna) opgetreden calamiteiten, oorzaken, gevolgen voorgestelde wijzigingen.

Bijlage: Onderhoudsbeheer (dejinitie) Gepleegd onderhoud, met conclusies. Onderhoudsplan komende periode(s).

Bijlage: Documentatie (dejinitie) Nieuwe versie nummers (of errata).


7

(productie datum)

STRUCTURERENVANEEN IT-BEHEERORGANISATIE MET ITIL, ONTWIKKELEN VAN EEN SERVICE LEVEL RAPPORTAGE SYSTEEM MET BEHULP VAN SOM

Recommend Documents