XR Magazine januari 2012

SOA en EDA - een sterke mix
SOA voor
gevorderden
Business & ICT-trends 2012
TOGAF - SABSA integratie
Het realiseren van een veilige bedrijfsarchitectuur
XR.XR Magazine | Kennisdeling over de praktijktoepassing van Enterprise Architectuur
Editie 29 | Januari 2012
www.xr-magazine.nl
Trends in
Business & Architectuur
Thema
Weersvoorspelling 2012:
Het regent kansen

Gratis uw evenement
op de XR website?
Heeft u een training,workshop,congres of seminar die u graag
onder de aandacht wil brengen bij een breed publiek?
Op de XR website kunt u gratis uw evenement plaatsen. Kijk
voor meer informatie op:
www.xr-magazine.nl/events

In deze editie van XR Magazine staat het thema ‘Trends in Business & Architectuur’ centraal. De auteurs gaan
onder meer in op de vragen:Wat zijn de megatrends voor 2012 op business en ICT-gebied?Wat is de impact van
het concept ‘BYOD’ op IT-beheer? Hoe integreer je risicomanagement in de bedrijfsvoering? Dit en meer leest
u deze maand in XR Magazine.
Trends in Business & Architectuur
Inhoud
Het regent kansen 4
Architecten: verhalenvertellers 10
SOA voor gevorderden 18
‘Consumerization of IT’ vraagt andere
manier van IT-beheer 20
Thema
De artikelen in XR Magazine beslaan onder andere opiniestukken, ver-
diepingsartikelen,best practices,interviews en recensies op het gebied
van enterprise architectuur, bedrijfs- en ICT-architectuur en aanverwan-
te vakgebieden. Dit magazine is samengesteld op basis van artikelen
die op de website van XR Magazine zijn geplaatst.
Rubrieken
TOGAF - SABSA integratie 12
Opinie: Scrum zonder architecten -
(g)een ideale wereld? 31
Poster: Dragon1 EA Framework -
Change View 23
januari 2012 XR Magazine
Do you know how to
eXceleRate?
We do!
3
Successen in een project… 32Opinie:Wie betaalt de architectuur? 24
Alarmbel in de Zorg (en daarbuiten)
terecht! 26

Na ruim zeventien jaar Business & ICT Trends onderzoe-
ken proberen we uit deze enorme schatkamer van re-
sultaten de grote lijnen en de golfbewegingen te onder-
scheiden. Wat vindt er net onder de oppervlakte van de
woelige ICT zee plaats?
Wij zijn uitgekomen op een zestal ontwikkelingen op
business & ICT vlak waarlangs de meeste trends zich zul-
len bewegen (de megatrends):
• Slinger van de klok trends
• Socio media trends
• In de wolken verdwijnende trends
• Keten- en procesmanagement trends
• Risico & beveiligingtrends
• Van enkele superego’s naar allemaal hyper-ego’s
Megatrend ‘De slinger van de klok’
Bij veel als nieuw gepresenteerde ontwikkelingen zien
we ‘de slinger van de klok’ of ‘oude wijn in nieuwe zak-
ken’. Hebben we dit vijftien jaar geleden ook al niet zien
gebeuren? Dan is het leuk als je een aantal jaren terug
kan kijken en wat realisme kan brengen in de vaak hoog-
gespannen verwachtingen.
Een ‘slinger van de klok’ trend betreft het beheer van
ICT-infrastructuur, hard- en software. Waar we ooit in de
jaren 70 begonnen met een centrale beheerorganisatie
werd in de 80’er jaren van de vorige eeuw een decentrale
beheerorganisatie de mode. Halverwege de jaren 90 is
de trend weer richting centralisatie of concentratie inge-
zet. En nu zijn we weer volop bezig met het ‘outsourcen’
van infrastructuur via applicaties naar hele processen.
De Cloud (virtuele digitale wolk) lijkt hierbij een nieuwe
fase in te luiden waarbij de vraag waar ICT ondersteunde
processen plaatsvinden niet meer van belang is. De ICT
processen worden dan ‘ergens’ uitgevoerd in een über-
concentratie van ICT diensten.Terug naar de ‘mainframe’
gedachte is de slinger van de klok.
Vanaf de jaren zeventig deed de terminal zijn intrede in
de kantoren. De terminal was slechts een beeldscherm
en alle berekeningen, transacties en dergelijke werden
centraal op een mainframe verricht. Hierbij werden de
capaciteit en de snelheid vooral bepaald door het aantal
gelijktijdige gebruikers (‘concurrent users’). De termi-
nal was bij uitstek een voorbeeld van een ‘empty client’.
Een belangrijke reden waarom voor deze architectuur
4 XR Magazine januari 2012
Een wereldwijde financiële crisis, een korte opleving en gevolgd door angst voor rating agencies
zoals Standard & Poors. Is Griekenland nu wel of niet failliet en zorgt Monti nu wel of niet voor de red-
ding van Italië? Wat in ICT land al heel gewoon was gebeurt nu ook in de ‘bricks’. Verschuivingen,
reorganisaties, bezuinigingen, investeringen,fusies, ICT is een economie op zich.Was het niet in 2004
dat Carr stelde dat ICT er niet meer toe doet? Hebben Apple en Google de afgelopen jaren zo’n vijf tot
zes jaar na deze uitspraak dezelfde uitspraak niet volledig van de tafel geworpen? Wederom zijn het
de gebruikers die de ICT organisaties laten zien wat zij willen, het regent dus kansen.
Barry Derksen
Het regent kansen
Trends en Architectuur
We zijn nu weer volop bezig
met het ‘outsourcen’ van
infrastructuur via applicaties
naar hele processen
Reageren op dit artikel? Klik hier.

werd gekozen, was het feit dat geheugencapaciteit en
rekencapaciteit buitengewoon duur waren. Om hier zo
efficiënt mogelijk gebruik van te kunnen maken werden
alle transacties en gegevensbestanden op centrale main-
frames uitgevoerd.
In de jaren tachtig kwam hier verandering in. De voor-
lopers van de personal computer (pc) kwamen op. In
eerste instantie waren dit geïntegreerde beeldschermen,
toetsenbord en computerkracht. ICT en met name kan-
toorautomatisering raakte in een stroomversnelling. De
prijsdaling van computers maakte het mogelijk dat op ie-
der bureau een pc aanwezig was met rekenkracht en ge-
heugencapaciteit.De architecturen werden complexer en
drie- tot en met zevenlagen modellen werden gebruikt
om te bepalen waar bepaalde verwerkingsactiviteiten,
rekenregels en dergelijke moesten worden uitgevoerd.
Dit is bij velen bekend als de client-server architectuur.
De ‘empty’ terminals werden vervangen door ‘thick cli-
ents’,waarbij de‘userinteractie’en een stukje processing
decentraal (op de pc) werden verricht.Een uitkomst voor
de gebruiker, die hierdoor veel vrijheden kreeg, maar
een enorme uitdaging voor de ICT beheerder, die het
ICT park in complexiteit en kosten bijna exponentieel
zag toenemen.
Deze trend zette zich door tot eind jaren negentig en het
beheer werd alleen maar complexer. Bovendien zorgde
de opkomst van e-mail en internet voor een toenemend
beslag op de beperkte bandbreedte van het netwerk.
Megatrend ‘Socio media’
Socio media is volgens ons een echte blijver. Of het nu
gaat om de nieuwste iPad of het door Microsoft gepro-
pageerde ‘het nieuwe werken’. Iedere ICT ontwikkeling
die is gericht op de ultieme behoefte om op elk gewenst
moment op iedere locatie via ieder randapparaat infor-
matie uit te kunnen wisselen en transacties aan te gaan,
is succesvol.
De socio media trend sluit ook goed aan bij de ontwik-
keling waarbij de consument ook producent wordt, denk
aan zonnepanelen op het huis die straks uw huis en de
elektrische auto van energie voorzien i.p.v. via de ener-
giemaatschappij en tankstations. Socio Media - ICT ont-
wikkelingen die goed op de megatrend aansluiten zijn:
Google+ Hyves, LinkedIn, Facebook,Twitter, Blogs,Wiki-
pedia, Marktplaats,TomTom etc. Het is voor de gebruiker
steeds prettiger geworden.De Apple en Android produc-
ten zijn daar wel een voorbeeld van. De top 3 van dit mo-
ment? Dat zijn Facebook,Twitter en Linkedin.
Kortom de socio media ontwikkelingen hebben bijgedra-
gen aan het daadwerkelijk gemakkelijker maken voor de
ICT gebruikerszijde, alhoewel dit veelal nog beperkt is
tot consumenten ICT. ICT afdelingen van bedrijven staan
voor de uitdaging om te zorgen dat wat de medewerker
thuis heel gewoon vindt en gratis krijgt ook binnen de
5januari 2012 XR Magazine
Figuur 1: Opeenvolgende fasen van ICT beïnvloeding
Stand-alone
Interfacing
Verwevenheid
Integratie
Pervasive
Cloudiness
1970 1975 1980 1990 2000 2010 2020
Volwassenheid
1
2
3
4
5

bedrijfsomgeving tegen acceptabele kosten aan te bie-
den.
Megatrend‘In de wolken verdwijnende trends’
Een echt ‘containerbegrip’ waar ook reeds bejaarde ICT
trends worden ondergebracht. De term cloud wordt ge-
bruikt voor ‘applicatiebeheer’ op afstand en betalen per
gebruik (SaaS), maar ook voor ‘organisatie onafhankelij-
ke gegevensopslag’. Alles heet tegenwoordig werken in
‘de cloud’.
In figuur 2 wordt het ontstaan, de onderliggende trends
en andere aspecten van in de wolken verdwijnende
trends weergegeven.
In navolging van de vorige twee figuren is een toelichting
op laatste fase (cloudiness) op haar plaats kijkend naar
professionalisering van Cloud toepassingen (wat bete-
kent het dan voor mijn organisatie?). Deze staat in figuur
3 weergegeven waarbij vooral aandacht is gegeven aan
onderliggende ICT Trends (voor de bedrijfsvoering be-
tekent dit namelijk ook behoorlijk veel).
Megatrend ‘Keten- en procesmanagement
trends’
Alle ICT ontwikkelingen die helpen om processen en
ketens te integreren en te verkorten blijven interessant.
Daarbovenop hebben de nieuwste ICT ontwikkelingen
de belofte dat ze naast ketenintegratie en verkorten ook
de mogelijkheid bieden om ketens te ‘flexibiliseren’.
Deze ontwikkeling blijft interessant omdat bedrijven con-
tinu op zoek zijn naar mogelijkheden om sneller en effi-
ciënter te leveren. Daarnaast zien bedrijven zich gecon-
fronteerd met sterk veranderende markten en behoeften
waar ze snel hun voortbrengingsprocessen op moeten
aanpassen.
Daar komt nog overheen dat onder druk van de overheid
of vanuit de markt meer en meer initiatieven komen om
processen over organisaties heen te integreren en ge-
bruik te laten maken van elkaars gegevens (authentieke
bron).
Steeds meer proces- en ketengeoriënteerde software zo-
als Business Process Management (BPM), Service Orien-
ted Architecturen (SOA) en Enterprise Resource Planning
(ERP) worden ingezet om de processen over organisaties
heen beter op elkaar af te stemmen.
Web 2.0 and
Mashups
Subsidized
Applications
Googleplex
Web Platforms
Global-Class
Consumer Application
SaaS
Data Center
Pressures
Virtualization
Grid
Real-Time
Infrastructure
Management
Discipline
Utility Models
Focus on “the Cloud” Focus on “Computing”
From the EnterpriseFrom the Web
Definition of Cloud computing: “A style of computing where scalable and elastic IT-enabled capabilities are
provided ‘as a service’ to external customers using Internet Technologies.
Cloud
Web
Internet
Connectivity
Information
and Browser UI
Services and
Web
API/Arch.
1980 1990 2000 2010 2020
Figuur 2: Meervoudige perspectieven op cloud computing (Prentice, 2010)
Cloud Computing:
Multiple Perspectives, Multiple Origins
Nieuwe ICT ontwikkelingen
hebben de belofte om
ketens te verkorten en te
‘flexibiliseren’

