INHOUDSOPGAVE. Van de redactie 3. Column: Mag het een beetje meer wezen? 4 Gert van der Pijl. Reactie op de column van Anton Tomas 6 Ad de Visser

Transcriptie

1 Colofon De EDP-Auditor is een uitgave van de Nederlandse Orde van Register EDP-Auditors. Redactieraad drs. J.P. Harmens RE RA drs. M.A. Bongers RE RA drs. H.A. Kampert RE RA prof. ir. E.F. Michiels prof. dr. ir. J.A.E.E. van Nunen J.C. Vos RA H. de Zwart RE RA Redactie drs. Th.M.J.Gerritse RE drs. W.T. Houwert RE prof. dr. G.J. van der Pijl RE drs. E.J.M Ridderbeek RE CISA drs. R.J.Steger RE RA ir. A.J. Tomas RE RI RO drs. Th. Wijsman RE Eindredactie prof. dr. G.J. van der Pijl RE Bureauredactie M. Keyzer Uitgever Reed Business Information BV Postbus AD Amsterdam Tel.: Abonnementen De EDP-Auditor wordt kosteloos aan de leden van de NOREA verzonden. De abonnementsprijs voor niet-leden bedraagt voor ,65 excl. btw. De verzendtoeslag voor België bedraagt 6,95 en voor de Nederlandse Antillen en overige landen 21,55. De prijs van losse nummers is 21,53 excl. btw. Per jaar verschijnen 4 nummers. Een abonnement kan worden beëindigd door schriftelijk vóór 1 november van een lopend jaar op te zeggen. Bij niet-tijdige opzegging wordt het abonnement met een jaar verlengd. Abonnementenadministratie en lezersservice Reed Business Information BV Postbus 4, 7000 BA Doetinchem Tel.: Fax: klantenservice@reedbusiness.nl Copyright Het geheel of gedeeltelijk overnemen van artikelen, schema s of tekeningen uit deze uitgave is slechts toegestaan na voorafgaande schriftelijke toestemming van de uitgever. ISSN Bijdragen De redactie nodigt lezers uit een bijdrage te leveren aan de EDP-Auditor. U kunt uw bijdrage sturen naar de bureauredactie. Advertenties Elsevier Media Amsterdam Tel.: Fax: info.ema@reedbusiness.nl Geldend advertentietarief Vormgeving Studio Putto BNO, De Rijp INHOUDSOPGAVE Van de redactie 3 Column: Mag het een beetje meer wezen? 4 Gert van der Pijl Reactie op de column van Anton Tomas 6 Ad de Visser Een audit op informatiearchitectuur: waar te beginnen? 9 Ruurd Smildiger De Wireless Toolbox van de IT-auditor 20 Mauriche Kroos en Robbert Kramer Ketenauditing in de publieke sector, complex en daarom spannend! 28 Anastasia van der Meer en Leon Dirks Virtualisatie en de IT-auditor 39 Bert Rechter IT-auditor: adviseur of controleur? 44 Interview met Paul van Kessel en reactie van Rob Fijneman Wilfried Olthof en Rainer Steger Een dag uit het leven van 50 Arno Nuijten Automatiseringsbedrijf wint tuchtprocedure tegen RE RA 52 Kor Mollema Boekbespreking 55 Kracht van de vernieuwing; Visies op ICT Thomas Wijsman Van de NOREA Mededelingen 57

2 de EDP-Auditor nummer Van de redactie Het is begin augustus en de eerste drukproef van dit nummer is binnen. Bij afwezigheid van de redactievoorzitter, zoals zo velen momenteel op vakantie, aan mij de eer om dit keer Van de redactie te mogen verzorgen. Het weer in Nederland valt tegen, maar in mijn ogen niet de eerste drukproef. Bij het doorlopen hiervan constateer ik dat dit nummer zeer divers van samenstelling is. Voor elke ITauditor wat wils! Ik ben als redactielid dan ook zeer blij met de kwaliteit en de samenstelling. Zal ik alvast een tipje van de sluier oplichten inzake hetgeen u in dit nummer tegenkomt? Hier gaan we dan! Onze redactievoorzitter Gert van der Pijl heeft voor een prikkelende column gezorgd, waarin hij ingaat op mogelijk kruideniersgedrag binnen de beroepsgroep. Mag het een beetje meer zijn of juist wat minder bij het bepalen van scope van een audit is een van zijn stellingen. Maken wij ons hieraan schuldig? Ook dit keer geeft de column voldoende stof om na te denken. Ad de Visser gaat vervolgens in op een eerdere column, geschreven door mijn collega-redactielid Anton Tomas. Hij reageert op Antons uitspraken inzake auditopleidingen en de ervaring die een IT-auditor minimaal zou moeten hebben. Hierbij brengt Ad een aantal nuances aan. Ik roep u hierbij op om vaker op deze wijze op columns te reageren! Ruurd Smildiger gaat in op het vraagstuk of en op welke wijze je informatiearchitectuur kunt auditen. De ermee gemoeide begrippen passeren de revue en ook geeft hij een aantal (inrichtings)normen inzake dit onderwerp. Het artikel biedt handvatten om een informatiearchitectuur te kunnen beoordelen. Mauriche Kroos en Robbert Kramer hebben reeds in de EDP-Auditor 4/2004 aandacht besteed aan WLAN-netwerken. In het eerste artikel hebben zij ons over het wat verteld, nu gaan ze in op het hoe testen ervan. Heeft u de schroevendraaier al paraat?! meerdere ministeries en ook audit teams bij betrokken zijn. Het artikel levert een aantal eye-openers op! Bert Rechter gaat in op het begrip virtualisatie. Dit houdt in dat software op een dusdanige wijze wordt gebruikt dat hardware of een gehele computeromgeving anders dan die waar de software feitelijk op draait, wordt geëmuleerd. Bert wijst de lezer op deze ontwikkeling en geeft aan dat dit aanvullende eisen aan de IT-auditor stelt bij het onderzoeken van een dusdanige omgeving. Rob Fijneman en Paul van Kessel hebben onder meer met elkaar gemeen dat zij beiden voorzitters zijn van een ITauditing-praktijk van een big four-kantoor en tevens hoogleraar zijn. Mede naar aanleiding van de recente oratie van Rob hebben Wilfried Olthof en ik over de toekomst van het beroep gesproken. Ik kan u verzekeren dat dit tot een aantal krachtige uitspraken van de beide heren heeft geleid! Dit keer heeft Arno Nuijten onze rubriek Een dag uit het leven van verzorgd. Hij doet dit op een wel zeer bijzondere wijze! Kor Mollema gaat in op een recente tuchtrechtuitspraak. Aan de hand van een chronologische opbouw van feiten vertelt hij ons waar de casus betrekking op heeft en tot welke beslissingen de Raden en het College zijn gekomen. Ten slotte wordt dit nummer met een boekbespreking en mededelingen van het NOREA afgesloten. In de laatst genoemde rubriek roept mijn collega-redactielid Thea Gerritse u op om uw ervaringen inzake het gebruik van internet bij audits met ons te delen. Wij kijken al uit naar verfrissende invalshoeken! Ik wens u veel leesplezier toe. Rainer Steger De auteurs Anastasia van der Meer en Leon Dirks gaan in op ketenauditing in de publieke sector. Zij geven aan dat het een complex vraagstuk is, als gevolg van het feit dat er

3 4 de EDP-Auditor nummer Column Mag het een beetje meer wezen? Gert van der Pijl Een vraag gesteld door een collega: vertonen wij als ITauditors geen trekjes van kruideniers? Als wij verwikkeld zijn in wervingstrajecten, kunnen we het dan laten onze cliënten de vraag te stellen: mag het ietsje meer zijn? Met andere woorden, proberen wij onze cliënten altijd een stukje extra werk aan te smeren, misschien niet met het primaire doel die klant ook daadwerkelijk verder te helpen, maar vooral met het doel onze omzet te vergroten. We leven immers in een maatschappij waarin ieder van ons individueel wordt beoordeeld op zijn of haar prestaties. En het creëren van omzet is daarbij een niet onbelangrijk beoordelingscriterium. IT-auditing-organisaties zijn commerciële instellingen en daar is dergelijk gedrag gewenst. Het zou dus niet zo verwonderlijk zijn als er iets bestaat als een natuurlijke drive om onze omzet te vergroten. Wie zou het ons kwalijk nemen als we naar goed koopmansgebruik onze klant wijzen op de vele manieren die er veelal te bedenken zijn om de scope van de opdracht te verbreden en hem daardoor een beetje meer met een grote meerwaarde te leveren. Waarom zouden we ons beperken tot een quick scan als er ook ruimte lijkt te zijn voor een niet alleen breed maar ook diepgaand onderzoek? Waarom alleen maar kijken naar de betrouwbaarheid van de financiële informatievoorziening als we met een klein beetje extra moeite ook een oordeel kunnen geven over de kwaliteit van de managementinformatievoorziening in zijn geheel? Waarom de risico-analyse niet Prof. Dr. G.J. van der Pijl RE is hoogleraar IT-auditing aan de Erasmus Universiteit te Rotterdam, Program Director van de Eurac opleiding EDP-auditing en Director of Research van Eurac bv. uitgebreid van de primaire processen tot een aantal belangrijke ondersteunende. En we hebben de wind mee: Sarbanes Oxley en Tabaksblat lijken de weg te banen tot een grote drift tot beheersing en zelfs bedrijven die niet onmiddellijk gedwongen zijn deze regelgeving na te leven omdat ze niet beursgenoteerd zijn, komen toch onder de druk om te zorgen dat hun organisaties in control zijn. Een beetje extra audit kan daarbij nooit kwaad. Als wetenschapper moet ik voorzichtig zijn met het doen van uitspraken waarvoor ik niet uit eigen of andermans ervaring voldoende empirisch materiaal heb kunnen verzamelen. Helaas is het zo dat over de concrete uitvoering van het IT-auditing-beroep en de wijze waarop opdrachten worden geworven heel weinig is geschreven en nog minder met wetenschappelijke methoden is onderzocht. Ik moet dan ook veel terughoudendheid betrachten bij het doen van uitspraken over het realiteitsgehalte van bovenstaande beschouwing. Wat ik wel kan doen is wat doorredeneren op het bovenstaande en me afvragen of het nu eigenlijk goed of slecht zou zijn als de door mijn collega gestelde vraag met ja zou moeten worden beantwoord en IT-auditors dus inderdaad kruidenierstrekjes zouden bezitten. Vanwege mijn positie als hoogleraar met wat meer afstand tot de dagelijkse praktijk komt een dergelijke beschouwing uit onverdachte hoek. Ik heb immers geen commercieel belang bij de uitkomst daarvan. Laten we dus op dat spoor verdergaan. Een redenering naar analogie van ons voorbeeld is dan op zijn plaats. Het beeld van de kruidenier die altijd meer wil verkopen heeft voor de meeste mensen een negatieve bijklank. Het wordt, zo lijkt het, niet erg op prijs gesteld dat de kruidenier zijn klanten altijd iets meer wil leveren dan gevraagd, met de bedoeling daarmee meer omzet te creëren. Maar is dit

