Concerns van stakeholders in de beheerorganisatie
|
|
- Nathalie van der Velde
- 8 jaren geleden
- Aantal bezoeken:
Transcriptie
1 Concerns van stakeholders in de beheerorganisatie Risico analyse op basis van interactie en checklists versie 0.2 Bert Dingemans
2 1 Inleiding Risico analyse is een relatief onbekend fenomeen binnen de ICT, op een aantal plaatsen kom je het tegen binnen de beheerprocessen zoals ITIL. Echter binnen de methoden voor enterprise architectuur zoals Togaf en Archimate is werken met risico s een onderbelicht onderwerp. Dit artikel zoekt naar de mogelijkheden om risico inventarisatie te implementeren binnen de kaders van Togaf en Archimate. Het beperkt zich hierbij om reden van projectscope tot de risico s van de beheerorganisatie. Vanzelfsprekend is deze scopebeperking arbitrair. Ook voor andere stakeholders is het werken vanuit risico s een interessant perspectief. 2 Stakeholders en beheer 2.1 Stakeholders in de beheerorganisatie Bij het opstellen van een enterprisearchitectuur spelen de concerns van de stakeholders een belangrijke rol. Deze bepalen de richting van de oplossing in de target architectuur. Ook is bij het uitwerken van de baseline architectuur de input van stakeholders een belangrijke bron van informatie bij inventarisatie van concerns. De beheerorganisatie is in deze een stakeholder populatie die een afwijkende rol vervuld binnen de enterprise architectuur. De beheerorganisatie maakt geen deel uit van bijvoorbeeld de werkprocessen die deel uitmaken van de uitwerking van de architectuur. Sterker nog de beheerorganisatie van ICT systemen is ingericht op basis van eigen werkprocessen. Deze processen worden omschreven als de beheerprocessen en zijn in veel gevallen gebaseerd op service libraries zoals BISL, ASL en ITIL. Bovenstaand neemt niet weg dat de betrokken beheerders in veel gevallen een heel goed beeld hebben van de knelpunten in de te modelleren organisatie en haar ondersteunende ICT. Tijdens de beheerfase van een ICT landschap komen de knelpunten van de ingezette software- en infrastructuurcomponenten pas goed aan de orde. Bijvoorbeeld omdat er veel klachten binnenkomen over applicatie componenten. Denk echter ook aan problemen van beschikbaarheid en performance rond verschillende onderdelen. Deze worden als eerste structureel geconstateerd door de beheerorganisatie. Daarnaast zijn de beheeractiviteiten feitelijk (door de afwijkende taken en processen) geen onderdeel van de enterprise. Dat maakt ze een soort van buitenstaander die daardoor in staat zijn een onafhankelijke visie te vormen. 2.2 Aspecten van de beheerorganisatie Zien we bij architectuur de focus veelal liggen op aspecten van vernieuwing en optimalisatie. Bij ontwikkelaars van software zien we een duidelijke overeenkomst met deze focus, met name gericht op optimalisatie. Beheerders hebben echter focus op hele andere aspecten van het ICT landschap. Onderstaande opsomming geeft een beeld: Continuiteit Van ICT voorzieningen wordt verwacht dat deze beschikbaar zijn op het moment dat de afnemers van de diensten van deze voorzieningen dat verwachten. Dat stelt eisen aan de 2
3 configuratie van het ICT landschap maar ook aan de implementatie van de afzonderlijke onderdelen. Reductie van complexiteit Een grote complexiteit van het ICT landschap stelt extra eisen de beheerorganisatie, bijvoorbeeld op het vlak van kennisontwikkeling, inrichting beheerprocessen en op het vlak beheeractiviteiten. Bijvoorbeeld een ICT landschap dat in hoge mate gestandaardiseerd is op het vlak van technologie (zoals één database platform) zal de introductie van een implementatie met een afwijkend platform proberen te voorkomen. Reden is dat dit afwijkende component een onevenredige eis stelt aan de beheerorganisatie. Risicoreductie Naast continuïteit in de dagelijkse uitvoering zie je dat lange termijn continuiteit een belangrijk aandachtspunt is voor de beheerorganisatie. Men zal dus veelal zoeken naar componenten die toekomstzeker zijn. Daartoe wordt bijvoorbeeld gekeken naar de leveranciers rond een component. Leveranciers op het vlak van opleidingen, ondersteuning en toekomstige releases. Hiermee wordt voorkomen dat in een later stadium de continuïteit van de ICT dienstverlening in het gevaar komt of dat onevenredige kosten gemaakt moeten worden voor het beheer van componenten. Kostenaspecten In bovenstaande punten is reeds een aantal keren het kostenaspect genoemd. Een slecht beheerd en divers ICT landschap is naast de andere aspecten veelal duur. Bijvoorbeeld omdat er meer personen ingezet moeten worden om de componenten beschikbaar te houden, maar ook doordat bijvoorbeeld vaker updates en releases nodig zijn. Ook is het op peil houden van het kennisniveau van een divers ICT landschap veelal duurder dan een homogene inrichting. Uit bovenstaande punten blijkt dat de beheerorganisatie hele andere criteria hebben voor de componenten in een ICT landschap. Neem daarnaast de afwezig dat het beheren van ICT componenten veelal vele malen duurder is dan het ontwikkelen van deze componenten. Gevolg is dat de beheeraspecten een interessante oplossingsrichting zijn om ICT architectuur te optimaliseren op het vlak van risico s en kosten. 3 Concerns, principes en requirements 3.1 Indeling van de concerns Concerns, principes en requirements zijn binnen Togaf verschillende views op de requirements die betrokken stakeholders stellen aan het applicatie en ICT landschap. Bij het uitwerken van een architectuur zijn deze requirements een belangrijk uitgangspunt voor de selectie van de verschillende onderdelen. Want afhankelijk van het belang van een requirement zal het ene ICT component beter toepasbaar zijn dan het andere. Bijvoorbeeld voor alle betrokken stakeholders geldt dat de kosten van de voorgestelde oplossing zo laag mogelijk zijn. Voor de keuze van het database platform is dan MySQL een interessantere keuze ten opzichte van bijvoorbeeld SQL-server of Oracle vanwege licentiekosten. Echter andere concerns zoals bijvoorbeeld beschikbaarheid en schaalbaarheid zijn in sommige situaties eveneens belangrijke concerns. Gevolg is dat een afweging gemaakt moet worden welk concern het zwaarst wegend is. Om bovengenoemde afweging te kunnen maken is het noodzakelijk om verschillende concerns te gaan kwantificeren en op basis van deze kwantitatieve analyse deze 3
4 vergelijking te onderbouwen. In het volgende hoofdstuk wordt een uitwerking gegeven waarbij op basis van checklists gevraagd wordt aan de relevante stakeholders wat hun oordeel is over de score voor architectuur componenten voor een concern. In onderstaande paragraaf zijn een aantal voorbeelden van concerns beschreven. 3.2 Voorbeelden concerns Concerns liggen voor allen stakeholders op een ander vlak. Zo zullen gebruikers van de systemen concerns hebben op het vlak van gebruikersvriendelijkheid, gebruiksgemak en het ondersteunen van de werkzaamheden. Voor stakeholders betrokken bij informatiebeveiliging liggen de concerns met name op het vlak van beveiliging en beveiligingsrisico s. Voor de beheerorganisatie zijn met name non functionele aspecten als beschikbaarheid, beheerbaarheid en uitbreidbaarheid van groot belang. Hieronder een aantal relevante concerns voor stakeholders uit de beheerorganisatie. Nogmaals wordt benadrukt dat de inperking voor de beheerorganisatie een keuze is voor het ARE project. Concerns kunnen voor alle stakeholders bepaald en gekwantificeerd worden. Kosten Kosten, maar ook de opbrengsten van de componenten in een architectuur zijn vanzelfsprekend voor een groot aantal stakeholders belangrijke concerns. Een onbeperkt budget voor ICT komt niet vaak voor. Toch zie je bij de uitwerking van een architectuur dat het kostenaspect niet of maar ten dele aan de orde komt. Wordt er gekeken naar de kosten, dan zie je veelal dat dit beperkt blijft tot de initiele kosten zoals ontwikkel- en licentiekosten. Beheer- en migreerkosten zijn lastiger te berekenen en worden daarom regelmatig buiten beschouwing, of er wordt een vuistregel toegepast. Non functionals Functionele requirements zijn door stakeholders meestal wel te benoemen. Een deel van de non functionele aspecten worden vaak genoemd zoals beschikbaarheid en performance. Een goed uitgangspunt bij het uitwerken van non functionele requirements is de standaard norm ISO 9126 en de uitbreiding Quint 2 genaamd. Deze non functionele eisen kunnen goed gebruikt worden voor een inventarisatie van de concerns in combinatie met een gedetailleerde verdeling van wegingsfactoren. Software volwassenheid Een minder voor de hand liggende concern is de volwassenheid van de organisatie rond componenten. Hiermee kun je in kaart brengen hoe toekomstvast een bepaald component is. Selecteer je bijvoorbeeld een toepassing die ontwikkeld en beheerd wordt door slechts één persoon waarbij de broncode niet vrijgegeven is heeft grotere volwassenheidsrisico s dan een component dat in een veelgebruikte ontwikkelomgeving is ontwikkeld en waarvan de broncode wel beschikbaar is. Beheerlibraries Een categorie alleen relevant voor beheerorganisatie zijn de beheerprocessen in libraries zoals ITIL, ASL en BISL. Deze libraries beschrijven de beheerprocessen vanuit een verschillend beheerperspectief. Risico s hierbij liggen op het vlak van ontbreken van de inrichting van deze beheerprocessen of dat deze processen wel ingericht zijn maar dat de inrichting onvoldoende in staat is om aan de vraag vanuit de organisatie te voldoen. Hierbij speelt 4
5 vanzelf ook de beheerbehoefte van de verschillende ICT componenten een rol. Denk bijvoorbeeld aan de keuze voor een divers of homogeen applicatielandschap. 5
6 4 Risico inventarisatie en interacties Risico inventarisatie is een relatief onbekend fenomeen binnen enterprise architectuur. Binnen de beheerlibraries wordt al iets meer gedaan aan risico analyse, bijvoorbeeld door het toepassen van acceptatiecriteria. De wijze waarop risico inventarisatie kan worden ingezet binnen architectuur wordt beschreven in deze paragraaf. Hierbij worden een aantal voorbeelden van inventarisaties genoemd, echter de uitwerking is niet uitputtend. Hierbij is het aanpassen van de interacties aan de specifieke situatie voor een inventarisatie van groot belang. 4.1 Verschillen in risico inventarisatie Bij het doen van risico inventarisaties zijn verschillen in de opzet van groot belang voor de uitwerking. Een veelgebruikte indeling is de volgende: 6 Test, bij non functionele meetbare requirements wordt bijvoorbeld gemeten of aan de eis wordt voldaan, zoals performance en beschikbaarheid Review, bij non functionals zoals uitbreidbaarheid, herbruikbaarheid en onderhoudbaarheid een veel toegepaste werkwijze Checklist, vragenlijsten en checklists om te controleren of aan de gestelde eis is voldaan. Vanuit architectuur kunnen de volgende verschillende viewpoints genoemd worden: Inventarisatie van de risico in de baseline architectuur. Hierbij wordt gekeken naar welke risico s er zijn voor de huidige inrichting. Men zal in deze situatie veelal kijken voor welke componenten in de architectuur het risico het hoogst of laagst is in de bestaande situatie. Inventarisatie van de risico s in de target architectuur. Men kan in dat geval enerzijds kijken naar welke componenten in de toekomstige situatie het meeste risicovol zijn. Een andere mogelijkheid is een analyse van een target architectuur waarbij de risico s van de baseline architectuur het meest gereduceerd worden. De roadmap inventarisatie, hierbij brengt men in kaart wat de grootste verschillen zijn om de risico s van de baseline binnen target architectuur te reduceren in de target architectuur. Een grote inspanning per component heeft dan een grote impact en vormt dan een groter risico. Bij het uitwerken van risico inventarisaties zijn verschillende vormen te vinden. Een veel voorkomende werkwijze is bijvoorbeeld het opgeven van verschillende elementen en deze vervolgens te sommeren. Denk bijvoorbeeld aan het in kaart brengen van de kosten voor een bepaald component of een cluster van componenten. Een andere uitwerking is het combineren van een waardering en een score. Men scoort een component en deze score wordt vermenigvuldigd met een waardering, op basis van deze berekening kan een sommering gemaakt worden van deze berekening. Hierbij wordt een onderscheid gemaakt tussen een negatieve en een positieve sommering. Dit is gerelateerd aan de inventarisaties zoals genoemd in bovenstaande opsomming een relevante werkwijze. Bij een positief gestelde analyse zal gezocht worden naar een zo hoog mogelijk uitkomst van de score, bij een negatieve opzet is het realiseren van een zo laag mogelijke score een positief resultaat. Een meer complexe vorm is inventarisatie die gebaseerd is op eigen formules. Hierbij kunnen negatieve en positieve aspecten met elkaar gecombineerd worden en is in de ene situatie de waardering negatief en in de andere positief. Ook de uitwerking van de overall berekening kan in deze anders zijn dan een sommering. Denk bijvoorbeeld aan een sommering van de positieve onderdelen verminderd met de
7 negatieve onderdelen of het berekenen van verschillen tussen vragen en een groot verschil tussen de beantwoording positief of negatief te beoordelen. 4.2 Interactievormen Risico inventarisaties onderscheiden zich in twee interactievormen: Directe interactie, de stakeholder wordt rechtsreeks bevraagd door de architect. Veelal door middel van checklists, enquetes en vragenlijsten Indirecte interactie, de stakeholders worden bevraagd door de architect in de vorm van interviews of workshops, vervolgens bepaald de architect de risico score op basis van de uitkomsten van de toegepaste interactievorm, bijvoorbeeld bij reviews. Directe interactievormen Checklists en vragenlijsten, de meest voor de hand liggende vorm van interactie. Men stelt een aantal vragen op en de beantwoording van deze vragen bepaald in welke mate het risico geanalyseerd wordt. Bijvoorbeeld zoals hierboven genoemd met een positieve of negatieve inventarisatiewijze. Hierbij kunnen verschillende presentatievormen gebruikt worden voor het bepalen van de score voor een vraag. Zoals keuzelijsten, sliders of grafische weergaven zoals stoplichten of smileys e.d.. In onderstaande afbeelding een voorbeeld van deze interactie. Afbeelding Berekeningen en calculaties, zeker bij een kwantitatieve analyse van bijvoorbeeld kosten, opbrengsten, rendement of andere financiële aspecten van een inrichting. Invulling van deze onderdelen biedt dan vervolgens de mogelijkheid om uit te rekenen wat de financiele 7
8 risico s zijn van een architectuur configuratie. Onderstaande afbeelding geeft een voorbeeld van deze vorm. Afbeelding Score en sorteringen, Bij een analyse kan men een groep van verschillende entiteiten laten sorteren voor één of meerdere risico s. Op een as zet men aan de ene kant aan dat het risico hoog is en aan de andere kant of het risico laag is. Vervolgens laat men de stakeholder de verschillende componenten op deze as afbeelden waarmee men aangeeft welk een hoog en welk een laag risico betreft. In onderstaande afbeelding een voorbeeld. 8
9 Afbeelding Matrices, bovenstaande interactievormen hebben als nadeel dat men twee dimensies onderscheid, de componenten en de risico s, maar dat men bij één van de dimensies slechts één onderdeel kan uitwerken. Of men heeft meerdere componenten gerelateerd aan één risico of omgekeerd. In een aantal gevallen kan het verhelderend werken voor de stakeholder om het verband te zien tussen meerdere componenten en meerdere risico s. Dit kan men doen door het toepassen van een matrix waarbij op de ene as de componenten worden afgebeeld en op de andere risico s. Zie bijvoorbeeld onderstaande afbeelding. 9
10 Afbeelding Indirecte interactievormen Interviews, bij een interview worden de stakeholders geïnterviewd door de architect. Dit kan in groepen of in één op één vraaggesprekken. Het voordeel van de werkwijze is dat men specifiek in kan gaan op de antwoorden die gegeven worden tijdens het interview op de vragen. Op basis van deze antwoorden kan ook een detaillering gemaakt worden op niet vooraf bepaalde risico s. Het is een krachtige interactievorm die echter wel als nadeel heeft arbeidsintensief en duur te zijn. Workshops, een bijzondere vorm van interviews is het werken met workshops. Hierbij wordt gewerkt met groepen van stakeholders die binnen een workshop met elkaar interacteren om de risico s te bepalen. Vaak wordt er gezocht naar een combinatie van indirecte en directe werkvormen. Indirect is bijvoorbeeld het opsplitsen in kleine werkgroepen en vervolgens in een groepssessie de uitkomsten te bespreken. Vaak wordt het relateren van korte omschrijvingen van risico s op basis van Brown paper sessies gebruikt. Hierbij zie je vaak dat de interactie onderling de uitkomsten binnen de groep bepalen. Dit kan een positief maar ook een negatief effect hebben. Deze vorm is minder arbeidsintensief dan het doen van interviews maar vraagt vaardigheden van de architect in het begeleiden van deze workshops Score sessies, Een nog specifiekere vorm van interactie zijn scoresessies. In workshop vorm worden risico s in kaart gebracht. Vervolgens wordt per risico of component bepaald welke de hoogste of laagste score heeft. Hierbij kan men bijvoorbeeld kiezen voor het verdelen van een beperkt aantal scorepunten over de desbetreffende onderdelen. Een andere vorm is het in volgorde zetten van onderdelen in workshop opzet. Een bijzondere vorm, veel in agile omgevingen gebruikt, is een vorm van poker. Deze vorm van risico poker is om de deelnemers per component een kaart te laten neerleggen. Een 10
11 kaart met een laag getal betekent een laag risico, een hoog getal een hoog risico. Vervolgens lichten de deelnemers met de meest extreme score (positief en negatief) de afgegeven score toe. Combinaties van directe en indirecte interacties, bovengenoemde directe en indirecte vormen van interactie kunnen vanzelfsprekend op allerlei wijzen met elkaar gecombineerd worden. Bijvoorbeeld in eerste instantie een beeld vormen van de risico s op basis van vragenlijsten en checklist. Vervolgens kan op basis van deze uitkomsten een interactieve sessie met de stakeholders worden georganiseerd of vraagt men aan een deel van de betrokkenen om de uitkomsten te scoren. In bovenstaande beschrijving zijn een aantal interactievormen genoemd, echter dit is slechts een klein voorbeeld van de vele interactievormen die ingezet kunnen worden voor het inventariseren van de risico s 4.3 Are checklists en vragenlijsten Het kunnen doen van risico inventarisaties binnen een architectuur is een belangrijk onderdeel in de implementatie binnen de Archimate Risico Extensie. Enerzijds is het de module die zorgdraagt voor het kwantificeren van risico s en het relateren van deze kwantificatie aan de diverse architectuur elementen. Anderzijds is het een uitwerking van verschillende checklists en vragenlijsten die van waarde zijn bij het bepalen van architectuur risico s. Bij de uitwerking van ARE is een prototype ontwikkeld in de vorm van een eenvoudige webapplicatie. Deze webapplicatie kent een aantal modulen waarvan de checklist of enquete module een is. In deze module is het mogelijk om eenvoudige checklists te registreren en toe te wijzen aan relevante stakeholders. Vervolgens worden deze stakeholders uitgenodigd via deze checklist in te vullen. Deze laatste activiteit wordt ook ondersteund in het het prototype. Implementatie Implementatie van de chelcklistmodule bestaat uit een data georiënteerde webapplicatie. Dit houdt in dat er een eenvoudige gebruikersinteractie is die het mogelijk maakt om de gegevens omtrent de entiteiten binnen de checklistmodule te beheren. Gezien de opzet van het bedrijfsproces is niet gekozen voor een implementatie in de vorm van een werkprocesondersteuning. Gevolg is dat de schermen zijn gebaseerd op lijst detail interactiepatronen, waarbij via de detail interactie de gegevens van de entiteiten gemuteerd worden. In onderstaande afbeelding ziet u een voorbeeld van de webinterface 11
12 Afbeelding Ten behoeve van het invullen en verwerken van de checklists is de opbouw van de toepassing iets verder uitgewerkt. De in de databank opgeslagen checklist gegevens worden omgezet naar verschillende soorten checklist. De beheerder van de toepassing heeft de mogelijkheid de samenstelling van de vragen en evaluaties aan te passen en uit te breiden waarmee het zonder de inzet van technische expertise mogelijk is om deze beheertaken uit te voeren. Op dit moment zijn een beperkt aantal checklist implementaties mogelijk, te weten: Sommeren van antwoorden Vermenigvuldigen van waardering en score Formuleberekening Hiermee worden de directe interactievormen checklists en berekeningen geimplementeerd. Deze checklists worden dynamisch samengesteld en in de module gepresenteerd aan de gebruiker. Deze kan de vragen beantwoorden en verzenden naar de toepassing. Daar wordt vervolgens de score berekend. Objectmodel 12
13 Het objectmodel van de checklist bestaat uit de volgende entiteiten Checklist, beschrijving van het soort checklist, inclusief omschrijving voor de eindgebruiker. Daarnaast wordt hier de relatie naar de concerns van de stakeholder gelegd Vraag, eigenschappen van de vraagstelling, antwoordkeuzes, soort besturingselement en validatie Evaluatie, instantie van een checklist voor één specifieke stakeholder. Aan deze evaluaties worden de antwoorden op de vragen gerelateerd Antwoord, instantiatie en dus beantwoording van vragen door een stakeholder Evaluatie_element, koppeling tussen evalutie en architectuur element. Hiermee kunnen de behaalde scores gekoppeld worden aan de architectuur elementen. In onderstaande afbeelding een uitwerking van de objecten en hun onderlinge relaties. Architectuur proces Het proces dat ondersteunt wordt binnen het Are project omvat enerzijds de analyse van de concerns van stakeholders binnen ICT beheer. Stakeholders betrokken bij ICT beheer hebben concerns op het vlak van ICT kosten en opbrengsten, risico s op het vlak van non functionele requirements zoals performance en beschikbaarheid en dergelijke. Anderzijds wordt aandacht besteedt aan de modelleerwerkzaamheden van enterprise architecten. Dit wordt samengevoegd tot een uitbreiding van de Archimate taal waarbij in de diagrammen een extra dimensie wordt toegevoegd. Deze dimensie omvat een weergave van de risicodimensie voor de structurele elementen. Indien mogelijk wordt op basis van infrastructuur- en applicatieservices een extra ontsluiting toegevoegd aan de archimate taal. 13
14 Processen zijn uitgewerkt op basis van Togaf ADM. In onderstaande afbeeldingen wordt getoond binnen welke fasen van het ADM de risico inventarisatie wordt toegepast. Daarnaast worden ook de activiteiten benoemd relevant voor deze extensie in onderstaande afbeelding. Afbeelding Togaf ADM Risico inventarisaties worden voornamelijk uitgevoerd in de fasen van het uitwerken van de architecturen. Dit geldt zowel voor de baseline als de target architectuur. Hierbij is de risico inventarisatie een extra dimensie van de architectuur die uitgewerkt wordt en gerelateerd aan de architectuur elementen in de uitwerking. Dit proces wordt vanzelfsprekend gevoed door de requirements en concerns die door de beheerders zijn geformuleerd. Deze requirements worden gevoed door veranderingen in de omgeving, de beheerprocessen en de overige ontwikkelingen binnen de organisatie. 14
15 5 Tot slot In dit artikel is het inventariseren van risico s aan de orde gekomen. Hierbij is ingegaan op een aantal risico s die onderkend worden bij het beheren van een ICT landschap. Aspecten als toekomstvastheid, beheerprocessen en non functionele requirements zijn hierbij benoemd. Vanzelfsprekend is dit een beperkte set van risico s binnen de beheerorganisatie. De webtoepassing ingericht voor dit project biedt de mogelijkheid om zelf de risico inventarisatie uit te breiden. Daarnaast moet benadrukt worden dat deze werkwijze niet enkel toepasbaar is voor de stakeholders binnen de beheerorganisatie. Ook voor andere stakeholders kan het interessant zijn om risico s te inventariseren met behulp van checklists en vragenlijsten. Dit op vergelijkbare wijze als hierboven beschreven. Laatste aandachtspunt is dat in dit artikel alleen de risico inventarisatie en het verzamelen van gegevens aan de orde is gekomen. Net zo belangrijk als het verzamelen van de gegevens is het presenteren van de uitkomsten binnen een architectuur notatiewijze. Hierover is op de Are website een artikel te vinden. 15
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 informatieArchimate risico extensies modelleren
Archimate risico extensies modelleren Notatiewijzen van risico analyses op basis van checklists versie 0.2 Bert Dingemans 1 Inleiding Risico s zijn een extra dimensie bij het uitwerken van een architectuur.
Nadere informatieBusiness Scenario. Voorbeeld Archimate Risico Extensie. versie 0.1. Bert Dingemans
Business Scenario Voorbeeld Archimate Risico Extensie versie 0.1 Bert Dingemans Administratieve pagina Wijzigingshistorie Versie Datum Auteur Reden wijziging Review historie Naam Afdeling Functie Datum
Nadere informatieDATAMODELLERING SCORE MATRIX
DATAMODELLERING SCORE MATRIX Inleiding In dit whitepaper wordt de datamodelleervorm Score Matrix beschreven. Deze modelleervorm staat in verhouding tot een aantal andere modelleervormen. Wil je een beeld
Nadere informatieCanonieke Data Modellering op basis van ArchiMate. Canonieke Data Modellering op basis van Archimate Bert Dingemans
Canonieke Data Modellering op basis van ArchiMate Canonieke Data Modellering op basis van Archimate Bert Dingemans Abstract Modelleren op basis van de open standard ArchiMate is een goed uitgangspunt voor
Nadere informatieStakeholder behoeften beschrijven binnen Togaf 9
Stakeholder behoeften beschrijven binnen Togaf 9 Inventarisatie van concerns, requirements, principes en patronen Bert Dingemans Togaf 9 kent verschillende entiteiten om de behoeften van stakeholders te
Nadere informatieDATAMODELLERING ARCHIMATE DATA- & APPLICATIEMODELLERING
DATAMODELLERING ARCHIMATE DATA- & APPLICATIEMODELLERING Inleiding In dit whitepaper wordt de datamodelleervorm ArchiMate data- & applicatiemodellering beschreven. Deze modelleervorm staat in verhouding
Nadere informatieDATAMODELLERING SIPOC
DATAMODELLERING SIPOC Inleiding In dit whitepaper wordt de datamodelleervorm Sipoc beschreven. Deze modelleervorm staat in verhouding tot een aantal andere modelleervormen. Wil je een beeld krijgen van
Nadere informatieDATAMODELLERING CRUD MATRIX
DATAMODELLERING CRUD MATRIX Inleiding In dit whitepaper wordt de datamodelleervorm CRUD Matrix beschreven. Deze modelleervorm staat in verhouding tot een aantal andere modelleervormen. Wil je een beeld
Nadere informatieDe architect twijfelt over een aantal zaken in beide scenario s en stelt daarom voor een aantal analyses te doen, zoals:
Kwalitatieve - en kwantitatieve analyses kunnen de dienstverlening van de enterprise-architect verbeteren. Toch is de inzet van deze analysevormen eerder uitzondering dan regel. Hoe kunnen we dit hulpmiddel
Nadere informatiePProject Start Architectuur (PSA)
PProject Start Architectuur (PSA) Archimate Risico Extensie (Are) versie 0.2 Bert Dingemans Administratieve pagina Wijzigingshistorie Versie Datum Auteur Reden wijziging 0.1 Juni 2011 Bert Dingemans Geen
Nadere informatieDATAMODELLERING RACI MATRIX
DATAMODELLERING RACI MATRIX Inleiding In dit whitepaper wordt de datamodelleervorm RACI Matrix beschreven. Deze modelleervorm staat in verhouding tot een aantal andere data modelleervormen. Wil je een
Nadere informatieVAARWEL ARCHITECTUUR DOCUMENT WELKOM ARCHITECTUUR REPOSITORY INZETTEN VAN ENTERPRISE ARCHITECT ALS ALTERNATIEF VOOR ARCHITECTUURDOCUMENTEN
VAARWEL ARCHITECTUUR DOCUMENT WELKOM ARCHITECTUUR REPOSITORY INZETTEN VAN ENTERPRISE ARCHITECT ALS ALTERNATIEF VOOR ARCHITECTUURDOCUMENTEN AGENDA Architectuurdocumenten waarom wel of niet? Alternatieven
Nadere informatieDATAMODELLERING ARCHIMATE DATAMODELLERING
DATAMODELLERING ARCHIMATE DATAMODELLERING Inleiding In dit whitepaper wordt de datamodelleervorm ArchiMate datamodellering beschreven. Deze modelleervorm staat in verhouding tot een aantal andere modelleervormen.
Nadere informatieKeteininformatiemodellering op basis van Archimate
Keteininformatiemodellering op basis van Archimate Notatie en voorbeelden versie 0.1 Bert Dingemans Inhoudsopgave Inhoudsopgave... 2 Inleiding... 3 Archimate... 3 Domeininformatiemodellen... 4 Modellering...
Nadere informatieDATAMODELLERING BASIS UML KLASSEMODEL
DATAMODELLERING BASIS UML KLASSEMODEL Inleiding In dit whitepaper wordt de datamodelleervorm basis UML klassemodel beschreven. Deze modelleervorm staat in verhouding tot een aantal andere modelleervormen.
Nadere informatieDATAMODELLERING DATA MAPPING MODEL
DATAMODELLERING DATA MAPPING MODEL Inleiding In dit whitepaper wordt de datamodelleervorm data mapping model beschreven. Deze modelleervorm staat in verhouding tot een aantal andere modelleervormen. Wil
Nadere informatieDATAMODELLERING DATA FLOW DIAGRAM
DATAMODELLERING DATA FLOW DIAGRAM Inleiding In dit whitepaper wordt de datamodelleervorm data flow diagram beschreven. Deze modelleervorm staat in verhouding tot een aantal andere modelleervormen. Wil
Nadere informatieDATAMODELLERING BEGRIPPENBOOM
DATAMODELLERING BEGRIPPENBOOM Inleiding In dit whitepaper wordt de datamodelleervorm begrippenboom inclusief de begrippenlijst beschreven. Deze modelleervorm staat in verhouding tot een aantal andere modelleervormen.
Nadere informatieProject Start Architectuur (PSA)
Project Start Architectuur (PSA) InterActory Architectuur Service Orientatie versie 0.2 Bert Dingemans Administratieve pagina Wijzigingshistorie Versie Datum Auteur Reden wijziging 0.1 Maart 2012 Bert
Nadere informatieTools voor canonieke datamodellering Bert Dingemans
Tools voor canonieke datamodellering Tools voor canonieke datamodellering Bert Dingemans Abstract Canonieke modellen worden al snel omvangrijk en complex te beheren. Dit whitepaper beschrijft een werkwijze
Nadere informatieStakeholders, concerns, principes en patronen in dataarchitectuur. Bert Dingemans
Stakeholders, concerns, principes en patronen in dataarchitectuur Bert Dingemans Abstract Veranderingen in en rond organisatie zijn van invloed op de rol van de data-architect. Door deze veranderingen
Nadere informatieDATAMODELLERING ER DIAGRAM
DATAMODELLERING ER DIAGRAM Inleiding In dit whitepaper wordt de datamodelleervorm ER diagram beschreven. Deze modelleervorm staat in verhouding tot een aantal andere modelleervormen. Wil je een beeld krijgen
Nadere informatieInterActory CDModeller
InterActory CDModeller Evaluatie prototype versie 0.1 Bert Dingemans 1 Inleiding Voor het uitwerken van een service register en een tool voor het beheer van een canoniek model is gekozen voor een werkwijze
Nadere informatieIntroductie ArchiMate
Introductie ArchiMate NAF Insight De Meern, 8 maart 2012 Egon Willemsz, enterprise architect UWV Programma Waarom ArchiMate? Praktijkvoorbeelden Samenvatting concepten Van start met ArchiMate Tot besluit
Nadere informatieDATAMODELLERING TOEPASSEN DATA ANALYTICS
DATAMODELLERING TOEPASSEN DATA ANALYTICS Inleiding In dit whitepaper wordt een toepassingsgebied beschreven voor datamodellering. Een toepassing is een werkveld op het vlak van architectuur of modellering
Nadere informatieKickstart Architectuur. Een start maken met architectuur op basis van best practices. Agile/ TOGAF/ ArchiMate
Kickstart Architectuur Een start maken met architectuur op basis van best practices. Agile/ TOGAF/ ArchiMate Context schets Net als met andere capabilities in een organisatie, is architectuur een balans
Nadere informatieLNV architectuurrichtlijnen gelijke geschiktheid Open Source Software. Versie 1
LNV architectuurrichtlijnen gelijke geschiktheid Open Source Software Versie 1 2 Gelijkegeschiktheid Inhoud 1 Inleiding 4 1.1 Doelstelling 4 2 Toetsing gelijke geschiktheid 5 2.1 Total Cost of Ownership
Nadere informatieQlik Sense Healthcare. Document 16052
Qlik Sense Healthcare Document 16052 Inhoud 1. Introductie... 3 1.1 Qlik Sense... 3 1.2 Qlik Sense Healthcare... 3 1.3 Qlik Sense als product... 3 2 Overview healthcare module... 4 2.1 De opbouw van de
Nadere informatieTien tips voor canonieke datamodellering. Bert Dingemans
Tien tips voor canonieke datamodellering Bert Dingemans Abstract Modelleren is een vakgebied gebaseerd op eenvoudige notaties. Echter op het moment dat en model opgesteld wordt blijkt de te modelleren
Nadere informatieKenmerken van DLArchitect
Kenmerken van DLArchitect Bert Dingemans, e-mail : bert@dla-os.nl www : http://www.dla-os.nl 1 Inhoud KENMERKEN VAN DLARCHITECT... 1 INHOUD... 2 INLEIDING... 3 ARCHITECTUUR... 3 Merode... 3 Methode en
Nadere informatieCMS Ronde Tafel. Cloud Continuity. Ir. Jurian Hermeler Principal Consultant
CMS Ronde Tafel Cloud Continuity Ir. Jurian Hermeler Principal Consultant Introductie Quint Wellington Redwood Onafhankelijk Management Adviesbureau Opgericht in 1992 in Nederland Ruim 20 jaar ervaring
Nadere informatieGenereren van een webapplicatie op basis van DLA
Genereren van een webapplicatie op basis van DLA ir Bert Dingemans DLA Ontwerp en Software info@dla-architect.nl Inleiding Bij het ontwikkelen van maatwerk software loopt men al snel tegen het probleem
Nadere informatieKwaliteitsbewaking en testen in ICT beheerorganisaties
DKTP Informatie Technologie Veembroederhof 1 1019 HD Amsterdam Telefoon 020 427 52 21 Kwaliteitsbewaking en testen in ICT beheerorganisaties Voor de meeste projectgroepen die software ontwikkelen vormt
Nadere informatieLifecycle Management: opereren onder architectuur. Jan Willem van Veen jwvveen@archixl.nl
Lifecycle Management: opereren onder architectuur Jan Willem van Veen jwvveen@archixl.nl Agenda Introductie mijzelf en ArchiXL Korte inleiding Lifecycle Management methodiek Inzicht in status Inzicht in
Nadere informatieBeheerVisie ondersteunt StUF-ZKN 3.10
Nieuwsbrief BeheerVisie Nieuwsbrief BeheerVisie 2015, Editie 2 Nieuws BeheerVisie ondersteunt StUF-ZKN 3.10 BeheerVisie geeft advies MeldDesk App Message Router MeldDesk Gebruikers Forum Nieuwe MeldDesk
Nadere informatieInvloed 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 informatieDATAMODELLERING XML SCHEMA DEFINITIONS
DATAMODELLERING XML SCHEMA DEFINITIONS Inleiding In dit whitepaper wordt de datamodelleervorm XML Schema Definition (XSD) beschreven. Deze modelleervorm staat in verhouding tot een aantal andere modelleervormen.
Nadere informatieVastgoedinformatiesystemen. Thijs van der Spil
Vastgoedinformatiesystemen Thijs van der Spil Wat je wilt voorkomen is een systeem dat niet kan wat je nodig hebt dat veel te duur is in aanschaf of exploitatie dat niet kan meegroeien met je organisatie
Nadere informatieProject Fasering Documentatie Applicatie Ontwikkelaar
Project Fasering Documentatie Applicatie Ontwikkelaar Auteurs: Erik Seldenthuis Aminah Balfaqih Datum: 31 Januari 2011 Kerntaak 1 Ontwerpen van applicaties De volgordelijke plaats van de documenten binnen
Nadere informatieNAF Opzet Werkgroepen
NAF Opzet Werkgroepen Youetta de Jager Frank Luyckx Roland Drijver Denis Hageman Raymond Slot Juni 2016 1 Achtergrond Om een nieuwe start te maken met de werkgroepen, is er vanuit de PC een opzet gemaakt
Nadere informatieDATAMODELLERING GEAVANCEERD UML KLASSEMODEL
DATAMODELLERING GEAVANCEERD UML KLASSEMODEL Inleiding In dit whitepaper wordt de datamodelleervorm geavanceerd UML klassemodel beschreven. Deze modelleervorm staat in verhouding tot een aantal andere modelleervormen.
Nadere informatieVerschillen in QA aanpak tussen ERP projecten en niet-erp projecten
Verschillen in QA aanpak tussen ERP projecten en niet-erp projecten SYSQA B.V. Almere Datum : 06 mei 2013 Status : definitief Versie : 2.0 Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van 5 Overzicht
Nadere informatieKickstart-aanpak. Een start maken met architectuur op basis van best practices.
Kickstart-aanpak Een start maken met architectuur op basis van best practices. www.theunitcompany.com Kickstart-aanpak Soms is net dat extra duwtje in de rug nodig om te komen waar je wilt zijn. In onze
Nadere informatieEr valt veel te zeggen over enterprise architectuur. Dit document wil een deel van het onderwerp aansnijden vanuit twee motto s: Begrippen...
Duurzame architectuur met draagvlak Hans Admiraal 2 november 2018 Er valt veel te zeggen over enterprise architectuur. Dit document wil een deel van het onderwerp aansnijden vanuit twee motto s: Focus
Nadere informatieRoadmap. RIE Manager
Roadmap RIE Manager Look & Feel Rapportage/ Documentatie Uploaden Documenten Major Release 3 Lokaal beheer Major Release 2 Regie in eigen hand Submodules Major Release 1 Introductie In deze roadmap geeft
Nadere informatieInhoud. Deel een Het ontwikkeltraject 13. Inleiding 11
5 Inhoud Inleiding 11 Deel een Het ontwikkeltraject 13 1 Werken binnen organisaties 15 1.1 Non-profit-organisatie 15 1.2 Profit-organisatie 16 1.3 Doelen 16 1.4 Rechtsvormen 16 Rechtspersoon 17 Persoonlijke
Nadere informatieEibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008
Titel, samenvatting en biografie Eibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008 Samenvatting: Eibert Dijkgraaf (testconsultant Test
Nadere informatieCanonieke data-architectuur Bert Dingemans
Canonieke data-architectuur Canonieke data-architectuur Bert Dingemans Abstract Deze whitepaper beschrijft diverse aspecten van canonieke data-architectuur. Naast de definitie van canonieke data-architectuur
Nadere informatieLoopbaanIndicator. Voor een duurzame loopbaanplanning
LoopbaanIndicator Voor een duurzame loopbaanplanning 1. Inleiding LoopbaanIndicator wordt ingezet om alle relevante waarden rondom menselijke inzetbaarheid gestructureerd en genormeerd in kaart te brengen,
Nadere informatieCyberpesten: social media platform mining tools
Cyberpesten: social media platform mining tools ABI team 27: Pascal Pieters, Stephaan Declerck Begeleider: dr. Rik Bos Opdrachtgever: prof. dr. ir. Remko Helms Inhoud Achtergrond Opdracht Projectaanpak
Nadere informatiePHP-OPDRACHT SITE BOUWEN
PHP-OPDRACHT SITE BOUWEN PERIODE 4 LEERJAAR 1 Opleiding: Duur: Applicatieontwikkelaar 1 onderwijsperiode (4-8 weken) Voorkennis: Basiscursus PHP 5.4 Victor Peters (978 90 125 8499 9) Basiscursus XHTML,
Nadere informatieISM: BPM voor IT Service Management
ISM: BPM voor IT Service Management ISM: BPM voor IT Service Management Het jonge IT-vakgebied wordt bestookt met allerlei frameworks om grip te krijgen op de input en output: ITIL, ASL, BiSL, COBIT en
Nadere informatieDe rol van een data-architect. Bert Dingemans
De rol van een data-architect Bert Dingemans Abstract Bij een toenemende volwassenheid van data-architectuur neemt het gebruik van generieke gegevensverzamelingen toe. Deze gegevens worden veelal beheerd
Nadere informatieUML. From weblog http://dsnippert.wordpress.com. Dennis Snippert
UML From weblog http://dsnippert.wordpress.com Naam: Dennis Snippert Inhoudsopgave 1. Wat is Uml?... 3 2. UML diagrammen... 4 3. Uitleg diagrammen... 5 3.1. Usecase diagram:... 5 3.2. Class diagram:...
Nadere informatieInformatiebeveiliging en privacy beleid binnen de mbo sector Congres sambo-ict te Assen
Informatiebeveiliging en privacy beleid binnen de mbo sector Congres sambo-ict te Assen Auteur Datum Ludo Cuijpers 5 februari 2016 1. Informatiebeveiliging en privacy in het mbo 2. IBP framework 3. Mens
Nadere informatieIn een keten gaat het om de verbindingen, niet om de schakels.
Verbindingsmodel IV Serviceketen Theo Thiadens en Adri Cornelissen In een keten gaat het om de verbindingen, niet om de schakels. Verbindingsmodel IV Serviceketen Theo Thiadens Alleen een organisatie die
Nadere informatieTechnische architectuur Beschrijving
A gemeente Eindhoven Technische architectuur Beschrijving Specificatiecriteria Versie 1.1 A. van Loenen Technisch Beleidsadviseur B&E 21-Sep-2011 avl/fd11027578 Colofon Uitgave Gemeente Eindhoven Realisatie
Nadere informatieBRAIN Deelplan: Website
BRAIN Deelplan: Website Respond BV Sportweg 15 5037 AC TILBURG T +31(0)13 532 10 01 F +31(0)13 544 23 40 info@respond.nl www.respond.nl KvK nummer Tilburg 18035794 Bank (ING-BANK) 68.47.49.203 1 INHOUDSOPGAVE
Nadere informatieIntegratie van Beheer en Ontwikkeling op basis van een Drielagenarchitectuur
Integratie van Beheer en Ontwikkeling op basis van een Drielagenarchitectuur Bert Dingemans info@dla-architect.nl www.dla-architect.nl Inleiding In de sector jeugdzorg zijn momenteel een aantal ingrijpende
Nadere informatie5 Opstellen businesscase
5 Opstellen In de voorgaande stappen is een duidelijk beeld verkregen van het beoogde project en de te realiseren baten. De batenboom geeft de beoogde baten in samenhang weer en laat in één oogopslag zien
Nadere informatieNulmeting van de e-depotvoorziening van het Noord-Hollands Archief aan de hand van het toetsingskader ED3
Nulmeting van de e-depotvoorziening van het Noord-Hollands Archief aan de hand van het toetsingskader ED3 Pilot Uitplaatsing digitaal archief gemeente Haarlem Auteur: Noord-Hollands Archief: Stinie Francke
Nadere informatieSROI Quick Scan als basis voor contractinnovatie
SROI Quick Scan als basis voor contractinnovatie Het contracteren van de juiste zorg op de juiste plek Vitaal Thuis is een veldcoalitie: van en voor veldpartijen. Samen zetten we met de Werkgroep Structurele
Nadere informatieCEL. Bouwstenen voor een elektronische leeromgeving
CEL Bouwstenen voor een elektronische leeromgeving FACTSHEET CEL VERSIE 1.0 DECEMBER 2001 CEL - Bouwstenen voor een elektronische leeromgeving Inhoudsopgave Wat is CEL? 1 Uitgangspunten 1 De eindgebruiker
Nadere informatieResultaten EAM Barometer 2010
1 van 14 Resultaten EAM Barometer 2010 Beschikt Onderhoudend Nederland over een onderhoudsbesturingssysteem? Onderdeel Opgenomen Toelichting Rappotage resultaten onderzoek Individuele resultaten deelnemer
Nadere informatieBISL 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 informatieHoe ver moet je gaan?
Hoe ver moet je gaan? Requirements verzamelen in agile John Copier; Marcel Steur 8 oktober 2015 Introductie Marcel + Qquest Informatica TU Delft Bedrijfskunde HSA + VU IT combineren met bedrijfskunde Qquest
Nadere informatieDe impact en implementatie van de outsourcing op de bedrijfsvoering is als één van de 6 deelprojecten ondergebracht binnen het project outsourcing.
Bijlagen 1 en 2: Aanbevelingen en opvolging Gateway Reviews (corsa 2018017934) Bijlage 1: Aanbevelingen en opvolging Gateway Review 2018 Aanbeveling Opvolging Status Opmerking 1. Richt een apart project
Nadere informatiekwaliteitsmeterplus 4
kwaliteitsmeterplus 4 Testen voor de toekomst Eenvoudig en intuïtief Werkproces georiënteerd Scheiding bevindingen en issues Hertest methode Schermafdruk en -opnames SaaS Open platform kwaliteitsmeterplus
Nadere informatieICT 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 informatieTaakcluster Operationeel support
Ideeën en plannen kunnen nog zo mooi zijn, uiteindelijk, aan het eind van de dag, telt alleen wat werkelijk is gedaan. Hoofdstuk 5 Taakcluster Operationeel support V1.1 / 01 september 2015 Hoofdstuk 5...
Nadere informatieStappenplan Social Return on Investment. Onderdeel van de Toolkit maatschappelijke business case ehealth
Stappenplan Social Return on Investment Onderdeel van de Toolkit maatschappelijke business case ehealth 1 1. Inleiding Het succesvol implementeren van ehealth is complex en vraagt investeringen van verschillende
Nadere informatiebedrijfsprocessen 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 informatieReview op uitgevoerde risico-inventarisatie implementatie resultaatgerichte bekostiging
Review op uitgevoerde risico-inventarisatie implementatie resultaatgerichte bekostiging mr. drs. E.P.J. de Boer Rotterdam, Aanleiding en opzet van de review In opdracht van de GR Jeugdhulp Rijnmond is
Nadere informatieToegepaste notatiewijzen DLA software
Toegepaste notatiewijzen DLA software Bert Dingemans info@dla-architect.nl Inleiding In de DLA Software wordt gebruik gemaakt van een aantal notatiewijzen voor het opstellen van een object- en procesmodel.
Nadere informatieDe complete oplossing voor uw kadastrale informatievoorziening.
De complete oplossing voor uw kadastrale informatievoorziening. Foto: Mugmedia Het Kadaster gaat de levering van kadastrale informatie ingrijpend vernieuwen. Het huidige proces van verwerken van kadastrale
Nadere informatieRegister- en sleutelbeleid Bert Dingemans
Register- en sleutelbeleid Register- en sleutelbeleid Bert Dingemans Abstract Bij een toenemende volwassenheid van data-architectuur neemt het gebruik van generieke gegevensverzamelingen toe. Deze gegevens
Nadere informatieCanonieke datamodellering in de praktijk
Canonieke datamodellering in de praktijk Bert Dingemans Samenvatting Canonieke datamodellering kent vele dimensies en toepassingswijzen. Maar hoe is dit in de praktijk inzetbaar? Dit whitepaper gaat in
Nadere informatieBelastingdienst MCC Visie op mobiel en interactie met burgers en bedrijven
Belastingdienst MCC Visie op mobiel en interactie met burgers en bedrijven Bestede digitale tijd Aandeel telefoongebruik in digitale tijd ICT 2.500 FIOD 1.200 Toeslagen 1.200 CA 1.600 Belastingdienst BelTel
Nadere informatieSoftware Test Plan. Yannick Verschueren
Software Test Plan Yannick Verschueren November 2014 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 1 Inhoudstafel 1 Introductie 3 1.1
Nadere informatieOffective > CRM > Vragenlijst
Offective > CRM > Vragenlijst Onder het menu item CRM is een generieke vragenlijst module beschikbaar, hier kunt u zeer uitgebreide vragenlijst(en) maken, indien gewenst met afhankelijkheden. Om te beginnen
Nadere informatieIT-audit in vogelvlucht. Jeanot de Boer 24 april 2012
IT-audit in vogelvlucht Jeanot de Boer 24 april 2012 Agenda Introductie Wat is IT-audit Hoe is IT-audit in Nederland geregeld? Het IT-audit proces Wat is de toegevoegde waarde van IT-audit Enkele praktijkvoorbeelden
Nadere informatieUser experience voor projecten
User experience voor projecten In de PS module zijn er een aantal nieuwe mogelijkheden beschikbaar voor het werken met projecten. Zo is in EhP 6 de Project Editor uitgebreid met de mogelijkheid om Gannt
Nadere informatieForm follows function -Louis Henry Sullivan
www.grundsatzlich-it.nl Form follows function -Louis Henry Sullivan Datawarehouse: vorm en functie Ronald Kunenborg licentie: Datawarehouse: vorm en functie Een data warehouse komt voort uit pijn Die pijn
Nadere informatieIncore 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 informatieFactsheet COOKIE COMPLIANT Managed Services
Factsheet COOKIE COMPLIANT Managed Services COOKIE COMPLIANT Managed Services Mirabeau helpt u de cookiewetgeving op de juiste manier te implementeren. Zo geven we uw online omgeving een betrouwbare uitstraling
Nadere informatieOlde 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 informatieOpen Source Software community- en teruggave beleid EL&I. Versie 1
Open Source Software community- en teruggave beleid EL&I Versie 1 2 Open Source Software community- en teruggave beleid EL&I Inhoud Inleiding 4 1 Inzet OSS software 4 2 Community beleid 6 2.1 Communitybeleid
Nadere informatieBedrijfsarchitectuur 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 informatieJe weet wat je wilt bereiken, maar wie & wat loop je tegen het lijf?
Plannen gemaakt? Met hulp van de standaardaanpak ImpactAnalyse in de Zorg kom je verder! Je weet wat je wilt bereiken, maar wie & wat loop je tegen het lijf? IMPACT? de ZORG? STANDAARD AANPAK 1 Inpassen
Nadere informatieArchitectuurredeneermodel Afgewogen keuzes maken
Architectuurredeneermodel Afgewogen keuzes maken Robert Deckers SASG okt 2012 v3 Architectuur: technologie in perspectief Klantbehoefte Toepassing Systeem T 2 Vele wegen die naar ergens leiden Bewuste
Nadere informatieTechnisch Ontwerp Ontwerp template
Auteur Dennis Steenwijk Versie Datum Status 1 Inleiding 2 Versie geschiedenis Versie Datum Status Naam Omschrijving 03-10-08 Dennis Steenwijk versie 2 van 9 Versie geschiedenis 3 Distributie Naam Functie
Nadere informatieEindrapportage Interactieve Leerlijnen. www.dnsleerroutes.net. Auteur(s) : Annemarieke Schepers Versienummer : januari 2010. Kennisnet.
Eindrapportage Interactieve Leerlijnen versie datum 1 / 7 Eindrapportage Interactieve Leerlijnen www.dnsleerroutes.net Auteur(s) : Annemarieke Schepers Versienummer : januari 2010 Kennisnet.nl www.dnsleerroutes.net
Nadere informatieSecurity (in) architectuur
Security (in) architectuur ISC2 chapter Netherlands Donderdag 21 november 2013 Ing Renato Kuiper, CISSP, CISA, TOGAF, CSF Logo Klant Focus op: Security, risicomanagement, IAM, Cloud en architectuur Vanuit
Nadere informatieRapportage Lineage. Introductie. Methode. J. Stuiver
Rapportage Lineage Rapportage Lineage J. Stuiver Introductie In elk project is het essentieel om informatie over het project en haar activiteiten voor alle partijen beschikbaar te stellen. Deze informatie
Nadere informatieB l u e D o l p h i n
B l u e D o l p h i n H e t s a m e n w e r k i n g s p l a t f o r m d a t s l i m g e b r u i k m a a k t v a n d e i n f o r m a t i e e n k e n n i s o p h e t g e b i e d v a n g e m e e n t e l i
Nadere informatieTechnische implementatie De infrastructuur rondom Transit kent de volgende rollen:
Transit Herkent u het? Steeds dezelfde uitdagingen in migratieprojecten; meerdere variabelen, in verschillende stadia en in een blijvend veranderende omgeving, managen. Grote hoeveelheden gegevens over
Nadere informatie15 Mate van dekkingsgraad, een eerste aanzet tot baten
15 Mate van dekkingsgraad, een eerste aanzet tot baten Sanneke van der Linden Sinds 2007 organiseert M&I/Partners de ICT Benchmark Ziekenhuizen. Op hoofdlijnen zijn de doelstellingen en aanpak van de ICT
Nadere informatie