Tot het eind van de jaren negentig waren decentralisatie,
integraal management en de vorming van business units
toverwoorden om de toenemende complexiteit en dyna-
miek van de omgeving het hoofd te kunnen bieden. De
laatste jaren gaan steeds meer organisaties om verschil-
lende redenen weer terug naar centralisatie of concen-
tratie, liefst met behoud van de flexibiliteit bij de gebrui-
kers.
In dit verband staat het fenomeen SSC (Shared Service
Center) al sinds de jaren negentig in de belangstelling.
SSC’s hadden in de jaren 90 de belofte van kostenreduc-
tie. Tegenwoordig worden SSC’s meer ingericht om de
‘flexibele gebruiker’ de garantie te geven dat hij/zij 24-
uur per dag voldoende deskundige ondersteuning krijgt.
Vaak is een SSC ook een eerste stap op weg naar outsour-
cing of zelfs het overbrengen van activiteiten naar een la-
gelonenland (offshoring) – ICT-ontwikkelwerk in India, of
gloeilampenfabrieken in Polen.
In het verlengde hiervan zijn organisaties steeds meer be-
zig met het bij andere partijen in de keten onderbrengen
van delen van het eigen primaire proces.Dit is een speci-
ale vorm van outsourcing,‘business process outsourcing’
ofwel BPO. Zo kan een pensioenfonds overwegen:“Waar-
om zouden we de pensioenadministratie van onze deel-
nemers zelf blijven doen? Dit kan toch veel beter door
een salarisbureau worden gedaan?”Of:“Waarom moeten
we zelf een beleggingsportefeuille beheren? Er zijn veel
beter toegeruste partijen die dit voor ons kunnen doen.”
Nog een ontwikkeling in dit verband is de Service Orien-
ted Office. Dit is een op zichzelf staande ‘mini-SSC’ dat,
mogelijk gemaakt door webservices, een aantal speci-
fieke services aanbiedt. Een nieuwe stap op weg naar de
‘network society’.
Organisaties ontwikkelen zich langzamerhand naar een
zogenaamde ‘digital factory’, met daarin alleen maar
Straight Through Processing (STP). Kenmerken van zo’n
digital factory zijn:
• al het inkomende berichtenverkeer wordt vastge-
legd aan de bron door de klant. Niet het eigen per-
soneel voert de registraties uit maar de klant zelf op
een portal, danwel via een koppeling van zijn syste-
men aan uw systemen.Minder fouten,sneller en voor
uw bedrijf lagere kosten.
• alle verwerkingsstappen binnen het eigen bedrijf
worden maximaal automatisch. In plaats van een
schadebehandelaar heeft u geavanceerde statisti-
sche/actuariële rekenmodellen die veel standaard-
handelingen weg automatiseren. Ook weer sneller,
foutlozer en digitaal.
• alle dossiers maakt u en bewaart u elektronisch
(electronic archives, scanning, pdf, dms).
• alle routing door het bedrijf gebeurt los van mensen
/ plaatsen, maar met een workflowmanagement sys-
teem.
Step 1
Consolidation
Step 2
Virtualization
Step 3
Automation
Step 4
Utility
Step 5
Cloud
Consolidation
& Modernization
of Resources
Abstraction &
Resource Pooling
Adaptive, Secure &
Repeatable
Self-Service &
Metering
On-Demand &
Scalable
Server
Consolidation
Server & Storage
Virtualization
Policy-Based Provisioning
& Management
Self-Service & Metering IaaS, SaaS, PaaS
Tiered Storage
Consolidation
Desktop Virtualization ITIL-Based Repeatable
Processes
Service Level Agreements
(SLAs)
Service-Oriented
Architecture
Consolidation of Network
Services
Virtualized Network
Services
Multi-Tier Security Incident Response & Audit Inter-Cloud Federation
Consolidation of
Disparate Applications
Application Virtualization Multi-Tier Data Recovery Continuous Availability &
Failover
Integration of Web 2.0 &
Web Portals
Key Enabling Capabilities
Consolidation Virtualization ITIL Service Management DR & COOP Cloud Internetworking
Modernization Thin Client Computing Network Security Risk / Vulnerability
Management
Integration
Power & Cooling Green IT Data Center Security Situational Awareness Provisioning
High Performance
Computing
Data Duplication Infrastructure Protection
Figuur 3: Cloud Computing Maturity Model (Jadhwani, et al., 2009)

• alle output gebeurt digitaal naar de buitenwereld:
ook weer op portals danwel via PDF’s of secure-mails.
Megatrend ‘Privacy is een mythe’
Producten en diensten worden in toenemende mate via
een ondoorzichtige cloud aangeboden. De ontvanger
weet daardoor niet wie wat aanbiedt en/of de bron ook
daadwerkelijk de betrouwbare bron is. Tel daarbovenop
dat generatie Y of Einstein geen enkele moeite heeft om
de gegevens op het internet wereldkundig te maken en
dan is het internet niet meer gecompliceerd, maar com-
plex (overtreffende trap).
Voor de ICT beheerder wordt het eenvoudiger door de
cloud,immers het maakt niet meer uit waar het gebeurt…
het gebeurt. Maar bovenstaande is het schrikbeeld voor
elke zichzelf respecterende informatiebeveiligingsexpert
als ook voor de ICT jurist;wie kun je waarop aanspreken?
Wie zorgt voor bevestiging dat die gegevens echt klop-
pend zijn? De in 2009 onderbroken vlucht van Nederland
naar de VS waarbij de VS voldoende informatie had om
de potentiële terreurdreiging te onderscheppen, (maar
dat niet deed) is een goed voorbeeld van de mogelijke
risico’s.Er is zoveel informatie dat door de bomen het bos
niet meer te herkennen is.En heeft u al gehoord van Twit-
tergate?
Het is inmiddels al een mythe dat privacy gewaarborgd
is. Belangrijker wordt het om te weten hoe, wat en wie
inzake heeft in uw bedrijfs- of persoonlijke informatie.
Wellicht is het van belang dat er een trusted third party
op uw bedrijfs- en persoonlijke informatie komt die kan
aangeven:“deze informatie is juist en betrouwbaar”.
Megatrend ‘Van enkele super ego’s naar
allemaal hyper-ego’s’
Weliswaar extra gestimuleerd door de economische cri-
sis, maar een trend die al gaande was: meer dan 700.000
zelfstandigen zonder personeel (zzp’ers). Samenwerken
is oké, maar een ouderwetse baas die op basis van hië-
rarchie aan de lijntjes trekt, dat is verleden tijd aan het
worden.Door de toenemende ontwikkelingen in energie,
online kennis, cloud etc. is het aantal omvangrijke be-
drijven met veel personeel aan het verminderen en daar
staat tegenover de vele mensen die specifieke kennis en
kunde aan meerdere bedrijven ‘verkopen’ of juist aan an-
dere mensen die daarmee de keten vervolmaken.Trends
als het nieuwe werken dragen bij aan de mogelijkheden
om dat te realiseren. Hadden we voorheen enkele super-
ego’s (de grote bazen), deze staan nu onder vuur vanwe-
ge de beloningen en de daadwerkelijke kennis en kunde.
Tot slot
Al met al hopen wij dat we met elkaar wat geleerd heb-
ben de afgelopen zeventien jaar en dat we deze kennis de
komende jaren ook gaan gebruiken om de aankomende
spannende periode te overbruggen. Spannend omdat de
economische neergang nog niet uitgewerkt blijkt te zijn,
dat bedrijven als Nokia en TomTom in zwaar weer verke-
ren, Social Media (Twitter,Linkedin, Facebook, Google+)
snel stijgt. Dat Google de grootste en sterkste is gewor-
den,Microsoft voorbij gaat en Apple van een niche speler
nu ineens een wereldleider blijkt te zijn in vernieuwing
en acceptatie.
Misschien dat dit wel de be-
langrijkste ontwikkeling is:
het ICT vakgebied is vol-
wassen geworden. Maar de
nieuwe fasen voortvloeiend
vanuit ICT zoals Social Media
Technologie, lees het nieuwe
denken in informatie verza-
melen en verwerken etc., is
nog een onvolwassen markt. Als we dit onder ICT mogen
noemen dan is ICT spannender dan ooit en de CIO zal nu
echt Chief INFORMATION Officer worden.
We mogen concluderen dat alleen de technologie vol-
wassen is geworden (hoewel daar nu ook weer veel ge-
beurt). Tevens mogen we concluderen dat ICT nog veel
meer een integraal deel van de samenleving zal worden.
De ICT-leveranciers zullen verder uiteenvallen in creatie-
ve I-leveranciers en robuuste en stabiele CT-leveranciers.
Wij zien vooral voor de I-leveranciers de komende jaren
nog veel mogelijkheden en kansen. Zij zullen de proble-
men en vraagstukken van de toekomst het hoofd moeten
bieden. De indicatoren uit de ICT branche wijzen ons in-
ziens de goede richting op.
Met alle trends en ontwikkelingen die momenteel gaan-
de zijn kunnen we uit ervaring stellen… het regent… het
regent kansen.
Dit artikel is een onderdeel van het boek ‘Trends in Busi-
ness & IT - Richten,inrichten en verrichten’- meer informa-
tie op www.bitti.nl
Barry Derksen is Research Director bij
Business & IT Trends Institute.
E-mail: barry.derksen@bittti.nl
Het is inmiddels al een mythe dat privacy
gewaarborgd is. Belangrijker wordt het om
te weten hoe, wat en wie inzake heeft in uw
bedrijfs- of persoonlijke informatie

Ik gaf ooit een training over het gebruik van verhalen
door architecten. Ik begon met uitgebreid de voordelen
op te sommen van het werken met verhalen. Ik gaf ook
met verve af op het gebruik van saaie PowerPoint-pre-
sentaties. Na een minuut of tien vroeg een van de deel-
nemers waarom ik al mijn punten met PowerPoint-bullets
had samengevat en waarom ik eigenlijk niet met een ver-
haal was begonnen. Ik kon wel door de vloer zakken. Hij
had groot gelijk. Als je overtuigd bent van de kracht van
verhalen, vertèl dan verhalen!
...Op een heuglijke dag werd een prinsje geboren.Al toen
de koningin in verwachting was werd de tweede toren van
het kasteel opgeruimd. Toen het prinsje geboren was gin-
gen timmerlieden en hofdames aan de slag om de toren in
te richten als Prinsentoren.Als het kind op zou groeien kon
hij in zijn eigen toren slapen, les krijgen en spelen. Toen
de prins twee jaar oud was werd er nog een prinsje gebo-
ren. Niet lang daarna volgden nog twee prinsesjes en een
prinsje. Elke keer dat er een kind bij kwam werd het kas-
teel opnieuw ingericht. De nieuwe prinsjes en prinsesjes
moesten natuurlijk hun eigen vertrekken hebben.Niet alles
hoefde nieuw gemaakt te worden. De speelzaal konden ze
best delen en er hoefde maar één klaslokaal te zijn. Maar
toch, bij elk nieuw prinsje en prinsesje moest er even wor-
den gepuzzeld. Naast de Prinsentoren kwam er zo ook een
Prinsessenvleugel in het paleis...
Verhalen kunnen een wijsheid bevatten die niet in een
UML of BPMN diagram kan worden uitgedrukt. Ik heb het
dan niet eens over het feit dat de business de syntax van
deze formele talen niet kent. Zelfs als jouw doelgroep de
diagrammen begrijpt, vertellen ze alleen maar de bare
bones, het skelet van de boodschap. Het vlees en bloed,
de emotie,de dilemma’s en afwegingen - de aspecten die
jouw verhaal realistisch en geloofwaardig maken - adres-
seer je er niet mee. Daarmee mis je een wezenlijk deel
van het architectenwerk. Een architect moet systemen
realiseren met waarde voor de organisatie. Hij moet an-
deren betrekken en inspireren. Zijn visie moet hij aan-
sprekend overdragen. Hij moet samenwerken met veel
partijen met mogelijk tegenstrijdige belangen. Om zijn
oplossingen tot een succes te maken moet hij verander-
processen faciliteren en om kunnen gaan met dilemma’s
en afwegingen. Met alleen rationele argumenten en for-
Er waren eens een koning en een koningin.Ze waren gelukkig samen en regeerden het land naar volle
tevredenheid. In de grote zaal van hun kasteel sprak de koning recht. In de balzaal werden grootse
banketten en feesten gegeven. Een van de torens was ingericht als gastenhuis voor bezoekers uit an-
dere landen. Op het binnenplein werd elk jaar de grote jaarmarkt gehouden. Om het kasteel lag een
mooie slotgracht...
Arjen Uittenbogaard
Architecten:
verhalenvertellers
Verhalen kunnen een
wijsheid bevatten die niet in
een UML of BPMN diagram
kan worden uitgedrukt