4 de EDP-Auditor nummer gedrag nu werkelijk zo negatief als het lijkt? Het antwoord op die vraag is naar mijn idee minder voor de hand liggend dan je zou denken. Het is afhankelijk van de aard van het verkochte product en van de kennis daarvan bij consument respectievelijk leverancier, in ons voorbeeld dus de kruidenier. Wanneer het gaat om een simpel product, waarvan de consument zelf voldoende kennis heeft, is er geen geldige reden voor het beetje meer gedrag van de leverancier. De klant weet immers donders goed wat zijn eigen behoeften zijn en als het om een eenvoudig product gaat heeft hij er ook geen moeite mee om die behoefte om te zetten in een concrete vraag naar een concrete hoeveelheid product. Heel anders wordt het als het gaat om een complex product waarvan de leverancier veel kennis heeft maar de consument veel minder. In termen van de theorie over het afsluiten van contracten spreken we dan van een situatie met informatieasymmetrie. In dat geval is het voor de klant veel lastiger zijn wensen te vertalen in een concrete bestelling. Is het bijvoorbeeld beter om dat complete pakket met ingrediënten voor een oosterse maaltijd aan te schaffen of is het voordeliger de ingrediënten los aan te schaffen? En hoe staat het met de kwaliteit van de producten in beide varianten? Zijn ook andere combinaties mogelijk? Is er een voor- of nagerecht dat als beetje extra zou kunnen worden meegenomen en dat voor weinig geld veel toegevoegde waarde levert? Nu kan de leverancier met zijn grote productkennis en waarschijnlijk ook kennis van de behoeften van verschillende typen gebruikers een belangrijke rol spelen. Hij kan de klant in de genoemde dilemma s adviseren en hem zo helpen tot een veel verstandiger keuze te komen dan deze geheel op eigen kracht had gekund. Wel is het zo, dat daarbij niet alleen beetje meer - maar ook beetje minder -varianten als advies denkbaar zijn. Kruideniersgedrag zou in dat geval kunnen betekenen: kennis van zaken betreffende de geleverde producten en inzicht in de behoeften van de klant. Wel zou de contractingtheorie vragen dat er mechanismen zijn die garanderen dat de klant een advies krijgt waarmee zijn doelen gediend zijn en dat niet primair bedoeld is om de zakken van de leverancier te spekken. De parallel met IT-auditors is nu makkelijk te trekken: daar waar sprake is van eenvoudige auditproducten heeft de klant weinig behoefte aan een beetje meer houding van de IT-auditor. Integendeel: een dergelijke houding zou het vertrouwen van auditklanten in hun leverancier op de lange termijn ernstig kunnen schaden. Maar daar waar, zoals vaak het geval, sprake is van complexe auditproducten is het goed als de IT-auditor kruideniersgedrag in positieve zin laat zien en de klant met kennis van zaken adviseert, bijvoorbeeld over diepgang en reikwijdte van de uit te voeren audit. In sommige gevallen kan dit leiden tot een beetje meer -advies, bijvoorbeeld in die gevallen waar een te smalle scoping van de audit ertoe leidt dat de problematiek van de klant niet werkelijk wordt opgelost. In andere gevallen zou het advies moeten luiden een beetje minder, bijvoorbeeld in gevallen waar een quick scan al veel inzicht kan verschaffen terwijl de klant vraagt om een breed en diepgaand onderzoek. In beide gevallen redeneert de auditor primair vanuit het belang van de klant. Terugkomend op de vraag die aanleiding gaf tot deze column concludeer ik dan ook dat wij auditors best wat meer de kruidenier mogen zijn, maar dan wel in de goede zin van het woord: soms een beetje meer, maar alleen als dat nodig is, en in andere gevallen een beetje minder om de klant niet onnodig op kosten te jagen.

5 6 de EDP-Auditor nummer Reactie op de column van Anton Tomas Ad de Visser Maar doodslaan deed hij niet, want tussen droom en daad, staan wetten in de weg en praktische bezwaren, W. Elsschot Anton Tomas heeft al vaker een prikkelende bijdrage geschreven in de EDP-Auditor. Deze las ik dan met veel interesse, dacht er nog even over na en ging vervolgens weer over tot de orde van de dag. Dit zal waarschijnlijk bij meerdere lezers het geval zijn geweest, want er volgde zelden een publieke reactie op zijn uitdagende stellingen. De boodschap van Tomas in zijn meest recente column Over de auditorsfuik en het nut van auditopleidingen intrigeerde mij echter zodanig dat een reactie ditmaal niet kon uitblijven. Is het inderdaad zo dat het uitvoeren van diepgaande IT-audits is voorbehouden aan mensen die een gedegen IT-kennis bezitten en ruime werkervaring in IT hebben opgedaan? Het interessante aan het betoog van Tomas is dat het op een aannemelijke wijze enkele bekende feiten samenvoegt en hier een verrassende conclusie aan verbindt. Hij ondersteunt zijn argumentatie met voorbeelden, zoals een allegorie uit de bouwsector en een beschrijving van een praktijksituatie waarin niet-auditors een audit uitvoeren op het gebied van informatiebeveiliging. Indien Tomas gelijk heeft, lijkt er dus in de toekomst geen plaats meer te zijn voor al die mensen met relatief weinig werkervaring en ook nog met een vooropleiding in het verkeerde vakgebied, die onze postdoctorale opleidingen bevolken. Tot op zekere hoogte heeft Tomas natuurlijk ook gewoon gelijk. Het is niet mogelijk IT-audits uit te voeren zonder een zekere affiniteit te hebben met het desbetreffende domein. Kennis van IT is onontbeerlijk en werkervaring in IT een pré. Dat deze condities geen voldoende voorwaarde zijn om IT-audits uit te kunnen voeren, wordt door A.A.C. de Visser is werkzaam bij Fortis Audit Services/ICT Audit, en is tevens als docent verbonden aan de Postdoctorale opleiding EDP-Auditing aan de Erasmus Universiteit Rotterdam. Tomas impliciet onderkend. Hij stelt immers dat: zelfs IT-deskundigen een aanvullende IT-audit-opleiding nodig hebben. Hij is echter te stellig als hij vervolgens beweert dat beide condities noodzakelijk zijn voor het kunnen uitvoeren van (diepgaande) IT-audits. Dit laatste is wat mij betreft onderwerp van discussie en zeker geen uitgemaakte zaak! Hoewel hij dit niet expliciet in zijn column vermeldt, refereert Tomas in zijn betoog, mijns inziens, aan twee bekende vraagstukken in IT-auditing, te weten: 1) is een goede IT-auditor een generalist of een specialist, en 2) is ITauditing ambacht of wetenschap? Deze vraagstukken zorgen voor een regelmatig terugkerende discussie tussen vakgenoten, maar kennen tot op heden geen algemeen geaccepteerde oplossing. Dit is tevens de kracht van het betoog van Tomas. Hij kiest ongemerkt positie in het aloude debat tussen generalist/specialist en academici/vaklieden en voegt daardoor stilzwijgend het volledige gewicht van deze positie toe aan zijn argumenten. In deze reactie zal ik enkele argumenten geven om de stellingen van Tomas te nuanceren. Ik doe dit aan de hand van een alternatief perspectief op de in zijn column geïntroduceerde audittypologie. De eerste twee soorten rechtvaardigen volgens Tomas geen universitaire auditopleiding: Ze gaan niet diep en in de kern komt het neer op het afvinken van een rijtje regels. Het is zelfs heel goed denkbaar dat een groot deel van dit soort audits in de toekomst verregaand geautomatiseerd zal plaatsvinden. Het derde type IT-audit heeft als kenmerk dat de auditor diepgaand de werking van een bepaald technisch of organisatorisch systeem doorgrondt en analyseert en zich een mening vormt over de betrouwbaarheid van de functionaliteit ervan. Het uitvoeren van dit laatste type IT-audit vereist volgens Tomas dat de IT-auditor over een gedegen IT-opleiding en relevante werkervaring beschikt. Uit de wijze waarop hij de twee afvink-audits beschrijft, leid ik af dat Tomas deze inferieur acht aan de diepgaande IT-audit. Hij geeft daarmee een waardeoordeel zonder te verklaren waarop dit oordeel is gebaseerd. Waarde is ech-

