XR Magazine januari 2012

SOA en EDA - een sterke mix

SOA voor gevorderden

Business & ICT-trends 2012

TOGAF - SABSA integratieHet 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

http://www.eam-congres.nl

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

http://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

Weersvoorspelling 2012: 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? 31Poster: 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

Weersvoorspelling 2012: 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.

http://www.xr-magazine.nl/node/1257

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

Volw

asse

nhei

d

12

34

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 andMashups

SubsidizedApplications

Googleplex

Web Platforms

Global-Class

Consumer Application

SaaS

Data CenterPressures

Virtualization

Grid

Real-TimeInfrastructure

ManagementDiscipline

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

Informationand Browser UI

Services andWebAPI/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 1Consolidation

Step 2Virtualization

Step 3Automation

Step 4Utility

Step 5Cloud

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 StorageConsolidation

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 slotAl 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: [email protected]

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



http://www.dragon1.com

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

: ap

ple

r /

Shut

ters

tock

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

materialising

Likelihood ofweaknessexploited

Assetvalue

Negativeimpactvalue

Threats

Loss event

Likelihood ofopportunity

materialising

Likelihood ofstrengthexploited

%

Assetvalue

Positiveimpactvalue

€

Opportunities

Beneficial event

Assetsat risk

Risk contextNegativeoutcomes

Positiveoutcomes

% €

lingen gelden als kritische succesfactoren om optimaal te kunnen inspelen op mogelijke gebeurtenissen als gevolg 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

andPrinciples

A.Architecture

Vision

B.Business

Architecture

G.Implementation

Governance

H.Architecture

ChangeManagement

C.Information

SystemsArchitectures

D.TechnologyArchitecture

F.MigrationPlanning

E.Opportunities

andSolutions

RequirementsManagement

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, Practicesand Procedures

Security Standards

Security Management

Security Audit

Security Awareness

Security ArchitectureGovernance

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



Attribuut

Attribuut

Attribuut

Prestatiedoel

Prestatiedoel

Prestatiedoel

Prestatiedoel

Prestatiedoel

Prestatiedoel

Beheersdoelen

Beheersdoelen

Beheersdoelen

Beheersdoelen

Beheersdoelen

Beheersdoelen

Ris

icoa

naly

se

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

https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=12449

http://twitter.com/xrmagazine