mele diagrammen komt hij er niet.
...De prinsen en prinsessen groeiden op en werden volwas-
sen. Eén voor één werden ze verliefd. Soms op een prinses
uit een ander land,soms op een boerenknecht uit een dorp
verderop.Het maakte niet uit.Eén voor één trouwden ze en
de koning en koningin verwelkomden elk nieuw schoon-
kind van harte.Voor elk prinsenpaar werd het kasteel ver-
bouwd zodat zij er konden wonen. De gezinnetjes vonden
dat heel fijn,maar wilden wel wat privacy.De gasten wer-
den voortaan in de herberg in het dorp ondergebracht.
Zo kon de Gastentoren ook door de familie bewoond
worden. Ook dat was al snel niet afdoende meer. De
torens werden hoger gemaakt. Hier kwam een uit-
bouw die boven de slotgracht hing, daar werden za-
len gebouwd, ook in alle hoeken van het binnenplein.
De koning had een kundige bouwmeester in dienst en
vaardige metselaars en loodgieters. Geen uitdaging
was te groot.
Nog wat jaren later werden de eerste kleinkinderen
geboren. Naar goed gebruik werd ervoor gezorgd
dat ook zij hun eigen ruimte kregen. Net als hun ou-
ders destijds hadden zij recht op hun eigen plekken om
te slapen, leren en spelen. De zaal waarin de koning recht-
sprak was allang geen grote zaal meer en de balzaal was
een zaaltje geworden dat alleen nog maar voor kleine
feestjes kon worden gebruikt. Uitbouwen werden vergroot
en met kunstige stellages gestut. Tussen torens werden
overspanningen gemaakt waarop weer even kon worden
voortgebouwd...
Dit verhaal schreef ik ooit in de context van een CBD-
traject. De metafoor van het alsmaar uitdijende kasteel
bleek zeer herkenbaar: voor architect én opdrachtgever,
voor ontwikkelaar én eindgebruiker. De alsmaar groei-
ende uitdagingen voor de bouwers in het verhaal zijn
vergelijkbaar met situaties in menig IT-praktijk. In eerste
instantie was het verhaal bedoeld om business-mensen
bewust te maken van een onhoudbare situatie binnen de
IT-organisatie.De systemen die tien jaar geleden voor het
eerst ontwikkeld waren,hielden het niet lang meer.Om te
appelleren aan de emoties die deze situatie opriep,gaf ik
het verhaal een enigszins pathetisch eind:
...Toen de vijfde prins zijn vijfde kind kreeg, waren de mo-
gelijkheden uitgeput. Tot dan toe had de bouwmeester
steeds weer oplossingen kunnen bedenken voor de vraag
naar meer ruimte. Tegen zijn zin had hij af en toe om raad
moeten vragen bij andere bouwmeesters en altijd waren ze
eruit gekomen.Nu kon het niet meer.De waterleidingen en
riolen waren een onontwarbare knoop geworden. De bin-
nen- en buitenmuren liepen zo in elkaar over dat nergens
meer iets kon worden verbouwd.De torens konden niet ho-
ger anders stortten ze in onder hun eigen gewicht.
De bouwmeester was ten einde raad en vroeg audiëntie bij
de koning.Voor het jongste kleinkind was geen plaats meer
op het kasteel…
Dit verhaal heb ik sindsdien in verschillende vormen
en variaties voor tal van doelen gebruikt. Bijvoorbeeld
om een discussie te openen over hoe verder? Het open
einde nodigt hiertoe uit: gaan wij nóg meer ingenieuze
constructies bedenken om ook deze wens nog te hono-
reren, of moeten we op zoek naar alternatieven? Een an-
dere toepassing van het verhaal was bij een brainstorm
over oplossingsrichtingen: wat moet de koning beslui-
ten? Komt er een nieuw kasteel? Krijgt elk kind zijn eigen
kasteel? Zijn de kinderen te verwend en moeten ze maar
eens met wat minder tevreden zijn? En wat betekenen
deze oplossingen in het sprookje voor de werkelijkheid
van ons IT-landschap?
Zelf houd ik van het gebruik van metaforen en verpak ik
mijn boodschap graag in dierenverhalen of sprookjes.
Maar een goed gekozen anekdote is ook heel waardevol.
Vertel over die keer dat je de plank enorm missloeg en
je hebt de sympathie van het publiek: eindelijk eens een
architect die niet doet alsof hij onfeilbaar is. Je demon-
streert in alle openheid dat je van fouten kunt leren. Er
zijn oneindig veel soorten verhalen.Vertel ze. Een goede
architect is een verhalenverteller.
Arjen Uittenbogaard is senior adviseur, coach
en docent bij Inspearit / CIBIT Academy.
www.verhalenmaker.nl
Foto:appler/Shutterstock.com

Deze vraag wordt beantwoord aan de hand van de inhoud
van de‘TOGAF-SABSA integration whitepaper’,die in ok-
tober 2011 is gepubliceerd.De boodschap:alleen met de
integratie van operationeel risicomanagement in de be-
drijfsarchitectuur,kan architectuur zijn doel vervullen.Dit
doel is het voorzien in een continue afstemming tussen de
organisatiedoelstellingen en de operatie, als ook het op
een effectieve en efficiënte wijze realiseren hiervan, zelfs
als de omgeving of bedrijfsdoelstellingen veranderen.
Dit artikel is bedoeld voor breed georiënteerde architec-
ten, maar ook voor veranderen risicomanagers die een
idee willen krijgen over hoe optimaal te kunnen blijven
inspelen op elkaar steeds sneller opvolgende (technolo-
gische) ontwikkelingen en veranderende concurrentie-
krachten.
Dat de aandacht uitgaat naar het beheersen van opera-
tioneel risico, is omdat het de operationele capaciteiten
binnen de organisatie zijn, die bijdragen aan de realisa-
tie van organisatiedoelstellingen. Of het nu het schetsen
van een business model op de achterkant van een siga-
rendoosje, het ontwikkelen van een cloud strategie, het
motiveren van medewerkers of het administreren van po-
lissen is, allen dragen in zekere mate bij aan waardetoe-
voeging. De rol van de architect hierin is niet meer, maar
ook niet minder dan met het inbouwen van risicomanage-
ment in architectuur, een operationele omgeving te rea-
liseren, die optimaal bijdraagt
aan deze waardetoevoeging. Het
eeuwige dilemma voor archi-
tecten en managers is duidelijk
te krijgen en te maken wanneer
goed, goed genoeg is. Kortom
wat is optimaal? Bij het managen
van risico’s is de risicotolerantie,
ofwel de risk appetite hiervoor
een uitgangspunt. Deze wordt
bepaald door het vaststellen van hoeveel verlies draag-
baar is en hoeveel waarde moet worden gecreëerd met
het benutten van kansen om organisatiedoelstellingen
te kunnen realiseren. Het bepalen hiervan is een verant-
woordelijkheid van het management. De dynamiek van
het zich kunnen voordoen van gebeurtenissen, die waar-
de beïnvloeden, is weergegeven in figuur 1. De operatio-
nele capaciteiten gelden als de ‘assets at risk’.
Tijdens de verhoren van de parlementaire enquêtes Financieel Stelsel eind vorig jaar was een ant-
woord op veel van de vragen: ”Met de kennis van toen hebben we destijds in onze ogen het juiste be-
sluit genomen”. Dit is het domein van risicomanagement, vrij vertaald naar het inschatten van en anti-
ciperen op de effecten van niet of nauwelijks beïnvloedbare gebeurtenissen op wat van waarde wordt
geacht. Hoe bescherm je deze waarde, hoe integreer je risicomanagement in de bedrijfsvoering?
Jeroen van Esch
TOGAF-SABSA
integratie
Alleen met de integratie van
operationeel risicomanagement in de
bedrijfsarchitectuur, kan architectuur
zijn doel vervullen
Het realiseren van een veilige bedrijfsarchitectuur

Twee kernpunten
Om de opdracht tot het realiseren van een operationele
omgeving die optimaal bijdraagt aan waardetoevoeging
te kunnen uitvoeren, worden twee kernpunten aange-
reikt.
Het eerste is security niet als geïsoleerde operationele
capaciteit te beschouwen, maar als view van de bedrijfs-
architectuur. Vanuit dit perspectief gaat security niet al-
leen om het borgen van de veiligheid van informatie en
informatiesystemen, maar om het borgen van de veilig-
heid van alle operationele capaciteiten in hun bijdrage
aan de organisatiedoelstellingen. Een operationele ca-
paciteit kan hierbij natuurlijk nog steeds een informatie-
systeem zijn. Veiligheid omvat ook meer dan alleen de
vanuit de informatiebeveiliging bekende aspecten be-
schikbaarheid, integriteit en vertrouwelijkheid. Het gaat
om alle aspecten die bijdragen aan een ‘fit for purpose’.
De gewenste veiligheid wordt bepaald aan de hand van
de risk appetite en kan worden uitgedrukt in beveili-
gingsdoelstellingen.
Het tweede kernpunt is het toekennen van een centrale
rol voor requirements management als verbindend ele-
ment tussen de organisatiedoelstellingen en de operatie.
Een belangrijk aspect hierin is dat het niet alleen om het
stellen van beveiligingsdoelstellingen gaat, maar dat het
ook mogelijk is om terugkoppeling te krijgen over de ef-
fecten van de realisatie ervan.
Een toepassing
Daar waar in TOGAF geen concrete invulling is gege-
ven aan requirements management biedt SABSA hier een
belangrijke toevoeging. Hoe werkt dit concreet en hoe
draagt het proces van requirements management bij aan
de afstemming van organisatiedoelstellingen en opera-
tie? Figuur 2 geeft het TOGAF ADM proces weer voor het
ontwikkelen van architectuur. De rechthoeken zijn SABSA
artifacten waarmee een security view op het ontwikkel-
proces en uiteindelijk op de bedrijfsarchitectuur wordt
geboden.
Het begint met het opstellen of verzamelen van beschrij-
vingen van externe ontwikkelingen en algemene organi-
satiedoelstellingen. Om in de financiële sector te blijven;
aangescherpte eisen van toezichthouders aan kapitaal-
toereikendheid en snelle berichtgeving via de sociale
media over vermeende misstappen,zijn voorbeelden van
relevante ontwikkelingen voor banken en verzekeraars.
Voorbeelden van algemene doelstellingen zijn het ver-
hogen van omzet en het verbeteren van de marktpositie.
Vanuit een security perspectief kunnen ontwikkelingen,
die kansen en bedreigingen in zich hebben, worden
verbonden met de algemene doelstellingen via beveili-
gingsdoelstellingen. Voorbeelden zijn het bereiken van
adequate inschattingen van de waarde van passiva (bij-
voorbeeld technische provisie) en het verbeteren van de
Net Promotor Score (NPS). De beveiligingsdoelstel-
Figuur 1: De invloeden op waarde
Likelihood of
threat
materialising
Likelihood of
weakness
exploited
Asset
value
Negative
impact
value
Threats
Loss event
Likelihood of
opportunity
materialising
Likelihood of
strength
exploited
%
Asset
value
Positive
impact
value
€
Opportunities
Beneficial event
Assets
at risk
Risk context
Negative
outcomes
Positive
outcomes
% €

lingen gelden als kritische succesfactoren om optimaal
te kunnen inspelen op mogelijke gebeurtenissen als ge-
volg van de ontwikkelingen. De complete set van beveili-
gingsdoelstellingen komt tot stand aan de hand van vra-
gen over het wat, waarom, wie, hoe, waar en wanneer van
de strategie.
De beveiligingsdoelstellingen zijn niet concreet en spe-
cifiek genoeg om als basis te dienen voor architectuur
voor operationele capaciteiten. Dit kan worden opgelost
door een decompositie te maken naar het niveau van het
domein waar een of meerdere operationele capaciteiten
onderdeel van zijn. De organisatie als geheel is hierbij
het topdomein. Door het toepassen van bijvoorbeeld een
opdeling naar functie of afdeling,ontstaan deeldomeinen.
De eisen worden bepaald voor karakteristieken, of attri-
buten van operationele capaciteiten binnen een domein.
Het gaat om die attributen die verwacht worden bepa-
lend te zijn voor de realisatie van de beveiligingsdoel-
stellingen.
Voor operationele capaciteiten binnen grotere verzeke-
raars zal gelden dat het belangrijk is om bij te dragen
aan het kunnen voldoen aan de
Solvency II richtlijnen, om hier-
mee als organisatie in te kunnen
spelen op de ontwikkeling aan-
gaande aangescherpt toezicht.
Nauwkeurigheid, toepasselijk-
heid en compleetheid zijn in het
kader van Solvency II relevante
attributen. Hier kan het attribuut
reputatie aan worden toege-
voegd om bij te dragen aan reputatiebescherming. De
uiteindelijke set van attributen komt tot stand door het
verantwoordelijke management en andere stakeholders
die nodig zijn voor het bereiken draagvlak, te betrekken.
De attributen worden beschreven in termen die voor
het verantwoordelijke management duidelijk maken op
welke wijze wordt bijgedragen aan de beveiligingsdoel-
stellingen. Hierbij kunnen de attributen de verbinding
vormen tussen een domein en een deeldomein,maar kan
Prelim:
Framework
and
Principles
A.
Architecture
Vision
B.
Business
Architecture
G.
Implementation
Governance
H.
Architecture
Change
Management
C.
Information
Systems
Architectures
D.
Technology
Architecture
F.
Migration
Planning
E.
Opportunities
and
Solutions
Requirements
Management
Business Drivers
Security Principles
Key Risk Areas
Risk Appetite
Security Resource Plan
Business Risk Model
Law and Regulation
Control Frameworks
Security Domain Model
Trust Framework
Security Organization
Security Policy Architecture
Security Services Catalog
Security Stakeholders
Security Services Catalog
Classification of Services
Security Rules, Practices
and Procedures
Security Standards
Security Management
Security Audit
Security Awareness
Security Architecture
Governance
Risk Management
Business Attribute Profile
Control Objectives
Figuur 2: Het ontwikkelen van een veilige architectuur met SABSA en TOGAF ADM
De beveiligingsdoelstellingen zijn
niet concreet en specifiek genoeg om als
basis te dienen voor architectuur voor
operationele capaciteiten