6 de EDP-Auditor nummer ter een subjectief begrip en wordt in de regel bepaald door de gebruikers van de auditresultaten. In essentie bestaat het eindproduct van een audit uit een kwaliteitsoordeel. De audit kan betrekking hebben op het IT-object zelf (beoordelen van de intrinsieke kwaliteit) of het IT-object in relatie met zijn omgeving (beoordelen van de extrinsieke kwaliteit). De eerste vorm van kwaliteit komt bijvoorbeeld tot uitdrukking in de toegepaste constructie, de gebruikte componenten, de gehanteerde ontwikkelstandaarden, enzovoort, van het IT-object. Audits gericht op het vaststellen van de intrinsieke kwaliteit zijn vooral interessant voor bedrijven in de IT-sector zoals ontwikkelaars en leveranciers van IT-componenten. Het certificeren van producten heeft dan commerciële waarde. Voor het onderzoeken van de intrinsieke kwaliteit van IT-objecten is een gedegen IT-kennis noodzakelijk, bijvoorbeeld op IT-deelgebieden als software engineering, IT-architectuur, cryptografie en IT-security. Ik ben het in dit geval volledig met Tomas eens dat de kennis en kunde van een gemiddelde IT-auditor onvoldoende zijn om een dit soort diepgaande IT-audit uit te voeren. Dergelijke onderzoeken wordt in de praktijk dan ook veelal uitgevoerd door een team van IT-deskundigen werkzaam bij officiële test- en certificeringlaboratoria zoals TNO en NSA. De tweede vorm van kwaliteit komt tot uitdrukking in de bijdrage van een IT-object in een specifieke context. Denk bijvoorbeeld aan het gebruik of de inzet van het IT-object in een logistiek proces. Auditresultaten met betrekking tot de extrinsieke kwaliteit zijn vooral interessant voor het (lijn)management dat bijvoorbeeld wil weten in welke mate IT-objecten het realiseren van bepaalde bedrijfsdoelstellingen ondersteunen. Het lijkt erop dat de zogenaamde afvink-audits uit de audittypologie van Tomas voornamelijk in audits met betrekking tot de extrinsieke kwaliteit van IT-objecten terug te vinden zijn. Hoewel een checklist in de IT-audit-praktijk een vaak voorkomend hulpmiddel is, impliceert dit niet onmiddellijk dat een groot deel van dit soort audits in de toekomst verregaand geautomatiseerd zullen plaatsvinden. Automatiseren is alleen mogelijk in situaties waarbij er een eenduidige interpretatie bestaat omtrent bijvoorbeeld norm, meetwaarden en beslissingsmodel. In de praktijk zal dit alleen voor een beperkt aantal IT-audits van toepassing zijn. Audits naar de extrinsieke kwaliteit van ITobjecten hebben veelal betrekking op complexe beheer- en sturingsvraagstukken waarbij het van belang is een multidisciplinaire benadering te hanteren. De IT-auditor zal bij het beoordelen van de extrinsieke kwaliteit van een IT-object rekening moeten houden met de specifieke context waarin dit object zich bevindt. Hiertoe gebruikt de IT-auditor kennis uit de relevante disciplines, zoals bedrijfskunde, informatica, bedrijfseconomie en auditing. Het is juist deze mix van kennis op het snijpunt van organisatie en techniek die nodig is bij de beoordeling van het gebruik van IT-objecten in bedrijfsprocessen. Een te eenzijdige focus op een van deze kennisdomeinen zou mogelijk tot een suboptimaal oordeel kunnen leiden. Uit het bovenstaande valt op te maken dat het merendeel van de IT-audits heden ten dage betrekking heeft op het beoordelen van de extrinsieke kwaliteit van IT-objecten en dat er ook bij dit perspectief sprake is van diepgaande IT-audits. Wat resteert is de vraag of het noodzakelijk is over gedegen IT-kennis te beschikken en/of ruime werkervaring in IT te hebben om dit soort IT-audits uit te voeren, zoals Tomas beweert? Ik ben van mening dat ook de theoretische RE over voldoende kennis en kunde be - schikt om een diepgaande IT-audit uit te kunnen voeren naar de extrinsieke kwaliteit van IT-objecten. Voordat ik deze bewering nader toelicht, zal ik eerst een voorbeeld geven afkomstig uit de klinische psychologie. Gedurende haar opleiding krijgt een psychologiestudente een grote hoeveelheid theorie aangeboden. De vele modellen en concepten ontwikkelen de sensibiliteit van de studente, waardoor zij in staat is om diverse ziektebeelden te kunnen onderscheiden en herkennen. Tevens wordt aandacht gegeven aan veel voorkomende behandelmethoden (de zogenaamde best practices) en handelingskennis. Daarna volgt een praktijkstage. Daarin leert de studente bijvoorbeeld diagnoses te stellen en scherpt ze haar oordeelsvorming met betrekking tot de ernst van aandoeningen of complicaties. Gedurende de opleiding is er dus aandacht voor zowel theoretische kennis alsmede het opdoen van praktische ervaring. Beide condities zijn noodzakelijk om uiteindelijk zelfstandig als klinisch psycholoog aan de slag te kunnen. Je hoeft dus niet psychotisch te zijn (geweest) om een psychose te kunnen diagnosticeren of behandelen! De postdoctorale opleidingen EDP-Auditing kennen een soortgelijke structuur als in het bovenstaande voorbeeld, maar dan in een wat meer gecomprimeerde vorm. De student krijgt, meestal in het eerste jaar, relevante theorieën aangeboden afkomstig uit de onderliggende disciplines van IT-auditing. Door middel van deze theorieën ontwikkelt de sensibiliteit van de student ten aanzien van de specifieke problemen in het aandachtsgebied. De focus ligt

7 8 de EDP-Auditor nummer daarbij niet eenzijdig op informatica, maar benadrukt vooral het multidisciplinaire aspect. Daarnaast krijgen de studenten, veelal in het tweede jaar, een grote hoeveelheid opgaven die zijn gebaseerd op praktijkcases. Het intensief uitwerken en bespreken van deze praktijkcases in groepsverband of individueel scherpt het diagnostische en analytische vermogen alsmede de oordeelsvorming van de student. Het is juist deze combinatie van het aanbieden van multidisciplinaire theoretische kennis en het simuleren van praktijksituaties dat maakt dat de opleiding EDP-Auditing niet alleen compenseert voor een eventueel gebrek aan werkervaring in IT, maar bovendien een goede basis levert om audits naar de extrinsieke kwaliteit van IT-objecten te kunnen uitvoeren. De verplichting om daarnaast ten minste drie jaren relevante werkervaring te hebben, maakt dat ook de theoretische RE in staat is om diepgaande ITaudits uit te voeren. Je hoeft dus niet te kunnen programmeren om de betrouwbaarheid van de functionaliteit van een informatiesysteem te kunnen beoordelen! Hetgeen Tomas voorstelt zal waarschijnlijk een utopie blijken. Er bestaan immers diverse praktische implicaties die de brede doorvoering van zijn voorstel zullen belemmeren. De term IT-deskundige duidt bijvoorbeeld al op een zekere specialisatie. Iemand is deskundig op een specifiek terrein, maar niet noodzakelijkerwijs daarbuiten. Een IT-deskundige ten aanzien van IT-architectuur beschikt waarschijnlijk niet over de kennis om de kwaliteit van een Java-applicatie te kunnen beoordelen. In de praktijk zou de variatie aan IT-audit-specialismen enorm toenemen terwijl tegelijkertijd de inzetbaarheid van de desbetreffende IT-auditors flink zal afnemen. Dergelijke vergaand gespecialiseerde IT-auditors zul je overigens alleen maar bij de Big 4 aantreffen. Interne auditafdelingen zullen in de meeste gevallen een dergelijke specialisatie niet rendabel kunnen maken en moeten overgaan tot het insourcen van deze kennis. Bedrijven die besluiten om hun IT-deskundigen als parttime IT-auditor in te zetten om het werk van collega s te beoordelen, krijgen daarmee geen audits (onafhankelijk!) maar peer reviews. Ten slotte is de auditorsfuik die door Tomas wordt beschreven natuurlijk ook van toepassing op deze IT-deskundigen: zonder dagelijkse IT-werkervaring zal het ze moeilijk vallen hun IT-vakkennis op peil te houden, waardoor het ze onmogelijk wordt na enige tijd alsnog naar een IT-functie te kunnen ontsnappen. Gelukkig heeft de IT-auditor met de verkeerde vooropleiding in dit geval nog andere carrièremogelijkheden Het is de functie van een columnist om een extreme positie in te nemen om daardoor andere mensen aan het denken te zetten. Ik denk dat Tomas daarin uitstekend is geslaagd. Het interessante van zijn column is natuurlijk niet zijn voorstel om het RE-register te sluiten voor personen onder de 35 jaar, maar de beweegreden(en) tot het schrijven ervan. Het zou kunnen dat Tomas niet tevreden is over de prestaties van IT-auditors in het algemeen en hij de oorzaken hiervoor zoekt in de (voor)opleiding van ITauditors. Zijn gegeneraliseerde oplossing heb ik in het bovenstaande, naar mijn mening, voldoende genuanceerd. Het is echter belangrijk te onderkennen dat wij beiden een positie innemen zonder dit te onderbouwen met gedegen en concrete onderzoeksresultaten. De wederkerende vraag of IT-auditing nu een vak of wetenschap is, is niet echt interessant. Het is veel interessanter te vragen of het mogelijk is om wetenschappelijk onderzoek uit te voeren naar of binnen IT-auditing. Aangezien er wereldwijd bij diverse universiteiten reeds auditingonderzoekprogramma s lopen, is het antwoord op deze vraag al gegeven. Ik ben ervan overtuigd dat toegepast wetenschappelijk onderzoek op het gebied van ITauditing noodzakelijk is om de kwaliteit van IT-audits structureel te verbeteren. Zonder dergelijk onderzoek zullen we bijvoorbeeld nooit weten of er een causaal verband bestaat tussen (voor)opleiding van IT-auditors en de kwaliteit van IT-audit-resultaten.

8 de EDP-Auditor nummer Een audit op informatiearchitectuur: waar te beginnen? Stel dat je als IT-auditor gevraagd wordt om een oordeel te geven over de kwaliteit van een informatiearchitectuur. Wat dan? Wat is een informatiearchitectuur? Waar moet je op letten? Wat kun je doen? Ruurd Smildiger Dat die vraag een keer komt is niet ondenkbeeldig. Bedrijven en overheidsinstellingen moeten snel kunnen reageren op marktontwikkelingen en wijzigende wet- en regelgeving. De aanpasbaarheid van de achterliggende systemen blijkt dan vaak beperkt te zijn en gaat met grote inspanningen, dus kosten, gepaard. Terwijl het management juist de noodzaak ervaart dat systemen snel en tegen relatief lage kosten aangepast zouden moeten kunnen worden. Dit stelt eisen aan het systeemontwerp. Vergelijk het maar met het ontwerpen van een huis. Als je de wens hebt om in de toekomst van het dak een dakterras te maken, zul je bij het ontwerp van de dakconstructie en het bepalen van de locatie van een raam (dat later een deur kan worden) al rekening moeten houden met het dakterras. Dat is flexibiliteit inbouwen. Een ander voorbeeld is dat een architect zoekt naar eenvoudige oplossingen indien hij een huis ontwerpt dat meerdere malen gebouwd moet gaan worden en relatief snel en gemakkelijk te bouwen moet zijn. Hij zoekt naar reductie van complexiteit in zijn oplossingen. In de praktijk zijn voor dit soort wensen bij systeemontwerp grofweg twee mogelijke strategieën: 1. Systemen kunnen zodanig worden ontworpen dat ze niet of weinig aangepast hoeven te worden. Dit betekent de realisatie van generieke systemen met een groot aantal parameters. Met deze parameters kan het R. Smildiger is werkzaam bij de Auditdienst van het ministerie van Onderwijs, Cultuur en Wetenschap in de functie van auditor. Sinds 1995 is hij werkzaam als IT-auditor. systeem worden ingesteld op een groot aantal specifieke situaties. Veranderen de omstandigheden, dan worden de parameters in overeenstemming daarmee aangepast. Denk hierbij aan de ERP-systemen. 2. Systemen kunnen zodanig worden ontworpen dat aanpassingen snel en tegen relatief lage kosten worden aangebracht. Deze wens van systeemontwerp heeft geleid tot de architectuurgedachte en de ontwikkeling van informatiearchitecturen. Over deze laatste strategie gaat dit artikel. Onder de kop Maar wat is nu architectuur? zal ik een schets geven van wat informatiearchitectuur kenmerkt. In de paragraaf Alignment leg ik uit wat wellicht de belangrijkste schakel is om een architectuurproject te doen slagen: communicatie met het management. Daarbij wordt de koppeling gelegd met de mogelijke doeleinden van een informatiearchitectuur, namelijk een offensieve of defensieve toepassing. Daarna wordt beschreven hoe een project van informatiearchitectuur past in een systeemontwikkelingsproject. In de paragraaf daarna volgen de aandachtspunten die naast de communicatie van belang zijn voor het doen slagen van de implementatie van de informatiearchitectuur. Dit betreffen procesmatige aspecten. Om een informatiearchitectuur te kunnen beoordelen volgen drie modellen die een hulpmiddel daarbij kunnen zijn. Tot slot is een door mijzelf ontwikkeld normenstelsel opgenomen om de kwaliteit van een informatiearchitectuur te kunnen onderzoeken en die ook specifieke normen bevat voor een project waarin informatiearchitectuur wordt ontwikkeld. Voor het toetsen aan die normen kan één of meer van de modellen worden gebruikt.

