Een audit op informatiearchitectuur:

Maat: px
Weergave met pagina beginnen:

Download "Een audit op informatiearchitectuur:"

Transcriptie

1 9 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.

2 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.

3 11 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

4 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

5 13 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.

6 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

7 15 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.

8 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

9 17 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.

10 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;

11 19 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;

Extended ISO 9126: 2001. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Extended ISO 9126: 2001. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Extended ISO 9126: 2001 Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3

Nadere informatie

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

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 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.

Nadere informatie

READ: de informatiestrategieaanpak van Steenwinkel Kruithof Associates (SKA)

READ: de informatiestrategieaanpak van Steenwinkel Kruithof Associates (SKA) READ: de informatiestrategieaanpak van (SKA) INLEIDING HET SPANNINGSVELD TUSSEN KORTETERMIJNVERWACHTINGEN EN LANGETERMIJNBEHOEFTEN In veel bedrijven volgen businessgerelateerde veranderingen elkaar snel

Nadere informatie

Softwareproductkwaliteit

Softwareproductkwaliteit informatie / maand jaar softwarekwaliteit Overdruk Softwareproductkwaliteit Florijn & Greefhorst informatie 0101 1 Softwareproductkwaliteit Ervaringen en ontwikkelingen Met de groeiende interesse voor

Nadere informatie

Oplossingsvrij specificeren

Oplossingsvrij specificeren Oplossingsvrij specificeren ir. J.P. Eelants, projectmanager Infrabouwproces CROW Samenvatting De methodiek van oplossingsvrij specificeren richt zich niet alleen op het formuleren van functionele eisen.

Nadere informatie

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. BISL Business Information Services Library Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2

Nadere informatie

Van Samenhang naar Verbinding

Van Samenhang naar Verbinding Van Samenhang naar Verbinding Sogeti Page 2 VAN SAMENHANG NAAR VERBINDING Keuzes, keuzes, keuzes. Wie wordt niet horendol van alle technologische ontwikkelingen. Degene die het hoofd koel houdt is de winnaar.

Nadere informatie

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Evo Evolutionary Project Management Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. INLEIDING... 3 2. EVO... 4 3. FASERING...

Nadere informatie

14-9-2015. Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Systeemontwikkeling

14-9-2015. Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Systeemontwikkeling Les 1 Docent: Marcel Gelsing Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Systeemontwikkeling Je kunt hier (optioneel) ook een gratis tool downloaden

Nadere informatie

Invloed van IT uitbesteding op bedrijfsvoering & IT aansluiting

Invloed van IT uitbesteding op bedrijfsvoering & IT aansluiting xvii Invloed van IT uitbesteding op bedrijfsvoering & IT aansluiting Samenvatting IT uitbesteding doet er niet toe vanuit het perspectief aansluiting tussen bedrijfsvoering en IT Dit proefschrift is het

Nadere informatie

Geef handen en voeten aan performance management

Geef handen en voeten aan performance management Geef handen en voeten aan performance management De laatste jaren is het maken van concrete afspraken over de ICT-serviceverlening steeds belangrijker geworden. Belangrijke oorzaken hiervoor zijn onder

Nadere informatie

ISO 9000:2000 en ISO 9001:2000. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

ISO 9000:2000 en ISO 9001:2000. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. ISO 9000:2000 en ISO 9001:2000 Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 11 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER...

Nadere informatie

HOE DE KANS OP EEN SUCCESVOLLE ERP- IMPLEMENTATIE TE VERGROTEN

HOE DE KANS OP EEN SUCCESVOLLE ERP- IMPLEMENTATIE TE VERGROTEN WHITEPAPER HOE DE KANS OP EEN SUCCESVOLLE ERP- IMPLEMENTATIE TE VERGROTEN..HET EFFECT VAN VREEMDE OGEN.. Copyright 2014 OPDIC W www.implementatie-erp.nl E info@implementatie-erp.nl Hoe de kans op een succesvolle

Nadere informatie

Advies. Advies over en ondersteuning bij het (initieel) inrichten/optimaliseren van de structuur van de(it Service Management)organisatie

Advies. Advies over en ondersteuning bij het (initieel) inrichten/optimaliseren van de structuur van de(it Service Management)organisatie DIENST Advies over en ondersteuning bij het (initieel) inrichten/optimaliseren van de structuur van de(it Service Management)organisatie Advies over en ondersteuning bij het initieel inrichten/optimaliseren

Nadere informatie

ROAD MAP VOOR HET CONCRETISEREN EN HET IMPLEMENTEREN VAN DE STRATEGIE Strategisch performance management

ROAD MAP VOOR HET CONCRETISEREN EN HET IMPLEMENTEREN VAN DE STRATEGIE Strategisch performance management De road map is erop gericht om het beoogde succes van een organisatie (de strategische ambitie) te helpen maken. De road map gaat in op hoe de weg naar het succes expliciet en concreet te maken Jan Scheffer