Figuur 4: Relatie beveiligingsdoelstellingen, attributen, prestatiedoelen en beheersdoelen
voor het deeldomein een eigen specifieke beschrijving
worden toegekend.
Om meetbaar te kunnen maken in welke mate wordt vol-
daan aan de beveiligingsdoelstellingen, worden per at-
tribuut prestatiedoelen bepaald. Dit kan met het gebruik
van bekende score card technieken met indicatoren.
Achtereenvolgens worden een meetmethode, een me-
triek en het prestatiedoel zelf vastgelegd. Ideeën bij het
management over haalbaarheid van prestatiedoelstel-
lingen, bestaande maatregelen, geldende (technische)
beperkingen en risicobereidheid zijn bepalend voor de
waardes van de prestatiedoelen.Het zichtbaar maken van
scores op de prestatiedoelen kan met real-time operatio-
nal risk dashboards of score cards.
Een volgende stap is het uitvoeren van een riscioanalyse,
het bepalen van beheersdoelen en een bijbehorende set
van maatregelen die ervoor moet zorgen dat de risico’s
van het niet kunnen halen van de prestatiedoelen worden
beperkt tot een acceptabel niveau. Ook hier is de risico-
bereidheid van het verantwoordelijke management be-
palend.
De set van attributen, prestatiedoelen en beheersdoelen
vertegenwoordigen gezamenlijk de bijdrage aan de be-
veiligingsdoelstellingen en zijn daarmee een weergave
van de risk appetite van de organisatie.
Met het kiezen van maatregelen, vindt er ook een door-
vertaling plaats naar oplossingsniveau. Hoe uiteindelijk
praktisch wordt bijgedragen aan het optimaliseren van
risico’s, is voor een belangrijk deel aan de architect.
Hiermee is de link tussen strategie en operatie, alsook
de link tussen doelen en oplossingen compleet. Ook is er
sprake van volledige traceerbaarheid. Dit zal het kunnen
nemen van geïnformeerde beslissingen bij het maken
van keuzes over bijvoorbeeld te realiseren maatregelen
Figuur 3:Voorbeeld van een attribuut en prestatiedoel
bevorderen.
Het werken met attributen is niet uniek voor de invulling
van requirements management. Methodes als “Extended
ISO 9126”maken er ook gebruik van.Het verschil zit er in
dat de ISO methode security ziet als een afzonderlijk attri-
buut, terwijl in de hier beschreven aanpak attributen en
prestatiedoelen gezamenlijk de gewenste veiligheid re-
presenteren. Een ander verschil is dat niet met een alge-
mene set wordt gewerkt, maar met een set die afgestemd
is op gezamenlijk onderkende bijdrage van de operatio-
nele capaciteiten aan waardeoptimalisatie.
Het op genoemde wijze uitvoeren van het proces van re-
quirements management is allerminst een lineair proces
en eenvoudig van aard.Zo is het opstellen van een set van
attributen en prestatiedoelen een ontwikkelproces met
een bijbehorende dynamiek in het betrekken van stake-
holders. De uitdaging ligt in het definiëren van meetbare
prestatiedoelen die terug te voeren zijn naar de bevei-
Attribuut Nauwkeurigheid
Betekenis Informatie wordt als nauwkeurig
beschouwd als de vastlegging ervan
volgens beschikbare werkinstructies en
tijdig plaatsvindt, dat met de opslag wordt
voldaan aan weten regelgeving en dat
de informatie bij het weer opvragen ervan
consistent is, ongeacht tijd en plaats.
Meetmethode Steekproef in offertes
Metriek Aantal fouten in offertes
Prestatiedoel 80 % van offertes in een keer goed
Beveiligings-
doelstelling
Beveiligings-
doelstelling
Beveiligings-
doelstelling
Attribuut
Attribuut
Attribuut
Prestatiedoel
Prestatiedoel
Prestatiedoel
Prestatiedoel
Prestatiedoel
Prestatiedoel
Beheersdoelen
Beheersdoelen
Beheersdoelen
Beheersdoelen
Beheersdoelen
Beheersdoelen
Risicoanalyse

ligingsdoelstellingen.Daarnaast zijn governance,vastleg-
ging van resultaten,eigenaarschap en het onderhoud van
het proces belangrijke aandachtspunten.
Denken en doen
In de praktijk wisselen planning en realisatie zich con-
tinu af. Er is meestal meer geld beschikbaar om op op-
lossingsniveau architectuur te ontwikkelen en toe te pas-
sen dan op bedrijfsniveau. Maar op bedrijfsniveau is er
vaak meer tijd dan op projectniveau. Het verkrijgen van
draagvlak en aantonen van de voordelen van het proces
van requirements management hebben de beste kans van
slagen op programma- of portfolioniveau. Dit is niet al-
leen omdat dit het veilige midden is. Het is de plek waar,
als het goed is, het hart van organisatieverandering ligt
en ook de coördinatie voor het wel of niet volgens een
roadmap implementeren van architectuur.
Tot slot
Met de integratie van TOGAF en SABSA is een verdere
stap gezet in de invulling van het proces van require-
ments management.In het gebruik van dit proces kan een
krachtig beleidsinstrument worden gevonden, dat de be-
veiligingsdoelstellingen van het verantwoordelijke ma-
nagement weergeeft en als leidraad kan dienen voor het
inrichten van operationele capaciteiten en het operatio-
neel risico daarbinnen te optimaliseren.Denk aan het be-
ter kunnen inrichten en gebruiken van tools voor Business
Event Monitoring en Business Service Management, een
betere afstemming van vraag en aanbod in contracten
voor managed services, maar ook bijvoorbeeld het bepa-
len van kwaliteitsattributen voor een master test plan.
Met de getoonde methode wordt mogelijk om het wat,
waarom, wie, hoe, waar en wanneer op strategisch niveau
op een gestructureerde wijze te kunnen verbinden met
die zelfde aspecten op operationeel niveau, dit alles met
in acht name van de risk appetite.
Voorwaarden om er werkelijk de vruchten van te kunnen
plukken zitten in het betrekken van beslissers, waarbij
een sterk beroep gedaan wordt op de samenwerking tus-
sen partijen in de keten, en op de kennis en kunde van
managers en architecten.
Download de whitepaper ‘TOGAF-SABSA integration’
Jeroen van Esch is IT Management consultant
bij Ideas to Interconnect B.V. (i-to-i).
www.i-to-i.nl

SOA wordt door velen gezien als dé oplossing om ver-
schillende bedrijfssystemen flexibel via internet of een
bedrijfsnetwerk met elkaar te laten communiceren. Het
zou voor wereldwijd opererende bedrijven de oplossing
zijn om diensten beschikbaar te maken voor diverse pro-
ductlijnen en landen. Veel bedrijven zien het potentieel
van SOA-oplossingen.Er kunnen namelijk op grote schaal
‘highly distributed’-oplossingen ingezet worden om ge-
lijkmatig verdeelde bedrijfsprocessen te beheren. Maar
bedrijven die in SOA een efficiënte, kosteneffectieve, al-
lesomvattende oplossing zien voor hun IT-infrastructuur
kunnen ook van een koude kermis thuiskomen.
SOA is een technische oplossing die maar al te vaak slecht
toegepast kan worden op het organisatorisch model van
een bedrijf. Niet iedere afdeling gebruikt dezelfde dien-
sten of stelt dezelfde prioriteiten aan een applicatie.Hier-
door ontstaat een situatie waarin vraag,verantwoordelijk-
heden en geldstromen niet parallel lopen.
Neem bijvoorbeeld een bedrijf waarbij IT-budgetten per
productlijn of regio worden vastgesteld. Vanuit het cen-
trale kantoor wordt besloten dat de bedrijfsonderdelen
in alle landen toegang moeten krijgen tot een dienst om
postcodes te valideren. Hoewel de functie voor alle me-
dewerkers noodzakelijk is, heeft niet iedereen dezelfde
eisen. Sommige afdelingen hebben er baat bij als de
gegevens 24/7 gecontro-
leerd worden, voor een
ander is één keer per
dag voldoende. Hierdoor
is niet voor iedere bud-
getverantwoordelijke de
gevraagde investering in
verhouding met het afna-
meprofiel.
En hier wringt de schoen.
De beperking van SOA is voornamelijk gelegen in niet-
technische redenen. Veel business units willen niet zo-
maar een oplossing opgedrongen krijgen. Een dienst
moet aan bepaalde randvoorwaarden voldoen om als
betrouwbare oplossing geaccepteerd te worden. Geluk-
kig zijn recentelijk zowel medewerkers als bedrijven de
voordelen van SOA gaan inzien. Op het gebied van flexi-
biliteit en besparingen op lange termijn is de acceptatie
van op SOA-gebaseerde oplossingen sterk gestegen.
SOA en EDA,een sterke mix of gaan beiden niet samen? SOA wordt steeds meer geaccepteerd binnen
organisaties.In dit artikel wordt ingegaan op wat SOA is en hoe het bedrijven kan helpen. Een recente
ontwikkeling is de toevoeging van EDA (Event Driven Architecture) bij SOA. Kan dit de architectuur
van een organisatie nog meer versterken?
Bert Hooyman
SOA voor
gevorderden
Praktische realisatie van de nieuwe generatie systeemintegratie
SOA wordt door velen gezien als dé
oplossing om verschillende bedrijfssystemen
flexibel via internet of een bedrijfsnetwerk
met elkaar te laten communiceren

SOA en EDA - een sterke mix - SOA 2.0
EDA (Event Driven Architecture) versterkt de voordelen
van SOA door asynchrone en sterk ontkoppelde service-
patronen in de SOA-oplossingen binnen te halen. SOA
is alleen effectief als zoveel mogelijk mensen van een
dienst gebruik maken,EDA kan deze effectiviteit van SOA
alleen maar verbeteren.Denk hierbij aan een service die
het mogelijk maakt om een e-mailaccount aan te maken.
Bij veel huidige bedrijfsmodellen, waar geldstromen en
verantwoordelijkheden bepalend zijn voor handelingen
en beslissingen, is een EDA effectiever. Door de schaal-
baarheid van deze architectuur sluit deze beter aan bij
de filosofie dat bedrijfsonderdelen hun eigen eisen en
budgetten kunnen bepalen. Bedrijven die SOA hebben
geïmplementeerd, hebben al gebruik gemaakt van of
zijn gestart met het gebruik van EDA om highly distribu-
ted en operationeel beheerbare SOA-oplossingen aan te
bieden. Nu de SOA-adoptie en -standaardisatie is toege-
nomen, zijn bedrijven gestart met het inzetten van SOA-
oplossingen. Zo kunnen atomische en complexe scena-
rio’s voor het beheer van bedrijfsprocessen aangepakt
worden met SOA- en EDA-patronen. Dit gebeurt door ge-
bruik te maken van BPEL en functies voor transactiepro-
cessen die gedreven worden door SOA en EDA.
Veel bedrijven die eerder op een kleine schaal zijn be-
gonnen met SOA willen SOA en EDA nu uitbreiden naar
een zakelijk niveau. Zo kunnen de complexe eisen vanuit
de organisatie beter beheerd worden, vaak betreft het
namelijk meerdere business units met ieder hun eigen
budgetten en beslissingen op regionaal niveau. Bedrij-
ven zien de waarde van op SOA en EDA (SOA 2.0) geba-
seerde zakelijke oplossingen die een hoge afhankelijke,
maar gelijkwaardig ontkoppelde infrastructuur kunnen
creëren. Deze oplossingen kunnen daarnaast een flexi-
bele bedrijfsconnectiviteit faciliteren tussen de organisa-
tie en zijn klanten, business partners, leveranciers en an-
dere partijen binnen het ecosysteem van de organisatie.
Er kan dus geconcludeerd worden dat de recente ver-
menging van EDA-patronen met SOA, samen met een
continue verbetering van ESB-, BPEL-, SCA-patronen en
standaarden, SOA 2.0 verder hebben versterkt. Het is nu
een van de belangrijkste en praktisch geaccepteerde
zakelijke architectuurpatronen. Tegelijkertijd heeft de
opkomst van cloud computing, met name SaaS-modellen
die sterk gebaseerd zijn op SOA-architectuur, de accep-
tatie en uitrol van vele bedrijfskritieke SOA-oplossingen
vergroot. Het motto is: ‘Maak gebruik van geavanceerde
SOA,dat een sterke combinatie is tussen SOA en EDA,om
zakelijke complexiteiten aan te pakken en om geld te be-
sparen op de korte en lange termijn’.
Bert Hooyman is Chief Architect Europe bij
MphasiS.
www.mphasis.com
Foto:irin-k/Shutterstock.comFoto:irin-k/Shutterstock.com

Grens tussen privé en werk vervaagt
De grens tussen werk en privé en de technologie die
thuis of op het werk gebruikt wordt,vervaagt steeds meer
nu werknemers hun persoonlijke apparaten als een tablet
of mobiele telefoon ook op de werkvloer gebruiken. Of
andersom, wanneer de werknemer de werklaptop thuis
op de bank nog even voor een persoonlijk rondje surfen
openklapt.
IT-managers hebben met de ‘consumerization of IT’- en
‘BYOD’-trend een aantal vragen die om antwoord vragen:
• Als iemand een eigen apparaat gebruikt, moet het
IT-team hier technische ondersteuning voor geven of
niet?
• Als iemand een applicatie nodig heeft,mag deze dan
op een eigen apparaat worden geïnstalleerd of moet
dit altijd op de werk-PC gebeuren?
• Hoe wordt het persoonlijke apparaat van de werkne-
mer up-to-date gehouden als het aankomt op bevei-
liging?
• Wat gebeurt er als de gebruiker van baan verandert
of het bedrijf verlaat?
Deze vragen zorgen al voor genoeg stof tot nadenken als
het gaat om beheer van bedrijfs- PC’s of laptops. Als het
gaat om een apparaat dat privé eigendom is, wordt het
beheer voor het IT-team nog gecompliceerder.
Gebruikers willen meer flexibiliteit en
snelheid
Gebruikers vragen meer flexibiliteit en snelheid van de
IT-afdeling in vergelijking met vroeger. Immers, waarom
duurt het zo lang voor IT iets heeft aangepast of geïnstal-
leerd op een desktop computer, wanneer de werknemer
thuis binnen drie minuten een app kan selecteren en
installeren op zijn mobiele telefoon? De werknemer wil
meer vrijheid in de manier waarop hij werkt en waarmee
hij werkt.IT kan daarbij als een belemmering gezien wor-
den nu de werknemer het gevoel heeft in zijn keuzevrij-
heid van toepassingen te worden beperkt.
Veranderingen in IT-beheer
Hoe moet IT nu met het beheer omgaan? De stijgende
vraag van werknemers om eigen apparaten te mogen
gebruiken voor werksituaties, vraagt om een aanpas-
‘Consumerization of IT’
vraagt andere manier
van IT-beheer
De ontwikkeling in IT heeft de afgelopen jaren niet stil gestaan. Alleen al het concept ‘BringYour Own
Device’ (BYOD), een gevolg van Het Nieuwe Werken, veroorzaakt een verandering in de manier waar-
op IT-beheer vandaag de dag wordt uitgevoerd.
Bob Janssen
Als iemand een eigen
apparaat gebruikt, moet het
IT-team hier dan technische
ondersteuning voor geven?