9 10 de EDP-Auditor nummer Maar wat is nu architectuur? Als over een architectuur wordt gesproken, wordt vaak meteen gedacht aan een ontwerp van gebouwen. Dit sluit ook aan op de definitie van architectuur die in de Dikke van Dale te vinden is, namelijk: Bouwkunst, de kunst en de leer van het ontwerpen en uitvoeren van bouwwerken. Is een informatiearchitectuur ook een kunst en leer van het ontwerpen en uitvoeren van een informatiebouwwerk? Het Genootschap van Informatie Architecten (GIA) hanteert de volgende definitie van informatiearchitectuur: Een Informatie Architectuur is de architectuur van de informatiehuishouding van een organisatie. In deze definitie tot stand gekomen na een brede discussie met vakgenoten valt op dat er gesproken wordt over informatiehuishouding in plaats van de vaker gebruikte term informatievoorziening. Dit suggereert dat informatie een resultante is van een breder geheel binnen een organisatie dan de afdelingen die direct betrokken zijn bij de informatieverschaffing. Er is inderdaad sprake van een informatiebouwwerk en de hier gestelde vraag kan dus met ja worden beantwoord. Kenmerken van architectuur Een informatiearchitectuur heeft een vijftal definiërende kenmerken. Deze kenmerken zijn een vertaling van de kenmerken die [SAND97] heeft gegeven aan architectuur. Een eerste kenmerk van architectuur is dat deze de structuur van het object beschrijft. Als er sprake is van een informatiearchitectuur wil dit zeggen dat dit het ontwerp van de informatiehuishouding van een organisatie (conform de definitie van het GIA) beschrijft. Dat wil zeggen, beschrijft uit welke componenten de informatiehuishouding van het betrokken bedrijf(sonderdeel) is samengesteld; wat hun functie is, welke bijdrage ze elk leveren aan de bedrijfsuitoefening; welke bijdrage ze elk leveren aan de realisatie van de doelstellingen uit het beleid; hoe de componenten samenhangen. Als tweede kenmerk is genoemd dat architectuur het instrument is om de kwaliteit van het geheel te sturen. Kijkend naar informatiearchitectuur wil dit zeggen dat de informatiearchitectuur een instrument is voor het sturen van de kwaliteit van de informatiehuishouding als geheel. Hiermee wordt bedoeld de mate waarin de informatiehuishouding de bedrijfsuitoefening ondersteunt en flexibel is. Voor de informatiearchitectuur betekent sturen van de kwaliteit in de eerste plaats dat er een duidelijke en zo eenduidig mogelijke relatie is tussen de doelstellingen van het bedrijf en de informatiecomponenten die aan de realisatie ervan een bijdrage leveren. Ten slotte betekent sturen van de kwaliteit van het geheel: suboptimalisatie tegengaan. Naast een duidelijke afbakening van de informatiecomponenten is daarom een goede onderlinge aansluiting van belang. Met andere woorden: binnen de informatiehuishouding zijn geen overlappen ten behoeve van de informatievoorziening en er zijn geen witte vlekken. Het derde kenmerk van architectuur is dat ze uitdrukking dient te geven aan een visie. Daarbij gaat het bij de informatiearchitectuur om de visie die het bedrijfsmanagement heeft op zijn bedrijfsuitoefening en de verbetering van de bedrijfsresultaten. Deze visie dient het uitgangspunt te zijn bij het ontwerpen van de informatiearchitectuur. De concretisering ervan is meestal verwoord in het informatiebeleid. Het informatiebeleid beschrijft op hoofdlijnen de gewenste bijdrage van de informatiehuishouding aan het realiseren van het bedrijfsbeleid. Naast een goede aansluiting op het bedrijfsbeleid betekent dit ook de mogelijkheid snel in nieuwe informatiebehoeften te voorzien, zonder daarbij steeds grote delen van de informatiehuishouding te moeten vervangen. Als vierde kenmerk van architectuur is genoemd dat ze re - sultaat is van onderhandeling. Een informatiearchitect krijgt te maken met veel partijen, eisen en belangen. Deze eis heeft meer betrekking op de wijze waarop de architectuur tot stand komt, dan op de inhoud ervan. Het ontwerpproces moet je zodanig organiseren, dat alle belanghebbende partijen tijdig betrokken worden. Als partijen te laat betrokken worden, hebben ze geen mogelijkheid meer zelf een bijdrage te leveren aan de oplossing. Het risico is dat het commitment voor het resultaat gering zal zijn. Daarnaast is het ook noodzakelijk dat de verschillende eisen met elkaar in overeenstemming zijn gebracht en zichtbaar en helder geformuleerd in het ontwerp zijn verwerkt. Een architectuur beschrijft niet alleen de structuur en de opbouw van het object zelf, maar ook de ontwikkeling en de bouw ervan. Het vijfde kenmerk is dat de informatiearchitectuur een scharnier is tussen wensen en doen. Voor de informatiearchitectuur betekent dit kenmerk dat het een scharnierfunctie dient te vervullen tussen het bedrijfs- en het informatiebeleid enerzijds en de systeemontwikkeling anderzijds. Dit betekent dat je zowel de strategische wenselijkheid van de informatiearchitectuur als de technische en projectmatige uitvoerbaarheid ervan moet vaststellen.

10 de EDP-Auditor nummer De onderdelen van informatiearchitectuur en hun doel De informatiearchitectuur kan worden opgedeeld in een aantal specifieke onderdelen [VREV94] die allemaal hun eigen functie hebben. De informatiearchitectuur bestaat uit een applicatiearchitectuur, een gegevensarchitectuur en een technische infrastructuur. Applicatiearchitectuur (ook wel informatiesystemen- of toepassingenarchitectuur) bestaat uit het definiëren van delen van systeemfunctionaliteit zodanig dat een deel bij meerdere systemen kan worden gebruikt. Waarom het wiel opnieuw uitvinden, als een functionaliteit een standaard is. Een voorbeeld hiervan is de functionaliteit om de printer aan te sturen. Het doel van een applicatiearchitectuur is verhoging van de efficiency van de systeemontwikkeling. Gegevensarchitectuur bestaat uit het definiëren van gegevens op een wijze dat een gegeven door verschillende systemen kan worden gebruikt. Neem bijvoorbeeld het definiëren van het gegeven persoon. Definitievragen die aan de orde komen zijn: Nemen we alleen natuurlijke personen op? Welke set van gegevens hoort tot persoon? Hoe worden voorvoegsels verwerkt? Et cetera. Het doel van een gegevensarchitectuur is het gemeenschappelijk gebruik van gegevens door de informatiesystemen. bedrijfsstrategie (alignment). De auditor zal bij een audit aan dit punt expliciet aandacht geven. In het normenstelsel dat in dit artikel is opgenomen is er sprake van slechts één norm op dit punt, namelijk wordt bij aanvang van het modelleren van de architectuur rekening gehouden met de bedrijfsstrategie? Boer & Croon hebben hiervoor een denkmodel ontwikkeld. Het denkmodel werkt als een communicatiemiddel naar het topmanagement. Het legt namelijk de relatie tussen een informatiearchitectuur en met voor het topmanagement bekende elementen als strategie en organisatie. De boodschap voor het topmanagement is: Architectuur lijnt strategie, organisatie en ICT uit. Het model laat ook zien dat er sprake is van elkaar beïnvloedende entiteiten. Een veranderende strategie raakt de organisatie en de ICT. Architectuur helpt om dat inzichtelijk te maken en daardoor veranderingen te vergemakkelijken. Het denkmodel van Boer & Croon onderscheidt een offensieve én een defensieve toepassing van architectuur. Dit denkmodel kan worden gebruikt als hulpmiddel door degene die informatiearchitectuur als onderwerp met het topmanagement gaat bespreken. Voor de auditor kan het ook een hulpmiddel zijn bij zijn onderzoek. De begrippen offensieve en defensieve toepassing van architectuur worden hierna toegelicht. Technische architectuur bestaat uit: de databasearchitectuur dit heeft te maken met de technische inrichting van de databases; de apparatuurarchitectuur dit heeft te maken met de technologie waarmee de systemen draaien; de communicatiearchitectuur dit heeft te maken met de wijze waarop systemen met elkaar en met de gebruikers kunnen communiceren. Doel is het verbeteren van de toepasbaarheid en het verhogen van de flexibiliteit van het gebruik van de systemen. De technische architectuur wordt in dit artikel niet verder uitgewerkt. - Mogelijkheden - Huidige infra ICT Strategie Architectuur - Uitgangspunten - Regels - Afspraken - Ambitie Organisatie Figuur 1. Denkmodel volgens Boer & Croon - Structuur - Cultuur(normen, waarden, gewoonten) - Autonomie - Verandering Alignment In de inleiding is geschetst dat managers de noodzaak ervaren dat systemen flexibel zijn en snel en tegen relatief geringe kosten kunnen worden aangepast. Losjesweg heb ik geconcludeerd dat dit eisen stelt aan het systeemontwerp en daardoor zelfs aan de informatiearchitectuur. Maar hoe komt het belang van een informatiearchitectuur voor het voetlicht van het topmanagement? Hierbij gaat het erom dat de ICT-manager duidelijk kan maken dat de informatiearchitectuur ondersteunend dient te zijn aan de Offensieve toepassing van architectuur Het topmanagement is vooral geïnteresseerd in de wijze waarop de bedrijfsstrategie kan worden behaald en hoe de informatiearchitectuur daarbij ondersteunend kan zijn. In het maken van de strategische keuzes dienen afwegingen te worden gemaakt die alleen het topmanagement kan maken. De informatiearchitectuur zal van deze keuzes dienen te worden afgeleid. Het topmanagement zal de consequenties van haar keuzes voor de informatiearchitectuur moeten kennen. Dit klinkt misschien wat abstract. Daarom volgen enkele