http://www.linkedin.com/groups/XR-Magazine-Enterprise-Architectuur-platform-2981600?homeNewMember=&gid=2981600&trk=&ut=3lf9GQUHTEF541

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 gevorderdenPraktische 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.0EDA (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

: iri

n-k

/ Sh

utte

rsto

ck.c

omFo

to: i

rin-

k /

Shut

ters

tock

.com

Grens tussen privé en werk vervaagtDe 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 snelheidGebruikers 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-beheerHoe 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 ‘Bring Your 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 applicatiesDe 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

: top

selle

r /

Shut

ters

tock

.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 centraalHet 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 noodzakelijkOmdat 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 isFo

to: D

aboo

st /

Shu

tter

stoc

k.co

m



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 - Change View


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

Sec

urity

Arc

hite

ctuu

r

Besturingsarchitectuur

Dienst architectuur

Product architectuur

Proces architectuur


Technische architectuur

Informatiearchitectuur



Sec

urity

Arc

hite

ctuu

r


Netwerk architectuur

Storage architectuur

Printing architectuur

Applicatie architectuur

Data architectuur

Integratie architectuur

Dienst architectuur


Proces architectuur




Sec

urity

Arc

hite

ctuu

r


Informatiearchitectuur Applicatie

architectuur Data

architectuur Integratie

architectuur

Dienst architectuur


Proces architectuur



Informatiearchitectuur



Sec

urity

Arc

hite

ctuu

r


Netwerk architectuur

Storage architectuur

Printing architectuur

Applicatie architectuur

Data architectuur

Integratie architectuur

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

Informatiearchitectuur Applicatie

architectuur Data

architectuur Integratie

architectuur




AS-IS (Plateau 0) TO-BE (Plateau 5) over 3 jaar Envision (Ideale wereld) over 10 jaar

Technische architectuur Technische 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.com Dragon1 Modelnr: 203NL / v1.0


http://wiki.dragon1.org/index.php?title=Enterprise_Architectuurraamwerk



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

www.xr-magazine.nl/node/1258

25 januari 2012 XR Magazine

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 DiamantElk 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 KubusDe 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-kosten 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

In C

ontr

ol

Kosten€

BehoefteICT-gebruik

ICT-middelenConfiguration Mgt.

HoeveelheidCapacity Mgt.

KwaliteitQuality Mgt.

DoorbelastingDemand

ContracteringSupply

Core BusinessPrimaire en ondersteunende processen

Eerste dimensie: DoelKijkend 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: MiddelenDe 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: GeldTen 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

Mid

dele

n

Doel

Geld

Applicatiesoftware

Systeemsoftware

Hardware

Kantoorsy

stemen

Personeelskosten

Bedrijf

ssys

temen

Besturin

g

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

SamenvattingLaten 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 inzichtIn 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 deXR 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

http://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 kansDe 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…

Jan Willem 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 werkEen 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.”

Organiseerje proces

Leg require-ments vast

Start methet probleem

Weespragmatisch

Betrek debusiness

Succesvolrequirementsengineering

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 grenzenRequirements 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 houdenOplossing 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 project 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.

Project manager en requirements engineer: een natuurlijke symbioseUit het voorgaande kun je al concluderen dat het bepa-len van het juiste doel van groot belang is voor de pro-ject manager. En de requirements engineer is daarbij de meest aangewezen persoon om het doel te achterhalen. Wanneer we de skills, vaardigheden en middelen van een requirements engineer en een project manager ver-gelijken dan zien we veel overlap. Naar ons idee is het dan ook nodig om een co-leiderschap van deze twee rol-len te organiseren in ieder project. Want waar de requi-rements engineer zich in eerste instantie vooral richt op inhoud en kwaliteit, richt de project manager zich primair op tijd en geld (al is de wereld in werkelijkheid natuur-lijk niet zo zwart-wit). Maar die zaken zijn natuurlijk wel onlosmakelijk met elkaar verbonden. We noemen dat het duivelsvierkant: trek aan een hoek en de andere hebben de neiging om mee te bewegen. Door het co-leiderschap leiden project manager en re-quirements engineer ieder project naar het doel waar we een project voor optuigen: het leveren van de maximale waarde voor de business, voor de tijd, geld en resources die je erin investeert. En daarbij is dan zelfs vloeken in de kerk geoorloofd: niet altijd is tijd of geld leidend in het bereiken van de juiste koers. Neem bijvoorbeeld de film “Titanic”. Veel te laat opgeleverd, veel te duur maar het succes was uiteindelijk wel zo groot dat het een van de best bezochte films aller tijden is geworden en de film 11 Oscars won. Een project manager die stuurt op tijd en geld moet door een requirements engineer op koers worden gehouden als het gaat om de doelen en de kwaliteit. Andersom geldt dat natuurlijk net zo. Door die samenwerking kan het duivelsvierkant echt in de hand worden gehouden.

Figuur 4: Duivelsvierkant PM en RE

Jan Willem Knop is als Product Manager / Consultant werkzaam bij Valori.www.valori.nl


Precies volgens plan!Dit artikel is gebaseerd op het boek ‘Precies vol-gens Plan!’ geschreven door Mark Hoogveld, Jan Willem Knop en Marcel Schaar. Eerder verscheen in dit blad het artikel: “Requirements zijn de Big Hitter…” waarin het boek wordt geïntroduceerd. In het boek ‘Precies volgens Plan!’ (ISBN-13: 9789012583060) geven we meer concrete tips en adviezen waardoor requirements engineering succesvol uitgevoerd en geïmplementeerd kan worden in een organisatie. In iedere organisatie! En uiteindelijk is ‘succesvol’ requirements engi-neering vooral ook een kwestie van keuzes maken die passen bij jouw orga-nisatie. Die keuzes maak je met al de mensen die het moeten doen. Requi-rements engineering is tenslotte mensenwerk.Ben je door het lezen van dit artikel benieuwd naar de andere tips in het boek, neem dan contact op met Valori of ga naar www.valori.nl.


Het duivelsvierkant

KwaliteitInhoud

Doorlooptijd Middelen


Volgende editie van XR Magazine:

Outsourcing en architectuurIn de maand februari is ‘Outsourcing onder controle met Business Architectuur’ het centrale thema van XR Magazine. Wij zijn daarom op zoek naar artikelen, columns, praktijkcases en opiniestukken waarin nieuwe ontwikkelingen, visies, uitdagingen en best practices m.b.t. dit onderwerp centraal staan. Denk hierbij bij-voorbeeld aan onderwerpen als:

• Wat is outsourcing en welke smaken zijn er?• Welke ervaringen zijn er mee?• Do’s & dont’s bij outsourcing• Business case voor outsourcing• Outsourcing onder architectuur• Business Process Outsourcing• Cloudsourcing• Nearshore outsourcing

Naast thema-artikelen zijn wij ook op zoek naar bijdragen op het gebied van:

• Vakgebieden: Enterprise architectuur, Business architectuur, Informatie architectuur, IT-architectuur, Software ar-chitectuur, BPM, IT Service Management, Project- en Programmamanagement, Agile en Lean, Business Intelligen-ce, IT Governance, Quality Assurance etc.

• Standaarden en methoden: ANSI/IEEE 1471-2000, ArchiMate, BIP, DEMO, Dragon1, DYA, IAF, RUP, TOGAF, Zach-man, BPMN, SCRUM, ITIL, ASL, BISL, Lean Six Sigma, NORA, GEMMA, PETRA, MARIJ, WILMA, AORTA, SABSA etc.

• Trends, technologie en ontwikkelingen: Cloud Computing, Virtualisatie, Open Source, Social Media, Dataware-housing, SOA, EDA, Zaakgericht werken, ERP, ECM, Shared Service Centre, Consumerization of IT, e-Overheid etc.

• En verder: Werken onder architectuur binnen diverse sectoren (overheid, zorg, banken verzekeraars, telecom, energie, logistiek etc.), architectuurprincipes, visualiseren van architectuur, de rol van de architect etc.

Alle artikelen die vóór woensdag 22 februari 2012 op de website zijn gepubliceerd maken kans om in de februari-editie van XR Magazine geplaatst te worden. Kijk voor meer informatie op: www.xr-magazine.nl/instructies

Colofon

XR Magazine: het online platform en vakblad voor managers en architec-ten uit het bedrijfsleven en bij de overheid over de praktijktoepassing van Enterprise-, Bedrijfs-, Informatie- en ICT-architectuur, BPM, SOA, ITSM en aanverwante vakgebieden. Op de website van XR kunt u de nieuwste en alle voorgaande edities van XR Magazine bekijken en ook alle edities downloa-den. Tevens worden deze edities als e-magazine maandelijks in de vorm van een pdf naar onze mailinglist verstuurd waar u zich ook voor kunt aanmelden.

Oplage en attentiewaarde: Steeds vaker zijn de artikelen uit XR Magazine het gesprek van de dag op kantoor! XR Magazine verschijnt 10 keer per jaar en wordt gratis verspreid via e-mail in Nederland en België in een oplage van 3.000 exemplaren. Meer dan 30% van de abonnees bezoekt naar aanleiding hiervan binnen vier uur de XR website en leest het XR Magazine.

Volg XR Magazine: XR Magazine maakt intensief gebruik van sociale media om nieuwe content zo snel mogelijk te verspreiden. Hiervoor maakt XR Maga-zine o.a. gebruik van Twitter, LinkedIn, NUjij.nl en RSS-feeds.

Redactie: Redactie XR Magazine, 0317 41 13 41, [email protected]

Advertenties:Afdeling Marketing, 0317 41 13 41, [email protected]

Artikelen uit XR Magazine mogen alleen worden overgenomen, gekopieerd enz. na uitdrukkelijke schriftelijke toestemming van XR Magazine.

Website: www.xr-magazine.nl

Foto voorkant: Tom Wang / Shutterstock.com


WWW.EAM-CONGRES.NLVoor meer informatie en inschrijvingen:

Interesse in de laatste ontwikkelingen rond EnterpriseArchitectuur?

EAM2012EAM2012 gaat vanuit de praktijkervaring van een groot aantal orga-nisaties in op de toegevoegde waarde van Enterprise Architectuur voor de bedrijfsvoering van organisaties. Vragen als: ‘Wat is de waarde van Enterprise Architectuur?’, ‘Hoe creëer en gebruik je Enterprise Archi-tectuur?’ en ‘Wat bereik je met Enterprise Architectuur?’, staan tijdens EAM2012 centraal. Best-practices en voorbeelden uit de dagelijkse praktijk worden gedeeld en besproken.

Donderdag 31 mei, Hotel Houten

‘Delivering Business Value!’

http://www.eam-congres.nl

XR Magazine januari 2012

Technology

Transcript of XR Magazine januari 2012