sing van processen. Mogelijkheden voor het automati-
seren van IT-beheer moet bijvoorbeeld onder de loep
genomen worden.Door het automatiseren van dagelijkse,
tijdrovende IT-taken kan de IT-afdeling een steeds com-
plexer wordende IT-infrastructuur op een eenvoudige
manier beheren en tegelijkertijd een betere service le-
veren aan de rest van de organisatie.
Onderdeel van het aanpassen van de processen is ook de
omschakeling van een apparaat gerichte aanpak naar een
service gerichte aanpak. In plaats van apparaten waarop
alles is voor geïnstalleerd, willen gebruikers meer keuze
in bijvoorbeeld de programma’s die ze gebruiken om hun
werk uit te voeren.Ook het gebruik van verschillende ap-
paraten, bijvoorbeeld een laptop overdag en een tablet
in de avond om nog even wat werk e-mails te lezen, is
een reële situatie. De diversiteit in de verschillende ap-
paraten, zorgt voor de grootste uitdaging voor het IT-be-
heer.
Daarnaast zal het licenseren van software ook een veran-
dering doormaken nu steeds meer consumentapparaten
hun weg naar de werkvloer vinden.Een licentie wordt im-
mers niet meer toegewezen aan een bepaald stuk hard-
ware. Op dit gebied is flexibiliteit nodig. Zo wordt bij-
voorbeeld bij sommige software een model gehanteerd
waarbij er betaald wordt afhankelijk van het daadwerke-
lijke gebruik.IT-beheer moet ook op dit gebied de veran-
deringen en mogelijkheden in de gaten blijven houden.
Toegang tot diensten en applicaties
De ontwikkelingen in het beheer van apparaten voor het
IT-team, zijn ook weer verbonden met de toegang tot ap-
plicaties en diensten voor de werknemer. De manieren
waarop een werknemer toegang heeft tot een applicatie,
zijn aanzienlijk vermeerderd in de laatste jaren. Zo is er
software die vanaf een lokale server draait,maar ook soft-
ware-as-a-service en virtuele desktops.
Deze verschillende manieren waarop de werknemer toe-
gang kan krijgen tot stukjes software en programma’s,
kunnen een voordeel opleveren voor de gebruiksvrien-
delijkheid of de kosteneffectiviteit ervan. Maar niet elke
manier zoals hierboven genoemd is voor elke situatie
geschikt. Voor werknemers die mobiel werken is een
lokaal gehoste virtuele desktop minder geschikt. In het
geval van een werknemer met ondersteunende taken, is
een servergebaseerde oplossing soms wel de beste
Werknemers hebben op
steeds meer manieren
toegang tot applicaties en
diensten
Foto:topseller/Shutterstock.com
“Gebruikers vragen meer flexibiliteit
en snelheid van de IT-afdeling in
vergelijking met vroeger.”

optie. Om tot de beslissing
voor een bepaald model te
komen, is dan ook kennis
nodig op het gebied van
de verschillende technolo-
gieën en bijkomende voor-
delen per situatie.
Dat betekent dat in de toe-
komst vaker het zogenoem-
de concept ‘IT-as-a-Service’
(ITaaS) zijn intrede zal doen.
Gebruikers vragen IT hier-
bij om de applicaties en
diensten die ze nodig heb-
ben. Met deze aanpak ver-
anderen ook processen
voor afdelingen buiten IT.
Zo zal er een link gelegd moeten worden met personeels-
beleid als het gaat om de rechten per werknemer bij het
aanvragen van applicaties en diensten.
Om IT-managers mee te laten gaan met deze ontwikke-
ling, is er een goed besef nodig van de recente verande-
ringen rondom het toegankelijk maken van applicaties.
Hier moet het nieuwe dienstenmodel voor worden inge-
richt. De verschuiving naar ITaaS betekent een einde aan
de kijk op apparaten als voor geïnstalleerde producten,
en vraagt in plaats daarvan een IT-werknemer die be-
grijpt hoe IT-diensten gebruikt worden, zich ontwikkelen
en veranderen met de tijd.
Gebruiker staat centraal
Het apparaat zal niet meer het uitgangspunt zijn. Bedrij-
ven moeten kijken wat de gebruiker nodig heeft,welk ap-
paraat of apparaten ze daarbij kunnen gebruiken en waar
en wanneer toegang nodig is. Dit klinkt ingewikkelder
dan het beheren op desktopniveau. En de meeste orga-
nisaties hebben dan ook nog geen effectieve IT-beheer
aanpak voor deze nieuwe vorm.
ITaaS levert de organisatie meer flexibele eindgebrui-
kers op.De gebruiker hoeft niet meer langs bij IT-beheer,
maar kunnen met doe-het-zelf-modellen de gereed-
schappen vinden die ze nodig hebben.Tegelijkertijd kan
IT beter monitoren hoe verschillende apparaten worden
gebruikt om daarmee dankzij effectiever gebruik, voor
het bedrijf kostenvoordelen op te sporen.
Het bovenstaande model wordt ook wel de zakelijke ‘app
store’ genoemd. Gebruikers kunnen hier inloggen op
applicaties die ze af en toe nodig hebben. Programma’s
die zwaarder gebruik kennen,zijn onderdeel van een ba-
sisdienst waarvoor elke werknemer toegang krijgt. Hier
wordt goed duidelijk wat er zo ingewikkeld is aan deze
situatie. IT moet applicaties beschikbaar maken voor de
eindgebruiker en daarbij rekening houden met het soort
apparaat en de context van de toegang. Het eindresultaat
maakt het makkelijker voor gebruikers om IT-middelen
te gebruiken.Als het puntje bij het paaltje komt,dan is de
werknemer in het nieuwe model meer flexibel en daar-
mee ook productiever.
Overstap naar ITaaS
noodzakelijk
Omdat werknemers steeds va-
ker hun eigen apparaten mee
naar de werkvloer nemen, wor-
den organisaties gedwongen
te kijken naar de processen in
IT-management, zowel op appa-
raat- als gebruikersniveau. In de toekomst is de overstap
naar ITaaS onvermijdelijk om de verandering het hoofd
te bieden. Op termijn faciliteert ITaaS de werknemer met
meer keuze in de manier waarop, waar en hoe het werk
gedaan wordt.Voor het management dat zich bezighoudt
met apparaatbeheer, ligt de toekomst niet in statische
eenheden,maar meer in het leveren van een dienst waar-
aan een bepaalde bedrijfswaarde hangt.
Bob Janssen is mede-oprichter en Chief
Technical Officer van RES Software.
www.ressoftware.com
Bedrijven moeten kijken wat de gebruiker
nodig heeft, welk apparaat of apparaten
ze daarbij kunnen gebruiken en waar en
wanneer toegang nodig is
Foto:Daboost/Shutterstock.com

In steeds meer organisaties wordt gewerkt met enterprise architectuur.Twee belangrijke aspecten die bijdra-
gen aan het succes van werken onder enterprise architectuur is dat er een eenvoudig, begrijpelijk en goedge-
keurd overzicht is door en voor bestuur, directie, management en architecten waaruit blijkt welke architectu-
ren er zijn of worden onderkend.Wie de eigenaar er van is en hoe goed of hoe ver het staat met die architectuur.
Op de architectuurposter wordt getoond hoe het enterprise architectuurraamwerk door de tijd heen gezien
veranderd voor de organisatie: er komen architecturen bij, en er vallen architecturen af.
In de praktijk blijkt vaak dat een onduidelijke status of belangrijkheid van een architectuur debet is aan het gebrekkig
of niet willen of hoeven hanteren van de architectuur in de projecten. Stel dat in de business architectuur het concept
self service is gekozen. Dat maakt dat in feite overal waar dienstverlening aan klanten aan de orde is, het self service
principe moet gaan gelden in de business. Als het echter onduidelijk is waar, wanneer en welke business architec-
tuur van toepassing is in de organisatie, dan ontstaan er al snel onbedoeld overal uitzonderingen op de architectuur.
Door een dergelijke architectuurposter op te stellen krijgt de CFO of CIO weer het stuur in handen om te bepalen
waar de architectuur over gaat en waar ze zich op richt. Ook de onderliggende architecturen zijn harder en kunnen
beter zonder uitzonderingen worden doorgevoerd. Belangrijk hier is dat de CFO of CIO de opdracht geeft aan de en-
terprise architecten om deze architectuurposter te maken. De enterprise architecten zullen zich hier proactief moeten
bewegen richting de CFO of CIO. En zichzelf zien als ervaren creatieve (her)ontwerpers van ondernemingen.
Lees meer over het enterprise architectuurraamwerk van Dragon1 op http://wiki.dragon1.org
Poster:
Dragon1 EA Framework - ChangeView
Dragon1 Voorbeeld Generiek AS-IS & TO-BE Enterprise Architectuurraamwerk
Veranderaanzicht (Change view) / Dit is een baseline view
Zie begrippenkaderdocument voor definities
Legenda:
Enterprise architectuur
Businessarchitectuur
Markt en klant architectuur
SecurityArchitectuur
Besturingsarchitectuur
Dienst
architectuur
Product
architectuur
Proces
architectuur
Technische architectuur
Informatiearchitectuur
Netwerk
architectuur
Storage
architectuur
Printing
architectuur
Applicatie
architectuur
Data
architectuur
Integratie
architectuur
Dienst
architectuur
Product
architectuur
Proces
architectuur
Applicatie
architectuur
Data
architectuur
Integratie
architectuur
Dienst
architectuur
Product
architectuur
Proces
architectuur
Netwerk
architectuur
Storage
architectuur
Printing
architectuur
Applicatie
architectuur
Data
architectuur
Integratie
architectuur
Dienst
architectuur
Product
architectuur
Proces
architectuur
Referentie Enterprise Architectuur Raamwerk
Communicatieboodschap
Deze changeview zegt het volgende:
•Het architectuurraamwerk wordt aan de hand van een referentiemodel verbeterd in de loop der jaren.
•De organisatie heeft een fusieverleden en daarom is er nu geen sprake van 1 ICT-infrastructuur en informatievoorziening
•Er wordt gestreefd naar 1 technische architectuur, informatie architectuur, business architectuur etc..
•Er is een highlevel enterprise architectuur document waar in enkele concepten, principes en deelarchitecturen staan benoemd
•De bedrijfsprocessen, producten en diensten in de verschillende oorspronkelijke organisaties zijn gestandaardiseerd vanuit de branche, alleen is het nog niet
gedocumenteerd.
•De informatie architectuur staat per oorspronkelijke organisatie gedeeltelijk op papier, maar gaat nu geïntegreerd worden
•De technische architectuur is nog geen geheel en staat niet op papier en komt er zo snel mogelijk en krijgt een eigenaar
•De security architectuur en besturingsarchitectuur gaan er nooit komen
•De markt en klant architectuur is te kennisintensief en dynamisch voor de organisatie om te onderhouden en gaat verdwijnen.
Applicatie
architectuur
Data
architectuur
Integratie
architectuur
Technische
architectuur
Technische
architectuur
Technische
architectuur
AS-IS (Plateau 0) TO-BE (Plateau 5) over 3 jaar Envision (Ideale wereld) over 10 jaar
Technische
architectuur
Informatie
architectuur
Informatie
architectuur
Informatie
architectuur
Deze architectuur is er nu niet en
gaat er nooit komen
Deze architectuur is er nu niet maar
gaat er wel komen
Deze architectuur is er nu en blijft
Deze architectuur is er nu maar gaat
verdwijnen
Informatie
Documentversie:
Documentstatus:
Publicatiestatus:
Eigenaar:
Manager:
Beheerder:
Gebruikers:
Beheerlocatie:
Gebruikslocatie:
Deze changeview is een initiatief
van het architectuurteam.
Er dient een EA-programma /
ontwerpopdracht te worden
verstrekt.
Dan is deze view officieel te
maken en te accorderen door de
CIO.
Context
© Copyright Dragon1 | www.dragon1.comDragon1 Modelnr: 203NL / v1.0