11 12 de EDP-Auditor nummer voorbeelden van strategische keuzes die van invloed zijn op de architectuur van de (toekomstige) systemen om het te verduidelijken: Een onderneming wil enerzijds sterk groeien (omzetverdubbeling binnen drie jaar) door middel van acquisities en anderzijds ICT standaardiseren. Rijmt dit? Een onderneming wil binnen drie jaar 90% van haar inkopen via het internet doen. Een vergeten vraag hier is: Waar leg je de verantwoordelijkheid voor het datamanagement van de grondstofgegevens? Bij de leveranciers of intern in de eigen organisatie? Een onderneming wil de huidige situatie van lokale autonomie handhaven, maar wil tevens iets aan ebusiness doen. Er moet wel één gezicht naar buiten worden getoond. Hoe doe je dat? ICT heeft de tendens te centraliseren, mede ingegeven door kostenoverwegingen. Past dit wel in de cultuur van de onderneming? Wat leg je dan centraal (synergievoordeel) en wat decentraal? Het aansluiten bij specifieke thema s die leven bij het topmanagement is essentieel. De informatiearchitect communiceert erover hoe de informatiearchitectuur een rol speelt in deze thema s. Hij laat zien hoe de architectuur ondersteunend is aan de strategische wensen van het management, maar misschien ook dat bepaalde strategische wensen met elkaar conflicteren. De conclusie luidt dat de informatiearchitect in de communicatie met het topmanagement over informatiearchitectuur veel aandacht zal moeten besteden aan de relatie met strategie en organisatie. Het aangeven van deze relatie is nodig om architectuur bij het topmanagement op de kaart te zetten. Defensieve toepassing van architectuur Het tweede motief om een informatiearchitectuur te ontwikkelen is de behoefte aan beheersing van (de gevolgen van) de complexiteit van de IT. Dit beheersingsprobleem wordt veroorzaakt door de veelvormigheid en omvang van de voorzieningen, maar ook door grote dynamiek in het aanbod. De belangrijkste missie bij de uitvoering van architectuur is die van richting geven aan en faciliteren van de ontwikkeling van de informatiehuishouding en van informatiesystemen. zich meebrengt en als eerste moeten strategieën worden ontwikkeld, waarmee de complexiteit kan worden aangepakt. Deze strategieën kunnen zijn [HAMM98]: het voorkomen van onnodige complexiteit; het reduceren van de complexiteit van het bestaande en het nieuwe; het toegankelijk maken van complexe concepten en de kennis/informatie over IT-voorzieningen; het communiceren van de complexiteit om het bewustzijn daarvan te creëren. Het doel hiervan is bij te dragen aan de besluitvorming en realistische verwachtingen te scheppen. Hiermee is de defensieve rol van de informatiearchitectuur bepaald. De beperking van risico s, veroudering, redundantie en ondoorzichtigheid zijn overheersend. De missie van de IT-functie in het bedrijf is om uit het aanbod aan IT-middelen en diensten op de langere termijn een stabiele, state-of-the-art, waardevaste, veilige, transparante, betrouwbare, schaalbare, koppelbare en ook nog kosteneffectieve structuur te bouwen. Voorwaar een ambitieuze doelstelling! Nadat de behoefte aan beheersing heeft geleid tot het organiseren van een alignmentfunctie en een architectuurdiscipline ontstaan concepten, richtlijnen en afspraken op hoog niveau over oplossingen, verantwoordelijkheden en processen. In een bewust uitgevoerd alignmentproces worden innovaties ontwikkeld en gestuurd vanuit een visie op de gewenste inrichting van de informatievoorziening, die via architectuurprocessen is uitgewerkt. Het bedrijfsmanagement is hierbij sterk betrokken. Stakeholders Business eisen (High level) systeemeisen (High level) performance eisen Systeem Ontwikkeling informatie architectuur Systeemontwerp Componenten en services Interfaceontwerp Productkeuzen Ontwerprichtlijnen Ontwerpbeslissingen Systeemontwikkeling Om de complexiteit het hoofd te bieden moet de ICT-discipline op verschillende manieren de complexiteit te lijf. In de hele keten van het interne IT-bedrijf moet een proces op gang worden gebracht om de complexiteit te beperken en te beheersen. Dit begint met een bewustwording en een juiste perceptie van het probleem dat complexiteit met Organisatie Personeel Procedures Figuur 2. Informatiearchitectuur in zijn context

12 de EDP-Auditor nummer Architectuur- vs. systeemontwikkeling Zoals uit figuur 2 blijkt, liggen de ontwikkeling van een informatiearchitectuur en van een systeem in elkaars verlengde. De informatiearchitectuur vormt immers de basis voor het te ontwikkelen systeem en uiteindelijk voor meerdere systemen. De ontwikkeling van een systeem zal aansluiting moeten vinden op de informatiearchitectuur. En deze aansluiting verloopt niet altijd even vlekkeloos. Er zijn enkele aandachtspunten die hierbij een rol spelen. Deze aandachtspunten zijn voortgekomen uit eigen ervaring bij een groot architectuurproject dat helaas mislukt is en strookt met ervaringen van anderen [DISS00]. Vervolgens doe ik enkele suggesties om de genoemde aandachtspunten te kunnen hanteren. Aandachtspunten Gescheiden projecten Het realiseren van een informatiearchitectuur en de systeemontwikkeling worden vaak in verschillende projecten uitgevoerd of zijn verschillende fases in één project. Dit kan een aantal complicaties tot gevolg hebben: De mensen die aan de informatiearchitectuur gewerkt hebben zijn weg als er begonnen wordt met het systeemontwikkelingtraject. Voor een hedendaagse systeemontwikkelaar is het vaak belangrijk om te weten waarom bepaalde beslissingen genomen zijn. Om te vermijden dat beslissingen gedurende het ontwikkeltraject in twijfel worden getrokken (en dan ter discussie staan) en om commitment bij de systeemontwikkelaar te verhogen, is het belangrijk dat men inzicht krijgt in het hoe en waarom van beslissingen. Het is lastig, zo niet onmogelijk, om een informatiearchitectuur neer te zetten die genoeg diepgang en detail heeft zonder de systeemarchitectuur of cruciale delen ervan te testen of te prototypen. Vaak blijkt, dat om uiteenlopende redenen een ontwerpbeslissing niet juist is geweest. Daarbij komt, dat bij de informatiearchitectuur meestal wordt uitgegaan van een ideale situatie en afwijkingen hierop meestal zijn ingegeven door de omstandigheden van de niet ideale praktijk. De architectuur wordt immers pas daadwerkelijk getest in de ontwikkel- en uitrolfase. Miscommunicatie De communicatie tussen architecten en ontwikkelaars verloopt niet altijd even vlekkeloos als er al van communicatie sprake is. Miscommunicatie speelt zich af op een aantal vlakken en heeft verschillende oorzaken: Het gebruik van verschillende methoden en technieken die niet op elkaar aansluiten is niet bevorderlijk voor de overgang van informatiearchitectuur naar systeemontwikkeling. De meeste tools zijn niet in staat om alle facetten van architectuur en ontwikkeling af te dekken. Als er verschillende tools worden gebruikt, kijk dan of ze onderling interoperabel te maken zijn. Ook de introductie van een nieuwe manier van systeemontwikkeling legt een extra druk op de informatiearchitectuur. Begrippen en definities worden door de twee disciplines vaak verschillend geïnterpreteerd. Mismatch van producten Architectuur is een relatief jonge loot aan de ICT-boom. Over de definitie van architectuur is nog geen overeenstemming binnen de ICT-gemeenschap. Laat staan over producten die de architectuur op zou moeten leveren aan de systeemontwikkeling. Het risico is aanwezig dat het eindproduct van de architectuur niet als startpunt van de ontwikkeling van het beoogde systeem kan dienen. De architectuur heeft niet de mate van detail waarmee richting kan worden gegeven aan de systeemontwikkeling. Dit is funest als de ontwikkeling van een informatiearchitectuur en de ontwikkeling van een systeem in de tijd gescheiden projecten zijn. Gebruikers zijn niet betrokken Het risico is aanwezig dat gebruikers niet bij het architectuurproject betrokken worden. Voor de gebruikers is een architectuur begrijpelijkerwijs abstract. De architectuur is in het eindresultaat, de applicatie, transparant. Toch is de inbreng vanuit de gebruikersorganisatie belangrijk. Waarom? De feitelijke kennis over een (toekomstig) systeem zit bij de gebruiker. Hij zal in deze fase al input moeten leveren op het gebied van de gewenste functionaliteit en de benodigde gegevens. In deze fase wordt echter nog geen functioneel ontwerp gemaakt. Toch is kennis over de functionaliteit en gegevens nodig. Met deze kennis zal gezocht moeten worden naar gemeenschappelijke functionaliteit en gegevensgebruik. Suggesties Hier volgen suggesties in verband met de aandachtspunten die hiervoor zijn genoemd. Continuïteit Het probleem van verschillende projecten of gescheiden trajecten kan eenvoudig worden opgelost door ervoor te zorgen dat enkele personen die geparticipeerd hebben in het architectuurtraject beschikbaar zijn tijdens de realisatiefase. Beter nog is het om een aantal personen vanuit de realisatiefase te laten participeren in de architectuurfase. Het spreekt voor zich dat dit geen lichtgewicht ontwikkelaars zullen zijn.