Nadere informatie

Competenties met indicatoren bachelor Civiele Techniek.

Competenties met indicatoren bachelor Civiele Techniek. Competenties met indicatoren bachelor Civiele Techniek. In de BEROEPSCOMPETENTIES CIVIELE TECHNIEK 1 2, zijn de specifieke beroepscompetenties geformuleerd overeenkomstig de indeling van het beroepenveld.

Nadere informatie

CORA 1.0 Bedrijfs- en ICT-referentiearchitectuur voor woningcorporaties

CORA 1.0 Bedrijfs- en ICT-referentiearchitectuur voor woningcorporaties CORA 1.0 Bedrijfs- en ICT-referentiearchitectuur voor woningcorporaties Hoe zorgen we ervoor dat we nieuwe diensten en producten soepel in onze bedrijfsvoering op kunnen nemen? Hoe geven we betere invulling

Nadere informatie

Test naam Marktgerichtheidsscan Datum 28-8-2012 Ingevuld door Guest Ingevuld voor Het team Team Guest-Team Context Overige

Test naam Marktgerichtheidsscan Datum 28-8-2012 Ingevuld door Guest Ingevuld voor Het team Team Guest-Team Context Overige Test naam Marktgerichtheidsscan Datum 28-8-2012 Ingevuld door Guest Ingevuld voor Het team Team Guest-Team Context Overige Klantgerichtheid Selecteren van een klant Wanneer u hoog scoort op 'selecteren

Nadere informatie

ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden

ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden Drechtsteden Technische Architectuur (DTA) ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden Status : Definitief 1.0 Redactie : DTA Datum : 29-08-2007 1 Versiebeheer

Nadere informatie

T Titel stage/afstudeeropdracht : Toekomstvaste Applicatie Integratie - Interconnectiviteit

T Titel stage/afstudeeropdracht : Toekomstvaste Applicatie Integratie - Interconnectiviteit Titel stage/afstudeeropdracht : Toekomstvaste Applicatie Integratie - Interconnectiviteit Duur van stage/afstuderen Manager Begeleider Locatie : 6 à 9 Maanden : dr. ir. J.J. Aue : dr. ir. H.J.M. Bastiaansen

Nadere informatie

Bedrijfssystemen vervangen door Slim Software Nabouwen

Bedrijfssystemen vervangen door Slim Software Nabouwen Bedrijfssystemen vervangen door Slim Software Nabouwen Codeless White Paper Roland Worms, Directeur Wouter van der Ven, Lead Software Architect Inhoudsopgave 1. Introductie 2. Het IT dilemma. Als standaard

Nadere informatie

Whitepaper implementatie workflow in een organisatie

Whitepaper implementatie workflow in een organisatie Whitepaper implementatie workflow in een organisatie Auteur: Remy Stibbe Website: http://www.stibbe.org Datum: 01 mei 2010 Versie: 1.0 Whitepaper implementatie workflow in een organisatie 1 Inhoudsopgave

Nadere informatie

VAN DUIZEND BLOEMEN NAAR EEN HORTUS BOTANICUS Het Portaal 21 januari 2010 sambo~ict Coen Free Faraday van der Linden Maarten van den Dungen

VAN DUIZEND BLOEMEN NAAR EEN HORTUS BOTANICUS Het Portaal 21 januari 2010 sambo~ict Coen Free Faraday van der Linden Maarten van den Dungen VAN DUIZEND BLOEMEN NAAR EEN HORTUS BOTANICUS Het Portaal 21 januari 2010 sambo~ict Coen Free Faraday van der Linden Maarten van den Dungen Missie-Visie Het succes van de leerling is de reden van ons bestaan.

Nadere informatie

Doe eens gek! Houd rekening met de mensen in uw organisatie bij het implementeren van ICT oplossingen.

Doe eens gek! Houd rekening met de mensen in uw organisatie bij het implementeren van ICT oplossingen. Doe eens gek! Houd rekening met de mensen in uw organisatie bij het implementeren van ICT oplossingen. ERP, CRM, workflowmanagement en documentmanagement systemen, ze hebben één ding gemeen: Veel van de

Nadere informatie

PROJECTMANAGEMENT 1 SITUATIE

PROJECTMANAGEMENT 1 SITUATIE PROJECTMANAGEMENT George van Houtem 1 SITUATIE Het werken in en het leidinggeven aan projecten is tegenwoordig eerder regel dan uitzondering voor de hedendaagse manager. In elk bedrijf of organisatie komen

Nadere informatie

5 Programmastructuur

5 Programmastructuur 5 Programmastructuur Om het informatieplan en de daarin beschreven componenten is het aan te raden een programma- en projectenorganisatie in te richten. Volgend schema geeft de verschillende actoren en

Nadere informatie

Het BiSL-model. Een whitepaper van The Lifecycle Company