Ik kom het nu al bij meerdere klanten tegen.Wie be-
taalt eigenlijk de architectuur? De meeste organisaties
die onder architectuur werken hebben een doelarchi-
tectuur (SOLL) opgesteld. Soms is er zelfs een rede-
lijke beschrijving van de bestaande architectuur (IST).
Volgens het boekje (nou ja, het TOGAF boekje is zo’n
800 pagina’s…) moet er een gapanalyse komen tussen
de IST en de SOLL architectuur en moeten er samen-
hangende projecten komen om de gaten op te vullen.
Tot zover de theorie.
In de praktijk zie ik echter dat de meeste IT projecten
helemaal geen gevolg zijn van bovengenoemde gap-
analyse, maar het gevolg zijn van business wensen;
vaak gebaseerd op wijzigingen in de markt of weten
regelgeving.Er moet vaak een applicatie worden aan-
gepast,soms zelfs meerdere.Er wordt een Projectstar-
tarchitectuur (PSA) geschreven waarin de wijziging
wordt beschreven.
Maar dan komt ineens de afdeling Architectuur om
de hoek kijken. De nieuwe of aangepaste applicatie
moet (ineens) gaan voldoen aan de doelarchitectuur
(SOLL). En daarvoor moet het project de applicatie
ineens op een nieuwe infrastructuur gaan bouwen of
moet de applicatie gebouwd worden met de nieuwste
versie van het ontwikkelframework. Dat vindt het pro-
ject niet leuk. Tenslotte is het grootste belang van het
project de doelstellingen van het project zelf te berei-
ken (en niet die van de architectuurafdeling) binnen
de gestelde tijd en binnen het gestelde budget. Maar
omdat de SOLL architectuur vaak is bekrachtigd door
hogerhand rest het project weinig dan het voldoen
aan de architectuur, waarmee de projectleider wordt
geconfronteerd met hogere kosten,meer doorlooptijd
en een hoger risico.
Natuurlijk is er begrip voor de projectleider. Ook is
er begrip voor de architectuurafdeling. Het is tenslot-
te in het belang van de hele organisatie dat de be-
schreven SOLL architectuur wordt gerealiseerd. Maar
er ontstaat wel ongewenst een spanningsveld. De ar-
chitecten kunnen weinig anders doen dan dreigen
– “als het project niet volgens de SOLL architectuur
wordt gebouwd, wordt de applicatie niet in productie
genomen” of “de SLA kosten zullen enorm zijn”. De
projectleider kan ook alleen dreigen – “als ik volgens
de SOLL architectuur moet opleveren, dan lever ik te
laat op en dat is slecht voor de business”. Uiteinde-
lijk moet het project opdraaien voor de kosten van het
implementeren van een architectuur waarvan hij de
kosten niet kan beïnvloeden. En de architecten kun-
nen de prachtigste SOLL
architecturen maken zon-
der op de kosten te letten.
Welke kant de strijd op-
gaat is onduidelijk. Dat
hangt af van wie de mees-
te macht heeft in de orga-
nisatie; de projectleider
of de architecten. Het pro-
ject loopt uit door nieuwe
eisen vanuit architectuur of er moet een uitzondering
worden gemaakt door de architecten voor dit speci-
fieke project (80% van de gevallen); als de uitzonde-
ring maar tijdelijk is (en zoals u weet:alles is tijdelijk).
In veel gevallen leidt bovenstaande belangenconflict
tot een escalatie die voor alle partijen onwenselijk is.
Architectuur wordt gezien als politieagent en project-
leiders als onbuigzame types die niet denken aan het
langetermijnbelang.
In mijn opinie is er een uitweg voor deze impasse. De
architectuurafdeling zou een jaarbudget moeten krij-
gen om de kosten van het bereiken van de SOLL ar-
chitectuur te bereiken. Dit budget kan worden ingezet
‘Wie betaalt de
architectuur?’
De SOLL architectuur is vaak
bekrachtigd door hogerhand waardoor
het project weinig rest dan te voldoen aan
de architectuur
Opinie
Reageren op deze opinie? Klik hier.

voor het uitvoeren van projecten die leiden richting
de SOLL architectuur. Dit kunnen projecten zijn die
op initiatief van de architectuurafdeling worden uitge-
voerd, of – nog beter – projecten die toch al liepen.
Bij bestaande projecten kan de architectuurafdeling
als sponsor optreden (geld en mensen) als men in het
project stappen zet richting de SOLL architectuur.
Zo helpen de architecten de zorgen van de project-
leider te verkleinen en stellen ze zich opbouwend op.
Bovendien moet architectuur het doen met het gestel-
de budget. Dat betekent een snel einde aan te ambi-
tieuze kostbare plannen. Bovendien kan architectuur
aantonen wat haar toegevoegde waarde is (want ze
krijgen het budget natuurlijk alleen als er een goede
business case ligt voor de SOLL architectuur). En als
een project niet wil meewerken, kan de architectuur-
afdeling een apart project starten om de rommel van
het betreffende project op te ruimen waarmee bij ho-
gerhand kan worden aangetoond dat werken onder
architectuur op termijn toch goedkoper is. Ten slotte
kunnen architecten nu eindelijk gaan werken met een
fatsoenlijke plateauplanning om te komen van IST
naar SOLL. Komt dat TOGAF boek toch nog van pas.
Iedereen blij lijkt mij.
Toch zie ik het nog niet gebeuren. Als ik mensen
spreek over dit idee is iedereen het met mij eens. Dat
zouden ze wel willen. Maar ook:“Dat is niet hoe het nu
werkt”en“We hopen over een paar jaar zover te zijn”.
Ik zeg:“Start nu en eindig de strijd!”
Sjaak Laan werkt bij Logica als Principal IT
Architect en heeft 22 jaar IT ervaring.
www.sjaaklaan.nl

Het hoger plaatsen van ICT op de zorgagenda is een be-
langrijke eerste stap om inzicht te krijgen in de kosten en
opbrengsten van ICT. Met het verkregen inzicht worden
de kosten beheersbaar en wordt het nemen van beleids-
en toekomstbestendige keuzes vereenvoudigd.
Dit tweede artikel is bedoeld om zorginstellingen (en
andere organisaties) te helpen met een aanpak om het
gewenste inzicht te verkrijgen. En niet eenmalig, maar
continu inzicht.
De Diamant
Elk bedrijf en organisatie heeft minstens een doelstelling.
Deze komt onder andere tot uiting in de visie en missie
(statement). Hiertoe is een primair proces ingericht, ge-
relateerd aan de core business van het bedrijf en organi-
satie om de doelstelling te realiseren. Ter ondersteuning
van het primaire proces is een aantal secundaire proces-
sen aanwezig. Deze zijn natuurlijk anders bij een zieken-
huis, een hogeschool, een gemeente of een productiebe-
drijf.
Al deze processen hebben één ding gemeen: behoefte
aan informatie en verwerking. ICT levert de (technische)
mogelijkheden om dit efficiënt, foutvrij, uniform en be-
trouwbaar te doen. Divisies, afdelingen en medewerkers
maken gebruik van ICT om hun bijdrage te leveren aan
de primaire- en ondersteunende processen.
Wat kenmerkt het ICT-gebruik? We onderscheiden hier
drie aspecten:
• Middelen - Dit omvat alles van pc’s,printers,servers,
netwerken tot applicaties, middleware, diensten, da-
tabases en dataopslag. Gelukkig hebben de gebrui-
kers alleen maar te maken met de functionaliteiten
van deze middelen. De beheerders zorgen voor een
zo goed mogelijke werking. Een overzicht van deze
middelen is opgenomen in de Configuratie Manage-
ment Database (CMDB).
• Hoeveelheid - Ieder beschikbaar middel wordt in-
gezet met een bepaalde hoeveelheid. Dat kan varië-
ren van nul (ongebruikte licenties bijvoorbeeld) tot
vele duizenden (PC’s). Sommige middelen kunnen
gedeeld worden en hebben een maximale capaci-
teit. Het proces Capacity Management bewaakt de
gebruikte, benodigde en toekomstige capaciteit.
• Kwaliteit - Alle diensten worden geleverd met een
zekere kwaliteit. Die is deels inherent aan de aard
In deel 1 van ‘ICT kostenbeheersing met visie’ hebben we al gezien dat KPMG de alarmbel heeft ge-
luid in de Zorg. Dit heeft ze niet zonder reden gedaan. Bij de presentatie van het boek ‘IT in de Zorg’
uitten zij hun zorgen over het gebrek aan inzicht in ICT-kosten en de gevolgen hiervan voor de zorgin-
stellingen. Om dit te veranderen moet ICT hoger op de zorgagenda worden geplaatst. In dit tweede
deel gaan we in op de aanpak om dit inzicht daadwerkelijk te verkrijgen en vast te houden.
Kurt de Koning en Tom Louwrier
Alarmbel in de Zorg
(en daarbuiten) terecht!
Kostenbeheersing
ICT kostenbeheersing met visie - Deel 2:Verkrijgen van inzicht
Het hoger plaatsen van ICT
op de zorgagenda is een
eerste stap om inzicht te
krijgen in de ICT-kosten

van het middel en wordt deels bepaald door de ma-
nier waarop het wordt ingezet en beheerd. Dit is het
gebied waar architectuur, implementatie en beheer
elkaar ontmoeten. Quality Management zorgt ervoor
dat de kwaliteit constant is en blijvend voldoet aan de
afgesproken verwachtingen.
Met deze drie aspecten (Middelen, Hoeveelheid en Kwa-
liteit) is de inzet van ICT ten behoeve van de bedrijfspro-
cessen beschreven. We moeten echter ook weten welke
kosten hieraan gebonden zijn.
Uit de aard van het Middel en de Kwaliteit volgt de stuk-
sprijs. Uit stuksprijs en hoeveelheid volgen Kosten (Eco-
nomie 2: K= P x Q). Het totaal van deze kosten inclusief
de verborgen kosten(!), is de Total Cost of Ownership
(TCO).
Het aanschaffen van de middelen en diensten ten be-
hoeve van de ICT-diensten aan de Core Business wordt
uitgevoerd binnen Contracting (contractering).
Het toewijzen (en doorbelasten) van deze kosten aan de
gebruikersgroepen in de organisatie is de taak van Char-
ging (doorbelasting).
Als een organisatie in staat is om de relaties te leggen tus-
sen ICT-gebruik en totale kosten,dan is die organisatie In
Control. Er kan dan weloverwogen worden gestuurd op
een juiste balans tussen middelen, hoeveelheid, kwaliteit
en kosten.
In figuur 1 is het hiervoor beschreven model schematisch
weergegeven.
De Kubus
De Diamant laat zien hoe de relatie is tussen het ICT-ge-
bruik en de kosten die dit met zich meebrengt. Hierbij
is het uitgangspunt dat zaken als ICT-middelen overzicht,
toewijzing, gebruik en kwaliteit bekend zijn. De com-
plexiteit van het ICT-landschap is de oorzaak dat dit bij
veel organisaties een hele opgave is.
Binnen organisaties is alle data over inzet van middelen,
bijbehorende kosten en kwaliteit wel aanwezig. Helaas
ontbreekt het overzicht nog door de grote hoeveelheid
kostendragers, kostensoorten, kostenplaatsen etc. Ieder-
een die wel eens een begroting heeft geschreven (ex-
ploitatie, investering en projecten) weet hoe lastig en
tijdrovend dit kan zijn. Niet voor niets is er een oerwoud
aan oplossingen op de markt voor management informa-
tie, rapportages en cockpits.
Het is daarom niet verwonderlijk dat organisaties grote
moeite hebben om in control te zijn over hun ICT-kos-
ten aangezien het vaststellen en interpreteren van de kos-
ten op zich een enorme inspanning met zich meebrengt.
Om dit probleem op te lossen introduceren we de Kubus.
Een model om kosten 3D(!) vast te leggen.Hierin gaan we
een stap verder dan de huidige kostenplaats/kostensoort
registratie.
Figuur 1: Het ‘Diamant’-model
InControl
Kosten
€
Behoefte
ICT-gebruik
ICT-middelen
Configuration Mgt.
Hoeveelheid
Capacity Mgt.
Kwaliteit
Quality Mgt.
Doorbelasting
Demand
Contractering
Supply
Core Business
Primaire en ondersteunende processen

Eerste dimensie: Doel
Kijkend naar ICT dan moet het belang van de organisatie
voorop staan. ICT is geen doel op zich maar ondersteu-
nend. Daarom is de eerste as die van het Doel. Deze as
geeft aan waar alle systemen en middelen voor ingezet
worden. Het draait hier simpelweg om de vraag: ’Waar-
voor maken we deze kosten?’
We delen deze as op in drie categorieën:
1. Kantoorsystemen (KS) - Dit zijn de pc’s, laptops en
printers, maar ook de back-end systemen voor mail,
internet, file shares etc. Dit is commodity, eenduidig
en voorspelbaar.
2. Bedrijfssystemen (BS) - Deze categorie omvat alle
systemen die rechtstreeks de unieke bedrijfsproces-
sen ondersteunen.Denk aan een ERP,facturatiestraat,
een EPD, GIS, basisadministratie etc. Deze systemen
zijn bedrijfsspecifiek qua inrichting en er zit door-
gaans een flink stuk maatwerk in. Daarom is dit een
kostbare categorie.
3. Besturing (BE) -Voor het hebben van een ICT-omge-
ving moet ook het nodige aan management en be-
heer worden ingericht. Dit valt in de categorie Bestu-
ring. Let wel: de (technisch) beheerders worden toe-
gewezen aan KS en BS, dat zijn directe kosten. Bestu-
ring is dus vooral de overhead zoals de Service Desk,
Service Management, projecten, stafafdelingen etc.
Tweede dimensie: Middelen
De tweede as van de Kubus is die van de Middelen.Tech-
nische middelen die worden ingezet om de diensten aan
de business te leveren.‘Waar geven we het geld aan uit?’
Ook deze as delen we op in drie categorieën:
1. Hardware - Fysieke middelen zoals servers, PC’s,
netwerk, switches, laptops, maar ook de faciliteiten
van het rekencentrum waar de middelen zijn opge-
steld.
2. Systeemsoftware - Een technische softwarelaag die
als platform zit tussen de hardware en de applicatie
met zijn specifieke functionaliteiten.Het is noodzake-
lijk, maar de gebruikers zullen er niet rechtstreeks
mee van doen hebben. Pas bij de applicatie-software
wordt het voor de organisatie echt interessant.
3. Applicatiesoftware - Deze software biedt de functi-
onaliteiten die de gebruikers nodig hebben voor het
uitvoeren van hun werkzaamheden ten behoeve van
de bedrijfsprocessen.
Derde dimensie: Geld
Ten slotte komen we bij de derde as en dat is natuurlijk
die van het Geld.Hier beantwoorden we de vraag:‘Welke
kosten worden gemaakt?’
Ook hier onderscheiden we drie categorieën:
1. Kapitaallasten - Eenmalige kosten. Bijvoorbeeld
Figuur 2: De Kubus
Middelen
Doel
G
eld
Applicatiesoftware
Systeemsoftware
Hardware
K
antoorsystem
en
Personeelskosten
B
edrijfssystem
en
B
esturing
O
perationele
kosten
Kapitaallasten