13 14 de EDP-Auditor nummer Architectuur en ontwikkeling parallel Een gedeelte van de architectuur kan parallel worden uitgevoerd met het ontwikkeltraject van het systeem (de realisatiefase). Een parallel traject kan om verschillende redenen worden uitgevoerd: testen van concepten in de systeemarchitectuur; validatie bij de gebruikersorganisatie; aansluiting bij incrementele ontwikkeling; migratie van een bestaand systeem waarbij delen in de tijd vervangen worden. Spreek dezelfde taal en begrijp elkaar Dit is vooral van toepassing op de fase van de architectuur die het dichtst bij systeemontwikkeling ligt. De ervaring is dat een optimale situatie verkregen wordt als een systeemarchitect ruime ontwikkelervaring heeft en dat ontwikkelaars vertrouwd zijn met methoden die in de systeemarchitectuur gebruikt worden. Dit laatste kan bijvoorbeeld worden bereikt in de vorm van een introductiecursus. Op het gebied van methoden en tools kan worden gekeken naar tools die op elkaar aansluiten. Spreek heel goed af wat het bereik van de architectuur is en wat het bereik van systeemontwikkeling is. Werk samen. Een architect dient samen te werken met het gehele projectteam. Dit is zeker belangrijk in de fase van de architectuur die het dichtst bij de systeemontwikkeling ligt. Op deze manier wordt er commitment verkregen van de systeemontwikkelaars. Immers, ze werken beiden aan hetzelfde doel. Betrek de gebruikersorganisatie er vroegtijdig bij Zorg voor gebruikers die vrijgemaakt zijn om het architectuurproject te participeren. Zorg er dan ook voor dat in voor gebruikers begrijpelijke taal het doel en de functie van een architectuur wordt uitgelegd. De keuze voor wie in een dergelijk project kan participeren, zal niet altijd eenvoudig zijn. Het zullen gebruikers moeten zijn met veel kennis over de applicaties en met affiniteit voor automatisering. In een organisatie zijn dit al vaak de medewerkers waar zwaar op wordt gesteund. Al met al zijn dit geen vernieuwende suggesties. Toch blijkt in de praktijk dat ze weerbarstig genoeg zijn. Het is raadzaam om ook over deze eenvoudige tips van te voren na te denken en er een oplossing voor te vinden. Kwaliteit van architectuur Hoe kun je als auditor de kwaliteit van een architectuur toetsen? In dit hoofdstuk worden drie verschillende hulpmiddelen besproken waarmee de kwaliteit van architectuur kan worden getoetst. Het hoofdstuk wordt afgesloten met een conclusie. Aan het eind van het artikel heb ik een normenset geformuleerd dat als hulpmiddel kan worden gebruikt. Wat is kwaliteit? In studierapport nummer 2 van de NOREA getiteld Een kwaliteitsmodel voor Register EDP-auditors wordt gezegd: kwaliteit is nooit een incident, het is altijd het resultaat van een intelligente samenwerking. [NORE97] Deze definitie geeft aan waar het om gaat bij kwaliteit. Kwaliteit is geen incident, als zou het om een toevalligheid gaan. Kwaliteit is iets wat doelbewust moet worden nagestreefd. Kwaliteit is het resultaat van samenwerking. Ook bij het maken van een informatiearchitectuur gaat het om een nauwe samenwerking tussen de verschillende stake holders. In de definitie is sprake van intelligente samenwerking. Dit betekent in de context van architectuur dat bij het maken van een architectuur rekening wordt gehouden met de (interne) omgevingsfactoren, het creëren van draagvlak en het verzorgen van een goede communicatie. Dit alles is al aan de orde gekomen. De kwaliteit van een informatiearchitectuur kan als volgt worden gedefinieerd: De kwaliteit van een informatiearchitectuur is het vermogen van een architectuur de niet-functionele eisen aan de te bouwen systemen te ondersteunen. Wanneer is een architectuur goed? Of anders gezegd wanneer is een architectuur goed genoeg? In deze context is goed een betrekkelijk begrip, want om een architectuur te kunnen beoordelen, moeten we eerst de criteria vaststellen op basis waarvan we dat kunnen doen. Deze criteria zijn namelijk sterk afhankelijk van het doel wat met de architectuur wordt beoogd. Op basis van het doel kunnen de bijbehorende criteria en normering worden gedefinieerd waarop de resultaten worden beoordeeld. Door verschillende partijen zijn methodieken ontwikkeld om de validatie van de architectuur uit te voeren. In dit hoofdstuk zullen deze hulpmiddelen de revue passeren. Dit zijn achtereenvolgens: Architecture Score Card van Cap Gemini; architectuurreview van het Software Engineering Research Centre; de architectuurbenadering van ATOS Origin. Architecture Score Card De Architecture Score Card [ARCH00] is gebaseerd op een methodologische benadering van de verschillende architectuurproducten die voortkomen uit verschillende

14 de EDP-Auditor nummer Figuur 3. Relatie tussen architectuurgezichtspunten, aspectgebieden en abstractieniveaus architectuurprocesstappen. Op basis van een vooraf gedefinieerde normering voor alle architectuuraspectgebieden kan eenvoudig worden vastgesteld of de architectuurproducten aan de criteria voldoen. Alvorens in te gaan op de nadere details van de Architecture Score Card is het goed om de belangrijkste processtappen die hierbij worden gehanteerd te leren kennen. Cap Gemini heeft de aspectgebieden en de abstractieniveaus binnen het geïntegreerde architectuur raamwerk (IAF), verder uitgewerkt in een aanpak Cap Gemini s Integrated Architectural Approach (IAA). In deze benadering worden naast de genoemde architectuuraspectgebieden de vijf procesfaseringen onderscheiden, die in de IAA-aanpak vaak overeenkomen met de vijf abstractieniveaus: Contextuele fase: wat zijn de missie en doelen van de organisatie, hoe wenst de organisatie te functioneren in zijn omgeving en hoe ziet de omgeving van de organisatie eruit, wat is de omvang van het architectuurtraject? Conceptuele fase: wat zijn de randvoorwaarden, uitgangspunten, eisen en beperkingen die betrekking hebben op het architectuurtraject en die worden gesteld aan de architectuur? Een conceptueel architecturaal ontwerp. Logische fase: hoe kan de oplossing worden gerealiseerd, een logisch architecturaal ontwerp? Fysieke fase: waarmee kan de oplossing worden gerealiseerd, een fysiek architecturaal ontwerp? Transformatie fase: wanneer kan de oplossing worden geïmplementeerd en wat is de impact op de organisatie en de ICT-omgeving? De methodiek achter de Architecture Score Card maakt gebruik enerzijds van de architectuuraspectgebieden en anderzijds van de verschillende procesfaseringen. Op basis van deze benadering is een meetmethodiek ontwikkeld die inzicht geeft in en overzicht geeft van de kwaliteit van een te beoordelen architectuur. Op basis van vragen over de aspectgebieden en de procesfasen wordt vastgesteld in welke mate de architectuur aan een aantal criteria voldoet. Hierdoor kan een goed inzicht en overzicht worden verkregen van de kwaliteit van een architectuur. Specifiek wordt door de leverancier van het tool aandacht gevraagd voor de onderhoudbaarheid van de architectuur. Van belang daarbij is of de resultaten van de architectuurstudie op een zodanige manier zijn gedocumenteerd dat deze ook op de langere termijn onderhoudbaar zijn, ook door andere architecten dan de oorspronkelijke architecten. Het element van onderhoudbaarheid dient dan ook in de overall-beoordeling te worden meegenomen. Architectuurreview door het SERC Een tweede benadering is die van het Software Engineering Research Centre (SERC) [ZEIS96]. Door hen is een aanpak van architectuurreview ontwikkeld. Deze aanpak gaat uit van het toetsen van een architectuur aan de kwaliteitsattributen uit het Quint2/Extended ISO 9126 model. Het is de verantwoordelijkheid van de softwarearchitectuur om richting en (gedeeltelijke) invulling te geven aan de kwaliteitseisen die worden gesteld aan een systeem. Het SERC hanteert de Engelse terminologie. Afhankelijk van de bedrijfscultuur waar het model wordt toegepast, dienen de termen te worden overgezet naar de Nederlandse taal. De specifieke aanpak van een architectuurreview is erg afhankelijk van de situatie. Een belangrijke factor hierbij is het doel van de architectuurreview. De nadruk kan liggen op: het bepalen van de kwaliteitseisen die aan een architectuur in ontwikkeling worden gesteld; het bepalen van de kwaliteit van een architectuur en de bijbehorende artefacten; het bepalen van de impact van wijzigingen op een architectuur. Om deze doelen te verwezenlijken kan een aantal middelen worden ingezet zoals workshops, interviews, productstudies en experimenten.

15 16 de EDP-Auditor nummer Functionality Maintainability Usability Reliability Portability Efficiency Suitability Analyzability Understandability Maturity Adaptability Time-behavior Accuracy Changeability Learn ability Fault Installability Resource behavior Interoperability Stability Operability Tolerance Conformance Compliance Testability Explicitness Recoverability Replaceability Security Manageability Customizability Availability Traceability Reusability Attractiveness Degradability Clarity Helpfulness Figuur 4. Kwaliteitsattributen in het Quint2/Extended ISO 9126 model Een workshop heeft tot doel de (kwaliteits)eisen die aan het systeem worden gesteld in kaart te brengen en dient daarom te worden bijgewoond door alle bij het systeem betrokken partijen/stakeholders. Een workshop kan ook worden gebruikt om toekomstige wijzigingsscenario s te bepalen. Interviews worden gebruikt om het beeld van de verschillende partijen van de architectuur te bepalen en om de te toetsen eigenschappen van de architectuur in kaart te brengen. Het voordeel van interviews is dat betrokkenen sneller geneigd zijn hun opinie over het systeem te geven. Het doel van een productstudie is om de kwaliteit van de architectuur en de bijbehorende documenten en producten te bepalen. Experimenten en prototypes kunnen de haalbaarheid van oplossingsrichtingen toetsen. Ook kunnen experimenten en prototypes worden gebruikt om belangrijke verbeteringen in bestaande knelpunten te demonstreren. De architectuurbenadering van ATOS Origin De derde benadering is de architectuurbenadering van ATOS Origin [POST]. In feite is deze benadering ook een review op de architectuur die wordt uitgevoerd door consultant/architecten. Toch kan ik mij voorstellen dat er ook een beroep wordt gedaan op een IT-auditor omdat hij een onafhankelijke partij is. De werkwijze is interessant genoeg om in dit artikel op te nemen. De uitvoering van deze methode kan als eventueel advies worden gegeven of de IT-auditor kan de onafhankelijke rol die in deze benadering wordt genoemd, op zich nemen. De methodiek benadert de vraag waarom de relatie tussen de niet-functionele eisen en een architectuur zo lastig te bepalen is met de invalshoek van organisatieverandering. Een succesvolle organisatieverandering stoelt op drie pijlers, namelijk techniek, politiek en cultuur. Vanuit technisch perspectief kan worden gezegd dat er inderdaad nog veel te leren is over de beïnvloeding van de niet-functionele eisen en de architectuur. Architec tuurontwikkeling lijkt nog teveel te worden gedaan op basis van intuïtie en ervaring van de architecten. Het speelt zich nog veel af in het hoofd van de architect en is nauwelijks objectief meetbaar. Tools en technieken voor architectuurassessments zijn nog niet verkrijgbaar. Architectuurbesluiten zijn vaak niet gedocumenteerd. Rond architectuur ontwikkelen zich ook politieke invloeden. Dit is het logische gevolg van het feit dat een architectuur een strategisch belang heeft. Er zijn veel stakeholders bij betrokken terwijl een architectuur weinig zichtbaar is en vaak als abstract wordt ervaren. Er is een culturele beperking bij het leggen van een link tussen de niet-functionele eisen en de architectuur. Binnen organisaties is weinig bewustzijn voor de onderlinge relaties tussen afdelingen en werkzaamheden door de afdelingen. Iedere afdeling (marketing, productie, service, IT) ziet het maken van een architectuurproduct als niet transparant. Dit resulteert erin dat het (midden)management niet echt geïnteresseerd is in het definiëren van de nietfunctionele eisen. Doel van de architectuurbenadering is een systematische benadering van de architectuurmodellen waarbij de deelname van de stakeholders het uitgangspunt is. Doelstelling is de kwaliteit van de architectuur te bepalen en de mogelijkheden voor verbetering te identificeren. Kwaliteit is hierbij het vermogen van de architectuur in het realiseren van de niet-functionele eisen. Door het uitvoeren van het voorgestelde assessment in een vroeg stadium in het ontwikkelproject verkrijgt het management goed gedocumenteerd inzicht in de risico s van de architectuur. Het moment dient zo gekozen te zijn dat correctieve acties tegen beperkte kosten mogelijk zijn. De basisfilosofie achter de assessment is een zelfevaluatie geleid door een externe partij. De architecten zelf en de andere stakeholders moeten de kwaliteit van de architectuurmodellen bepalen. De taak van de externe expert is

