Ontwerp en Ontwikkeling van systeem-jnetwerkinfrastructurea Een plan van aanpak veer architecten, ontwerpers en projectleiders

KA~I

-~-..

Ontwerp en ontwikkeling van systeem-/netwerkinfrastru.cturen

Een plan van aanpak voor architecten, ontwerpers en projectleiders

Een gefaseerde aanpak om een systeem-/netwerkinfrastructuur te ontwerpen en te ontwikkelen. De onderscheiden fasen zijn:

- Definitiefase: vastleggen wat het resultaat van het te doorlopen traject wordt, aan welke eisen het resultaat moet voldoen, en welke uitgangspunten er gehanteerd worden.

Architectuurfase: opstellen van een bIauwdruk van de te realiseren infrastructuur.

Ontwerpfase: detail uitwerking van de architectuur naar de feitelijke geografische-, technische en organisatorische context. Selectie van toe te passen produkten en exteme diensten

Ontwikkelfase: toetsing van de goede werking en de schaalbaarheid van het ontwerp, realisatie van maatwerk aanpassingen en aanvullingen, opstellen van technische en procedure le richtlijnen.

23 maart 1995

Samenvatting

Gefaseerde aanpak

Deze handleiding bevat een gefaseerde aanpak voor het ontwikkelen van een technische infrastructuur (TIl. De fasen die achtereenvolgens zijn beschreven:

- definitiefase

- architectuurfase

- ontwerpfase

- ontwikkelfase.

Invoering en exploitatie zijn buiten beschouwing gelaten. Bii invoering is er al een geaccepteerd produkt, het resultaat van het ontwikkelen. Exploitatie is evenmin gericht op ontwikkelen, maar op in stand houden.

In de handleiding is gekozen voor een lineaire beschrijving van de fasen, terwijl ontwikkelen een iteratief proces is. De iteratie vindt echter plaats binnen de voorgestelde fasering. De uit te voeren werkzaamheden zullen bij de iteratie ook steeds min of meer gelijk zijn.

Hiema wordt een overzicht gegeven van de belangrijkste activiteiten en resultaten van de verschillende fasen.

Voorafgaand aan de eigenliike ontwikkelfasen moet duidelijk zijn hoe de verandering van de TI samenhangt met de realisatie van de doelstelling van de organisatie. De TI is immers ondersteunend ten opzicht van het beleid van de organisatie. Wensen en eisen aan de TI worden afgeleid van de rol die :1 speelt in de ondersteuning van de process en in de organisatie.

Definitiefase

Het resultaat van deze fase is:

- een duideliik beeld van de huidige TI-situatie

- eisen en wensen aan de nieuwe Tl-situatie

- oplossingsrichtingen om die nieuwe situatie te bereiken, inclusief

de (technische, financiele en organisatorische) consequenties die hieraan vastzitten

- een voorkeursopslossing met een programma van eisen

- een globaal plan van aanpak voor het vervolg.

Om dit resultaat te bereiken moet allereerst veel informatie verzameld worden: over de huidige situatie (beleid, bestaande TI, [organisatie-jplannen en wensen en harde eisen ten aanzien van de nieuwe situatie.

De wensen en eisen moeten vervolgens geordend worden. Zij zijn richtinggevend bij de keuze van een oplossingsrichting.

De variatie in oplossingsrichtingen is sterk afhankelijk van de uitgangssituatie en de noodzaak en bereidheid om daarin wijzigingen aan te brengen. Als een voorkeursoplossing met consequenties is vastgesteld worden wensen en eisen aangepast en vastgelegd in een programma van eisen.

Axc~tectuUJfase

Het resultaat van deze fase is een globale opzet (blauwdruk) van de uiteindelijke technische infrastructuur. De architectuur vormt her raamwerk voor de TI. Tot de architectuur behoren de volgende componenten: lokale en interlokale netwerken, werkstations en serverplatforms en netwerkdiensten. Van elk van deze componenten is beschreven: functionaliteit en kwaliteit, technologie, ondersteuning en beheer.

Het programma van eisen wordt uitgewerkt naar alternatieve architecturen. Er worden keuzes gemaakt voor te hanteren standaarden, voor lokatie en capaciteit, voor de wijze van ondersteuning en beheerorganisatie. Voor elk van de altematieve architecturen wordt een invoeringsscenario gemaakt en een overzicht van kosten en baten. Aan de hand van beoordelingscriteria uit de definitiefase worden de alternatieven beoordeeld, waama er 1 wordt geselecteerd.

Ontwerpfase

Het resultaat is hier een gedetailleerde uitwerking van de 11 in drie ontwerpen: een logisch en een fysiek ontwerp, en een ontwerp van de beheer- en supportorganisatie. Het bevat [logische, fysieke en organisatorische] specificaties op alle componenten van de architectuur.

Voor het maken van deze ontwerpen moeten globaal de volgende activiteiten verricht worden. Voor het logisch ontwerp moeten de geografische en kwantitatieve aspecten van de 11 gemventariseerd worden, waarna ze ingepast kunnen worden in de gekozen architectuur. De benodigde en ontbrekende produkten en diensten worden gedefinieerd per component van de architectuur [platformen, netwerken en netwerkdiensten]. Voor deze produkten/diensten wordt een offertetraject uitgezet.

Voor her fysiek on twerp worden de offenes van verschillende leveranciers beoordeeld. Als de produkten en de leveranciers gekozen ziin kan per component een gedetailleerd ontwerp opgesteld worden.

Met de leverancier worden levering en leveringsvoorwaarden uitonderhandeld.

Voor het ontwerp van de beheer- en supponorganisatie worden de globale richtlijnen uit de architectuurfase vertaald en geconcretiseerd (taken, procedures, middelen, organisatie).

Ontwikke1fase

Het resultaat van deze fase is een gedetailleerde voorbereiding op de technische en organisatorische invoering. Aan het eind is het ontwerp uitgewerkt tot een beproefd en te realiseren produkt.

Op technisch gebied wordt aandacht besteed aan beheertools, fixes/ workarounds en acceptatietests. Vaak wordt gebruik gemaakt van een uitgebreide testopstelling.

De uitwerking van beheer en support heeft betrekking op het opstellen van service level agreements en het maken van handboeken voor beheer, support en gebruikers.

Desgewenst maakt de organisatie gebruik van een pilot, waarin de technische en niet-technische componenten van de TI in de praktijk worden getest.

Inhoudsopgave

1 Inleiding
1.1 Waarom een handleiding technische infrastructuur! 1
1.2 Wat kunt u in deze handleiding vinden? 2
1.3 Wat u in deze handleiding niet zult aantre££en 2
1.4 Hoe gebruikt u de handleiding? 3
1.5 Opzet van de handleiding 4
2 Definitiefase 5
2.1 Inleiding 5
2.2 Afbakening definitiestudie 6
2.3 Activiteiten in de definitiefase 8
3 Architectuurfase 10
3.1 Inleiding 10
3.2 Afbakening architectuurfase 11
3.3 Activiteiten in de architectuurfase 13
3.3.1 Nader specificeren eisen 13
4 Ontwerpfase 19
4.1 Inleiding 19
4.2 Afbakening ontwerpfase 19
4.3 Activiteiten in de logisch ontwerpfase 21
4.3.1 Inventariseren 22
4.3.2 Invulling deelstructuren 23
4.3.3 Opstellen van de offerte-aanvraag 25
4.4 Activiteiten in de fysiekontwerpfase 26
4.4.1 Ahonding eerste fase offene-procedure 26
4.4.2 Tweede fase offene-procedure 26
4.4.3 Uitwerking fysiekontwerp 26
4.4.4 Derde fase offeree-procedure 27
4.5 Specificatie beheer- en support 28 5 Ontwikke1fase 29
5.1 Inleiding 29
5.2 Afbakening ontwikkelfase 30
5.2.1 Doel en aanpak 30
5.2.2 Resultaten ontwikkelfase 30
5.3 Uitwerking techniek 31
5.3.1 Testopstelling in laboratorium omgeving 31
5.3.2 Beheertools 31
5.3.3 Fixes/workarounds 32
5.3.4 Acceptatietest 32
5.4 Uitwerking beheer en support 33
5.4.1 Opstellen SLAts 33
5.4.2 Maken handboeken 34
5.5 Beschermde pilot 34
5.6 Opstellen implementatiedraaiboek 35 T raneactte Workflow Mail

monitor

Ge~evens

.'

Figuur 1.1 Traditionele scheiding infrastructuur en infonnatiesystemen

Pre5entatie

Communicatie

BedrUfslogica

Databa5e

Applicatie verregaand bepa/end voor infrastructuur

U Applicatie

Ii' Iechntecn« inirsetructuur

Figuur 1.2 Modeme indeling van de totale infrastructuur

Presen- Applicatie bearijf510gica tatie

• Applicatie ona'fhankefijk van infrastructuur

• Steeds meer functionafiteit wordt geboden door infrastructuur

U Applicatieve infrastructuur tii' Technische infrastructuur

Raamwerk plan van aanpak Technische Infrastructuur

1 Inleiding

1.1 Waarom een handleiding technische infrastructuur?

De ervaring leert dat veel organisaties met de vraag worstelen hoe ze een nieuwe technische infrasrructuur moeten ontwikkelen. Bij de ontwikkeling loopt men regelmatig tegen dezelfde vragen en problemen aan:

- technische infrastructuren zijn complex en worden steeds complexer, omdat steeds meer functionaliteit voor informatiesystemen wordt ondergebracht in infrastructuren (zie hiervoor figuur 1 en figuur 21; professionele ontwikkeling van technische infrastructuren is daardoor noodzakeliik,

in een systeemontwikkelingstraject wordt vaak pas in de laatste stadia aandacht gegeven aan de technische infrastructuur,

door de hiervoor genoemde problem en verloopt het ontwikkelen van een technische infrastructuur vaak ad hoc en niet gestructureerd, waardoor de ontwikkeling onbestuurbaar wordt.

Een aantalleden van de werkgroep Kantoorautomatisering en Telematica kwam hierdoor op het idee een handleiding te schrijven voor het ontwikkelen van technische infrastructuren. Een handleiding waarin de kennis en ervaring gebundeld is van "nonnale" systeemontwikkelingstrajecten enerzijds en van ingenieursdisciplines anderzijds.

Het resultaat ligt hier voor u. Deze handleiding bevat een gefaseerde .aanpak om een technische infrastructuur te ontwikkelen.

De handleiding is bedoeld voor projectieiders, architecten en ontwerpers die betrokken zijn bi; de ontwikkeling van een technische infrasttuctuur.

Wij hopen met deze handleiding een aanzet te geven voor een meer gesttuctureerde aanpak voor het ontwikkelen van technische infrasttucturen. Daarnaast willen we de betrokkenen van een "normaal" systeemontwikkeltraject (lijnmanagement, informatie-analisten etc.] ervan bewust maken dat:

- de ontwikkeling van een technische infrastructuur een ecbt project is; al te vaak wordt vanuit de systeemontwikkeling gedacht dat het niet uitmaakt waarop een informatiesysteem draait;

- men vanaf het begin van de systeemontwikkeling aandacht moet schenken aan de ontwikkeling van de biibehorende infrastructuur.

Id"" & PJanvorming

Ontwerp en realieatie Technieche infraetructuur

Invoering en exploitatie Technieche infraetructuur

Figuur 1.3 Aandachtsgebieden en beschouwde aspecten

Aandachbgebleden f

----~-~~~--

O'7T'GlNSd

1.2 Wat kunt u in due handleiding riDden?

Deze handleiding bevat een ge£aseerde aanpak voor het ontwikkelen van een technische infrastructuur (TI). Deze aanpak is a£geleid van de £asering in de systeemontwikkeling. Speci£iek voor het ontwikkelen van een technische infrastructuur is hier een architectuurfase aan toegevoegd. De fasen die in deze handieiding zijn uitgewerkt:

de£initie£ase

- architectuur£ase

- ontwerpfase

- ontwikkelfase.

De beschrijving van de fasen is voor iedere £ase geliik gehouden. Per fase wordt beschreven:

- doel en aanpak van de fase

- resultaten van de fase

- activiteiten van de fase

de activiteiten per fase worden onderverdeeld naar drie aandachtsgebieden (zie ook figuur 1.3):

functionaliteit

techniek

organisatie en beheer.

1.3 Wat u in deze handleiding Diet zult aantreffen

Fasen die strikt genomen niet tot het ontwikkeltraject behoren en dus niet in de handleiding beschreven zijn:

- ideevorming en initiatief

- invoering

- elqpIoitatie.

Exploitatie is een reguliere activiteit van een lijnafdeling. De exploitatiefunctie is gericht op het in stand houden en niet op het ontwikkelen van een technische infrastructuur. WeI is het zo dat de exploitatie-afdeling tekortkomingen van de technische infrastructuur kan aangeven en/of kan verzoeken de technische infrastructuur te wijzigen.

2

Raamwerk plan van aanpak Technische Infrastructuur

Vaak wordt pas tot [grootschalige] invoering van een nieuwe technische infrastructuur besloten als de technische infrastructuur is geaccepteerd door aIle betrokken partijen, na eventuele stresstesten, grootschaligheidstesten en/of een proefperiode. Invoering wordt niet gerekend tot het ontwikkeltraject, omdat er na acceptatie een "bevroren" produkt is. De invoering is vooral een logistiek probleem dat op zich zijn eigen methoden en draaiboeken verdient. Veelal zal een [grootschalige] invoering uitgevoerd worden door een tiideliike invoeringsorganisatie.

In deze handleiding wordt evenmin aandacht besteed aan de zogenaamde ptoiectbeheetsingsactiviteiten die tijdens de ontwikkeling van een technische infrastructuur uitgevoerd moeten worden. Redenen hiervoor zijn:

- de handleiding is gericht op vakinhoudeliike kennis

- projectbeheersingsactiviteiten voor een technische infrastructuur

wiiken niet af van deze activiteiten voor andere projecten

- er bestaat voldoende Iiteratuur over projectbeheersingsmethoden

- dit document is niet bedoeld als handleiding voor projectmatig

werken.

In deze handleiding wordt evenmin aandacht besteed aan onderwerpen die bekend staan als valkuilen van projectmatig werken omdat ze vaak genegeerd worden. Dit zijn onderwerpen als:

- draagvlak bii alle belanghebbende partijen

- belangentegenstellingen tussen betrokken partiien

- commitment van de juiste managementlagen

- acceptatie van de technische inirastructuur door alle partiien

- besluitvorming en rapportage en documentatie.

De inhoudelijke invulling is vooral gericht op de technische infrastructuur in administratieve-/kantooromgevingen en minder op wereld van de industrielejprocesautomatisering,

1.4 Hoe gebruikt u de handleiding?

Deze handleiding is tiiet te gebruiken als een kant en klaar recept om een technische infrastructuur te ontwikkelen. Het is niet reeel te denken dat door uitvoering van de beschreven stappen vanzelf een goede technische infrastructuur wordt ontwikkeld.

Dit document dient veel meer als ondersteuning voor projectleiders en direct betrokkenen bij de ontwikkeling van een technische infrastructuur.

3

Raamwerk plan van aanpak Technische Infrastructuur

Het kan onderdeel uitmaken van hun gereedschapset. Het is aan de gebruiker te beoordelen welk gereedschap, wanneer, op welke manier wordt ingezet.

In de tweede plaats zou uit de beschrijving ten onrechte afgeleid kunnen worden dat wij een lineaire methode voorstaan. Wij zijn ons ervan bewust dat ontwerpen een iteratief proces is. De iteratie vindt echter plaats binnen de voorgestelde fasering. Dat betekenr dat bepaalde £asen een aantal keren kunnen worden doorlopen. De uit te voeren werkzaamheden binnen een iteratie zullen naar onze mening steeds min of meer gelijk zijn.

Ten derde: in de fasering zijn activiteiten en beslissingen zo ver als mogeliik naar achter geschoven in de tijd, zodat keuzes niet te vroeg in de ontwikkeling gemaakt worden. Dan worden immers een aantal oplossingen al vroegtiidig uitgesloten.

In de praktijk ziin er echter minder vrijheidsgraden dan hier gesuggereerd. Daar waar keuzes reeds vastliggen worden deze zo vroeg mogelijk in het project als uitgangspunt of randvoorwaarde meegenomen.

Ten slotte: de voorbeelden en tekstkaders dienen slechts ter ilhistratie en hebben niet de pretentie volle dig en uirputtend te zijn,

1.5 Opzet van de handleiding

In hoofdstuk twee tot en met viif worden achtereenvolgens de verschillende fasen uitgewerkt.

4

Figuur 2.1 Kwaliteits/beheer cyclus

Actie

07fGIN9g

Bvsturen

Raamwerlc plan van aanpak Technische Infrastructuur

2 Definitiefase

2.1 Inleiding

De ontwikkeling van een nieuwe technische infrastructuur staat niet op zichzelf. Geen enkele organisatie zal een technische infrastructuur ontwikkelen zonder dat de organisatie een bepaalde doelstelling nastreeft. Iedere organisatieleenheid] heeft een of meer doelstellingen. Om die doelstellingen te realiseren wordt een groot aantal activiteiten verricht. Hierbij wordt een scala aan middelen ingezet, waaronder informatievoorziening en automatisering. De automatisering kent als basis een technische infrastructuur.

Van belang is dat de ontwikkeling van een technische infrastructuur bepaald wordt door het beleid van de organisatie. Anderziids kan het beleid van een organisatie mede bepaald worden door de keuzes die gemaakt worden binnen de ontwikkeling van een nieuwe technische infrastructuur. Veelal zal de invloed beperkt blijven tot "het hoe" van het beleid, en niet tot het "wat" van het beleid.

Als de doelstellingen van een organisatie veranderen, de middelen niet meer [voldoende] bii [kunnen] dragen aan het realiseren van de doelstellingen, of er zich nieuwe altematieve middelen aandienen, is het mogelijk tijd om in te grijpen. Ex kan een veranderingsproces op gang worden gezet om de technische infrastructuur aa:n te passen aan de eisen van de automatisering en/of de eisen en wensen van de gebruiker.

Na het veranderingsproces moet de technische infrastructuur (TIl efficienter aan de verwachtingen voldoen. Om de gewenste veranderingen aan te brengen wordt er een Tl-project ingericht. Alvorens dit TI-project te starten zal er doorgaans een of andere vorm van vooronderzoek plaatsvinden. Dit vooronderzoek is nodig om de noodzaak tot veranderen aan te tonen en de nieuwe doelstelling (eisen/wensen) te bepalen. Tevens dient een vooronderzoek er doorgaans toe om de grenzen waarbinnen het veranderingsproces zich af mag spelen te bepalen. Kortom het vooronderzoek dient een zo concreet mogeliik projectvoorstel voor de noodzakelijke verandering op te leveren.

In de definitiestudie wordt vervolgens vastgesteld wat er moet veranderen en hoe we een bepaalde verandering kunnen realiseren.

5

Raamwerk plan van aanpak Technische Infrastructuur

2.2 Afbakening definitiestudie

Doe} en aanpak deiinixiestudie

Indien besloten wordt dat een bepaalde verandering noodzakelijk dan wel wenselijk is, wordt het TI-project in gang gezet. De eerste fase daarin is de definitiestudie: wat wordt het resultaat van het TIproject (functionaliteiten/kwantiteitenJ, aan welke eisen moet her resultaat voldoen (kwaliteit), welke randvoorwaarden en welke uitgangspunten er zijn.

In deze fase wordt de huidige TI-situatie geanalyseerd en het pakket van eisen en wens en bepaald. Vervolgens worden mogelijke oplossingsrichtingen bedacht, zodat de opdrachtgever (en de organisatie] een voorkeursoplossing kunnen kiezen. Daartoe worden van de verschillende oplossingsrichtingen de consequenties aangegeven. Deze consequenties omvatten naast technische en financiele aspecten vooral ook de wissel werking van de TI met de organisatie en de (inrichting van de) bedriifsprocessen.

Het opstellen van het programma van eisen en her kiezen van een oplossingsrichting is vaak een enigszins iteratief proces. Na het kiezen van een oplossingsrichting kunnen eisen/wens en en uitgangspunten/randvoorwaarden veelal scherper gesteld worden.

6

Raamwertc plan van aanpak Technische Infrastructuur

Resultateti deiinitieiase

Belangriikste resultaten van de definitiestudie ziin:

een eenduidige afbakening van het resultaat van het Tl-proiect: wat dient de TI mogelijk te maken

welke functies en diensten dienen daartoe vervult te worden waar en in welke omvang moeten deze geleverd worden

hoe kunnen deze worden afgenomen

de kwaliteitseisen die aan de 11 gesteld worden:

wat worden de afnametiiden en de betrouwbaarheidseisen

welke mate van beveiliging tegen molest en inbraak of misbruik is nodig

welke ondersteuning in het gebruik wordt aan de afnemers geboden

de wijze waarop de afnemer zich wenst te organiseren met betrekking tot het gebruik van de geboden functies en diensten

de eisen van de afnemer aan de organisatie van de beheerder/ exploitant van de 11

de gekozen oplossingsrichting ten aanzien van techniek, beheerorganisatie en interactie tussen gebruikersorganisatie de 11; de mate waarin de gekozen oplossingsrichting tegemoet komt aan de doelstelling en vraagstelling zoals geformuleerd in het vooronderzoek

- een plan van aanpak voor het vervolg van het project

- de offers die hier tegenover staan mogen staan, biivoorbeeld:

hoe groot worden de investeringen en onderhoudslasten

hoe worden de investeringen gefinancierd en/of doorbelast aan de afnemers.

Afhankelijk van de situatie zal het bovenstaande in meer of mindere mate in 11-terminologie gesteld ziin. De opdrachtgever van het 11- project en de afnemers van de 11 zijn hierbij in principe leidend. In de definitiefase is het gebruik van Tl-terminologie niet noodzakeliik. De volgende fasen dienen zo nodig een vertaalslag en aanvulling op de resultaten van definitiefase uit te voeren.

7

Raamwerk plan van aanpak T echnische Infrastructuur

2.3 Activiteiten in de definitiefase

De activiteiten die achtereenvolgens doorlopen worden in de definitiefase zijn:

- verzamelen, uitwerken en aanvullen van uitgangsrnateriaal inventarisatie, ordening en prioritering van eisen en wensen beschrijven van het eindresultaat:

. de functionele eisen/wensen en de kwaliteitseisen . de organisatie van afnemer en TI-aanbieder

(globaal) uitwerken van enkele alternatieve oplossingsrichtingen en biibehorende consequenties ==---------

keuze hieruit met de opdrachtgever. ._ (

Als uitgangsmateriaal geldt in eerste instantie het eerder genoemde vooronderzoek. Verder is afhankeliik van de gewenste TI-diepgang doorgaans informatie nodig ten aanzien van:

- bestaand beleid voor de informatievoorziening en automatisering bestaande technische infrastructuren en informatiesystemen

- alle andere informatie- en automatiseringsplannen die mogeliik niet direct betrokken zijn geweest in het vooronderzoek

- ondernemingsplannen, mission statements en andere uitingen die op de middellange of lange termijn vormgeven aan de onderneming - organisatieplannen en procesbeschrijvingen.

----_.-

Indien de informatie niet beschikbaar is zullen zoveel mogelijk vertrekpunten zelf gedefinieerd moeten worden. Grote organisaties zijn bijvoorbeeld bereid een infrastructuur te onrwikkelen zonder dat exact duidelijk is welke informatiesystemen daarvan gebruik zullen gaan maken. In dat geval dienen er aannames opgesteld te worden, doorgaans een (geintegreerde) mix van primaire automatisering (AO en besturingsgericht) en secundaire [kantoor-lautomatisering.

Uit de verkregen informatie kunnen direct of indirect eisen en wensen vastgesteld worden. Een technische infrastructuur voor een multinational dient wellicht 24 uur per dag zeven dagen per week beschikbaar te ziin. Voor een gemeentelijke dienst zijn de lokale kantooruren meestal voldoende. De ene organisatie wil de afname van functies en diensten verrekenen op volume (gebruiks)basis, de andere slaat de kosten hoofdeliik om ever de bedriifseenheden of verrekent de kosten in het geheel niet met de gebruiker.

8

Raamwertc plan van aanpak Technisehe Infrastructuur

Vervolgens kunnen de eisen en wensen geordend worden. Bijvoorbeeld naar de verschillende resultaatgebieden van de definitiefase. De eisen en wensen zullen tevens een rol spelen bij de keuze tussen de altematieve oplossingsrichtingen zodat een prioriteitsstelling nodig is.

De bestaande situatie (geinstalleerd park, inrichting van de organisatie en vigerend beleid) bepalen in hoge mate de mogeliike varia tie aan oplossingsrichtingen. De bereidheid of noodzaak om in de bestaande situatie grote veranderingen aan te brengen zal dan ook de variatie mogelijkheden beinvloeden. Denk bijvoorbeeld aan de introductie van telewerken of grootschalige downsizing en decentralisatie van computerapparatuur.

Nadat de mogelijke oplossingsrichtingen en bijbehorende consequenties ziin bepaald, kan met de opdrachtgever de voorkeursoplossingsrichting gekozen worden. Meestalleidt dit proces tot bijstelling van het programma van eisen. De TI wordt te duur dus worden de eisen teruggeschroefd of de TI heeft zo'n groot belang gekregen dat de eisen worden opgeschroefd.

Na het keuzeproces kunnen de voorkeursoplossing en consequenties daarvan nog verder worden uitgewerkt om vervolgens een gedegen plan van aanpak voor het vervolg op te stellen. De resultaten van de definitiefase worden ten slotte vastgelegd en geaccordeerd door de opdrachtgever en bijvoorbeeld een stuurgroep of directie die achter of boven de opdrachtgever staat.

9

r

Raamwerk plan van aanpak Technische Infrastructuur

3 Architectuurfase

3.1 Inleiding

De architectuur vormt het functionele, kwalitatieve en rechnologische, organisatorische raamwerk waarbinnen de Tl-gerealiseerd moet worden en staat in principe los van de omvang van de TI en de ITprodukten en organisatorische invulling waaruit een TI bestaat. De architectuur bevat mogeliik keuzes ten aanzien van te hanteren technologie, fabrikanten van produkten en organisatievonnen en houdt tevens rekening met de potentiele omvang en geografische distributie van de TI.

Als er weinig beleid op Tl-gebied aanwezig is zal bij een omvangriik TI-project het resultaat van de architectuurfase als basis kunnen dienen voor het formuleren van TI-beleid.

Omgekeerd geldt bij een relatief klein veranderingsproject dat her bestaande beleid, en daarmee de bestaande architectuur, leidend zullen zijn voor het project. In de architectuurfase komt dan de nadruk te liggen op het toetsen of er binnen de bestaande situatie een goed ontwerp voor de gewenste verandering mogelijk is. Dit leidt eventueel tot een geringe verandering of uitbreiding van het bestaande beleid c.q. de bestaande architectuur.

De architectuur is onder te verdelen in een aantal deelstructuren: - lokale en interlokale netwerken

- werkstation en server platforms

- netwerkdiensten, zoals file-/print services, berichtentransport,

directory services.

Iedere deelstructuur kent de aspecten: - functionaliteit en kwaliteit

- technologie

- ondersteuning en beheer.

10

Figuur 3.1 Architectuurfase

Ar~hitectuur

Functie

• Applicatie-ondersteuning

• T raneport/ distributie

• Resource-sharing ·Systeeml

netwerkmanagement;

Kwaliteit/kwantiteit

Techniek

• Platformen

• Netwerken

• Netwerk diensten

• Overige diensten (rraneactte, DBMS, object, ...

• Beschikbaarheid -Integriteit

-Privacy

- Prestatie

- Flexibiiiteitl

echaalbaarheid

- Geografische spreiding

07fGIN7w

Drganisatie

- Beheer

-Support

- Financiering

Raamwerlc plan van aanpak Technische Infrastructuur

3.2 Afbakening architectuurfase

Doe1 en aatipak

De architectuuriase heeft tot doel de globale structuur (een blauwdruk) te vormen voor de uiteindeliike technische infrastructuur (TI). In de architectuurfase worden de eisen/wensen uit de definitiefase verwerkt tot een aantal globale schetsen van de technische infrastructuur. In de volgende (ontwerpJfase wordt de architectuur gedetailleerd uitgewerkt. Dan worden TI-produkten en externe diensten gekozen en gedimensioneerd. Het onderscheid tussen architectuur en ontwerp is in hoofdliinen tussen het ontwikkelen van een technische infrastructuur op strategisch en tactisch niveau.

Uitgaande van de resultaten van de definitiefase, de bestaande technische en organisatorische situatie en de technische mogelijkheden en trends wordt een beperkt aantal altematieve architecturen opgesteld {3 a 4 hoofdvariantenl en globaal uitgewerkt. Daarna wordt aan de hand van het programma van eisen uit de definitiefase en de verwachte consequenties voor de realisatie (de technische, organisatorische en economische haalbaarheidJ een voorkeursarchitectuur gekozen. Deze wordt zonodig nader uitgewerkt en opnieuw getoetst aan de resultaten van definitiefase.

Resultaten arcbitecttuujase

De architectuurfase mag niet te conceptueel eindigen, omdat de partijen deze dan verschillend kunnen interpreteren. Bovendien kan de complexiteit van de TI daardoor ondersneeuwen.

11

Raamwerk plan van aanpak Technische Infrastructuur

De belangrijkste resultaten van de architectuurfase zijn:

- een definitie van her functionele, kwalitatieve en kwantitatieve potentieel van de TI

overzicht van gekozen netwerkdiensten en eventueel de biibehorende intemationale of defacto standaarden [dit kan ook in de ontwerpfase]

typering van de werkstation en server platformen

een omschrijving [tekening] van de netwerktopologie en netwerkcomponenten, eventueel een overzicht van gekozen proto collen en biibehorende intemationale of defacto standaarden (kan ook in de ontwerpfase I

de hoofdlijnen van:

de beheertaken en -verantwoordelijkheden de beheerorganisatie

de taken en verantwoordelijkheden van de afnemer van de TI (gebruikersorganisati e I

de organisatie van de afnemer met betrekking tot het gebruik van de TI

- omschrijving van de invoering en migratie scenario's

- kosten/baten indica tie

- plan van aanpak voor het vervolg van het project.

12

Raamwertc plan van aanpak Technische Infrastructuur

3.3 Activiteiten in de architectuuriase

De architectuuriase be staat uit viif stappen, te weten:

1. nader specificeren eisen

2. functionele/kwantitatieve specificatie van de infrastructuur, vertaling van het programma van eisen naar:

- benodigde typen platformen, netwerkdiensten en netwerkverbindingen

- maximaal te bieden capaciteiten en geografische distributie van de netwerkdiensten en -verbindingen

3. opstellen altematieve architecturen, per alternatief voor zover onder ling afwijkend:

- [eventueel] keuze per te ondersteunen platform van internationale gestandaardiseerde en defacto netwerkdiensten

- vormgeven structuur/topologie van de netwerken, keuze lokatie en capaciteit/bedieningsgebied van servers voor netwerkdiensten

- globaal vormgeven van de ondersteuning en verantwoordelijkhe den van de beheerorganisatie en van de gebruikersorganisatie

- aangeven mogelijke invoerings-/migratie scenario's (haalbaarheid)

- globale kosten/baten indicatie

4. kiezen voorkeursaltematief

5. zonodig nader uitwerken van her voorkeursaltematief.

3.3.1 Nader speciiicexea eisen

Deze activiteit is bedoeld voor het verder uitwerken van het programma van eisen afkomstig uit de definitiefase en uit andere bronnen [bedriifsbeleid, wetgeving, zie oak paragraaf 2.31 in TI-termen en -dimensies. Afhankelijk van de [technische] diepgang die in de definitiefase gehanteerd is zal hier meer of minder werk verzet behoeven te worden.

De nadere uitwerking van de eisen dient twee doelen:

- (me de) aan de hand van de eisen zal er een keuze gemaakt moeten worden tussen de altematieve architecturen

- de eisen zullen in de loop van de architectuurfase omgevormd worden tot specificaties van de uiteindelijke architectuur.

13

-

Raamwerk plan van aanpak Technische Infrastructuur

Aan het einde van deze activiteit zal het in ieder geval duideliik ziin of het bestaande beleid en de bestaande architectuur een belangriike revisie zullen ondergaan of dat het veranderingstraiect binnen bestaand beleid en architectuur kan worden uitgevoerd.

Indien vooronderzoek en definitiefase gericht geweest ziin op een specifiek probleem of knelpunt en niet op de automatisering in de breedte, dan is het verstandig in de architectuurfase het programma van eisen zoveel mogelijk te verbreden. Zoals het woord TI aangeeft wordt er immers gewerkt aan een infrastructuur, een universeel inzetbaar hulpmiddeL Dit betekent dat er eventueel algemene eisen aan de TI worden gesteld zoals openheid [bruikbaar door open systemen), transparantie (onzichtbaar voor de afnemer, c.q. de aangesloten systemen), flexibiliteit (qua functionaliteit en omvang],

De kwaliteitseisen verdienen speciale aandacht omdat deze de complexiteit van de TI, en daarmee van her TI-project, sterk kunnen bemvloeden. Naast prestatie-eisen zijn vooral van belang:

- de betrouwbaarheid: integriteit, authenticiteit en vertrouwelijkheid

- beschikbaarheid: openingstijden, beschikbaarheidspercentage, calamiteiten opvang

- flexibiliteit/modulariteit, schaalbaarheid.

Ook zal gekeken moeten worden naar de beoogde tijdshorizon van de definitiestudie en de stabiliteit van het programma van eisen. De wereld en de daarin opererende organisaties kennen een hoog veranderingstempo. Dit stelt eisen aan het invoeringstempo, afschriivingstermijnen en/of de flexibiliteit/universaliteit van de TI.

Deze nadere specificatie van de eisen dient tijdig, dat wil zeggen niet aan het eind van de architectuurfase maar zo vroeg mogelijk, met de opdrachtgever/afnemer afgestemd te worden.

14

Figuur 3.2 Globale indeling in hoofdcomponenten

Raamwerk plan van aanpak Technische Infrastructuur

Functionelefkwasititatieve speciiicatie van de azcbitectuur

Zoals gezegd wordt aan de hand van de nader gespecificeerde eisen bepaald in welke functies en kwantiteiten de TI zal voorzien:

- functioneel, keuze van benodigde/ondersteunde:

[typen] platformen, zoals mainframes (centrale servers), minicomputers (decentrale servers), werkstations, terminals/printers en andere randapparatuur

netwerkdiensten, zoals file-/printservices voor de werkstations, messaging services voor de verschillende platformen en/of voor lokale E-mail systemen, gateways naar externe netwerkdiensten en/ of externe netwerken

netwerkverbindingen, welke platform en kunnen direct of indirect onderling gekoppeld worden

- de lokaties waar de platformen zich zullen of mogen bevinden

- de minimale en maximale capaciteiten en responsetijden van de

netwerkdiensten en de verbindingen tussen en binnen de lokaties.

Opstelleti altettiatieve arcbitectuxen

Voor ieder alternatief dienen onderstaande stappen doorlopen te worden. Het doel van deze stappen is te komen tot een globale schets van de toekomstige infrastructuur. Een globale schets is als een soort halffabrikaat een goed communicatiemiddel. Deze schets dient te worden aangevuld in de navolgende stappen en in de ontwerpfase.

Het opstellen van een Tl-architectuur vergt naast kennis van de hedendaagse/actuele mogelijkheden ook inzicht in de ontwikkeling van de technologie, standaarden en produkten. Dit vereist een grondige orientatie op met name de ontwikkeling van standaarden en de reactie daarop van de leveranciers.

Keuze van gestandaaxdiseetde setviceslptotocolleti

Strikt genomen kunnen deze keuzes uitgesteld worden tot de ontwerpfase. In de praktijk blijkt echter dat architectuur varianten duideliiker onderscheiden kunnen worden als platform, fabrikant, services en protocollen in een adem genoemd worden. Bijvoorbeeld de combinatie mainframe, mM, SNA, Netbios, Tokenring versus de combinatie UNIX-minicomputer, TCPjIP, LM/X, Ethernet.

Het detail niveau is beperkt. Voor bijvoorbeeld de nerwerkdienst E-mail is SNADS, SMTP of X.400 o.i.d. voldoende. Versie nummers, keuze van opties en instelling van parameters en dergeliike zijn niet relevant.

15

Figuur 3.3 Afbakening centrale en decentrale taken en veranrwoordeliikheden

CEO

07fGIN7y

I I

Raamwerk plan van aanpak Technische Infrastructuur

Vormgeven structtuultopologie van de TI

De keuze van de lokatie en capaciteit c.q. bedieningsgebied van de servers voor de netwerkdiensten en de netwerkcomponenten worden bepaald aan de hand van de geografische distributie van de vraag naar de netwerkdiensten, en beheersmatige en economische overwegingen.

De lokaties betreffen:

centrale en decentrale computercentra

- de decentrale omgeving van de gebruiker: plant, gebouw, afdeling

- de werkplek.

De netwerkcomponenten betreffen in dit stadium: - lokale netwerken (LAN's)

- interlokaal netwerk (WAN):

netwerkknooppunten

. transmissiemiddelen [diensten PTT Telecom en/of andere netwerk service providers)

- koppelingen tussen LAN's en WAN.

De lokatie en capaciteit van de netwerkdiensten en netwerkcomponenten ziin in deze fase alleen relevant als de kwaliteitseisen zeer kritisch ziin en/of er een meer nauwkeurige kostenindicatie opgesteld dient te worden. Het ligt in de architectuurfase meer voor de hand modelmatig te werk te gaan. De gekozen opzet dient weI te voorzien in voldoende mogelijkheden voor schaalvergroting.

Globaal vormgeven otuietstcuning en bebeetotgaaisatie

De taken en verantwoordelijkheden met betrekking tot het gebruik en het beheer van de TI dienen verdeeld te worden over de gebruikersorganisatie en de beheerorganisatie. De taken en verantwoordelijkheden worden deels bepaald door de gestelde kwaliteitseisen c.q. te hanteren kwaliteitsnormen.

Na 'deze afbakening kan vastgesteld welke ondersteuning geboden dient te worden aan de gebruiker en kunnen beide organisaties en hun onderlinge interactie [globaal] ingevuld worden.

16

Tabe13.1

Kosten/baten-indicatie

Kosten Investering

Jaarlijlcs

Baten Eenmalig

Jaarlijlcs

Apparatuur

Netwerk

{Besturingsl programmatuur

Implementatie

Diensten

Opleiding

Beheerorganisatie (personeeVopleidingen/proceduresl

Project

Audit, risico, •••

Totaal

\

\

Raamwerk plan van aanpak Technische Infrastructuur

Bepaleti invoeriiigs-lmigtatie scenario's

Deze fase bepaalt het migratiepad van huidige naar de gewenste situatie en analyseert de technische en organisatorische gevolgen van het betreffende altematief. Het migratiepad kan bestaan uit een of meerdere tussenstappen, al naar gelang de ingriipendheid van het veranderingstraject.

Om te beginnen dient vastgesteld te worden waar en welke elementen van de TI veranderen en welke systemen etc. van de afnemer daarbii in het geding ziin. Vervolgens dient gekozen te worden voor een methode voor invoering en migratie:

- geleidelijke invoering met of zonder koppelingen/integratie tussen oude en nieuwe situatie

- invoering in een klap van de nieuwe TI met of zonder parallel draaien gedurende een proefperiode (voor zover mogeliik en zinvol) - een combinatie, biivoorbeeld stapsgewijs gedeelten van de nieuwe functionaliteit in een klap invoeren.

Globale kostetilbateti indicatie

Voor het kunnen nemen van een afgewogen beslissing over de alternatieve architecturen is een financiele onderbouwing wenselijk. De kosten ziin te verdelen in de eenmalige investeringskosten en de iaarliikse onderhoudskosten. Naast de kosten dienen ook de kwantificeerbare bat en te worden betrokken. Vanwege de rol van de technische infrastructuur zullen de baten veelal een indirect karakter hebben. De verhouding tussen kosten en baten bepaalt uiteraard de terugverdienperiode en het rendement van de TI. Ook de eventuele baten van doorbelasting ziin te baseren op de geinventariseerde kosten en op de overige baten. Dit is met name van belang als de doorbelasting wordt berekend op basis van automatiseringsacties, zoals geheugen-, CPU- en licentiegebruik.

Per onderdeel of beslissingscriterium dienen bij voorkeur - naast de kosten en baten - tevens de risico's te worden geanalyseerd. De risico's geven aan welke risicomarge dient te worden aangehouden bij de geprognosticeerde kosten en baten. In tabel 3.1 is een raamwerk voor een eenvoudige kosten/baten-analyse weergegeven.

17

Raamwerk plan van aanpak Technische lnfrastructuur

Kiezeii vootketusalteiiiatiei

De criteria voor de keuze (en de gewichten daarvan) zijn direct af te lei den uit de resultaten van de definitiefase, eventueel aangevuld met criteria gebaseerd op kennis van IT-trends en marktontwikkelingen.

Aan de hand van deze criteria en gewichten worden de verschillende al tematieven beoordeeld.

18

Figuur 4.1 Ontwerpfase

Ontwerp

Logisch ontwer

• Services

• Protocollen

• Interfaces

• Principe schema's

Fysiek ontwer

• Produl<ten/leveranciers

• Principe configuraties

• Aantallen/lokatie

• Prestaties

.07TGIN7z

Beheer en su ort

• Beschiki7aarheid

• [ntegriteit

• Privacy

• Freetatte

• Flexii7i1iteitl schaalbaarheid

• Geografische spreiding

Raamwerlc plan van aanpalc Technische Infrastructuur

4 Ontwerpfase

4.1 Inleiding

Het on twerp bevat een gedetailleerde uitwerking van de Tl-infrastructuur, logisch en fysiek. Het omvat detailspecificaties en een eerste vertaling naar de werkeliike geografische/organisatorische situatie van de in de architectuurfase gedefinieerde deelstructuren: - de netwerkdiensten

- de netwerken

- werkstation- en serverplatformen.

De detailspecificaties omvatten:

- logische specificaties zoals functies, protocollen en principe schema's

- fysieke specificaties zoals produkten/principe configuraties, aantallen en lokaties

- specificaties van de beheer- en supportfuncties (taken), -procedures en -organisatie.

4.2 Afbakening ontwerpfase

Doel en aanpak

De ontwerpfase heeft tot doel een detailspecificatie op te leveren van de te realiseren TI. In de ontwerpfase wordt de architectuur uitgewerkt tot een voorlopig schema waarin alle componenten zijn opgenomen en gespecificeerd. Dit betekent dat de in te kopen produkten en diensten zijn geselecteerd en dat de [principe] configuraties en/of leveringsvoorwaarden van de produkten en diensten bepaald ziin. In de ontwerpfase wordt tevens vastgesteld hoe de beheer- en supportorganisatie eruit gaat zien en welke beheer- en supportprocedures ingevoerd moeten worden.

In de volgende (ontwikkelings)fase ondergaat het ontwerp een finale toetsing op de goede onderlinge samenwerking van aIle componenten, de reeds aanwezige TI en de systemen van de afnemer. In de ontwikkelingsfase wordt het principe schema tevens uitgewerkt tot een (definitief) bestek,

19

l

Raamwerlc plan van aanpak Technische Infrastructuur

De ontwerpfase omvat drie activiteiten:

- opstellen van het logisch on twerp; een principe schema

- opstellen van her fysiek ontwerp, waaronder de selectie van in te

kopen produkten/diensten en leveranciers en bepalen van de principe configuraties van deze produkten en diensten (voorlopig bestek]

- opstellen van het ontwerp beheer/support, beheer- en supportfuncties, -procedures, en -organisatie.

Resultateti otitwerpiase

De belangrijkste resultaten van de ontwerpfase zijn:

Het logisch ontwerp:

- gekozen standaarden en daarbinnen te hanteren opties/parameters voor de deelstructuren netwerken, netwerkdiensten en platformen - de samenhang en koppelingen tussen de deelstructuren en de componenten binnen de deelstructuren, technieken en hulpmiddelen voor netwerkbeheer

- offerte-aanvraag voor de selectie van produkten/Ieveranciers.

Het fysieke ontwerp:

- gekozen produkten/diensten en leveranciers, vastgestelde leveringsvoorwaarden

- principe dimensionering van de produkten en externe netwerkdiensten (PIT Telecom, V AN-leverancier) per lokatie, gebruikersgroep of andere afgebakende eenheid.

Het ontwerp beheer/support:

- beheerfuncties (taken) en procedures supportfuncties (taken) en procedures

- beschrijving beheer- en supportorganisatie

- basiselementen/specificatie voor te hanteren service level agree-

ments (SLA's).

20

~-- ..

Raamwerlc plan van aanpak Technische Infrastructuur

4.3 Activiteiten in de logisch ontwerpfase

De logisch ontwerpfase bestaat uit 4 stappen: - inventariseren van:

de geografische en kwantitatieve aspecten van de 11, zoals lokaties, aantallen aansluitingen, verkeersverwachtingen etc.

de gewenste ondersteuning [support]

- vertaling van de in de architectuurfase beschreven typen platformen, netwerken en netwerkdiensten naar feiteliike platformen, netwerktechnieken en -protocollen en netwerkdiensten en bepalen van de beheerstools

- opstellen van de offerte-aanvraag voor de selectie van produkten en externe diensten en biibehorende leveringsvoorwaarden en implementatiewerkzaamheden.

21

Figuur 4.2

Vertaling naar feiteliike platforrnen, netwerkdiensten, technieken en protocollen middels opsrellen en invullen van een logischmodel

~~----------~~~

Distribution Communication

services services

4<

"'r;-~ ~'.

............... ~

Data acces services ~,

»> ~~ / f
T ransport/netwerk services Systeem software s.
t
.. ~ ~~i
,.~:~; ... #"-; ./_ ~..Y /
Datalink Tranemieelernedia Platform hardware
.AI ~ 07rGIN~a

Tabe14.1

Voorbeeld keuze mogelijkheden platformen

Type service

Type platform

Produkt

Corporate informatie/applicatie

server

Mainframe

IBM/MVS Stratus Tandem etc.

Mini

UNIX ASlOS400 VAXNMS HP3000/MPE

Divisie/afdelings- informatie/applicatie server

Mini/PC-Server

(SCOnUNIX AS400/OS400 VAXNMS HP3000/MPE WindoWS/NT OS/2

Netware

Resource sharing

Mini/PC-Server

Netware LANManager (derivaten) WindoWS/NT

Wericstation

Terminal

alfanumeriek XJWindows

PC

DOS, OS/2, Windows, UNIX

Tabe14.2

Typen diensten en mogelijke invullingen

Type netwerkdienst

Intemationale/defacto standaard

Terminalverbinding

asynchroon ANSI, IBM3270/5250

Filetransfer

FTP,FrAM

Resourcesharing

NFS

PClSupport, LANServer Netware, LANManager VINES, LANtastic

Application communications services

RPC Mal

Ol TP service

TxRPC, STDl (X/Open), ENCINA

sal service

SaL/2,ODBC

Directory

X.SOO, DNS, NOS

Object Management

CORBA. OpenDoc, OLE

Messaging/E-mail

X.400, XAPIA MAP!,CMC

Telephony!P ABX-services

TAP! TSAPI

Raamwerk plan van aanpak Technische Infrastructuur

4.3.1 In vetitaiiseteti

Her inventariseren van de geografische en kwantitatieve aspecten is nodig voor:

het ramen van de gewenste verwerkingscapaciteiten voor de netwerkdiensten en de netwerken en het me de op grond daarvan bepalen van:

capaciteiten, aantallen en lokatie van benodigde servers voor de netwerkdiensten en van de benodigde data-/telecommunicatieverbindingen

te hanteren netwerktechnieken/-protocollen

het invullen van de kwantitatieve eisen/uitgangspunten voor de offerte-aanvraag

het maken van het fysiek ontwerp.

De inventarisatie van de kwantitatieve aspecten kan in eerste instantie globaal aangepakt worden. Er wordt vaak met kentallen gewerkt, waarbij het vooral gaat om de orde van grootte. Exacte aantallen en lokatiegegevens zijn pas echt van belang bij het opstellen van de feitelijke apparatuurconfiguraties in de ontwikkelingsfase (installatievoorbereiding).

De gewenste ondersteuning aan de afnemer van de TI betreft zaken als:

- helpdesk voor:

storingsmelding en informatieverschaffing over storingsafhandeling

vraagbaak voor het gebruik van de TI - storingsafhandeling

- managementrapportage over de kwaliteit en eventueel het gebruik

van de TI

- opleiding van de afnemer.

22

++ +
++ +
++ ++
+ +1-
++ +
++ +
++
+ +1-
+ + ++
, aanwezig:
++ + +
++ ++
++ ++
tools
kosten ++
beschikbaarheid + ++
betrouwbaarheid ++ + +
++ + + -

Raamwerk plan van aanpak Technische Infrastructuur

4.3.2 Itivulling deelstructuieti

Platiotmeti

Indien de platform keuze nog niet vaststaat dient deze in de logischontwerpfase bepaald te worden ltabel a.I]

Netwetkdiensten

In de architectuurfase is in ieder geval reeds Iiist van typen netwerkdiensten vastgelegd. In de ontwerpfase dient deze nodig uitgebreid en vertaald te worden naar concrete netwerkdiensten, c.q. naar protocollen/produkten [tabel c.Z].

Tijdens deze stap dient zonodig afstemming plaats te vinden met de verantwoordelijken in het bedriif voor systeemontwikkeling en aanschaf van applicatie programmatuur, zodat een naadloze aansluiting tussen de functionaliteit en werkwijze van de TI en de applicatie software gewaarborgd kan worden.

Netwetketi

Het maken van het logisch netwerkontwerp is een iteratief proces waarin vele stapp en doorlopen worden. De belangriikste stappen zijn:

analyse van de interlokale geografische distributie van de organisatie en mogelijke verkeersstromen

analyse van lokale distributie op plants en in gebouwen, lokatie keuze van centrale en decentrale servers

verde ling van het gehele necwerk in WAN en LAN delen

bepalen van LAN technologie, bekabelingswijze en monitoring en diagnose methoden

bepalen WAN technologie, transmissietechnieken en beheer methode

- bepalen van de technologie en positie (LAN of WAN, lokatie] van exteme koppelingen

- bepalen van de LAN-LAN koppelingswijze

- bepalen van de koppelingswijze tussen systemen/werkstations en

het netwerk

- segmenteren van de lokale netwerken in logische delen ten behoeve van performance en beheer

- bepalen van de middelen voor netwerkbeheer, afstemming van de activiteit beheerontwerp uit de ontwerpfase

- bepalen van typen produkten [technologie] en kwaliteitseisen (capaciteitsrange, flexibiliteit/modulariteit, betrouwbaarheid] voor de realisaue.

23

Raamwerlc plan van aanpak Technische Infrastructuur

Resultaat van dit iteratieve proces is:

- een tekening/beschrijving van het netwerk waarin opgenomen:

WAN: topologie: knooppunten en verbindingen, protocollen en transmissietechnieken

LAN's:

. segmentatie/knooppunten

. LAN protocol/transmissietechniek LAN-WAN koppeling netwerkbeheer hulpmiddelen

- end-to-end protocols tack, per platform/netwerkdienst combinatie

- programma van {kwaliteits)eisen voor de toe te passen produkten.

24

Raamwerk plan van aanpak Technische Infrastructuur

4.3.3 Opstellen van de offerte-aanvraag

Het selecteren van produkten/diensten en leveranciers aan de hand van een offertetraject vereist een gedegen aanpak waarin vooraf bepaald worden:

- de offerte-procedure

- de lay-out van de uit te brengen offertes

- de criteria, gewichten [prioriteiten] en bijbehorende meetlat.

De offerte procedure besl-iat minimaal drie rondes:

- voorselectie van produkten/leveranciers, opstellen short-list van circa 3 hoofdaanbieders

- selectie voorkeursprodukten/leverancier

- uitwerking details van de levering en de leveringsvoorwaarden.

De offerte-aanvraag dient minimaal te omvatten:

- algemene informatie over de omgeving waarin de 11 geplaatst zal worden

het logisch ontwerp geinventariseerde kwan titeiten

programma van [kwalireitsleisen voor de toe te passen produkten gewenste ondersteunende diensten (test/pilot, installatie, service/onderhoud, support); verdeling van verantwoordelijkheden tussen de eigen organisatie en de aanbieder

een acceptatieprocedure

leveringslproiectjvoorwaarden [tijd, geld, garantie, geschillen etc.) lay-out van de op te stellen offerte, waaronder in ieder geval voor de tweede en derde ronde van de offerteprocedure:

algemene iniormatie over de Ieverancierls]

een heldere indicatie in welke mate aan het logisch ontwerp en de andere eisen/wensen uit de offerte-aanvraag voldaan wordt een helder en voldoend uitgewerkt fysiekontwerp

volledige produkt/componentbeschrijvingen

een plan van aanpak voor de levering, installatie, acceptatie en andere te leveren diensten/werkzaamheden

een overzicht/beschrijving van televatite referenties een kostencalculatie, stuks- en verrekenprijzen.

De offerte-aanvraag en de offertes van de eerste ronde kunnen van beperkte diepgang ziin, uiteraard zonder dat het discriminerend vermogen verdwijnt.

25

Tabel4.3

WAN technieken

Knooppunt

Netwerkprotocol Datalink/transmissietechniek

Switch

X.2S PDN, ISDN, ATM,

;::;:-:-:::-::-::- --;S;;:;N~A~----_--_framerelay,

Router IP, IPX HDLC/SDLC,

CONS/CLNS huurlijnen

~FE~P~--------~id~e-m~swrt~·~ch~/~ro-~~er-----

Tabe14.4

LAN technieken

Knooppunt

LAN protocol

Transmissiemedium

Bridge Router Hub

Ethernet Tokenring FOOl Framerelay ATM

UTP

STP glasvezel draadloos/RF

Raamwerlc plan van aanpak Technische Infrastructuur

Het verdient aanbeveling spoedig na verzending van de offerteaanvraag deze mondeling toe te lichten aan de ontvangers.

4.4 Activiteiten in de fysiekontwerpfase

De fysiekontwerpfase bestaat uit 4 stappen:

- afronding eerste fase offerte-procedure: voorselectie aanbieders

- tweede fase offerte procedure: produkt/leverancier selectie

- uitwerken logisch-ontwerp tot fysiekontwerp

- derde fase offerte-procedure: uitwerking van de overgebleven

offerte tot een [voorlopig] bestek waarin feitelijke leveringen en installatie worden vastgelegd, vaststellen leveringslproiectlvoorwaarden.

4.4.1 Aftonding eetste [ase offerte-procedure

Aan de hand van de ontvangen offertes en de vooraf opgestelde criteria en prioriteiten worden de offertes globaal beoordeeld en vergeleken. Op grond van deze eerste [globale] vergelijking wordt een short-list opgesteld.

4.4.2 Tweede fase ofiette-ptocedure

Doel van de tweede fase is de selectie van de combinatie van voorkeursprodukten en -Ieveranciers, Daartoe dienen de leveranciers een tweede meer gedetailleerde offerte op te stell en aan de hand van een tweede meer gedetailleerde offerte-aanvraag,

De evaluatie van de offertes geschiedt nu nauwkeuriger mede aan de hand van de vooraf gedefinieerde meetlat.

4.4.3 Uitwetking fysiekontwerp

Bij het opstellen van het fysiekontwerp ziin er twee mogeliikheden: - het ontwerp wordt door de leverancier gemaakt en is mede resultaat van de derde ronde van de offerte-procedure

- het ontwerp wordt door de organisatie zelf gemaakt en is input voor de derde ronde van de offerte-procedure.

In het eerste geval kan direct de derde ronde ingegaan worden.

26

rsaarnwerx plan van aanpak Technische Infrastructuur

Nu de produkten gekozen ziin kan het fysiekontwerp opgesteld worden:

- een uitwerking van het WAN, per knooppunt:

de configura tie van de gebruikte apparatuur

· een definitie van de gebruikte transmissiewegen

· de configuratie van het beheerssysteem

een uitwerking van het LAN per plant/gebouw en segment: de configuratie van de gebruikte apparatuur

de verbindingen/bekabeling tussen de segmentknooppunten en de knooppunten binnen de segmenten

de bekabeling tussen de knooppunten en de aansluiting op de werkplek

de configuratie van het beheerssysteem per platform per netwerkdienst:

de hardwareconfiguratie en koppeling met het netwerk

· de software configura tie.

4.4.4 Detde [ase ofiexte-piocedure

In de derde £ase van de offeree-procedure dienen de feitelijke levering en alle leveringsvoorwaarden in detail uitonderhandeld te worden. Tevens dient de leverancier akkoord te gaan met het opgestelde fysiekontwerp, dan weI zelf dit ontwerp op te leveren.

,

Afhankelijk van de complexiteit van 11 of onderkende risico's kan in deze fase tevens in een testopstelling de goede samenwerking van aIle componenten (en de bestaande 111 getoetst worden. De toets wordt in ieder geval ook in de ontwikkelings£ase uitgevoerd en geldt daarom altijd als ontbindende voorwaarde bij het sluiten van contracten in deze £ase.

27

Raamwerlc plan van aanpak Technische Infrastructuur

4.5 Specificatie beheer- en support

In de architectuurfase is reeds globaal aangegeven wat de verantwoordelijkheden van de beheerorganisatie zijn en welke soort ondersteuning aan de afnemer van de TI wordt geboden.

In de ontwerpfase dienen deze verantwoordelijkheden en ondersteuning vertaald te worden in:

- beheerstaken en procedures

- ondersteunende dienstverlening (support) en procedures

- inzet en gebruik van hulpmiddelen voor beheer (wisselwerking

met de activiteiten logisch- en fysiekontwerp)

- her programma van eisen voor een SLA tussen beheerder en afnemer

- een beschrijving van de beheer- en supportorganisatie (wie doet wat].

Tevens dient in de ontwerpfase de beheer/supponorganisatie daadwerkelijk opgesteld te worden. De betreffende medewerkers kunnen in de ontwikkelingsfase vervolgens het SLA en de procedures uitwerken, en de gebruikers- en beheerdershandboeken opstellen.

I

28

Raamwerk plan van aanpak Technische Infrastructuur

5 Ontwikkelfase

5.1 Inleiding

De ontworpen technische infrastructuur wordt doorgaans gerealiseerd met standaardapparatuur en -programmatuur van verschillende leveranciers en zal moeten samenwerken met verschillende bestaande systemen. In de ontwikkelingsfase wordt de finale toetsing uitgevoerd of de verschillende componenten (ook) bij grootschalige toepassing en in de bestaande omgeving goed met elkaar samenwerken. In deze fase wordt voor alle technisch problemen een werkbare oplossing gezocht hetzij door (maatwerk) aanpassingen of aanvullingen (fixes) hetzij door het omzeilen (work-around) van het probleem.

Voor alle toe te pass en componenten geldt tevens dat zij op de juiste wiize (in de specifieke context van de betreffende 11) geinstalleerd en geconfigureerd moeten worden. In de ontwikkelfase worden deze installatiewijzen en configuratie-instellingen bepaald.

In de ontwikkelfase wordt ook in detail invulling gegeven aan de inrichting van de beheertools, per type component en voor de totale TI.

De activiteiten van de ontwikkelfase zijn erop gericht om van de verschillende losse onderdelen een werkend geheel, c.q. een werkend produkt te maken. Bij dit produkt behoren ook handboeken voor beheer/support en voor de gebruiker.

Het is de primaire verantwoordelijkheid van een beheersorganisatie om de stabiliteit van de 11 te "andhaven, zodat het dienstenniveau gerealiseerd kan worden dat met de gebruikersorganisatie is overeengekomen. Het invoeren van het uiteindelijke produkt is dan ook een taak voor de beheersorganisatie.

29

Figuur 5.1 Ontwikkelfase

Ontwikkeling

Techniek

• Configuraties/instellingen

• Flxes/wcrk-arounde

• Integratietest

Beheer & su ort

• Handboeken ·SLA

• Ingewerkte organisatie

• Leveringscontracten

Implementatie voorbereiding

• Pilot

• Draait70ek

07TGIN817

Figuur 5.1 Ontwikkelfase

Ontwikkeling

Techniek

• Configuraties/instellingen

• Fixee/work-arounde

• Integratietest

Beheer & su ort

• Handboeken ·SLA

.Ingewerkte organisatie • Leveringscontracten

Implementatie voorbereiding

• Pilot

• Draaiboek

Raamwerk plan van aanpak Technische Infrastructuur

5.3 Uitwerking techniek

De uitwerking van de techniek betreft: . beheertools

. fixes/workaronds - acceptatietest.

5.3.1 Testopstelling in laboratotiutn omgeving

Tijdens de onrwikkelfase zal veelvuldig gebruik gemaakt worden van een uitgebreide testopstelling. Dit gebruik betreft:

- eerste toetsing van het ontwerp [als dar nog niet is gedaan in de

onrwerpfasel

- ontwerpen, maken en testen van fixes en workarounds

- testen van de beheertools

- integratietest van alle componenten in/met de bestaande omge-

ving.

Am her begin van de ontwikkelfase dient de testomgeving gemstalleerd te worden. De testomgeving zal doorgaans gedurende de gehele ontwikkelfase in gebruik blijven.

5.3.2 Beheettools

Binnen de 11 zal onder meer gebruik gemaakt worden van hulpmiddelen voor het operationele of technische beheer. Het beheer betreft: - monitoring van de status van de componenten

- prestatiebeheer

- foutdetectie en diagnose

beveiliging

- configuratiebeheer

- accounting.

In het ontwerp is reeds aangegeven welke middelen waanoe ingezet zullen worden. In de ontwikkelingsfase dient met name de samenhang en integratie van de beheersystemen van de verschillende componenten en ook van de bestaande system en in detail uitgewerkt te worden.

Vele netwerkcomponenten ondersteunen bijvoorbeeld SNMP. In de ontwikkelfase kan een overkoepelend SNMP beheersysteem ontwikkeld worden.

31

Raamwerlc plan van aanpak Technische Infrastructuur

De instelling van de beheerssystemen dient afgestemd te worden op de wensen van het functionele beheer en de afspraken die in de SLA's worden gemaakt. Zo kunnen in de SLA's bijvoorbeeld afspraken gemaakt zijn over managementrapportages over genoemde beheersaspecten [zeals het aantal inbraakpogingen, frequentie en omvang van piekbelasting, inhoud van route- en autorisatietabellen, aantal en aard alarmmeldingen etc.].

Ook de supportorganisatie kan aangewezen ziin op gebruik van beheertools. De mogelijkheid daartoe dient in de ontwikkelfase

gerealiseerd te worden. .

De supportorganisatie zal doorgaans storingsmeldingen opnemen en over de voortgang van de storingsafhandeling moeten kunnen rapporteren. Dit kan ondersteund worden met een informatiesysteem dat in de ontwikkelfase gerealiseerd moet worden.

Tot slot kunnen er mogelijk tools ontwikkeld worden die de installatiewerkzaamheden en het onderhoud vereenvoudigen [bijvoorbeeld voor softwaredistributie en -installatie.

5.3.3 Fixes/workarounds

Voor geconstateerde technische problemen dienen oplossingen gespecificeerd, ontworpen en gerealiseerd te worden. De oplossingen kunnen bestaan uit:

- [tiideliike] wijzigingen van het ontwerp

- maatwerk hardware en/of software

- richtlijnen voor de beheer- en supportorganisatie

richtlijnen voor de gebruiker.

5.3.4

Acceptatietest

De te realiseren TI zal na installatie een acceptatietest moeten ondergaan. Afhankelijk van de situatie is er sprake van een acceptatietest met een opleveraar en een acceptant, of van een ketting van opleveringen. Bijvoorbeeld:

- de leverancier levert op aan de operationele beheerorganisatie, de operationele beheerorganisatie levert op aan de gebruiker

- de leverancier levert op aan de technische beheerorganisatie, de technische beheerorganisatie levert op c.q. draagt over aan de operationele beheerorganisatie, de operationele beheerorganisatie levert weer op aan de gebruiker.

32

I

Raamwerlc plan van aanpak Technische Infrastructuur

5.4.2 Maken haiidboeken

Het vastgestelde ontwerp en de uitwerking daarvan in de ontwikkelfase stellen eisen of geven richting aan de installatie, het beheer/support en het gebruik van de TI. Dit dient vastgelegd te worden in handboeken. Daarbii is het niet de bedoeling de handboeken van de leverancier te herschriiven maar hierop een situatie-afhankelijke aanvulling te geven.

Beheerdetsiuuidboek:

- installatie/configuratie procedures, voorschriften en instellingen

- voor opstarten en herstarten procedures

- revisieprocedure voor hardware/software

- diagnosemethoden

- methoden voor het verzamelen van managementinformatie.

Supporthandboek:

- meldprocedure voor storingen en klachten

- afhandelingsprocedure voor storingen en klachten

- procedure voor escalatie van problem en.

Gebruikersbandboek:

- omschrijving TI-diensten

- verwerving en initiatie van de Tl-diensten

- vereist opleidings- en kennisniveau voor gebruik van de TI

- dienstverlening van de helpdesk en de beheerorganisaties

- gebruikshandleiding en instructie.

5.5 Beschermde pilot

Doel van de pilot is het testen van alle (technische en niet-technische] componenten van de TI in de praktijk. Tijdens de pilot worden vooral de beheersbaarheid van de TI en de gebruikersacceptatie getoetst.

De pilot zal veelal in een beschermde omgeving plaatsvinden waarin extra aandacht geschonken kan worden aan de voorbereiding en uitvoering van de TI- en de gebruikersactiviteiten. Problemen dienen immers voorkomen dan weI tijdig onderkend en gecorrigeerd te worden.

34

Raamwerk plan van aanpak Technische Infrastructuur

De pilot kan beschouwd worden als een project op zich. Bij de voorbereiding en uirvcering van de installatie zal gebruik gemaakt worden van (een conceptversie van] het implementatiedraaiboek.

5.6 Opstellen implementatiedraaiboek

Het implementatiedraaiboek is een gedetailleerd activiteitenplan voor de invoering van de TI. De activiteiten ziin gericht op:

- vaststellen van het definitieve bestek (fysiekontwerp)

- installatievoorbereiding:

bestellen apparatuur etc. . opleiden gebruiker

. site preparation

- installatie en test

- handboeken up to date maken

- completeren documentatie

- opstellen communicatieplan

- bedriifsvaardig oplevering.

35