de aanschaf van een server waar een eenmalige fac-
tuur tegenover staat, projectkosten of inrichtingskos-
ten.
2. Operationele kosten - Terugkerende kosten van
bijvoorbeeld contracten van afgenomen diensten,
lease, licenties en support.
3. Loonkosten - Kosten van eigen medewerkers, maar
ook van externe inhuur.Een bijzondere variant op de
operationele kosten.
Hiermee is de Kubus af. Er staan hier nu 3 x 3 x 3 = 27
blokken waarmee we kosten kunnen duiden.
Met deze Kubus beschikken we over een enorm sterk
hulpmiddel om de kosten van ICT te rubriceren. Het is
nu mogelijk om alle facturen, begrotingen, contracten, fy-
sieke middelen vlot te ontrafelen en een plek te geven.
• Aanschaf van 150 pc’s? Dat is: Kantoorsystemen,
Hardware, Kapitaallasten.
• Jaarlijkse licentiekosten op applicatie X? Bedrijfssys-
temen, Applicaties, Operationele kosten.
• Afdeling met functioneel beheerders? Bedrijfssys-
temen, Applicatiesoft-
ware, Loonkosten.
Zodra alle kosten in de Ku-
bus zijn ondergebracht, is
een overzichtelijk beeld
ontstaan van de kosten
(TCO) en kunnen diverse
analyses worden gemaakt.
• Hoeveel % zit in Ka-
pitaallasten? Hoeveel in loonkosten van het tech-
nisch beheer? Als het eerste een laag getal is, en het
tweede is hoog, dan is een kwaliteitsissue zeer waar-
schijnlijk. Verouderde infrastructuur lijkt goedkoop,
maar de kwaliteit loopt terug en er moeten veelvul-
dig incidenten worden verholpen.
• Hoge operationele kosten, lage loonkosten en hoog
totaalbedrag? Wijst op een ongunstige outsourcing.
• Lage bedrijfssystemen kosten en hoog functioneel-
en technisch beheer, dan zijn de applicaties van on-
voldoende kwaliteit, en weinig flexibel. Penny wise,
Pound foolish.
De Stack
We hebben hiermee een beeld van de totale kosten
(TCO). Door nu relaties te leggen tussen kosten en het
gebruik op individueel of afdelingsniveau, ontstaat Grip
en Control. Gebruikers nemen functionaliteit en diensten
af en deze openbaren zich in verschillende vormen:
• Werkplekken met daarop kantoorautomatisering in-
clusief e-mail, teksteditor, internet;
• Randapparatuur voor printen, scannen en faxen;
• Service Desk;
• Toegang tot toepassing applicaties;
• Vaste en mobiele telefonie.
Genoemde voorbeelden bevinden zich in het vlak wat
overeenkomt met de voorkant van de Kubus. Doel/Mid-
delen en wel op de bovenste laag.Het zijn de diensten uit
de Producten en Diensten Catalogus (PDC).
De kosten van deze functionaliteiten komen tot stand
door de kosten van alle onderliggende blokken te tota-
liseren. Deze stapel van blokken noemen we de Stack.
Hierbij moet opgemerkt worden dat de onderste blokken
veelal gedeeld worden over meerdere functionaliteiten:
• In het rekencentrum staan meerdere servers, main-
frames,switches etc.De kosten van het rekencentrum
worden dan hierover toegewezen via een verdeel-
sleutel.
• Op de servers draaien meerdere applicaties. De kos-
ten van de server worden weer toegewezen via een
verdeelsleutel over de applicaties.
• Etc. op deze wijze wordt de prijs van alle applicaties
en diensten vastgesteld.
Per dienst of functionaliteit wordt vastgesteld welke me-
dewerkers hier gebruik van maken. Het resultaat is dat
de prijs per dienst of functionaliteit wordt uitgedrukt in
euro’s per medewerker per periode (maand, kwartaal,
jaar). En door een juiste groepering te maken van mede-
werkers kan een bedrijf nu de exacte ICT-kosten bepalen
naar afdeling, proces en/of product.
Hiermee is een volledig inzicht ontstaan van de kosten
per dienst per gebruiker.De kosten zijn nu transparant en
te gebruiken als stuurmiddel bij het nemen van besluiten.
Samenvatting
Laten we voorop stellen dat het verkrijgen van inzicht in
de totale ICT-uitgaven een intensief traject is waarbij de
onderste steen boven moet komen. Het met moeite ver-
kregen inzicht moet ook behouden en actueel blijven.
Ook dit vergt een blijvende inspanning. Gelukkig is het
net zo als met een tuin waar een tijd geen onderhoud aan
is gepleegd. De eerste keer dat er doorheen wordt ge-
gaan, zal een enorme hoeveelheid tuinafval, rot en dood
hout, bladeren en onkruid opleveren. De tweede keer
is het al een stuk minder en daarna is het een kwestie
van bijhouden. Uiteindelijk blijft er een nette tuin over
Hoeveel % zit in kapitaallasten? Hoeveel in
loonkosten van het technisch beheer? Als het
eerste getal laag is, en het tweede hoog, dan
is een kwaliteitsissue zeer waarschijnlijk

waar het een genot is om in te zitten en van te genieten.
De Diamant geeft de essentie weer van Inzicht en Con-
trol:de koppeling tussen gebruik en kosten,uitgedrukt in
euro’s per gebruiker per periode.
Om dit te kunnen bepalen gebruiken we de Kubus om
de verschillende kostencategorieën in onder te brengen.
Vanuit de Kubus vindt een toewijzing plaats van dienst en
functionaliteit die gebruikers nodig hebben bij hun werk-
zaamheden.
In de Stack worden de onderliggende kosten getotali-
seerd zodat bepaald wordt wat de kosten zijn per afge-
nomen dienst en functionaliteit. Hiermee komen we weer
terug bij de essentie van de Diamant:Control door inzicht
in euro’s per medewerker per periode.
Deel 3:Toepassing van transparantie en
inzicht
In het derde deel zal verder worden ingegaan hoe het
verkregen inzicht helpt bij het inrichten van een ko-
stenefficiënt werkende ICT-organisatie. Wat kunnen we
doen met dit inzicht en waar zitten de knoppen waar we
aan kunnen draaien om te komen tot optimaal gebruik
van ICT.Optimaal in de zin van effectief en efficiënt tegen
gerechtvaardigde kosten en de juiste kwaliteit.
De effecten van uitfasering, consolidatie, samenvoeging,
migratie, schaalvergroting of juist krimp etc. kunnen
nauwkeurig worden doorgerekend en voorspeld. Ook
gaan we in op de mogelijkheid van doorbelasting van
ICT kosten aan de organisatie. Doen of juist niet!
Kurt de Koning is medeoprichter en consul-
tant binnen Ratio Consultants.
www.ratioconsultants.nl
Tom Louwrier is medeoprichter en consultant
binnen Ratio Consultants.
www.ratioconsultants.nl
De Diamant:
Control door inzicht in
euro’s per medewerker
per periode
Uw vacature
gratis op de
XR website?
XR Magazine biedt een overzicht
van vacatures voor architecten, ont-
wikkelaars, managers en andere
professionals binnen diverse secto-
ren. U kunt zelf gratis vacatures plaat-
sen op de XR website. Kijk voor meer
informatie op:
www.xr-magazine.nl/vacatures

Tegenwoordig is Agile werken een veel voorkomende
projectaanpak. Scrum is één van de Agile-methoden
en voldoet aan veel actuele behoeften: korte feed-
backcycli, directe klantbemoeienis en -interactie.
Daarnaast kent deze methode ook een simpele rolver-
deling, waarin drie teamrollen zijn gedefinieerd: de
scrummaster, de product owner en het teamlid. Een
architectenrol ontbreekt in dit rijtje. Opvallend, want
uit de resultaten van de onlangs uitgevoerde Agile
Survey 2011 blijkt dat 61 procent van alle architecten
direct in een scrumteam werken of in een klein aantal
scrumteams meedraaien. Wat is dan nog het verschil
tussen een architect en een teamlid? Een scrumteam
is natuurlijk self-organising en multidisciplinair. Een
architect lijkt daardoor
niet langer noodzakelijk,
maar is dat daadwerkelijk
zo?
Over het algemeen heeft
een Scrumteam samen
met de product owner een
compromisloze focus op
een systeem. De product
owner bepaalt wat er op
de product backlog van het systeem komt en wat de
volgorde van de product backlog items is. Na iedere
sprint levert het team software op die productieklaar
is. Maar hoe vaak komt het voor dat systemen in pro-
ductie in isolatie draaien? Systemen zijn onderdeel
van een keten en afhankelijk van andere systemen of
van organisatorische zaken, voordat zij daadwerkelijk
door gebruikers kunnen worden gebruikt. Nadat een
Scrumteam software oplevert,moet het nog in een gro-
tere context worden gevalideerd. Om deze validatie
succesvol te laten zijn, moet ervoor worden gezorgd
dat de product backlog items technisch en organisato-
risch in die context passen. De items moeten dan ook
nog eens op het juiste moment worden geleverd.Dit is
vanzelfsprekend de verantwoordelijkheid van de pro-
duct owner: hij moet er namelijk voor zorgen dat de
product backlog items in ‘ready’ status komen en hij
is het enige aanspreekpunt voor het team als het gaat
om wat het team moet gaan doen.
Maar werkt dit in de praktijk ook echt? Laten we eens
kijken wat voor soort vragen een product owner dan
allemaal beantwoord moet krijgen. Binnen welk land-
schap gaat het systeem draaien en welke eisen stelt
dit aan integratietechnologie, verwerkingssnelheid,
schaalbaarheid en beveiliging? Wat zijn de techni-
sche interfaces met andere systemen? Waar wordt het
systeem gehost en welke eisen worden door functio-
neel en operationeel beheer gesteld? Welke proces-
sen moeten in de organisatie ingeregeld zijn om het
systeem te gebruiken? Zijn er juridische eisen waar-
aan voldaan moet worden? Hoe kunnen we effectief
valideren dat het systeem in de keten goed werkt?
Allemaal vragen die beantwoord moeten zijn, voordat
gebruikers daadwerkelijk
gebruik kunnen maken
van de nieuwe functiona-
liteit van een systeem in
een keten. Pas als deze
vragen beantwoord zijn,
kunnen de product back-
log items ‘ready’ gemaakt
worden, kan het team ze
effectief realiseren en kan
de ontwikkelde functionaliteit ook snel in de handen
van gebruikers komen en daadwerkelijk waarde gaan
toevoegen voor onze klant.
Als we als IT-organisatie de gebruiker willen laten
profiteren van een snel opgeleverde functionaliteit,
dan moeten we aandacht besteden aan de samenhang
tussen projecten en teams, de non-functionele eigen-
schappen van het systeem dat we ontwikkelen en de
samenhang van ons systeem met het reeds bestaande
landschap en de doelinfrastructuur. Hiermee komt de
beginvraag weer terug. Welke rol is er eigenlijk ver-
antwoordelijk voor deze aandachtsgebieden? Mis-
schien is de architect dan toch echt onmisbaar.
Sander van den Berg is Senior Consultant
bij Xebia.
www.xebia.com
Opinie
‘Scrum zonder architecten:
(g)een ideale wereld?’
Scrum voldoet aan veel
actuele behoeften zoals
korte feedbackcycli en
directe klantbemoeienis
31januari 2012 XR MagazineReageren op deze opinie? Klik hier.

Iedereen komt het tegen: projecten die ver
over het budget heen gaan, veel te laat wor-
den opgeleverd en dan ook nog zonder dat de
gewenste functionaliteit wordt gerealiseerd.
Waar komt dat door? In het eerste artikel in
deze reeks hebben we het al gehad over de
Big Hitters voor succesvolle projecten. Het
lijkt vanzelfsprekend, maar toch is het de oor-
zaak van veel problemen in projecten: een
onduidelijk of verkeerd doel. Hierdoor ont-
staat het risico dat de requirements, de eisen
aan de oplossing van het probleem,niet op de
juiste of sterk wijzigende uitgangspunten zijn
gebaseerd. Je realiseert dan met succes de
verkeerde verandering, of de realisatie komt
nooit af. Heb je daarmee je doel bereikt?
Dit artikel gaat over succes: het verzilveren
van kansen, oplossen van problemen en be-
halen van de juiste doelen.
Vind de kans
De behoefte tot verandering ontstaat wanneer een pro-
bleem of kans wordt ontdekt. De opdrachtgever is de
persoon die de opdracht moet geven om het probleem
op te lossen of de kans te verzilveren. De opdracht wordt
gegeven aan een projectmanager of in het ideale geval
aan een business analist voor een vooronderzoek.
Het is nu de kunst om de juiste doelstelling voor het pro-
ject te formuleren. Alleen dan wordt een project een suc-
ces. Maar dat is eenvoudiger gezegd dan gedaan.Welke
problemen kom je zoal tegen?
Allereerst wordt er in de praktijk onvoldoende tijd be-
steed aan de analyse van het probleem. Wat moeten we
Requirements Engineering
Successen in een
project…
JanWillem Knop
…bereik je doelen met requirements!
Dit artikel is deel 3 in een reeks van vijf artikelen over succesvol requirements engineering. In het vo-
rige deel hebben we gezien hoe je complexiteit en pragmatiek op elkaar kan afstemmen om require-
ments succesvol in te zetten. Door het requirements engineering proces goed te organiseren en prag-
matisch in te steken kan je veel knelpunten,die het succes van requirements bedreigen,voorkomen.In
dit artikel besteden we aandacht aan een volgend aandachtspunt, namelijk “start met het probleem”.
Figuur 1: Problemen bij requirements engineering