Het BiSL-model. Een whitepaper van The Lifecycle Company Het BiSL-model Een whitepaper van The Lifecycle Company Met dit whitepaper bieden we u een overzicht op hooflijnen van het BiSL-model. U vindt een overzicht van de processen en per proces een beknopte

Nadere informatie

Data Governance van visie naar implementatie

Data Governance van visie naar implementatie make connections share ideas be inspired Data Governance van visie naar implementatie Frank Dietvorst (PW Consulting) deelprogrammamanager Caesar - Vernieuwing Applicatie Landschap Leendert Paape (SAS

Nadere informatie

Last but not least. Hoofdstuk 35. Bijlagen

Last but not least. Hoofdstuk 35. Bijlagen Last but not least Hoofdstuk 35 Bijlagen V1.2 / 01 februari 2016 Geen copyright! MCTL is in licentie gegeven volgens een Creative Commons Naamsvermelding 3.0 Nederland licentie. Gebaseerd op een werk van

Nadere informatie

[functie] De functie die verantwoordelijk is voor het beheren van applicaties. [zaak] Een methode of maatregel om een risico te managen.

[functie] De functie die verantwoordelijk is voor het beheren van applicaties. [zaak] Een methode of maatregel om een risico te managen. Applicatiebeheer het beheren van applicaties. [functie] De functie die verantwoordelijk is voor het beheren van applicaties. Beheer (beheren) Control Onder de activiteit applicatiebeheer valt de ontwikkeling,

Nadere informatie

Inhoudsopgave. Bewust willen en kunnen 4. Performance Support 5. Informele organisatie 5. Waarom is het zo moeilijk? 6

Inhoudsopgave. Bewust willen en kunnen 4. Performance Support 5. Informele organisatie 5. Waarom is het zo moeilijk? 6 Inleiding De afgelopen vijftien jaar hebben we veel ervaring opgedaan met het doorvoeren van operationele efficiencyverbeteringen in combinatie met ITtrajecten. Vaak waren organisaties hiertoe gedwongen

Nadere informatie

Management. Analyse Sourcing Management

Management. Analyse Sourcing Management Management Analyse Sourcing Management Management Business Driven Management Informatie- en communicatietoepassingen zijn onmisbaar geworden in de dagelijkse praktijk van uw organisatie. Steeds meer

Nadere informatie

De beheerrisico s van architectuur

De beheerrisico s van architectuur De beheerrisico s van architectuur Een overzicht van de ArChimate Risico Extensie versie 0.2 Bert Dingemans Inleiding Het implementeren van een (enterprise) architectuur brengt altijd risico s met zich

Nadere informatie

EFQM model theoretisch kader

EFQM model theoretisch kader EFQM model theoretisch kader Versie 1.0 2000-2009, Biloxi Business Professionals BV 1. EFQM model EFQM staat voor European Foundation for Quality Management. Deze instelling is in 1988 door een aantal

Nadere informatie

Portal Planning Process

Portal Planning Process BROCHURE Portal Planning Process SAMENWERKEN AAN EEN WAARDEVOL PORTAAL BROCHURE PORTAL PLANNING PROCESS 2 Axians PORTAL PLANNING PROCESS BROCHURE Inhoud Introductie 4 3 Portal Planning Process 5 4 Uitdagingen

Nadere informatie

Onderdelen module 3 (gesplitst in delen 1 en 2)

Onderdelen module 3 (gesplitst in delen 1 en 2) Onderdelen module 3 (gesplitst in delen 1 en 2) Deel 1 1. Prelude 8 13 2. Achtergrond en Context MARIJ (leerdoel 3; duur 1-2 uur) 14-25 3. Eén architectuur voor de Rijksdienst (leerdoel 3; duur 1 uur)

Nadere informatie

Rijkspas: veiligheid en flexibiliteit. ID-ware, C. Borgmann, MSc Heerhugowaard 24 november 2011

Rijkspas: veiligheid en flexibiliteit. ID-ware, C. Borgmann, MSc Heerhugowaard 24 november 2011 Rijkspas: veiligheid en flexibiliteit ID-ware, C. Borgmann, MSc Heerhugowaard 24 november 2011 24-11-2011 Profile Consultancy Services State of the art software solutions Project implementation Life-cycle

Nadere informatie

De SYSQA dienst auditing. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

De SYSQA dienst auditing. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. De SYSQA dienst auditing Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3

Nadere informatie

PRINCE2 2009 is overzichtelijker

PRINCE2 2009 is overzichtelijker PRINCE2 2009 is overzichtelijker 29 mei 2009 door: Lia de Zoete en Reinier de Koning Half juni presenteert het Office of Government Commerce in Londen PRINCE2 2009. Het grote voordeel van de nieuwe versie

Nadere informatie

https://www.managementboek.nl/boek/9789012117951/informatiemanagement-enbeleid-toon-abcouwer#over

https://www.managementboek.nl/boek/9789012117951/informatiemanagement-enbeleid-toon-abcouwer#over https://www.managementboek.nl/boek/9789012117951/informatiemanagement-enbeleid-toon-abcouwer#over Samenvatting 'Informatiemanagement en -beleid' zijn voorwaardelijk voor een gezonde en effectieve informatiehuishouding.

Nadere informatie

Functiebeschrijving Technische Architect

Functiebeschrijving Technische Architect Functiebeschrijving 1. Algemene Gegevens Organisatie Functienaam Versie Auteur : [naam organisatie] : : 1.0 concept : Ad Paauwe a. Plaats in de organisatie De rapporteert aan de manager van het architectuurteam.

Nadere informatie

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe SPIDER werkgroep Requirements Management Subwerkgroep Methoden Toelichting inhoud en voortgang tot nu toe donderdag 17 januari 2008 Frans van Veen Bert Dubbelman Robert van Lieshout Erwin Bolwidt Jan-Willem

Nadere informatie

Dragon1 EA Tool. Business case webbased EA tool. Een webbased EA tool geschikt voor elke architectuurmethode!

Dragon1 EA Tool. Business case webbased EA tool. Een webbased EA tool geschikt voor elke architectuurmethode! Dragon1 EA Tool Business case webbased EA tool Een webbased EA tool geschikt voor elke architectuurmethode! uw organisatie, datum, versie #.#, documentstatus eigenaar/budgetverantwoordelijke: Kies op deze

Nadere informatie

notitie Systems Engineering Lesplan Requirements Engineering (RE) Werkgroep opleidingen Definitief; vastgesteld Stuurgroep 4P

notitie Systems Engineering Lesplan Requirements Engineering (RE) Werkgroep opleidingen Definitief; vastgesteld Stuurgroep 4P notitie Van project onderwerp opgemaakt door Systems Engineering Lesplan Requirements Engineering (RE) Werkgroep opleidingen status datum opmaak 20-7-2012 bijlagen Definitief; vastgesteld Stuurgroep 4P

Nadere informatie

Risicomanagement en NARIS gemeente Amsterdam

Risicomanagement en NARIS gemeente Amsterdam Risicomanagement en NARIS gemeente Amsterdam Robert t Hart / Geert Haisma 26 september 2013 r.hart@risicomanagement.nl / haisma@risicomanagement.nl 1www.risicomanagement.nl Visie risicomanagement Gemeenten

Nadere informatie

ORGANISATORISCHE IMPLENTATIE BEST VALUE

ORGANISATORISCHE IMPLENTATIE BEST VALUE ORGANISATORISCHE IMPLENTATIE BEST VALUE EEN ONDERZOEK NAAR DE IMPLEMENTATIE VAN BEST VALUE BINNEN EEN SYSTEMS ENGINEERING OMGEVING STEPHANIE SAMSON BEST VALUE KENNIS SESSIE WESTRAVEN 17 JUNI 09.00 12.00

Nadere informatie

Resultaten IBIS project. SISLink conferentie 19 juni 2009 Bote Folkertsma, Studielink

Resultaten IBIS project. SISLink conferentie 19 juni 2009 Bote Folkertsma, Studielink Resultaten IBIS project SISLink conferentie 19 juni 2009 Bote Folkertsma, Studielink Onderwerpen Projectdoel en -resultaten Analyse knelpunten IBIS concept Hoe verder Projectdoel IBIS Verkenning van de

Nadere informatie

HERGEBRUIK VAN REQUIREMENTS

HERGEBRUIK VAN REQUIREMENTS HERGEBRUIK VAN REQUIREMENTS EEN PRAKTISCHE AANPAK BUSINESS ANALYSE CENTER OF EXCELLENCE - SYNERGIO Inhoudsopgave 1 HERGEBRUIK VAN REQUIREMENTS... 3 1.1 GEBRUIKEN VERSUS HERGEBRUIKEN... 4 2 STRATEGIE...

Nadere informatie

Communicatieplan WTH Vloerverwarming in het kader van de CO2-Prestatieladder

Communicatieplan WTH Vloerverwarming in het kader van de CO2-Prestatieladder Communicatieplan WTH Vloerverwarming in het kader van de CO2-Prestatieladder Communicatieplan, 22 Augustus 2014 1 Voorwoord Duurzaamheid is geen trend, het is de toekomst. Het is niet meer weg te denken

Nadere informatie

Functiebeschrijving Business Architect

Functiebeschrijving Business Architect Functiebeschrijving 1. Algemene Gegevens Organisatie Functienaam Versie Auteur : [naam organisatie] : : 1.0 concept : Ad Paauwe a. Plaats in de organisatie De rapporteert aan de manager architectuur van

Nadere informatie

Antwoordmodel. Meerkeuzevragen (40 punten)

Antwoordmodel. Meerkeuzevragen (40 punten) Antwoordmodel Aan dit antwoordmodel kunnen geen rechten worden ontleend. Het antwoordmodel dient als indicatie voor de corrector. Studiemateriaal Bollen, L. en Vluggen, M (2012). Informatiemanagement.

Nadere informatie

Betere onderwijsondersteuning met Student Informatie Systemen SIS 2010: VAN INSCHRIJFSYSTEEM NAAR ONDERWIJS 2.0

Betere onderwijsondersteuning met Student Informatie Systemen SIS 2010: VAN INSCHRIJFSYSTEEM NAAR ONDERWIJS 2.0 Betere onderwijsondersteuning met Student Informatie Systemen SIS 2010: VAN INSCHRIJFSYSTEEM NAAR ONDERWIJS 2.0 MINISYMPOSIA Ter introductie / 2 Op 22 maart 2010 organiseerde M&I/Partners een minisymposium

Nadere informatie

Whitepaper. Hoe de kans op een succesvolle ERP-implementatie te vergroten. ..het effect van vreemde ogen.. VERTROUWELIJK. www.implementatie-erp.

Whitepaper. Hoe de kans op een succesvolle ERP-implementatie te vergroten. ..het effect van vreemde ogen.. VERTROUWELIJK. www.implementatie-erp. Whitepaper Hoe de kans op een succesvolle ERP-implementatie te vergroten..het effect van vreemde ogen.. VERTROUWELIJK W E www.implementatie-erp.nl info@opdic.nl Hoe de kans op een succesvolle ERP-implementatie

Nadere informatie

Architectuur, Organisatie en Business Cases

Architectuur, Organisatie en Business Cases Architectuur, Organisatie en Business Cases Ervaringen uit de praktijk Jan de Baat CMG Trade, Transport & Industry B.V. Inleiding In de Dynamiek track van LAC 2000 is de problematiek omtrent de alignment

Nadere informatie

Bewaren van digitale informatie: hoe kom je tot een goede beslissing?

Bewaren van digitale informatie: hoe kom je tot een goede beslissing? Bewaren van digitale informatie: hoe kom je tot een goede beslissing? Hans Hofman Nationaal Archief Netherlands NCDD Planets dag Den Haag, 14 december 2009 Overzicht Wat is het probleem? Wat is er nodig?

Nadere informatie

VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER

VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER Sander Hoogendoorn Versie 1.0 15 april 2002 Documentbeheer Versie Datum Auteur Omschrijving 0.1 15 April 2002 Sander Hoogendoorn 0.2 15 april

Nadere informatie

Richtlijnen voor het ontwerpen een Intranetportal Door Bas Fockens

Richtlijnen voor het ontwerpen een Intranetportal Door Bas Fockens Richtlijnen voor het ontwerpen een Intranetportal Door Bas Fockens Copyright Datacon www.datacon.nl Wat is een intranetportal? Een intranet is een online gepersonaliseerde en geïntegreerde toegang tot

Nadere informatie

Aan uw raad is het volgende toegezegd: Toezeggingen college van B&W in Commissies en Raad (september 2015) TCM 09 21 mei 2015

Aan uw raad is het volgende toegezegd: Toezeggingen college van B&W in Commissies en Raad (september 2015) TCM 09 21 mei 2015 Bedrijfsvoering De gemeenteraad van Bloemendaal Datum : 19 augustus 2015 Uw kenmerk : Ons kenmerk : 2015056815 Behandeld door : J. van der Hulst Doorkiesnummer : 023-522 5592 Onderwerp : Rapportage informatiebeveiliging

Nadere informatie

Praktisch Implementeren van EA bij Gemeenten

Praktisch Implementeren van EA bij Gemeenten Praktisch Implementeren van EA bij Gemeenten Edwin de Vries 3 juni 2008 Praktisch Implementeren van Enterprise Architectuur bij Gemeenten Waarom Architectuur bij Gemeenten? Praktische aanpak Invulling

Nadere informatie

6 TIPS DIE HET PRESTEREN VAN UW WERKOMGEVING VERBETEREN

6 TIPS DIE HET PRESTEREN VAN UW WERKOMGEVING VERBETEREN 6 TIPS DIE HET PRESTEREN VAN UW WERKOMGEVING VERBETEREN INLEIDING Het Nieuwe Werken is in de afgelopen jaren op vele plekken geïntroduceerd om slimmer om te gaan met de beschikbare middelen binnen organisaties

Nadere informatie

Architectuur en audit: een prima duo

Architectuur en audit: een prima duo Architectuur en audit: een prima duo Architectuur en audit: een prima duo Theoretische achtergrond Architectuur en audit in de praktijk Praktijk case IB-Groep Inhoud theorie Werkgroep architectuur Hoe

Nadere informatie

Handleiding voor het SURF Groene ICT Maturity Model

Handleiding voor het SURF Groene ICT Maturity Model Een zelfscan voor Groene ICT en Duurzaamheid in de organisatie Auteur(s): Met dank aan: Versie: Gebaseerd op: Albert Hankel Henk Plessius, Dirk Harryvan, Bert van Zomeren 2.0 SGIMM v2.0 Datum: 16-04-2015

Nadere informatie

Steenwinkel Kruithof Associates Management en Informatica Consultants. Opzetten en inrichten Shared Service Center in de zorg

Steenwinkel Kruithof Associates Management en Informatica Consultants. Opzetten en inrichten Shared Service Center in de zorg Opzetten en inrichten Shared Service Center in de zorg Hoe zet je gezamenlijk een nieuw en succesvol (ICT) Shared Service Center (SSC) op? En hoe zorg je ervoor dat de samenwerking tussen de deelnemende

Nadere informatie

ISO 25010: 2011. Een introductie SYSQA B.V.

ISO 25010: 2011. Een introductie SYSQA B.V. ISO 25010: 2011 Een introductie SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 15 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 4 2 OPBOUW VAN HET MODEL... 5 3 DE KWALITEITSEIGENSCHAPPEN

Nadere informatie

Bedrijfsarchitectuur sterker door opleiding

Bedrijfsarchitectuur sterker door opleiding Onderzoek naar het effect van de Novius Architectuur Academy Bedrijfsarchitectuur sterker door opleiding Door met meerdere collega s deel te nemen aan een opleiding voor bedrijfsarchitecten, werden mooie

Nadere informatie

Context Informatiestandaarden

Context Informatiestandaarden Context Informatiestandaarden Inleiding Om zorgverleners in staat te stellen om volgens een kwaliteitsstandaard te werken moeten proces, organisatie en ondersteunende middelen daarop aansluiten. Voor ICT-systemen

Nadere informatie

Software Engineering (I00094) College 3:

Software Engineering (I00094) College 3: Software Engineering (I00094) College 3: Kwaliteit, organisatie en documentatie Marko van Eekelen marko@cs.ru.nl kamer HG02.074 1 Huidige planning 1. 6 feb: Het systeemontwikkelproces 2. 13 feb: Requirements-analyse

Nadere informatie

Wij leggen rekenschap af over:

Wij leggen rekenschap af over: VRAGEN Het afleggen van rekenschap. ANTWOORDEN TOELICHTING / VOORBEELDEN VRAAG 1. Onze organisatie legt rekenschap af over onze effecten op de maatschappij, de economie en het milieu. Welke activiteiten

Nadere informatie

Rapport over het werkprofiel van Software engineer (sr)

Rapport over het werkprofiel van Software engineer (sr) Rapport over het werkprofiel van Software engineer (sr) Identificatienummer: Publicatiedatum: 19 november 2015 Leeswijzer Dit rapport omschrijft het werkprofiel van 'Software engineer (sr)' zoals die door

Nadere informatie

Praktijkplein Titel: Toepassing: Koppeling met het Operational Excellence Framework: Implementatiemethodieken: ontwerpen en ontwikkelen.

Praktijkplein Titel: Toepassing: Koppeling met het Operational Excellence Framework: Implementatiemethodieken: ontwerpen en ontwikkelen. Praktijkplein Titel: Implementatiemethodieken: ontwerpen en ontwikkelen. Toepassing: Beknopte samenvatting van twee implementatiemethodieken en hun toepassing bij het implementeren van een operational

Nadere informatie

Jacques Herman 21 februari 2013

Jacques Herman 21 februari 2013 KING bijeenkomst Audit- en Pentestpartijen Toelichting op de DigiD Rapportage template en de NOREA Handreiking DigiD ICT-beveiligingsassessments Jacques Herman 21 februari 2013 Samenvatting van de regeling

Nadere informatie

Informatie is overal: Heeft u er grip op?

Informatie is overal: Heeft u er grip op? Informatie is overal: Heeft u er grip op? Zowel implementatie als certificering Omdat onze auditors geregistreerd zijn bij de Nederlandse Orde van Register EDP-auditors (NOREA), kan Koenen en Co zowel

Nadere informatie

BASISCOMPETENTIES VOOR FACILITATOREN

BASISCOMPETENTIES VOOR FACILITATOREN BASISCOMPETENTIES VOOR FACILITATOREN ACHTERGROND De International Association of Facilitators (IAF) is een internationale organisatie met als doel om de kunst en de praktijk van het professioneel faciliteren

Nadere informatie

De impact van de basisregistraties op de informatievoorziening van gemeenten

De impact van de basisregistraties op de informatievoorziening van gemeenten De impact van de basisregistraties op de informatievoorziening van gemeenten Op weg naar de Gemeentelijke Service Bus Danny Greefhorst Gemeenten worden geconfronteerd met allerlei ontwikkelingen die van

Nadere informatie

Aanpak projectaudits

Aanpak projectaudits Aanpak projectaudits 1. Inleiding Veel lokale overheden werken op basis van een standaardmethodiek Projectmatig Werken. Op die manier wordt aan de voorkant de projectfasering, besluitvorming en control

Nadere informatie

Informatiebeveiliging voor gemeenten: een helder stappenplan

Informatiebeveiliging voor gemeenten: een helder stappenplan Informatiebeveiliging voor gemeenten: een helder stappenplan Bewustwording (Klik hier) Structureren en borgen (Klik hier) Aanscherping en maatwerk (Klik hier) Continu verbeteren (Klik hier) Solviteers

Nadere informatie

Cloud Computing, een inleiding. ICT Accountancy & Financials congres 2013: Cloud computing en efactureren. Jan Pasmooij RA RE RO: jan@pasmooijce.

Cloud Computing, een inleiding. ICT Accountancy & Financials congres 2013: Cloud computing en efactureren. Jan Pasmooij RA RE RO: jan@pasmooijce. Cloud Computing, een inleiding ICT Accountancy & Financials congres 2013: Cloud computing en efactureren 10 december 2013 Jan Pasmooij RA RE RO: jan@pasmooijce.com 10 december 2013 1 Kenmerken van Cloud

Nadere informatie

Van strategie naar praktijk: een case uit Den Haag

Van strategie naar praktijk: een case uit Den Haag Van strategie naar praktijk: een case uit Den Haag Door: Patrick Rancuret En wat levert het nu op? Dat is de vraag die menig manager in de gemeente Den Haag stelt als het gaat over het gebruik van sociale

Nadere informatie

Het gevolg van transitie naar de cloud SaMBO-ICT & KZA. 16 januari 2014 Doetinchem

Het gevolg van transitie naar de cloud SaMBO-ICT & KZA. 16 januari 2014 Doetinchem Het gevolg van transitie naar de cloud SaMBO-ICT & KZA 16 januari 2014 Doetinchem Agenda Introductie Aanleiding Samenvatting handreiking Uitkomsten workshop netwerkbijeenkomst Afsluiting 2 Introductie

Nadere informatie

Tabel competentiereferentiesysteem

Tabel competentiereferentiesysteem Bijlage 3 bij het ministerieel besluit van tot wijziging van het ministerieel besluit van 28 december 2001 tot uitvoering van sommige bepalingen van het koninklijk besluit van 30 maart 2001 tot regeling

Nadere informatie

Projectmatig 2 - werken voor lokale overheden

Projectmatig 2 - werken voor lokale overheden STUDIEDAG Projectmatig werken in lokale overheden LEUVEN 27 oktober 2011 Projectmatig werken in de lokale sector Katlijn Perneel, Partner, ParFinis Projectmatig 2 - werken voor lokale overheden 1 Inhoud

Nadere informatie

Functioneel beheer in Nederland

Functioneel beheer in Nederland Functioneel beheer in Nederland Achtergrond Op initiatief van Marjet Smits (ad Matres), Martijn Buurman (Functioneel-beheerder.com) en Günther Nijmeijer (inmezzo) is eind 2012 de eerste verkiezing voor

Nadere informatie

IT Service CMM. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

IT Service CMM. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. IT Service CMM Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 2 GESCHIEDENIS EN ACHTERGROND...

Nadere informatie

Functioneel ontwerp. Een introductie. Algemene informative voor medewerkers van SYSQA B.V. Almere

Functioneel ontwerp. Een introductie. Algemene informative voor medewerkers van SYSQA B.V. Almere Functioneel ontwerp Een introductie Algemene informative voor medewerkers van SYSQA B.V. Almere Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 Inleiding... 3 1.1 Algemeen... 3 2 Inleiding... 4 2.1

Nadere informatie

De informatie adapter vormt de basis voor uitwisseling van digitale informatie in projecten waarbij de volgende uitgangspunten gekozen worden:

De informatie adapter vormt de basis voor uitwisseling van digitale informatie in projecten waarbij de volgende uitgangspunten gekozen worden: Op het vlak van informatie uitwisseling tussen bedrijven valt veel te verbeteren. Veel van die verbeteringen vinden hun oorzaak in het niet goed op elkaar aansluiten van de verschillende softwaretoepassingen

Nadere informatie

VAN AMBITIE NAAR UITVOERING - INRICHTING EN BESTURING I&A DELFLAND. 31 augustus 2013

VAN AMBITIE NAAR UITVOERING - INRICHTING EN BESTURING I&A DELFLAND. 31 augustus 2013 VAN AMBITIE NAAR UITVOERING - INRICHTING EN BESTURING I&A DELFLAND 31 augustus 2013 CONTEXT Delfland wordt de komende jaren geconfronteerd met een groeiende interne en externe vraag naar (innovatieve)

Nadere informatie

bedrijfsprocessen en vormt daarmee de kapstok voor de producten van andere disciplines. Het PAM is geen RUP concept.

bedrijfsprocessen en vormt daarmee de kapstok voor de producten van andere disciplines. Het PAM is geen RUP concept. 1. 1.1. Inleiding Doel De Requirementdiscipline richt zich op het vaststellen en vastleggen van de eisen en wensen die aan een oplossing worden gesteld: de requirements. Rollen De keyrol binnen deze discipline

Nadere informatie

NEN 7510: Een kwestie van goede zorg

NEN 7510: Een kwestie van goede zorg NEN 7510: Een kwestie van goede zorg Menig zorginstelling geeft aan nog niet te voldoen aan de NEN 7510 omdat deze (nog) niet verplicht is. Wettelijk is dit wellicht het geval, maar wat nu als men dit

Nadere informatie

INITIATIEFVOORSTEL Gemeente Velsen

INITIATIEFVOORSTEL Gemeente Velsen INITIATIEFVOORSTEL Gemeente Velsen Raadsvergadering d.d. : 1 december 2011 Raadsbesluitnummer : R11.081 Carrousel d.d. : 17 november 2011 Onderwerp : Eindrapport Rekenkamercommissie kwaliteit Grondbeleid

Nadere informatie

Product Risico Analyse

Product Risico Analyse Product Risico Analyse Jurian van de Laar TestNet Avond 9 oktober 2013 www.improveqs.nl (info@improveqs.nl) Versie 2.0 1 Herkenbaar? In ons testproces wordt product risico analyse toegepast Wij gebruiken

Nadere informatie

Incore Solutions Learning By Doing

Incore Solutions Learning By Doing Incore Solutions Learning By Doing Incore Solutions Gestart in November 2007 Consultants zijn ervaren met bedrijfsprocessen en met Business Intelligence Alle expertise onder 1 dak voor een succesvolle

Nadere informatie

Ik ga het niet doen, en mijn mensen ook niet!

Ik ga het niet doen, en mijn mensen ook niet! Ik ga het niet doen, en mijn mensen ook niet! Wat zijn de belangrijkste eisen en uitdagen van jouw organisatie in de komende 6 maanden? Welke kritische succesfactoren worden er gesteld? Waar liggen de

Nadere informatie

KWALITEITSNETWERKEN: leren van elkaar. Een methode om de kwaliteit van forensische zorg te verhogen.

KWALITEITSNETWERKEN: leren van elkaar. Een methode om de kwaliteit van forensische zorg te verhogen. KWALITEITSNETWERKEN: leren van elkaar Een methode om de kwaliteit van forensische zorg te verhogen. CONTACT Voor meer informatie over de kwaliteitsnetwerken kunt u contact opnemen met: Diewke de Haen (ddehaen@efp.nl)

Nadere informatie

Olde Bijvank Advies Organisatieontwikkeling & Managementcontrol

Olde Bijvank Advies Organisatieontwikkeling & Managementcontrol SAMENVATTING ITIL ITIL is nog steeds dé standaard voor het inrichten van beheerspocessen binnen een IT-organisatie. En dekt zowel applicatie- als infrastructuur beheer af. Indien gewenst kan ITIL worden

Nadere informatie

UWV Testservice. Resultaatgerichte invoering van een adaptief procesmodel

UWV Testservice. Resultaatgerichte invoering van een adaptief procesmodel UWV Testservice Resultaatgerichte invoering van een adaptief procesmodel Rob Passage Karin Boons UWV Gegevensdiensten Sogeti Software Control Agenda 11e SPIder conferentie, 29 september 2008 De werkende

Nadere informatie

Draaiboek Invoering Basisregistratie Personen l Afnemers

Draaiboek Invoering Basisregistratie Personen l Afnemers Draaiboek Invoering Basisregistratie Personen l Afnemers Van Oriëntatie naar Gebruik van de BRP Inleiding & toelichting op de vijf hoofdstappen Publicatiedatum: oktober 2014 Ten geleide Voor u ligt de

Nadere informatie

Betere dienstverlening door eigen verantwoordelijkheid. Stop met procesgericht ICT-beheer!

Betere dienstverlening door eigen verantwoordelijkheid. Stop met procesgericht ICT-beheer! Betere dienstverlening door eigen verantwoordelijkheid Stop met procesgericht ICT-beheer! Agenda 19.00 Welkom 19.05 Terugblik op presentatie Service managersdag 2011 19.30 Gelaagdheid in dienstverlening

Nadere informatie

Strategische Issues in Dienstverlening

Strategische Issues in Dienstverlening Strategische Issues in Dienstverlening Strategisch omgaan met maatschappelijke issues Elke organisatie heeft issues. Een definitie van de term issue is: een verschil tussen de verwachting van concrete

Nadere informatie

Onderzoeksresultaten infosecurity.nl

Onderzoeksresultaten infosecurity.nl Onderzoeksresultaten infosecurity.nl Pagina 1 Introductie Tijdens de beurs infosecurity.nl, die gehouden werd op 11 en 12 oktober 2006, heeft Northwave een onderzoek uitgevoerd onder bezoekers en exposanten.

Nadere informatie

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces Software Processen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Het software proces Een gestructureerd set van activiteiten nodig om een software systeem te ontwikkelen Specificatie;

Nadere informatie