16 de EDP-Auditor nummer het assessment faciliteren. Zij vormen niet zelfstandig een oordeel over de architectuur; dit is alleen mogelijk met veel kennis van het applicatiedomein. Het assessment kent een aantal fasen. De volgende fases zijn te onderscheiden: Consensus over de eisen Identificeer de niet-functionele eisen en de prioriteiten door de stakeholders te interviewen. Deze interviewronde wordt gevolgd door een plenaire sessie met als doel consensus vast te stellen of te bereiken. De externe partij leidt de interviews en de plenaire sessie. De architecten spelen een meer passieve rol als geïnterviewden, net zoals de stake holders van het management van marketing, productie, systeemontwikkeling, servicemanagement enzovoort. Analyse van de architectuur Dit is de fase waarin de architectuur wordt aangelegd tegen de niet-functionele eisen waarover het management het eens is. De architectuurbeslissingen worden geïdentificeerd en gerelateerd aan de eisen. Op deze manier kan worden bepaald in welke mate de architectuur de eisen ondersteunt. Dit wordt uitgevoerd door de architecten. Architectuurreview De resultaten uit de vorige fase worden gepresenteerd en bediscussieerd in één of meerdere plenaire sessies. Deze worden geleid door de externe partij. De sterke en zwakke elementen van de architectuur, risico s en voorstellen van verbetering worden besproken. Dit is het belangrijkste onderdeel van het geheel. De resultaten van de interviews en de analyse komen hier samen, worden openlijk bediscussieerd en zal (moeten) leiden tot consensus over de kwaliteit van de architectuur en de eventuele uit te voeren verbeteringen. Rapportage De resultaten uit de vorige fase worden vastgelegd in een rapport. Dit rapport wordt gepresenteerd en wederom bediscussieerd in een plenaire sessie met daarin alle betrokkenen, inclusief het management. Deze fase wordt uitgevoerd door de externe partij. Hoe komt deze benadering tegemoet aan de eerder genoemde drie pijlers techniek, politiek en cultuur? De technische rationaliteit zal sterk worden vergroot door een systematische benadering op tafel te brengen die de nietfunctionele eisen expliciet en meer grijpbaar maken. Uiteindelijk worden ze allemaal bediscussieerd, gedefinieerd, gegroepeerd, geprioriteerd en toegekend in een open proces waarin veel experts hun zegje kunnen doen. Op deze manier worden veel van de overwegingen van de architecten die in eerste instantie in hun hoofden zitten, gebaseerd op ervaring en intuïtie, expliciet voor alle andere betrokkenen gemaakt. Politieke tegenstand is een onderdeel van een bedrijf en kan zich sterk laten gelden rond architectuurproducten. Welke systematische benadering er ook is, dit is moeilijk te bestrijden. Als mensen niet willen participeren in een open discussie is het moeilijk hen aan tafel te krijgen. Desalniettemin, zaken zijn meestal niet zwart of wit. Het gebruik van een systematische benadering, maar ook de aanwezigheid van een externe partij kan helpen de spanning te reduceren. Het wordt moeilijker voor mensen de discussies te domineren of zelfs te manipuleren. Dit kan anderen weer aanmoedigen vrijer te spreken. Achterkamertjesgeregel en misbruik van macht zullen moeilijker zijn in dit proces. Voor het culturele perspectief is het duidelijk dat deze benadering leidt tot een toegenomen besef van de belangrijkheid van goede architectuurproducten. Zowel het management als de architecten raken betrokken in dit proces en zullen veel kunnen leren over de architectuur. Mensen krijgen een open uitnodiging om deel te nemen in de discussies en bij te dragen aan nieuwe ideeën. Conclusie bij deze drie methoden De Architecture Score Card geeft inzicht in de verbindingen tussen strategie en uitvoering enerzijds en de verschillende aspectgebieden anderzijds. De architectuurreview van het SERC is gericht op de eisen waaraan een informatiearchitectuur moet voldoen. De architectuurbenadering van ATOS Origin voegt daaraan toe de actieve participatie van stakeholders. Iedere van de genoemde methoden heeft zijn eigen invalshoek en zo vullen ze elkaar aan. De architectuurbenadering van ATOS Origin sprak mij aan. Hij lijkt op de knelpuntenanalyse projectmanagement zoals die in het handboek EDP-Auditing staat beschreven [SWIN]. In de praktijk heb ik daar zeer positieve ervaringen mee opgedaan. Met een relatief kleine investering komen de sterke en zwakke punten van het projectmanagement duidelijk naar voren. Projectmanagement is geen architectuur. Maar ook bij projectmanagement spelen cultuur en politiek een belangrijke rol. Ervaring en intuïtie van de projectleider vormen ook nog wel eens de basis voor de genomen besluiten. Door deze overeenkomsten verwacht ik dat deze architectuurbenadering goede resultaten kan opleveren. Normen Normen voor het informatiearchitectuurproduct 1. Opdrachtgever en -nemer hebben overeen stemming over de eisen aan de architectuur, uit te splitsen naar: afbakening van het systeem, van het object van de architectuur.

17 18 de EDP-Auditor nummer Voorbeelden zijn: - alle processen, informatie-items, actoren en technologie-items gerelateerd aan de afdeling Marketing & Sales ; - alle processen, informatie-items en actoren ondersteund door de softwareapplicaties die onder UNIX draaien; - alle processen, actoren en technologie gerelateerd aan klantinformatie; - de eisen aan dat systeem; - de wijze van beschrijving van het systeem en van de eisen daaraan. 2. De opdrachtgever dient aan te geven welke eisen aan dat systeem in de architectuur dienen terug te komen. De kwaliteitseisen in het model van het SERC kunnen hierbij een hulpmiddel zijn. Er zullen ook investeringseisen zijn, zoals: kosten: eisen aan de kosten van het maken, onderhouden en exploiteren van het systeem; baten: eisen aan de baten van het maken, onderhouden en exploiteren van het systeem; risico s: eisen ten aanzien van de getolereerde risico s voor en als gevolg van het maken, onderhouden en exploiteren van het systeem. 3. De architectuur moet laten zien binnen welke eisen en randvoorwaarden ontwerpbeslissingen kunnen worden genomen. 4. Specifiek voor de gegevensarchitectuur: Standaardisering van de betekenis van gegevens, dat wil zeggen ontdoen van de willekeur van de specifieke situatie. Het doel van de betekenisstandaardisatie is het verkrijgen van een ondubbelzinnige en uniforme betekenis van de bedrijfsgegevens. Het gebruik van gegevens voor meer doeleinden vereist een uniform gedefinieerde betekenis, dit wil zeggen ongeacht: - de representatievorm op media; - het gebruik; - het toepassingssysteem dat het betreft; - de organisatorische eenheden die de gegevens gebruiken of beheren. Standaardisering van de vorm. Deze vormstandaards hebben betrekking op: - de schrijfwijze en maximale lengte van gegevenselementen; - de externe representatie van de gegevens. Dit leidt tot de keuze van codestelsels (bijvoorbeeld de ISOmuntcode). De interne representatie hoeft niet uniform te zijn. Gemeenschappelijk gebruik impliceert wel éénmaal waarnemen, verzamelen en registreren, maar niet noodzakelijk éénmaal opslaan; - de gewenste kwaliteit van de gegevens. Daarbij gaat het om de volgende aspecten: Δ de juistheid en betrouwbaarheid; Δ de volledigheid van de gegevensverzameling; Δ de actualiteit. Hieronder wordt verstaan de tijd die verstrijkt tussen het plaatsvinden van een relevant feit en het moment waarop dat leidt tot een wijziging in de administratie; Δ de toegankelijkheid. Koppel belang en verantwoordelijkheid = definieer, structureer en verzamel alleen gegevens die ook daadwerkelijk gebruikt gaan worden, zodat in het gebruik een gebrek aan kwaliteit tijdig kan worden opgemerkt. Leg de verantwoordelijkheid voor de gegevens en de gegevensbeschrijvingen bij degene die het grootste belang heeft bij de kwaliteit ervan. In geval van gemeenschappelijk gebruik van gegevens leg je de bevoegdheid en verantwoordelijkheid van de gegevens zoveel mogelijk bij degene die de hoogste eisen stelt aan de kwaliteit van de gegevens. Gegevensbeheersystemen dienen een zodanige structuur te hebben dat ze gemakkelijk uit te breiden zijn. Een groeiscenario ligt hieraan ten grondslag. Zodra een nieuw applicatiesysteem ontwikkeld wordt, leidt dit zonodig tot aanpassingen en tot uitbreiding van de standaards. Maak voor de juistheid van elk gegeven precies één organisatorische functie of eenheid verantwoordelijk. Dit is de functionele beheerder. De functionele beheerder is de enige die gemachtigd is een gegeven op te voeren, te wijzigen of te verwijderen. Bij toewijzing van het functioneel beheer gelden de volgende richtlijnen: - voor resultaatgegevens is degene verantwoordelijk, die het resultaat, waarop het gegeven betrekking heeft, tot stand brengt; - voor gegevens die afkomstig zijn uit de omgeving is degene verantwoordelijk voor wie vooral de kwaliteitseisen met betrekking tot actualiteit en volledigheid van het grootste belang zijn, ofwel degene die het gegeven als eerste nodig heeft. Een alternatief is de verantwoordelijkheid leggen bij degene die het grootste belang heeft bij de juistheid van het gegeven. Ook combinaties van beide zijn mogelijk. 5. Specifiek voor de gegevensarchitectuur De functionaliteit van een te bouwen architectuur dient volgens de volgende afbakeningscriteria opgedeeld te zijn: relatieve autonomie: dit wil zeggen een clustering van processen met een sterke interne samenhang en zwakke koppeling met andere clusters van processen; zelfstandig bestaansrecht: dit wil zeggen dat het (deel)systeem een bestaansrecht heeft onafhankelijk van andere (deel)systemen;