de overige betrokkenen bij de verandering, bestaat het
risico dat de oplossing van de opdrachtgever klakkeloos
uitgevoerd wordt. Hierdoor krijgt de opdrachtgever niet
de oplossing die hij nodig heeft, maar de oplossing die
hij wil. De kans is groot dat de doelstellingen hier niet
mee bereikt worden. Zo laat ook het voorbeeld zien met
de auto (zie kader ‘Doel en middel’), waarbij een alter-
natieve oplossing beter bijdraagt aan het succes van het
project dan het initieel gestelde doel.
De goede opdrachtgever… is het halve werk
Een ander veel voorkomend probleem is dat de op-
drachtgever niet altijd degene is die eigenaar is van het
probleem of verantwoordelijk is voor het verzilveren van
de kans.Zijn belang bij het probleem is daardoor minder
groot als van diegene die het probleem daadwerkelijk
dagelijks ervaart. Hierdoor ontstaat de kans dat het ei-
genlijke probleem niet binnen het project geadresseerd
wordt. Neem het voorbeeld ‘Klachten van klanten’.
nu eigenlijk precies oplossen?
Deze ‘haast’ zit in de aard van
de mens. Wij zijn van nature
geneigd om meteen met oplos-
singen aan te komen voordat
we het probleem volledig door-
grond hebben.
Het is dus belangrijk om niet te
starten met een project voordat
de kans of het probleem en de
bijbehorende doelstelling en
oplossingsrichting helder is. Ga
daarom bij je belanghebben-
denanalyse ook op zoek naar
degenen die verantwoordelijk
zijn, die probleemeigenaar zijn,
of die het meest geraakt worden
door het probleem. Deze per-
sonen moeten vervolgens ook
als belanghebbende bij requi-
rements engineering worden
betrokken.
Daarnaast geeft de opdrachtge-
ver bij het verstrekken van de
opdracht niet altijd goed weer
wat de kans of zijn probleem
precies is. Daar zijn verschillende oorzaken voor. Om te
beginnen is er natuurlijk het algemene probleem van
communicatie. Mensen die betrokken zijn in een pro-
ject begrijpen elkaar niet altijd even goed. Zeker in de
software industrie, waar opdrachtgevers aan de business
kant en opdrachtnemers in de IT (afdeling of leverancier)
vaak verschillende werelden vertegenwoordigen is dit
een probleem.
Opdrachtgevers hebben bovendien vaak de neiging om
in oplossingen te denken. Maar
hoe komt het nu dat het voor
een opdrachtgever makkelijker
is om oplossingen te formuleren
dan doelstellingen? Dit wordt
met name veroorzaakt doordat
doelen abstracter zijn dan op-
lossingen. Een auto is veel tast-
baarder dan het afleggen van
de afstand tussen twee punten
door 20 personen. Vandaar dat de opdrachtgever door
de requirements engineer geholpen kan worden bij het
formuleren van juiste en volledige doelstellingen.
Zoals we hebben kunnen zien geven opdrachtgevers in
de praktijk vaak opdracht voor het realiseren van een be-
paalde oplossing, in plaats van een doelstelling. Het be-
denken van de oplossing is echter de verantwoordelijk-
heid van domeinexperts. Dit zijn de belanghebbenden.
Omdat de opdrachtgever vaak hoger in hiërarchie is dan
Figuur 2: Aandachtspunten voor succesvol requirements engineering
Albert Einstein:“If I had one hour to save
the world I would spend fifty-five
minutes defining the problem and only
five minutes finding the solution.”
Organiseer
je proces
Leg require-
ments vast
Start met
het probleem
Wees
pragmatisch
Betrek de
business
Succesvol
requirements
engineering

Kritisch doorvragen zorgt ervoor dat je het probleem
achter het symptoom of de oplossing leert kennen. En
daarmee ook de eigenaar van het echte probleem. Je
loopt echter ook een gevaar wanneer je alsmaar door
blijft vragen naar de bron van het probleem en naar re-
quirements. Want uiteindelijk wil je naar een oplossing
toe. En sommige symptomen vragen om een onmiddel-
lijke, misschien niet-optimale oplossing. Je moet daarom
in de zoektocht naar het achterliggende probleem ook
weten wanneer je moet stoppen met het stellen van de
‘waarom’-vraag. Ieder antwoord dat een belanghebben-
de geeft op die vraag moet worden bekeken aan de hand
van een aantal criteria:
• Geeft de belanghebbende de diepere oorzaak of al-
leen een andere vorm van hetzelfde probleem?
• Wanneer je het probleem achter het probleem vindt
kan dat laatste (de bron) groter zijn dan het oorspron-
kelijke probleem. Vraag je voortdurend af: “Weegt
het oplossen van het bronprobleem echt op tegen het
bestrijden van het symptoom?”
Op enig moment moet je dus kunnen vaststellen dat het
stellen van de ‘waarom’-vraag niets meer oplevert. Dan
ben je aangeland bij het probleem dat je kunt gaan aan-
pakken. Daarmee weet je ook wie de opdrachtgever zou
moeten zijn. Wanneer dat een andere is dan nu in een
stuurgroep zit, dan moet je dus om verandering vragen.
Een requirements engineer moet dus stevig in zijn schoe-
nen staan.Want het zal niet altijd voor iedereen duidelijk
zijn dat de investering die je vroegtijdig in een project
wilt doen om doelstellingen helder te formuleren zichzelf
gaat terugverdienen.
Van problemen naar requirements (en
oplossingen)
Samenvattend kunnen we dus opmerken dat het belang-
rijk is om de probleemeigenaren vroegtijdig te betrek-
ken bij requirements engineering en tot de kern van het
eigenlijke probleem te komen, voordat de volgende stap
op de weg genomen wordt: het formuleren van de doel-
stelling.
Bij een verzekeraar wil de manager van de polisad-
ministratie de doorlooptijd van het afsluiten van een
(zorg)verzekeringspolis verlagen. Reden daarvoor is
een richtlijn dat een polis uiterlijk tien dagen na de
ontvangst van de aanvraag bij de klant moet liggen.
Vooronderzoek had uitgewezen dat die norm niet al-
tijd gehaald werd en dus werd door de manager een
project gestart om de tiendagentermijn weer structu-
reel te maken.
Uit de probleemanalyse bleek echter dat er minimaal
twee belangrijkere aanleidingen zijn voor het ver-
korten van de doorlooptijd van een verzekeringsaan-
vraag:
• In het huidige internettijdperk zijn klanten ge-
wend om direct geholpen te worden. Een klant
maakt geen onderscheid tussen zorgverzekering
of een autoverzekering. Die laatste is binnen en-
kele minuten af te sluiten. Een doorlooptijd van
twee dagen wordt gezien als het maximum.
• In het call center worden te veel klachten ontvan-
gen over het te laat leveren van de polis. Klanten
worden ongeduldig en bellen dan op om te vra-
gen waar de polis blijft. Dit soort telefoontjes is
voor de verzekeraar zeer duur. De eerder gestel-
de limiet is dus belangrijk om de verwachtingen
helder te krijgen. Vanuit bezuinigingsoogpunt
heeft het call center al een taakstelling voor vol-
gend jaar zodat flink op de FTE’s moet worden
bezuinigd.
Klachten van klanten
De juiste doelstelling is hier dus belangrijk. De ma-
nager van de polisadministratie draagt echter niet de
verantwoordelijkheid hiervoor en wil hieraan het bud-
get niet besteden.
Dat probleem had kunnen worden opgelost door een
andere opdrachtgever aan te stellen:
• de manager van het call center,die al bij voorbaat
gekort was op het aantal FTE’s in verband met de
beoogde verlaging van het aantal telefoonge-
sprekken.Die had er dus veel meer belang bij dat
de telefoontjes echt niet meer zouden komen;
• of de marketeer, die direct liet weten dat markt-
onderzoeken hebben duidelijk gemaakt dat in het
huidige internettijdperk klanten voor het aanleve-
ren van een polis een termijn van maximaal twee
dagen nog acceptabel vinden.
Gevolg: een jaar later was de klanttevredenheid ge-
daald, omdat de wachttijden bij het call center langer
waren geworden. De doorlooptijd was nu wel binnen
de (oude) richtlijn maar doordat die niet voldeed aan
de verwachting van de klant, kwamen er nog steeds
veel telefoontjes. Die moesten echter door minder
mensen worden afgehandeld…

Het gebrek aan doelstellingen is vaak te wijten aan de
opdrachtgever die vaak niet goed weet te verwoorden
wat de opdracht voor het project nu eigenlijk is. In de
praktijk worden regelmatig doelen en oplossingen met
elkaar verward. Tijdens onze requirements engineering
trainingen geven we vaak de case ‘Doel en middel’.
Zoek de oplossing binnen de grenzen
Requirements opstellen is uiteraard geen doel op zich,
ook al heb je het doel van het product goed voor ogen.
Uiteindelijk willen we toch maar een ding: een oplossing
voor het probleem. Daarbij helpen goede requirements
met de juiste doelstelling uiteraard wel. Want require-
ments geven de grenzen aan waarbinnen alternatieve
oplossingen gezocht kunnen worden. Als een opdracht-
gever de opdracht geeft om een oplossing te bouwen
waarmee de afstand tussen twee punten kan worden
overbrugd, en de belanghebbenden geven aan dat er
20 personen moeten kunnen worden vervoerd,dan zijn
binnen de grenzen van deze twee requirements meer-
dere oplossingen mogelijk, zoals een autobus, twintig
fietsen, vijf 4-persoons auto’s, lopen, openbaar vervoer
et cetera.
Naarmate er meer requirements van andere belang-
hebbenden worden geïnventariseerd, zal het aantal mo-
gelijke oplossingen verder afnemen. Als een belang-
hebbende bijvoorbeeld het requirement toevoegt: ‘het
vervoermiddel dient met een snelheid van ten minste
120 km per uur personen te kunnen vervoeren’, dan valt
de fiets als oplossing af. Wel is het altijd verstandig na
te gaan wat het achterliggende doel van dit requirement
is en hoe noodzakelijk die is. Is het niet echt nodig, dan
kunnen ook andere oplossingen,dus ook de fiets,weer in
beeld komen.
Op deze manier is het starten bij het doel zoals we eerder
betoogden de leidraad geworden bij het vinden van de
juiste oplossing. Door problemen goed te analyseren, de
juiste en volledige doelstellingen te formuleren, kom je
dus tot de juiste oplossing voor je eigenlijke probleem.
Wat zijn de gevolgen van ‘start met het doel’:
bijsturen i.p.v. koers houden
Oplossing en probleem uit elkaar houden is dus voor de
requirements engineer een belangrijke activiteit. Door
het doel helder en expliciet te beschrijven krijgen we de
informatie die we nodig hebben voor het sturen van een
project. Doelen hebben we nodig om het doel van je pro-
ject te halen. Maar ook omdat je tijdens een project er-
achter zult komen dat de wereld om het project heen aan
het veranderen is.Ieder project krijgt daarmee te maken.
Ga voor jezelf maar eens na: geen enkel projectplan of
business case, de startdocumenten van een project vol-
gens PRINCE2™, wordt in de praktijk exact zo uitgevoerd
als aan het begin van het project bedacht is. Als het doel
Figuur 3: De project manager stuurt bij, maar houdt, ook
bij zwaar weer, zijn doel voor ogen
van het project niet helder gedefinieerd is, zal het pro-
ject zich wel aanpassen aan de veranderingen eromheen,
maar dan rijst de vraag of het project bereikt wat het zou
moeten bereiken.Door een doel te hebben en dit continu
voor ogen te houden wordt de projectmanager in staat
gesteld om het project op koers te houden richting het
doel.
Doel en middel
Een opdrachtgever geeft de opdracht om een auto
te bouwen. Het budget dat de deelnemers krijgen
is € 20.000. De deelnemers staan voor de keuze
om vragen te stellen over de eisen die aan de auto
gesteld worden, of op zoek te gaan naar het pro-
bleem achter het probleem tot aan het doel dat
de opdrachtgever wil bereiken. Het team dat de
juiste vragen stelt komt er achter dat er bepaalde
belanghebbenden eisen hebben die conflicteren
met de voorgestelde oplossing. Bijvoorbeeld dat
de auto 20 personen tegelijkertijd moet kunnen
vervoeren. Het team ontdekt dat er misschien wel
betere oplossingen zijn om het doel te bereiken:
het overbruggen van de afstand tussen twee pun-
ten door 20 personen. Een autobus realiseren lukt
niet binnen het gestelde budget, het lijkt daarmee
een onuitvoerbare opdracht. De oplossing om met
de trein te gaan, zat niet in de originele opdracht,
maar kan wel snel en goedkoop gerealiseerd wor-
den.

XR Magazine januari 2012

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (14)

Ähnlich wie XR Magazine januari 2012

Ähnlich wie XR Magazine januari 2012 (19)

Mehr von RES Software Nederland

Mehr von RES Software Nederland (19)

XR Magazine januari 2012