18 de EDP-Auditor nummer projectmatige realiseerbaarheid: dit wil zeggen dat er een zodanige afbakening van het (deel)systeem is dat het ontwikkelingstraject op een succesvolle wijze is af te ronden. De volgende factoren bepalen het succes van projecten: - duidelijkheid van de doelstellingen; - kennis en ervaring met de toe te passen methoden; - kennis en ervaring met de toe te passen technieken; - omvang en complexiteit van het (deel)systeem. Normen voor het proces bij tot stand brengen architectuurproducten 1. Vanaf aanvang van het architectuurproject dient rekening te worden gehouden met de bedrijfsstrategie en zullen de eventuele gevolgen voor de te ontwikkelen architectuur inzichtelijk gemaakt zijn. 2. Het (top)management dient vanaf de start van het architectuurproject actief erbij te worden betrokken. 3. Er zijn maatregelen getroffen om de kennis over de architectuur en ontwerpkeuzes te borgen. Denk hierbij aan: ontwikkelaars zowel in de architectuur- als de realisatiefase laten participeren; ontwikkelen en gebruiken van documentatiestandaards; structureren van het keuzeproces in de architectuurfase. 4. In algemene zin dienen de juiste partijen te worden betrokken. Hierbij dient de gebruikersorganisatie niet te worden vergeten. 5. De ontwerpstrategie zal moeten voldoen aan twee belangrijke criteria: de complexiteitsvermindering in de modellering: dat wil zeggen dat de werkelijkheid voldoende is vereenvoudigd om een overzicht te bieden en tegelijkertijd voldoende complex is om alle relevante delen van de werkelijkheid weer te geven. de verifieerbaarheid van de modellen: dat wil zeggen dat de gebruiker aangeeft of de gewenste toekomstige situatie correct is uitgebeeld. Hiervoor is het nodig dat de gebruiker de modellen kan begrijpen en beoordelen. aspectgerichtheid: voor de beoordeling van de methode is het van belang welke aspectmodellen worden onderkend en hoe ze worden gebruikt. Literatuur [ARCH00] Architectuur en Infrastructuur (2000), nr. 4. [BURG] Burg, H., Volwassenheid in een architectuurorganisatie. [DISS00] Disseldorp, J. van, A. Hendriks, R. Spijkerman en H. Vader (2000), Architectuur vs. realisatie - Ervaringen, Problemen en Aanbevelingen. [HAMM98] Hammer, D.K. (1998), Architectuur belangrijkste middel om complexiteit te bedwingen, in: Automatiseringsgids, 30 oktober. [NORE97] NOREA (1997), Studierapport nr. 2 Een kwaliteitsmodel voor Register EDP-auditors De eerste stap, juli. [POST] Postema, H. en H. Akkermans, Managing architectural risks in product development a casestudy from the electronics industry. [SAND97] Sanden, W. van der en B. Sturm (1997), Informatiearchitectuur de infrastructurele benadering, pp [SWIN] Swinkels, G.J.P. en L.J.M.W. Gielen, Handboek EDP-auditing B Knelpuntenanalyse projectmanagement, NOREA. [VREV94] Vreven, A.A. (1994), Methoden en hulpmiddelen voor de systeemontwikkeling pp [ZEIS96] Zeist, B. van, et al. (1996), Kwaliteit van software producten, praktijkervaring met een kwaliteitsmodel. Deze bovenstaande criteria zijn te globaal om op basis hiervan methoden te toetsen. Hieronder volgt een aantal meer gedetailleerde criteria: herhaalbaarheid: wanneer de activiteit nogmaals wordt uitgevoerd, moet hetzelfde product ontstaan, ongeacht de persoon die het werk verricht; onderbouwing: de keuzen die in het modelleringsproces zijn gemaakt, dienen gemotiveerd en verifieerbaar te zijn; doelgerichtheid: de methode dient aan te geven hoe de bedrijfsdoelstellingen moeten worden vertaald naar systeemeisen;

19 20 de EDP-Auditor nummer De Wireless Toolbox van de IT-auditor Mauriche Kroos en Robbert Kramer De beveiliging van een WLAN-netwerk kan complex en uitgebreid zijn. Het beoordelen van de beveiliging van een WLAN-netwerk vereist dan ook een goed gevulde toolbox voor de IT-auditor. De toolbox bestaat voornamelijk uit gratis software op een Linux platform. De IT-auditor heeft echter niet alleen software nodig: een juiste combinatie van software, hardware en kennis is onontbeerlijk. Inleiding Dit artikel is een vervolg op het vorige artikel over WLAN-netwerken (de EDP-Auditor 4/2004) en gaat in op het gebruik van tools voor het testen van de beveiliging van WLAN-netwerken (reconnaissance en exploiting). In het vorige artikel zijn vooral de theoretische achtergronden van WLAN-netwerken beschreven. Deze achtergronden worden in dit artikel verondersteld als aanwezige kennis. Aangezien het artikel is geschreven vanuit de achtergrond van het testen van de beveiliging en niet vanuit het treffen van maatregelen, zullen in dit artikel geen maatregelen worden beschreven. In het volgende artikel wordt ingegaan op maatregelen voor het beveiligen van WLAN-netwerken. Hierbij zal eerst de komende tijd duidelijk moeten worden hoe nieuwe beveiligingsprotocollen worden geaccepteerd en geïmplementeerd in WLAN-netwerken door leverancier en gebruikers. In dit artikel worden verschillende tools beschreven voor het testen van de beveiliging van WLAN-netwerken. De lijst met beschikbare tools groeit gestaag, waarbij deze niet alleen binnen Linux, maar ook binnen Windows kunnen worden gebruikt. Een aantal van de Linux tools zijn ook toe te passen binnen Windows door gebruik te maken van emulatie tools (zoals bijvoorbeeld Cygwin). Met deze tools kan men in Windows een Linux commandoregel emuleren (vergelijkbaar met een DOS box ). De auditor is hierdoor R.P. Kramer RE is projectmanager bij Ernst & Young EDP Audit en in dienst sinds Ing. M.R. Kroos RE is manager bij Ernst & Young EDP Audit als EDP-auditor en in dienst sinds in staat bepaalde Linux tools binnen Windows te kunnen uitvoeren, zonder dat daarbij een complete installatie van Linux nodig is. De beschreven tools zijn al langer beschikbaar en/of hebben zichzelf min of meer bewezen. Het zijn tools die bij beveiligingstesten veelvuldig worden gebruikt. De doelstelling van dit artikel is duidelijk te maken wat allemaal mogelijk is met tools om de beveiliging van WLAN-netwerken te testen en op basis hiervan te verbeteren en niet om aan te zetten tot het inbreken op WLANnetwerken. Wij wijzen op het feit dat het gebruik van deze tools risicovol kan zijn. Gebruik deze tools alleen in overleg met de opdrachtgever of eigenaar van het WLAN-netwerk en na overeenstemming over eventuele risico s en de hiermee samenhangende aansprakelijkheid. Tools Het inzetten van tools is bij uitstek de manier om te testen of de getroffen beveiliging rondom WLAN s werkt zoals verwacht. De IT-auditor heeft bij het testen naast de gangbare zaken, zoals een laptop, de volgende hardware en software nodig: Diverse WLAN-kaarten die een of meer van de WLANstandaarden (zie vorig artikel) ondersteunt. De in elke WLAN-kaart aanwezige chipset dient te worden ondersteund door de te gebruiken tools. Het dient de voorkeur om gebruik te maken van een netwerkkaart waarop een externe antenne kan worden aangesloten. Diverse WLAN access points/bridges met tevens de mogelijkheid van het aansluiten van een externe antenne. Verschillende typen (externe) antennes met voldoende gevoeligheid, die aangesloten kunnen worden op access points en WLAN-kaarten. De juiste WLAN tools voor de reconnaissance en exploiting fase (zie verderop in dit artikel).

20 de EDP-Auditor nummer Verder is het belangrijk dat de IT-auditor bekend is met: het juiste moment voor sniffing, omdat zonder netwerkverkeer niet alle WLAN-netwerken (devices) te vinden zijn; de wetgeving inzake het toegestane zendvermogen WLAN. Een handige Linux tool voor het verkennen van de ether is wavemon. Deze tool geeft onder andere de sterkte van eventueel aanwezige WLAN-signalen weer zoals in figuur 1 duidelijk wordt. Naam Soort Platform Website Doel Chipsets kort toegelicht Fabrikanten van WLAN-kaarten maken doorgaans gebruik van gestandaardiseerde chipsets van een beperkt aantal leveranciers. De chipset is het hart van een WLAN-kaart. Het is van belang dat de gebruikte kaarten de juiste chipset hebben om ondersteund te worden door de tool. De auditor zal echter niet kunnen ontkomen aan het (simultaan) gebruik van meerdere kaarten met verschillende chipsets. Momenteel worden de volgende chipsets voldoende ondersteund door tools: Prism 2 en Prism 2.5/3 Orinoco/Hermes Silver en Gold Cisco Aironet Atheros Reconnaissance De reconnaissance (verkennen) van de WLAN-netwerkomgeving is de eerste stap in het testen van de beveiliging. Het doel van de reconnaissance is voldoende informatie achterhalen voor het vervolg in de exploiting fase. Voor het gestructureerd achterhalen van informatie is de reconnaissance opgesplitst in drie stappen, namelijk: verkennen; herkennen; sniffing. Voor iedere stap in de reconnaissance zijn specifieke tools beschikbaar. Verkennen De eerste stap is het verkennen van de ether (het luchtruim ). Hierbij is het de bedoeling om te achterhalen welke signalen aanwezig zijn in het 2.4 GHz en 5 GHz frequentiegebied. Indien WLAN-signalen aanwezig zijn, kan dit betekenen dat WLAN-apparatuur actief is. In dat geval is het zinvol om de volgende stap van het herkennen uit te voeren om vast te stellen wat voor WLAN-signalen en met welke eigenschappen aanwezig zijn. Wavemon Gratis Linux Verkennen ether Figuur 1. Wavemon voorbeeld Wavemon geeft beperkte informatie over eventuele gevonden WLAN devices maar niet over eventuele aanwezige beveiliging. Daarnaast geeft Wavemon informatie over de aanwezige signaal/ruis-verhouding. Deze verhouding is een indicatie voor de bruikbaarheid van het signaal. Hoe beter de verhouding hoe sterker en zuiverder het signaal. Wanneer Wavemon wordt gebruikt op een laptop die vervolgens wordt verplaatst, dan is het mogelijk in kaart te brengen waar het signaal het meest bruikbaar is. Hierdoor is de optimale testlocatie te achterhalen waarvandaan de test verder kan worden uitgevoerd. Herkennen Het herkennen van WLAN devices is de tweede stap in het testen van de beveiliging van een WLAN-netwerk. Onder WLAN devices wordt verstaan de apparatuur die via WLAN-signalen en standaarden kan communiceren met andere WLAN devices. Dit kan een veelvoud van apparaten zijn: laptops, desktops, PDA s en handscanners, et cetera. Voor het opsporen van WLAN devices zijn twee verschillende methoden beschikbaar: Actieve scanning: met de juiste software wordt een bericht de ether ingestuurd (vergelijkbaar met ping ). Indien een WLAN device zo is ingesteld om te reageren op het bericht, zal die een antwoordbericht terugsturen. Dit bericht wordt vervolgens door de betreffende tool opgevangen en geïnterpreteerd. Nadeel van deze methode is dat veel WLAN devices mogelijk niet reageren op deze verzoeken (zie voor nadere uitwerking paragraaf Actieve Scanning ).