XR_Magazine_21_2011

XR.XR Magazine | Kennisdeling over de praktijktoepassing van Enterprise Architectuur

Editie 21 | Maart 2011www.xr-magazine.nl

footer.indd 1 13-12-2010 13:56:15

Thema

Architectuur in projectenHoofdrol of bijrol?

Architectuur en

programmamanagementYin en Yang?

Architectuur in Agile projectenHet creëren van meer business value

Architectuur bij Groen Kennisnet

Architectuur tussen kennisvraag en -aanbod

http://www.xr-magazine.nl/advertenties/advertentie-eam-1-mag-21.html

“Binnen veel organisaties is er de beleving dat er een grote kloof is tussen de business en de IT”- Raimond Brookman in ‘Succesvol de brug slaan tussen Business en IT’

“In een MSP programma is het vanzelfsprekend dat er aandacht wordt besteed aan een blueprint of architectuur”

- Rix Hof in ‘Architectuur en programmamanagement: Yin en Yang’

“Architecten die werken in een organisatie die Scrum heeft geadopteerd hebben twee keuzes: meedoen of afhaken”- Niklas Odding en Gerard Janssen in ‘Architectuur in Agile projecten’

“Het is belangrijk om goed te weten welk deel van de ondernemingsbrede oplossing in het project gerealiseerd

dient te worden en met welke nauwkeurigheid en diepgang”- Mark Paauwe in ‘Dragon1 PXA: De visuele innovatie op de PSA’

“Hoe krijg je de voordelen van een goede architectuur gerealiseerd in een groot project? Wat moet er dan door wie worden gedaan?”- Harry Potma in ’De relatie tussen architecten en IT projecten’

“De poster vervult in vergaderingen met betrekking tot verbetering in dienstverlening een belangrijke rol als praatplaat”

- Frans Breedveld in ‘Poster: Gouda geeft Antwoord©’

“Voor het opstellen van de architectuurprincipes zijn de NORA 3.0 principes als referentiekader genomen”- Bas Jonkers in ‘Architectuur bij Groen Kennisnet’

“De specialist is dood, lang leve de generalist!”- Gerco Grandia in ‘Professionals over Architectuur’

Binnen elke onderneming wordt gewerkt in pro-jecten en programma’s om op een gestructureerde wijze veranderingen door te voeren en nieuwe ‘bouwwerken’ te realiseren. De uitdaging is om op efficiënte wijze van punt A naar punt B te komen en ervoor te zorgen dat bij aankomst ook daadwer-kelijk het beoogde eindresultaat behaald is; een uitdaging die de projecten programmamanagers graag aangaan. Een gemeenschappelijk beeld van de weg daar naartoe en hoe de concrete eindsitua-tie eruit zou moeten zien is hierbij onontbeerlijk. Er zijn duidelijke kaders en richtlijnen nodig in pro-jecten en programma’s en ook een blauwdruk van de huidige en toekomstige situatie is onmisbaar. Hier kan architectuur en de architect een belang-rijke rol spelen. Dat architectuur een belangrijke rol kan hebben in projecten en programma’s lijkt daarmee bijna vanzelfsprekend. Echter, de wijze waarop architectuur ingezet wordt en hoe de archi-tect zich manifesteert in projecten en programma’s bepaalt of dit een hoofdrol is of beperkt blijft tot een kleine (wellicht overbodige) bijrol.

Dat architectuur op effectieve wijze kan worden ingezet als stuurinstrument in projecten en pro-gramma’s laten Frans Breedveld en Bas Jonkers zien. Voor de gemeente Gouda heeft Frans Breed-veld een architectuurposter gemaakt die de kern van de beoogde verbetering in dienstverlening op treffende wijze samenvat. Bas Jonkers geeft een toelichting op de totstandkoming van de architec-tuur van Groen Kennisnet en het bijbehorende ar-chitectuurdocument; een aantrekkelijk document waarmee het doel en de inhoud van de architec-tuur op heldere wijze gecommuniceerd wordt. Twee mooie praktijkvoorbeelden van hoe archi-tectuur ook voor stuurgroepen en directie van toe-gevoegde waarde kan zijn en wel degelijk potentie heeft voor een glansrijke hoofdrol.

Koen van Boekel

maart 2011 XR Magazine

Voorwoord

Do you know how to

eXceleRate?

We do!Succesvol de brug slaan tussen Business en IT 4

3

Architectuur en programmamanagement: Yin en Yang 10

Architectuur in Agile projecten 18

Dragon1 PXA: De visuele innovatie op de PSA 26

De relatie tussen architecten en IT projecten 32

Poster: ‘Gouda geeft Antwoord©’ 36

Architectuur bij Groen Kennisnet 38

Professionals over architectuur:Gerco Grandia 42

Binnen veel organisaties is er de beleving dat er een gro-te scheiding is tussen “de business” en “de IT”. Waarbij “de business” dan wordt gepositioneerd als het verkopen en ondersteuning geven aan producten en diensten die de organisatie biedt. In een moderne organisatie is In-formatie Technologie (IT) niet meer weg te denken. Er is veel ondersteuning nodig om de (vaak administratieve) processen goed en efficiënt te kunnen laten verlopen. Dat is dan zoals “de IT” gepositioneerd kan worden: on-dersteunend zijn aan de bedrijfsprocessen. Andersom kan het ook zijn dat er vanuit technologische vooruitgang nieuwe mogelijkheden ontstaan om producten en dien-sten te leveren. In dat geval kan IT dus ook een driver zijn voor nieuwe business.

De kloofVanwaar die kloof tussen business en IT? Een belangrijke oorzaak is het feit dat beide disciplines een ander ver-trekpunt hebben om naar de wereld te kijken. Enigszins gechargeerd zien we de volgende beeldvorming:

Succesvol de brug slaan tussen Business en ITIs TOGAF en het PSA mechanisme Haarlemmerolie voor organisaties waar Business en IT niet goed

samenwerken? In de praktijk worden raamwerken zoals TOGAF en DYA vaak naar binnen gereden om

de problemen op dit gebied op te lossen. Helaas is dat echter te vaak “In Name Only” en liggen de

best practices op de plank te verstoffen of wordt alles klakkeloos ingezet, zonder naar de organisa-

tiecontext te kijken. In dit artikel wordt bekeken wat oorzaken zijn waardoor “de Business” en “de IT”

vaak niet als een geoliede machine samenwerken en hoe deze samenwerking verbeterd kan worden.

Business wereldbeeldVanuit de business kant geredeneerd, wordt IT vaak ge-zien als een infrastructureel middel wat vergelijkbaar is met kantoormeubilair, kopieerapparatuur en schoon-maakdiensten. Zaken waar je aan diverse partijen een offerte voor kunt vragen, er eentje uitkiezen en dat ver-volgens kopen en gebruiken om de dienstverlening te verbeteren of producten te kunnen verkopen. Om suc-cesvol producten te kunnen verkopen gaat het om men-sen en de kennis die ze hebben van de producten. De IT is ondergeschikt. Als er een apparaat (of applicatie) “stuk” is, dan kun je daarvoor iets anders kopen en de boel vervangen.

IT wereldbeeldVanuit de IT kant gaat het erom dat alle applicaties, sy-stemen en apparatuur op een goede manier integreren, robuust zijn, foutloos werken en dit ook blijven doen. De IT is voor een bedrijf wat bloedvaten en zenuwen zijn voor de mensen. Zonder IT zou een organisatie niet kun-nen functioneren en daarom is IT zo belangrijk. De IT zorgt ervoor dat bulk werkzaamheden geautomatiseerd uitgevoerd kunnen worden, veel sneller en foutlozer dan dat door mensen zou kunnen gebeuren. Om succesvol te zijn als organisatie gaat het erom dat de business goed kenbaar kan maken wat de eisen en wensen zijn met be-trekking tot IT ondersteuning en die op een goede ma-

Raimond Brookman

4 XR Magazine maart 2011

Beide disciplines hebben een ander vertrekpunt om naar

de wereld te kijken

Architectuur in projecten

nier realiseren. IT is complex omdat veel applicaties en systemen naadloos met elkaar moeten samenwerken. De business kan meestal niet exact genoeg aangeven wat ze willen.

Weinig standaardisatieAls “de business” binnen organisaties kan werken met “off the shelf” IT in plaats van IT maatwerk en er dui-delijke industriestandaarden waren om applicaties aan elkaar te knopen, dan zou de IT er een stuk eenvoudi-ger uitzien. Dan zou het echt mogelijk worden om de IT voorziening als een HiFi Home Theater modulematig op te bouwen. Voorlopig zijn we echter nog niet zover. Be-drijfsprocessen zijn nog te “uniek” om volledig generiek ondersteund te worden met standaardpakketten en de in-dustriestandaarden voor de benodigde koppelingen zijn nog te technisch. Deze standaarden liggen op het niveau “we gebruiken 220 volt” en niet op het niveau van een HDMI of SCART kabel waarmee beeld en geluid tussen twee HiFi componenten te transporteren zijn.

Hoe een brug slaan?Om een organisatie efficiënter en effectiever te maken is het van belang te onderkennen dat zowel “de business” als “de IT” een kritische succesfactor is voor de organi-satie. En door te erkennen dat elk vakgebied zijn eigen complexiteit en uitdagingen kent, al is dat voor de ander

niet altijd zichtbaar. Vanuit dat perspectief kunnen Busi-ness en IT samen optrekken, met gezamenlijke doelstel-lingen vanuit het hoger management.

Dit betekent dat vanuit de Business én de IT bij elke verandering moet worden gekeken hoe dat handig in samenhang op te lossen is. Er moet een Solution (oplos-sing) gerealiseerd worden. Vanuit de Business met de fo-cus op welke delen van het proces handmatig kunnen of geautomatiseerd moeten worden en welke eisen daaraan gesteld worden. Vanuit de IT met de focus dat de Solution ingepast moet kunnen worden in de bestaande IT omge-ving en de componenten te selecteren die de eisen kun-nen inwilligen. Dit betekent dat:• er inzicht moet zijn in de samenhang tussen Business

en IT elementen op bedrijfsniveau; zoals de samen-hang tussen producten/diensten, onderliggende be-drijfsprocessen en de applicaties en informatie;

5maart 2011 XR Magazine

“Binnen veel organisaties is er de beleving dat er een grote kloof is tussen de business en de IT”

Elk vakgebied kent zijn eigen complexiteit en uitdagingen; voor de ander is deze echter

niet altijd zichtbaar

• er intensieve samenwerking moet plaatsvinden om te komen tot een werkbare oplossing die bijdraagt aan de organisatiedoelstellingen;

• er expertise beschikbaar moet zijn op Business én IT vlak.

Inzicht op Enterprise niveauOm grote veranderingen (grote projecten of program-ma’s) binnen een organisatie te coördineren is er inzicht en overzicht nodig zodat duidelijk is welke projecten welke delen van de organisatie gaan raken en hoe die projectresultaten in samenhang het beoogde effect zul-len hebben.Dit is te realiseren door het inzetten van een Enterprise Architectuur raamwerk waarin zowel Business als IT ele-menten gestructureerd ondergebracht kunnen worden met hun onderlinge relaties.Vanuit Info Support werken we hier met diverse raamwer-ken die in de industrie bekend zijn zoals TOGAF of DYA. Het Novius Architectuur Raamwerk, waar Info Support ook regelmatig mee werkt, bouwt hierop voort. Info Support heeft bijgedragen aan de uitwerking van dit raamwerk en heeft daarmee een goede aansluiting naar realisatie van projecten geborgd in haar ontwikkelstraat Endeavour. Om de (toekomstige) bedrijfsinrichting voor een organi-satie inzichtelijk te maken, is het van belang dat er een gemeenschappelijke visie neergezet wordt. Daarom is


het belangrijk om op elk van de vier architectuurdomei-nen een referentie architectuur te positioneren.Onderdeel van die referentie architectuur zijn naast prin-cipes en richtlijnen ook een aantal highlevel referentie modellen. Niet om alles in detail uit te werken, maar wel concreet genoeg om als handvat en kader gebruikt te kunnen worden voor het vormgeven van oplossingen die binnen projecten gerealiseerd moeten worden.

Zo zal bijvoorbeeld voor het Procesdomein duidelijk moeten zijn wat de bedrijfsprocessen zijn en de onder-liggende werkprocessen. Voor de Informatievoorziening dient duidelijk te zijn welke Informatiedomeinen binnen de organisatie onderkend worden. En last but not least het eigenaarschap van deze zaken binnen de organisatie.

Intensieve samenwerkingHet is belangrijk om de lange termijn doelstellingen van de organisatie te verbinden met de projecten die uitge-voerd worden en de bijbehorende projectdoelstellingen.

Op elk architectuurdomein dien je een referentie

architectuur te positioneren

Figuur 1: Novius Architectuur Raamwerk (Bayens en Tönissen, 2009) en Info Support best practices

Producten en Diensten

Processen enOrganisatie

Informatievoorziening

InformatieTechnologie

Mar

kten

/ K

lant

en /

Leve

ranc

iers

Pro

duct

en /

Die

nste

n

Dis

tribu

tie K

anal

en

Med

ia

Bed

rijfs

func

ties

Pro

cess

en

Bes

turin

g

Men

sen

/ Org

anis

atie

Bed

rijfs

obje

cten

/ G

egev

ens

Ber

icht

en

Info

rmat

iedo

mei

nen

/ App

licat

ies

App

licat

ie C

ompo

nent

en

App

licat

ie In

frast

ruct

uur

Tech

nolo

gie

Infra

stru

ctuu

r

Services

Bedrijfsarchitectuur

View

Arc

hite

cten

View

Bus

ines

s

Dit vergt een visie op Enterprise niveau. Daarbij moet er wel voor gewaakt worden dat er niet te veel vanuit een blauwdruk model gewerkt moet worden. Door een goede feedback loop te creëren tussen projecten en de Enter-prise Architectuur wordt ervoor gezorgd dat:• projecten actuele kaders meekrijgen waar de oplos-

sing in moet passen;• de langere termijn visie van de Enterprise Architec-

tuur geborgd wordt.Na elke cyclus vindt er een herijking plaats, zodat rea-liteit en theorie steeds in de pas blijven lopen (zie ook figuur 2). Grofweg zijn er de volgende fasen:• Informatieplanning: hierbij wordt voor een langere

periode (1-3 jaar) vooruit gekeken zodat er een re-ferentie architectuur neergezet kan worden om deze lijn te ondersteunen. Daarbij wordt er ook voor het komende jaar een project portfolio in hoofdlijnen neergezet, om zo te zorgen dat er voldoende budget is om de belangrijke projecten uit te voeren.

• Oplossingsrichting: voor elk project wordt in samen-hang een PID (Project Initiatie Document) en PSA (Project Start Architectuur) opgesteld, zodat vanuit respectievelijk de projectmatige en de inhoudelijke kant er een eenduidige visie is wat de doelstellingen voor het project zijn, wat de oplossingsrichting voor het project is en hoe deze passen op de bedrijfsdoel-stellingen en visie. Dit betekent dat in de PSA ook

zeker een highlevel Solution Architectuur benodigd is en het niet kan blijven bij simpelweg het stellen van kaders. Verder is het belangrijk dat de PSA gere-duceerd wordt tot de essentie van de beïnvloedende kaders en de gemaakte keuzen. Het moet zeker niet een wollig verhaal zijn met veel standaard (template)tekst of op meerdere manieren uitlegbaar zijn. Zie het kader “PSA Best Practices” voor de top 8 best practi-ces voor het opstellen van zo’n PSA.

• Realisatie: binnen een project wordt de PID en de PSA verder geconcretiseerd naar een projectplan, een Logische Solution Architectuur (LSA) en een Techni-sche Solution Architectuur (TSA). Met deze architec-turen kan een projectteam aan de slag om conform de Endeavour ontwikkelstraat van Info Support een systeemintegratie of maatwerkproject uit te voeren, waarbij uitgegaan wordt van een Service Oriented

Na elke cyclus vindt er een herijking plaats, zodat

realiteit en theorie steeds in de pas blijven lopen


Figuur 2: Informatievoorziening innovatiecyclus

Project Start Architecturen

Producten en Diensten

Processen enOrganisatie


InformatieTechnologie

Mar

kten

/ K

lant

en /

Leve

ranc

iers

Pro

duct

en /

Die

nste

n

Dis

tribu

tie K

anal

en

Med

ia

Bed

rijfs

func

ties

Pro

cess

en

Bes

turin

g

Men

sen

/ Org

anis

atie

Bed

rijfs

obje

cten

/ G

egev

ens

Ber

icht

en

Info

rmat

iedo

mei

nen

/ App

licat

ies

App

licat

ie C

ompo

nent

en

App

licat

ie In

frast

ruct

uur

Tech

nolo

gie

Infra

stru

ctuu

r

Services

Bedrijfsarchitectuur

View

Arc

hite

cten

View

Bus

ines

s

BIP

EAFeedback

PSA

LSA /TSA

Borging

Informatieplanning

Realisatie

Oplossingsrichting

Front ends

Front end Front end

FunctionalA

rea

FunctionalA

rea

FunctionalA

rea

FunctionalA

rea

FunctionalA

reaIntegration Services

IntegrationS

ervice

IntegrationS

ervice

IntegrationS

ervice

PlatformService(s)

Service Bus

Business Services Process Services Platform Services

Platform

Service

Platform

Service

Process

Service

Process

Service

Process

Service

Business

Service

Business

Service

Business

Service

LegacySystem

LegacySystem

Legenda

Geeft de richting van de aanroep aan

Configuration item afhankelijkheid

Toekomstig Configuration item

Functional area

Legacy system

Toegang extern domein

Cluster

Configuration Item

Gegevensopslag

architectuurstijl.• Borging: Na uitvoering van het project worden de re-

levante elementen voor de Enterprise Architectuur geborgd. Door deze in een centrale repository op te nemen worden Enterprise Architectuur modellen steeds actueel gehouden en eventueel verder ge-completeerd.

Deze cyclus leidt ertoe dat er steeds op strategisch en tactisch niveau een actueel beeld is van de lijn die de or-ganisatie qua IT gaat volgen, dat deze te vertalen is naar concrete projecten en dat het inzicht in de informatie-voorziening steeds verder verbetert.

Expertise op Business en ITBovenstaande cyclus kan alleen succesvol zijn als er in alle fasen wordt samengewerkt. Dat wil zeggen dat er steeds Business en IT expertise in samenhang benodigd is en dat dus ook in alle fasen een dialoog tussen Business en IT nodig is. Hierbij kan de rolverdeling als volgt gepo-sitioneerd worden:

Informatieplanning• Business: de nadruk ligt hier op de veranderingen

die de business aan ziet komen en het bepalen van de impact daarvan op de informatievoorziening qua eisen.

• IT: technology “push” (welke IT innovaties kunnen de business verder helpen) en adviseren bij het bepa-len van de impact op de informatievoorziening qua mogelijkheden.

Oplossingsrichting• Business: stelt heldere eisen en randvoorwaarden

aan het project en draait mee in workshops ten be-hoeve van het bepalen van de oplossingsrichting.

• IT: zorgdragen voor een realistisch beeld van een werkbare oplossing, zodat er een gedeelde visie ont-staat van de doelstelling van het project.

Realisatie• Business: uitwerken van requirements en het bewa-

ken van de scope van het project. Daarnaast ook zorgen dat de benodigde organisatorische verande-ringen (bijv. nieuwe of aangepaste processen) voor-bereid worden.

• IT: realiseren van de requirements en het tijdig leve-ren van een oplossing van afgesproken kwaliteit.


Borging• Business: implementeren van de oplossing binnen de

lijnorganisatie• IT: overdragen van de project deliverables naar de

beheerorganisatie en borgen van nieuwe architec-tuurpatronen, best practices en elementen binnen de Enterprise Architectuur repository.

ConclusieDe effectiviteit van IT inzet en de efficiency van IT ontwik-keling kan binnen organisaties sterk worden verhoogd. Niet door klakkeloos een groot raamwerk te adopteren, maar door focus te creëren op samenwerking en door ac-tiviteiten te structureren binnen een pragmatisch en dy-namisch proces.Om aan te sluiten op een quote van Einstein: “Everything should be made as simple as possible, but not simpler.” Dat betekent niet dat raamwerken als TOGAF geen waar-de hebben, integendeel. Maar je moet als architect en als organisatie wel heel goed kijken wat wel en niet ingezet wordt, zodat dingen simpel en begrijpelijk blijven. Er dient dus geacteerd te worden vanuit de intentie om de organisatie verder te helpen en niet vanuit de intentie om stringent een vast proces te volgen.

Raimond Brookman is werkzaam als Principal Architect bij Info Support.www.infosupport.com

8 best practices voor het opstellen van een PSA:

1. Een PSA is niet te kopiëren (DRY)

2. PSA maakt keus uit alternatieven

3. Een PSA beschrijft de EA projectview

4. Een PSA beschrijft de highlevel solution

5. PSA en PID in samenhang

6. Met PSA is EA Compliance verifieerbaar

7. Consistente modellen en schematechniek

8. Gebruik architectuur patterns

Kijk voor een uitgebreide uitleg van deze punten op Raimond’s blog voor de presentatie die hij hier-over gegeven heeft op LAC 2010.

PSA Best Practices

In alle fasen uit de cyclus is een dialoog tussen Business

en IT nodig

http://www.xr-magazine.nl/advertenties/advertentie-toolbox-mag-21.html

Wat is een programma?IPMA, PMI en de OGC zijn allen organisaties die defini-ties geven van de begrippen programma en programma-management. Ondanks de verschillende bewoordingen komt het in feite allemaal op hetzelfde neer: • Een programma is een tijdelijke, unieke en flexibele

organisatievorm.• Een programma dient om een bedrijf te ondersteu-

nen in een verandering die van strategisch belang is. • Het programma wordt ingericht voor de coördina-

tie en besturing van een portfolio van projecten, in-spanningen en middelen, onzekerheid en risico’s met gecontroleerde stappen in een veranderende omge-ving.

• Het programmasucces wordt afgemeten aan de ge-realiseerde blauwdruk en gerealiseerde baten/bij-dragen (meetbare verbeteringen van bestaande of nieuwe operaties en diensten) die gerelateerd zijn aan strategische doelen.

Een programma gaat dus over het besturen van verande-ringen in een organisatie. Dit perspectief wordt in figuur 1 weergegeven.Een programmamanager dient rekening te houden met een aantal niveaus in en buiten de organisatie. Er is het strategisch niveau waarop gesprekken worden

Architectuur en programmamanagement:Yin en Yang

Programma en architectuur, programmamanager en architect. De programmamanager is van het pro-

ces en de architect van de inhoud: Yin en Yang. De auteur geeft een beschouwing van de dynamiek

tussen beide functies en de verwachtingen die een programmamanager heeft van een architect en wat

een architect van de programmamanager mag verwachten.

gevoerd over de rechtvaardiging (nut en noodzaak) van de gewenste veranderingen. Investeringsbeslissingen, belangenafwegingen en risico-evaluaties dienen gewo-gen te worden tegen de strategische intenties van de or-ganisaties. Veranderingen die gevraagd worden door de dynamiek van de omgeving zullen geëvalueerd worden op dit niveau.Er is het tactische en operationele niveau in een organi-satie die de veranderingen moeten doorvoeren. De ople-veringen van de projecten zullen geabsorbeerd moeten worden en dat gaat niet vanzelf.Het operationele niveau in de organisatie zal de bemen-sing leveren om alle resultaten op te leveren. Het werk gebeurt op dit niveau.En dan is er uiteraard de omgeving die inwerkt op diver-se facetten van de organisatie. Te beginnen bij de klanten met hun wensen en de overheden met hun eisen aan de bedrijfsvoering.Aangezien programma’s een grote planningshorizon hebben, zullen er veel veranderingen gedurende de rit plaatsvinden. De uitdaging is om dit goed te managen. De programmamanager heeft hiervoor een anker nodig, namelijk de beschrijving van de toekomst waar het pro-gramma naar toe beweegt (outcomes, capabilities, blue-print, benefits) en de rechtvaardiging van dit moment om überhaupt te willen veranderen (strategie en business-plannen).

Rix Hof


Hoe gaat het samen?


Architectuur in een programmaDit artikel is bedoeld om een beeld te geven over hoe een programmamanager aankijkt tegen een architect en architectuur. In architectenland zullen, net zoals in pro-gramma- en projectenland, meerdere modellen en me-thodieken gehanteerd worden voor architectuur. In dit artikel wordt het kader beschouwd vanuit MSP.

MSP geeft aan dat een Vision statement noodzakelijk is voor het programma, het richtinggevend perspectief.Tevens zal in een MSP programma in business termen beschreven worden wat uiteindelijk opgeleverd wordt. In eerste instantie zal dit een globale beschrijving zijn van de eindtoestand. Gaandeweg het programma zal deze eindtoestand steeds gedetailleerder beschreven wor-

Tabel 1: Voorbeeld Vision Statement


Vision Statement

Casus:Het bedrijf is een collectieve belangenbehartiger met een vereni-gingsstructuur in een politieke omgeving. Een onderdeel dient getransformeerd te worden naar een individuele dienstverlener die wordt afgerekend op resultaten. De kennis is verspreid over diverse organisatieonderdelen.

[…] wordt binnen twee jaar de erkende deskundige en de betrouwbare leverancier van informatie, kennisproducten en diensten op het gebied van arbeid en inkomen.• Levert een bijdrage aan het beeld van een klantgerichte, des-

kundige en betrouwbare individuele dienstverlener.• Gaat samen met het beeld van een constructieve, naar zijn

leden luisterende, deskundige, betrouwbare en zo nodig strijd-bare collectieve belangenbehartiger.

• Kwaliteit verhogen.• Aansluiten bij de behoeften en verwachtingen van leden.• Producten en diensten vanuit de eigen organisatie. • Gebruik van deskundigen en diensten uit collega-organisaties.• Taal van de leden in de sectoren.

Adagium `Kennis is macht’ middels kennismanagement om-vormen tot `Kennis delen is kracht’.

Figuur 1: Programma’s in relatie met de omgeving1

MissieVisie

StrategieBusinessplannen

Initiatieven

Programma’s Vision Statement tenaanzien van verandering

Projecten eninspanningen

OutcomesCapabilities

Blueprint van eindstadiumBusiness Benefits

Operationele omgevingBehalen benefits

MSP

Business omgeving (intern/extern)(politiek, economisch, sociologisch, technologisch, demografisch, juridisch)

MSP staat voor Managing Successful Programmes, een methode ontwikkeld door de OGC. MSP han-teert de volgende definitie voor programma:

Een programma is een tijdelijke flexibele orga-nisatie, opgezet ten behoeve van de coördinatie, aansturing en bewaking van de implementatie van een samenhangend geheel van projecten en activiteiten om outcomes en benefits te realiseren gerelateerd aan de strategische doelen van een or-ganisatie. Programmamanagement is in deze dan de uitvoering van de gecoördineerde organisatie, besturing en implementatie van een portfolio van projecten en transformatie activiteiten.

MSP

den. In een programma is het noodzakelijk om een tran-sitie op gang te brengen vanuit het heden (IST) naar de toekomst (SOLL). MSP definieert hiervoor de zogenaam-de Blueprint om deze transitie te beschrijven en bestaat uit de onderdelen zoals weergegeven in figuur 2.Op pagina 16 treft u een voorbeeld aan van een Blueprint.Bij dit voorbeeld behoren organisatie- en processchema’s die in het kader van dit artikel zijn weggelaten.De Blueprint kan ook op een andere wijze worden be-schreven, namelijk als een verzameling architecturen (or-ganisatie-, proces-, systeem- en informatiearchitectuur). Business Architecture-planning en Enterprise Architec-ture-planning zijn gebruikelijke instrumenten in organi-saties.Een Blueprint zoals MSP deze definieert en een architec-tuur hebben in essentie dezelfde doelstelling binnen een programma. De vorm is niet belangrijk, de aanwezigheid is van belang en de aansluiting bij wat het bedrijf gewend is te gebruiken.Zowel de IST als de SOLL situatie zal in kaart gebracht worden evenals een mogelijke transitie naar de SOLL si-tuatie toe. Hiervoor heeft de architect niet alleen informa-tie nodig over de missie, visie en strategie, maar ook over de transformatiecapaciteit van de organisatie (zie figuur 1).Door de beoogde transitie goed te omschrijven is het mogelijk om, eventueel in een plateauplanning, een port-


folio samen te stellen van projecten die uitgevoerd moe-ten worden. Een tranche in MSP kan vergeleken worden met een plateau (zie figuur 3).

In een MSP programma is het vanzelfsprekend dat er aan-dacht wordt besteed aan een blueprint of architectuur. Dit is één van de opleveringen. Er is zelfs een aparte functie in het leven geroepen, de zogenaamde Design Authority oftewel de architect.In de praktijk zal een programmamanager expliciet deze functie moeten benoemen of de informatie die benodigd is voor het maken van de IST en SOLL architectuur expli-ciet beleggen bij de projectteams.

Architectuur en programma; Yin & YangHerbrink en van Bruchem hebben de relatie tussen pro-gramma en architectuur uitvoerig beschreven (zie figuur 4).

In een MSP programma is het vanzelfsprekend dat er

aandacht wordt besteed aan een blueprint of architectuur

Figuur 2: Blueprint in een programma1

ProcessenTools / Technologie

OrganisatieInformatie

Logistiek

Workflow

ProductieBeheer

Klantafhandeling

Verantwoorde-lijkheden

Bevoegdheden

Productie

Organogram

Taken

Competenties

Gebouwen

Productiemiddelen

ICT

Methodieken

Technologie

Productiekosten

Communicatie

Kennis

Markt

Sturing

Opbrengst


Figuur 3: Een plateau of Tranche planning1

Project B

Activiteit C

Project D

Activiteit F

Project G

Activiteit H

Project I

Activiteit J

Project K

Activiteit L

Benefits

Risico’s

Tijd, Kosten

Project A

Project E

Een

Tra

nche

is e

en p

late

au

End

Tra

nche

Rev

iew

End

Tra

nche

Rev

iew

End

Pro

gram

me

Rev

iew

Opgeleverde veranderingen, producten, diensten, trainingen, processen, methoden, vaardigheden

Vision StatementBlueprint, Benefit Profiles

Effectiviteit veranderproces

Continuiteit bedrijf

Efficiente uitvoering

Flexibele absorptie

Aansturing veranderproces

Aansturing bedrijf

Veranderproces

Bedrijfsvoering

Relatie 3

Relatie 1

Relatie 2

Strategischeplanning

Corporatedevelopment

ArchitectuurProgramma

Bekrachtigde project-opdrachten en plannen(met kaders, planning,ontwerp, organisatie,financiën, communicatie)

Resultaten veranderproces(= projectresultaten)plus nieuw gedefinieerdeveranderbehoeften

Positionerenverandering inarchitectuur

Positionerenverandering in

programma

OntwikkelenImplementeren

Ontwerpen

Initiëren veranderin

g

Figuur 4: Architectuur en niveaus in het veranderingsproces2

In de uitvoering is het de uitdaging voor een program-mamanager om de resultaten van de projecten en de veranderinitiatieven te matchen met de strategische in-tenties van de top. Ondertussen is er ook nog zoiets als een programmaplan dat uitgevoerd moet worden en een operationele organisatie die alle veranderingen moet ab-sorberen.

De architect is hier niet alleen een ontwerper, maar zal een balans moeten vinden tussen stevigheid (dit is het ontwerp en planning en zo moeten we het doen) en sen-sitiviteit voor wat haalbaar is in de organisatie (relatie 2).De architect toetst inhoudelijk de voortgang van de pro-jecten aan de architectuur en is betrokken bij de formu-lering van de projectopdrachten (relatie 1). Tevens toetst


hij nieuwe initiatieven op haalbaarheid aan de beschre-ven doelarchitectuur en dient daarmee als geweten van de organisatie als er weer een verandering aankomt die door de top wordt opgelegd (relatie 3).Een MSP programma zal uitgevoerd worden met een ar-chitectuur als onderlegger. Deze architectuur dient als ankerpunt voor het programma en als communicatie naar de organisatie, een richtinggevend perspectief. Een pro-gramma met een architectuur zal een ontwerp- of blauw-drukprogramma genoemd worden.Een programma zonder architectuur is op zich mogelijk. Dit wordt een ontwikkelprogramma genoemd. De eind-toestand is dan niet helder omschreven. Het programma zal zich dan gaandeweg ontwikkelen en het programma-team zal dan een lerende omgeving bieden. De doelstel-ling en de visie van zo’n programma zal dan expliciet het leren zijn en niet de te bereiken eindtoestand. Of dit in een doelarchitectuur wordt vastgelegd is nog maar de vraag.

Verantwoordelijkheden in een programmaMSP kent een besturingsmodel met verantwoordelijkhe-den voor de gewenste verandering (figuur 5).De Sponsoring Group bestaat uit het besturend orgaan

De architect toetst nieuwe initiatieven op haalbaarheid

aan de beschreven doelarchitectuur

Figuur 5: Programma organisatie1

Sponsoring Group

Programme Board

Design Authority

ProgrammeManager

Senior Representatives

Senior Responsible OwnerProgramme Director

Business Change Manager(s)Change Agent(s)

Project Board

ProjectExecutive(s) Change Activities

ProgrammeAssurance

van de organisatie en besluit over de gewenste verande-ringen. De Senior Responsible Owner is de opdrachtge-ver voor het programma en de programmamanager re-gelt de dagelijkse uitvoering.In de Programme Board zijn de Business Change Mana-gers aanwezig (zij die de projectresultaten in de operati-onele organisatie moeten implementeren) en de Design Authority, oftewel de architect van het programma.Figuur 6 geeft de combinatie weer van het MSP organi-satiemodel en de niveaus in het veranderingsproces. Zo wordt zichtbaar gemaakt, wie waarover zeggenschap heeft in een programma. Echter de architect zal zich moeten opsplitsen in drie ni-veaus, namelijk de architect van het strategisch niveau, het programmaniveau en het operationeel niveau.

ConclusieArchitectuur en programmamanagement zijn op elkaar aangewezen. De architect verzorgt de beschrijving van de huidige organisatie-, proces-, systeem- en informatie-architectuur. Dit zal op strategisch, tactisch en operatio-neel niveau moeten gebeuren. Door de beschrijving van de gewenste situatie (een proces op zich) ontstaat er een inzicht waaruit de projecten en veranderingsactiviteiten

vormgegeven kunnen worden en vastgelegd in het port-folio.De architect heeft een inhoudelijke rol ten aanzien van de projectopdrachten (welke resultaten moeten opgeleverd worden?) en een controle op de voortgang. Initiatieven die gaandeweg het programma ontstaan, zullen opgeno-men moeten worden in de doelarchitectuur. De architect

vertaalt de nieuwe wensen naar de haalbaarheid binnen het bestaande portfolio en dient derhalve als geweten voor de organisatie (past het initiatief logischerwijs in de architectuur en portfolio?).De programmamanager verzorgt het proces binnen het programma en tussen het programma en de organisatie. Hij zal de dialoog met alle partijen gaande houden


De programmamanager verzorgt het proces binnen

het programma en tussen het programma en de organisatie

Figuur 6: Verantwoordelijkheidsniveaus in programma’s

Effectiviteit veranderproces

Continuiteit bedrijf

Efficiente uitvoering

Flexibele absorptie

Aansturing veranderproces

Aansturing bedrijf

Veranderproces

Bedrijfsvoering

Relatie 3

Relatie 1

Relatie 2

Strategischeplanning

Corporatedevelopment

ArchitectuurProgramma

Bekrachtigde project-opdrachten en plannen(met kaders, planning,ontwerp, organisatie,financiën, communicatie)

Resultaten veranderproces(= projectresultaten)plus nieuw gedefinieerdeveranderbehoeften


architectuur


programma

OntwikkelenImplementeren

Ontwerpen

Initiëren verandering

Sponsoring Group

Programme Board

Design Authority

ProgrammeManager

Senior Representatives

Senior Responsible OwnerProgramme Director

Business Change Manager(s)Change Agent(s)

Project Board

ProjectExecutive(s) Change Activities

ProgrammeAssurance

Strategisch niveau

Programmaniveau

Operationeelniveau

over de voortgang van het programma, mogelijke koers-wijzigingen en consequenties daarvan. De architect en de programmamanager zullen regelmatig overleggen over het ontwerp en de haalbaarheid van het programma en de gevraagde veranderingen, die gaandeweg ontstaan.Wie is in de lead? De architect of de programmamana-ger? Deze vraag is lastig te beantwoorden. Beiden zijn dienstverlenend naar de organisatie en de veranderdoel-stellingen. Het overleg binnen en buiten het programma mag stevig gevoerd worden. De architect heeft zijn invals-

Figuur 7: Relatie tussen architectuur en programmama-nagement2


hoek vanuit het ontwerp (zo moet het) en de programma-manager vanuit het proces (zo kan het).In de praktijk zullen de prioriteiten bepaald worden door de top van de organisatie, de Sponsoring Group (zie fi-guur 5). Het is aan de deskundigheid van de architect en de programmamanager om de consequenties van beslui-ten te expliciteren en te verwerken in de programmare-sultaten. Zowel de architect als de programmamanager zullen de initiatieven volgen: “Als het niet kan zoals het moet, moet het maar zoals het kan”.

Referenties

1 De kleine MSP, R. Hof, SDU, 2008

2 Architectuur en programma als stuurinstrument, Herbrink & van Bruchem,

a&i, 2001

Rix Hof werkt bij I-to-I als management con-sultant. Rix is auteur van “De kleine MSP”, een methode voor programmamanagement.

Programma

Architectuur

De ontwikkel-essentie in dearchitectuur

zorgt voor voortdurendeaansluiting bijdat wat vanuit

het programmahaalbaar is

De ontwerp-essentie in het

programma

zorgt voor hetmeegroeien vanhet programma

met hetverschuivende

doel

Blueprint

Hoofdlijnen:Contact Centrum is het nieuwe ENIGE LOKET:• Vraag gedreven voorlichting en advisering aan leden en niet-leden. • Samengaan van diverse onderdelen van het bedrijf, vrijwilligers, kaderleden en beroepsorganisatie.Contact Centrum is KENNISARSENAAL:• Borgen (beheren, onderhouden en dus `behouden’) van kennis en informatie. • Vaktechnische kennis en ervaringskennis. • Opgebouwde inzichten en vaardigheden van bestuurders, kaderleden en beleidsmedewerkers.

Procesmodel en organisatie van het werk • Vragenenbestellingenkomendiversbinnenbijdefrontoffice.• Backofficezijndeskundigenuitdeorganisatie(adviseurs,bestuurders,kaderleden)encollega’svanandereorganisaties.• Contact Centrum blijft verantwoordelijk voor afhandeling van doorverwezen vragen.• Behandelaars zijn verantwoordelijk voor de inhoud.• Wijziging rollen diverse gelieerde organisaties.• Uitspraken over faciliteiten, werktijden en -vormen.• Bedrijfsvoering is gericht op een opdrachtgever - opdrachtnemer relatie.• Toepassen budgetverdeling en tijdschrijven ten behoeve van resultaatgericht werken.• Visie op kennismanagement en huishouding.

Personeelsmanagement en opleidingen• Beschrijvingvanfuncties,taken,niveaus,opleidingen,flexibiliteit,technologie,faciliteiten.

Ondernemingsresultaat • Uitspraken over kosten, investeringen, functie-eenheden, performancecriteria.• Exploitatiekosten onder huidige kosten.• Verdere standaardisatie van diensten en werkwijze. • Langere en betere bereikbaarheid, meer decentralisatie, hoger serviceniveau. • Meer maatwerk, verbreding of verdieping dienstenpakket.

Waardering• Waarderingsonderzoeken maatschappij, klant, medewerkers, kaderleden. • Doel: klanttevredenheid 8,5; personeels- en kaderledentevredenheid 7

Tabel 2: Voorbeeld Blueprint

Voorbeeld van een Blueprint

Het congres voor infrastructuurmanagers en –specialisten

Na het succes van voorgaande edities vindt Het Infrastructuur Congres in 2011 plaats op 12 april. Het thema richt zich in 2011 op de rol van infrastructuur in de dienstverlening naar de eindklant.

Keynote sprekers:De informatie-infrastructuur, fundering en skelet van de informatie huishoudingDr. Jan Truijens, Digitalis ICT/S Adviens

Connect but don’t forget to leadMenno Lanting, Lanting Consult.

Toepassing van cloud op Olympisch niveauJean Pierre Martens, Tamtam

12 april 2011 - NBC Nieuwegein

Use

Connect

Organize

Innovate

- Van ITIL naar IT Supply Chain Management, Itility BV- Inzicht in spreadsheets en spreadsheetgebruik, TU Delft/Infotron

- De impact van IPv6, IPv6 Task Force- Een mobiele infrastructuur voor bedrijfskritische applicaties, RAM Mobile Data

- Verantwoorde Cloud-navigatie dankzij architectuur, NAF Werkgroep - Uw business verdient een een transparante infrastructuur, CIMSOLUTIONS

- Document in de Cloud, Portbase Rotterdam en Ricoh- Smart City, Gemeente Amsterdam

Binnen de tracks o.a. de volgende praktijkvoorbeelden

Platinum sponsors OrganisatieMediapartners

Ga voor het complete programma en inschrijven naar: www.hetinfrastructuurcongres.nl

Gold sponsor

http://www.xr-magazine.nl/advertenties/advertentie-hic-mag-21.html

Architecten die werken in een organisatie die Scrum heeft geadopteerd, hebben twee keuzes: meedoen of afhaken. De architect die zich steeds verder terugtrekt, versteent in zijn ivoren toren. Meedoen dus. In agile projecten is architectuur een belangrijk element voor succes. Het zorgt voor de balans tussen korte en lange termijn. Betrokken architecten staan midden in de realisatie en be-grijpen wat gevraagd wordt en wat mogelijk is.

De architect als communicator gebruikt schetsen, ideeën en principes om globale IT oplossingen te ontwerpen en deze af te stemmen met een brede groep van stakeholders. Architecten zorgen voor een gedeelde visie bij iedereen, waarbij dikke architectuurdocumenten achterwege blijven. In plaats daarvan wordt er pragmatisch gekeken naar wat nu belangrijk is. Een goede architect combi-

neert dat met een heldere visie op de toekomst, met oog voor de realiteit. Architecten vervullen meer dan ooit een verbin-dende rol. Dicht bij de producteigenaar, om hem te helpen bij het vertalen van zijn wensen naar goede IT oplossingen en het prioriteren van de backlog. Dicht bij de teams om deel te nemen aan de dia-loog over de dagelijkse onderwerpen die boven komen drijven. Architecten adviseren en helpen ideeën ontwikkelen voor verbetering.

Adoptie en invoering van ScrumIn de jaren zestig schreef Alfred Chandler al dat de organisatiestructuur van een organisatie verbon-den is aan de strategie door de organisatorische processen. In de optimale wereld volgens Chand-ler geldt het volgende: Structuur volgt Processen volgt Strategie. Het is daarom logisch te stellen dat een procesverandering, zoals het adopteren van Scrum, een verband moet leggen tussen strategi-sche keuzes en de structuur van de organisatie.De toepassing van Scrum in een organisatie is een procesverandering. Het zorgt voor dramatische verandering van de dynamiek van softwareontwik-keling. Het is een manier van werken die begint bij business requirements en eindigt bij werkende software. Echter met de uitspraken van Chandler in


De invoering van Scrum in organisaties heeft veel impact op de mensen die er werken en de rollen

die zij vervullen. Dit geldt ook voor architecten. Scrum zegt weinig over architectuur en dus vragen

veel architecten zich af, “Wat nu?” In dit artikel geven wij antwoord op die vraag. Meer dan ooit is de

architect een communicator die alles moet weten. Hij staat midden in het team en heeft een visie op

de toekomst.

Niklas Odding en Gerard Janssen

Het creëren van meer business value

Architecten die werken in een organisatie die Scrum heeft geadopteerd hebben twee

keuzes: meedoen of afhaken

Architectuur in Agile projecten


het achterhoofd rijzen drie vragen, waarvoor in de agile wereld nog onvoldoende aandacht is:

Was de invoering van Scrum een voortvloei-sel van de strategie van de organisatie en

helpt Scrum de organisatie om de strategie uit te voeren?Procesveranderingen binnen een organisatie heb-ben een doel nodig. Zonder een helder doel zal de invoering van een nieuw proces zeker falen. De motieven van invoering van Scrum zijn daarom zeker het onderzoeken waard. Wordt Scrum inge-voerd om de organisatie als geheel beter te laten werken, zodat de strategie verder ingevuld kan worden, of is het een uit de hand gelopen hobby van een IT manager? Een onjuiste aansluiting op de strategie van de organisatie, kan voor veel pro-blemen zorgen bij de implementatie van Scrum.

Wordt de organisatiestructuur aangepast en ontstaan er nieuwe afdelingen?

Scrum invoeren betekent de komst van zelforga-niserende teams die verantwoordelijkheid nemen om zaken gedaan te krijgen. Maar wat betekent dat voor de oude functionele afdelingen? Houden zij op te bestaan? Zal de rol van de lijnmanager veran-deren, en hoe? En wat gebeurt er met ondersteu-

nende IT-afdelingen zoals architectuur, kwaliteit en operaties? Een verandering is nooit geïsoleerd en kan op vele manieren de structuur van de organi-satie beïnvloeden.

Hoe raakt Scrum de processen die in ver-band staan met software realisatie?

Processen in een organisatie zijn met elkaar ver-bonden en hebben elkaar nodig om optimaal te

werken. Het Scrum proces heeft bijvoorbeeld een duidelijke invloed op het requirements proces. Maar ook voor de business processen geldt dat ze in staat moeten zijn om veranderingen sneller te adopteren dan voorheen. Daarnaast moeten de ondersteunende IT-processen worden geherdefi-nieerd in overeenstemming met het Scrum ontwik-kelingsproces.


2

31

Figuur 1: Organisatie volgt Processen volgt Strategie

De ondersteunende IT-processen moeten worden geherdefinieerd

in overeenstemming met het Scrum ontwikkelingsproces

Strategie

Proces

Organisatie

Deze vragen zijn te breed om allemaal te beant-woorden in één artikel. Dit artikel richt zich op de laatste vraag en specifiek over de wijze waarop de invoering van Scrum invloed heeft op de architec-tuurprocessen en de rol die de architect moet ver-vullen.

Architecten en ScrumHet merendeel van de literatuur over de rol van architecten in een agile context richt zich op de agile flow zelf en hoe architecten deze flow zo min mogelijk verstoren. Mike Cohn, in zijn boek “suc-ceeding with agile”, maakt het onderscheid tussen coderende en niet coderende architecten. Hij stelt dat de coderende architecten minder moeite heb-ben met het vinden van hun nieuwe rol in het agile-ontwikkelproces.

Mike Cohn vindt dat een architect binnen een team zit en in staat moet zijn om zelf software te coderen. Als lid van het team en door zijn ervaring helpt de architect de structuur van de applicatie te door-gronden en een betere software architectuur te re-aliseren. Scrum kent geen expliciete rol voor niet coderende architecten. De vraag rijst of er echt geen behoefte is aan deze architecten.

Architectuur in een agile omgeving hoort te pas-sen binnen de waarden van het Agile Manifesto. Hieronder bespreken we deze waarden, waarbij we ingaan op wat de consequenties zijn voor de ar-chitectenrol. Het geeft een eerste blik op de wijze waarop de architectuurrol wordt beïnvloed door de invoering van Scrum.

Individuen en interacties boven processen en tools

De eerste agile waarde stelt dat alles draait om mensen en de manier waarop ze communiceren. Processen en tools kunnen nuttig zijn in bepaalde situaties, maar mogen nooit de nadruk krijgen. Verplichte dikke architectuurdocumenten bij de start van een project of langdurige reviewproce-dures van documenten, zijn voorbeelden waar de processen en tools te veel aandacht krijgen. In een


Scrum omgeving is dit uit den boze. Architecten verleggen hun focus van schriftelijke communica-tie (zenden) naar mondelinge communicatie (dia-loog). Ze communiceren met alle belanghebben-den in de organisatie. Architecten communiceren effectief met zowel de producteigenaar als met individuele teamleden. Effectieve communicatie is tweerichtingsverkeer, zodat de architect gevoed wordt met ideeën van anderen. Een architectuur-raamwerk zoals TOGAF kan worden gebruikt, maar alleen om de visie echt te laten landen. De methode is niet bepalend voor welke activiteiten de architecten uitvoeren.

Werkende software boven uitgebreide do-cumentatie

Architecten werkten in het verleden vaak op grote afstand van de daadwerkelijke software bouwers. Communiceren door middel van uitgebreide ont-werpdocumenten bleek veelal niet bepaald ef-fectief. Hoewel architecten vaak zelf trots zijn op hun architectuurdocumenten, werkt dit anders in een Scrum omgeving. De invoering van Scrum in een organisatie dwingt de architecten om zich veel meer te richten op het communicatieve en facili-terende aspect van hun rol. Een architect werkt nu veel meer met schetsen. Schetsen van de totaal-plaat, schetsen van onderdelen waar problemen ontstaan, schetsen van nieuwe technieken etc. Pre-cies genoeg om zijn rol te vervullen, maar zeker niet te veel. Hij gebruikt schetsen om de communi-catie met de betrokkenen te structureren en om de kennis te delen. De schetsen evolueren mee met de inzichten tijdens een project. De input die bijvoor-beeld het ontwikkelteam geeft, wordt verwerkt in de schetsen. De schetsen helpen ook om proble-men die ontstaan bij de realisatie van software te analyseren en om oplossingen te bedenken. Aan de hand van schetsen helpt de architect om bij alle belanghebbenden in de organisatie een gemeen-schappelijk beeld te vormen, waarlangs iedereen zijn activiteiten richt. De kwaliteit van de software zal daardoor zienderogen verbeteren. In figuur 2 is een voorbeeld opgenomen van een dergelijke schets. Deze organisatie wil zijn brondata beschik-baar stellen conform het Master Data Management (MDM) concept. De visie hierop is toegesneden voor de organisatie en is een prima voorbeeld van de schetsen die een architect maakt.

Samenwerking met de klant boven contract-onderhandelingen

Architecten spelen een grote rol bij de alignment van IT en business. In ondernemingen met een

1

2

3

Coderende architecten hebben minder moeite met het vinden

van hun nieuwe rol in het agile-ontwikkelproces

complex multisysteem landschap en meerdere agile teams, staan architecten dicht bij de producteigenaar. Met het schetsen van IT-oplossingen en het geven van inzicht in de complexiteit van deze oplossing, helpen architecten de producteigenaar om zijn prioriteiten vast te stellen. Globale ont-werpkeuzes samen met de producteigenaar ma-ken zorgt voor betere input aan de teams. Zo le-veren teams ook beter werk. Een effectieve relatie tussen een producteigenaar en een architect leidt tot verbeterde waardecreatie met minder inspan-ning.

Inspelen op verandering boven het volgen van een plan

De waarde van architectuur en architecten zit juist in het kunnen reageren op verandering. De beste manier om de dagelijkse problemen die vragen om wijziging van koers te ervaren is om dicht bij het ontwikkelteam te zitten. Architecten nemen deel aan praktische ontwerpvraagstukken. Zo ont-staat de architectuur vanuit de praktijk. Het aan-passen van schetsen is een stuk eenvoudiger dan het bijwerken van lijvige architectuurdocumenten. De architect laat de praktijk en de uitvoerbaarheid leidend zijn en niet zijn oorspronkelijke overtui-ging.

De functie van architect in een agile omgeving is dus echt anders dan we gewend zijn. Maar redene-rend vanuit de agile principes zijn architecten nog steeds relevant, ook als ze niet zelf coderen. Com-municeren en de dialoog met stakeholders is wel een stuk belangrijker geworden. De samenwer-king met de producteigenaar helpt om de juiste balans te vinden tussen de business requirements en de IT mogelijkheden. De meeste van bovenge-noemde veranderingen zijn gericht op het verster-ken van de hartslag van de Scrum teams. De soft-ware kan sneller worden opgeleverd met hogere kwaliteit, waardoor reeds gemaakte software min-der vaak moet worden herontworpen.

De architect en visieDe nadruk bij veel Scrum implementaties ligt vaak op de rol van de architect bij het versterken van de ‘heartbeat’ van de iteraties en het product. Logisch, maar er is meer. Een architect is er ook om de visie te verwoorden en te creëren over hoe de IT inge-zet kan worden in de organisatie; de IT als enabler. Hij onderkent en beheert nieuwe ontwerpideeën. Deze ontwerpideeën komen vanuit een strategi-sche alignment met de business doelen en de en-terprise architectuur. Het zijn verbeterideeën die bijdragen aan het resultaat en net als business


4

Figuur 2: Voorbeeld van een schets van het Master Data Management concept

Brongegevens(Bronsysteem)

Contractgegevens(systeem ...)

Opleiding(systeem ...)

Afspraken& KPI’s

(systeem ...)

Offerte- gegevens (systeem ...)

...

requirements geprioriteerd moeten worden. Ook uit projecten waarbij tijdens het globale ontwerp of tijdens de realisatie van software, nieuwe ideeën ontstaan voor verdere verbetering.Figuur 3 toont de twee aspecten van de rol van de architect. Aan de ene kant heeft hij een rol te spe-len bij de versterking van de hartslag. Aan de an-dere kant heeft hij ook een rol te vervullen als visi-onair van de toekomst. In de volgende paragrafen zal voor elke afzonderlijke activiteit uit de Scrum aanpak de rol van de architect worden beschreven.

Product backlog Traditioneel zijn architecten de hoofdontwerpers in softwareontwikkeling. Projecten starten vaak met een omvangrijk Project Start Architectuur do-cument, opgesteld in enkele maanden tijd en met veel informatie over de te realiseren oplossing.


Scrum projecten werkt vanuit de backlog, gevuld met themes, epics, user stories; korte beschrijvin-gen van wat er gevraagd wordt. Implementaties worden vaak als onderdeel van de sprint gefor-muleerd. Dus waar is de rol van de architect in dit geheel?Architecten spelen een rol in de beginfase van een project door te sturen op complexiteit en haalbaar-heid. Vooral in grotere organisaties met een grote hoeveelheid van software en systemen is daar ex-pliciete aandacht voor nodig. Door echt te begrij-pen wat de business requirements zijn kan je plan-nen voor te toekomst. Eenvoudige oplossingen die zorgen voor wendbaarheid op de lange termijn vereisen een goed begrip van de business requi-rements en focus op complexiteitsreductie. Na-tuurlijk kan je en wil je niet alles van te voren be-denken, we ontdekken pas echt of iets werkt door het te doen. Maar succesvolle projecten hebben een architectuurvisie, die zorgt dat een project niet verzandt in korte termijn oplossingen. Architecten zetten het eerste globale ontwerp neer en houden focus op het totaalplaatje. Bij het maken van keuzes nemen architecten de rol van facilitator en zorgen ze ervoor dat zoveel mogelijk invalshoeken mee-genomen worden. Ze zijn de spil in het multidis-ciplinaire web. Ze gaan het gesprek aan met pro-

Figuur 3: Activiteiten van de architect binnen een Scrum omgeving

Architecten spelen een rol in de beginfase van een project door te sturen op complexiteit

en haalbaarheid

Businessrequirements

Enterprisearchitecture

Productbacklog

Agileteamwork

Designideas

STRENGTHENING THE HEARTBEAT

ENVISION THE FUTURE

ducteigenaren over wat echt nodig is en met de agile teams over hoe de software echt werkt.De ontwerpbeslissingen in het begin van een pro-ject worden normaliter in dit stadium op niet meer dan een half A4’tje opgeschreven. Zo voorkomt de architect zich te verliezen in details. De detail in-vulling doen de teams zelf. Architecten ondersteu-nen producteigenaren bij het vaststellen van prio-riteiten door een eerste schatting te maken van de complexiteit van de oplossing.Architecten werken epics van de product back-log uit in meer detail, passend binnen de totale architectuurplaat. Hij betrekt hierbij iedereen die daarvoor nodig is. Door dit uit de sprint te halen, kunnen teams zich beter richten op de specifieke oplossing binnen het gebied van hun deskundig-heid en op de ‘heartbeat’ van de levering.

Werken in agile teams Architecten zijn dagelijks aanwezig in agile teams. Hier praten ze mee over aankomende epics en user stories in de volgende sprint. Teams nemen dagelijks ontwerpbeslissingen die ze met de ar-chitect toetsen aan de architectuurvisie en het gro-tere plaatje. Dit zorgt voor samenhang en feedback voor de architect op de globale ontwerpbeslissin-gen. Architecten zonder ervaring met het werken in teams verliezen het contact met de werkelijk-heid en kunnen geen goede architecturen ontwik-kelen.Architecten hebben een belangrijke rol in het toe-zicht houden op de architectuurprincipes in alle lagen van de architectuur. Dit betekent bijvoor-beeld dat ze moeten weten of alle business rules zijn geïmplementeerd binnen de business layer, of dat klantinformatie altijd wordt opgeslagen in het CRM-component. Dicht bij het team zijn helpt de architect om praktische architectuurprincipes op te stellen. Architectuurprincipes evolueren vanuit zowel een praktisch oogpunt als een visionair oog-punt.Het samenwerken in teams met ontwikkelaars, tes-ters, performance specialisten, hardware specia-listen en meer, helpt bij het creëren en vastleggen van nieuwe ontwerpideeën, die niet altijd direct uitgevoerd worden. Nieuwe ideeën kunnen een impact hebben op meerdere teams, kunnen teveel tijd kosten voor realisatie binnen een sprint, of de expertise is niet beschikbaar binnen het team. De volgende paragraaf beschrijft de manier van wer-ken met deze ideeën.

Omgaan met ontwerpideeënArchitecten die producteigenaren helpen bij het

concretiseren van de product backlog en het wer-ken in agile teams gaan vaak op in deze flow. Ze komen niet toe aan het andere aspect van hun rol: het ontwikkelen van de architectuurvisie voor de toekomst. Architecten moeten tijd vrij maken naast hun operationele en ‘heartbeat’ gerichte taken. Zo kunnen ze vooruit kijken naar welke mogelijkhe-den de IT de organisatie biedt. Het resultaat hier-van zijn ontwerpideeën. Deze komen grofweg op twee manieren tot stand.Ten eerste ontstaan nieuwe ontwerpideeën in de realisatie flow. Agile teams zijn gericht op het implementeren van nieuw features met een be-trouwbare snelheid. Verstoringen worden hierbij geminimaliseerd. Onverwachte issues die de flow verstoren kunnen we uit de iteratie halen en in een ontwerpidee vatten. De producteigenaar kan ze prioriteren en in de flow opnemen. Nieuwe ideeën kunnen ook voortkomen uit de strategische alignment van de business en IT. Het opstellen van een enterprise architectuur en IT-strategie geven hier voeding aan. IT kan een kri-tische succesfactor worden van de organisatie en katalysator van veranderingen. Een enterprise architect of de Chief Information Officer is nauw verwant aan het hogere management van de orga-nisatie. Hij of zij werkt samen met hen om te zien op

welke manier IT kan worden gezien als één van de belangrijkste productiefactoren van de organisa-tie. De enterprise architect zal hierbij strategische keuzes vertalen in nieuwe ontwerpideeën. Deze ontwerpideeën zullen vervolgens hun weg vinden naar de product backlog. In het verleden werden ontwerpideeën uitge-voerd, wanneer de architect vond dat het nodig was. In een agile aanpak werkt dat niet zo. Het uit-gangspunt bij het prioriteren van ontwerpideeën is de realisatie van business value. Business value hoeft niet altijd kostenbesparing te zijn, maar kan ook worden gevonden in continuïteit (bijvoor-beeld wanneer het aantal servers niet zal worden uitgebreid zal het hele systeem instabiel worden), of aanpassingsvermogen (sneller nieuwe functio-naliteiten toevoegen zonder dat hiervoor te veel refactoring nodig is binnen de teams). De produc-teigenaar beslist welke ontwerpideeën in de


Een enterprise architect is nauw verwant aan het hogere

management van de organisatie

teams worden uitgevoerd. De architect heeft een belangrijke rol bij het promoten en adviseren van deze ontwerpideeën naar de producteigenaar.

Communiceer en balanceer het werk Als we Chandler’s principes volgen, kunnen we stellen dat bij de adoptie van Scrum de organisatie, processen en strategie op elkaar afgestemd moe-ten zijn, anders zal het falen. In dit artikel hebben we de afstemming tussen de adoptie van Scrum en de architectuurprocessen onderzocht. We hebben beschreven op welke manier de rol van de archi-tect vorm krijgt om meer business value te creëren.De invoering van Scrum helpt de architect bij het focussen op de belangrijkste uitkomsten van zijn werk. Hij moet terug naar de basis. Door te focus-sen op minder documentatie en meer communica-


tie, kan de architect uitgroeien tot de belangrijkste versneller voor sprint teams en de organisatie hel-pen bij het bepalen van prioriteiten. De architect moet zich echter niet verliezen in de dagelijkse problematiek van de producteigenaar en teams. Het toevoegen van visie is ook een be-langrijk onderdeel van zijn werk. Elke architect moet daarom de balans weten te vinden in de da-gelijkse werkzaamheden. Waar deze balans uitein-delijk uitkomt, zal zich in de praktijk moeten uit-wijzen. Architecten moeten nu wel uit hun ivoren torens komen. Er wordt van hen verwacht dat zij pragma-tisch en betrokken zijn, zonder de toekomst uit het oog te verliezen.

Niklas Odding is werkzaam als architect bij Xebia.www.xebia.com

Gerard Janssen is business unit mana-ger bij Xebia en verantwoordelijk voor de architectuurgroep.

Van architecten wordt verwacht dat ze pragmatisch en

betrokken zijn

Leer alle essentiële elementen van Enterprise IT Management in 5 dagenDeze intensieve opleiding is speciaal ontwikkeld voor ambitieuze professionals en managers die snel alle essentiële elementen in IT management willen leren kennen. In drie modules behandelen we de werking van een IT organisatie en de samenwerking en integratie met de business. Reken op theoretische diepgang maar ook praktische toepasbaarheid, met real-life voorbeelden.

Start: 9 mei 2011Nederlandstalig

Voor meer informatie: www.antwerpmanagementschool.be/masteringIT

Verbreed, verdiep en integreer uw IT kennis met onze langlopende Part-time Executive Masters:

Executive Master of Enterprise IT Architecture (Engelstalig)Executive Master of IT Governance and Assurance (Engelstalig)

Voor meer informatie: www.antwerpmanagementschool.be/ITmanagement

MASTERING IT MANAGEMENTEen innovat ief managementprogramma van Antwerp Management School

Antwerp Management School Sint-Jacobsmarkt 9-13 | BE-2000 Antwerpen T +32 (0)3 265 47 58 | E [email protected] www.antwerpmanagementschool.be

Alle IT Management opleidingen worden ondersteund door een eigen onderzoeks-centrum: Information Technology Alignment and Governance (ITAG) Research Institute

http://www.xr-magazine.nl/advertenties/advertentie-ams-mag-21.html

Gratis uw vacature op de XR website?XR Magazine biedt een overzicht van vacatures voor architec-ten, ontwikkelaars, managers en andere professionals binnen diverse sectoren. U kunt zelf gratis vacatures plaatsen op de XR website. Kijk voor meer informatie op:

www.xr-magazine.nl/vacatures

De Project Start Architectuur (PSA) in tekstvorm heeft zijn langste tijd gehadSteeds meer organisaties hebben architectuur ontdekt als stuurinstrument ter verhoging van kwaliteit in projec-ten en beleid. Dit heeft er onder andere toe geleid dat er steeds vaker in projectplannen een project start architec-tuur (PSA) als richtinggevend kader wordt onderkend. Omdat integrale ondernemingsbrede oplossingen veelal nooit in één project worden ontworpen, gerealiseerd en geïmplementeerd, dient men in een project goed te we-ten welke deel van de ondernemingsbrede oplossing ge-realiseerd dient te worden en met welke nauwkeurigheid en diepgang.

Hierbij is een richtinggevend architectuurdocument in relatie tot het project van toegevoegde waarde. Echter, het project heeft zelf geen architectuur en is zelf geen doel. Het architectuurdocument van een project dient al-

Dragon1 PXA: De visuele innovatie op de PSADe Dragon1 PXA, de Project aXeleratie Architectuur, is een verzameling van een aantal belangrijke

architectuurvisualisaties waarmee de opdrachtgever en stuurgroep in de vorm van een presentatie

of verzameling sheets het project een visueel ontwerp meegeven waarmee beleidsmedewerkers,

programma-managers, architecten en projectleiders direct sturen op de kwaliteit van de oplossing en

tegelijkertijd de risico’s beheersen.

tijd het te realiseren deel van een oplossing in dat project als focus en doel te hebben. PSA’s hebben in de praktijk vaak een lastig bruikbare verschijningsvorm: een dik tekstueel document, zonder op de doelgroep afgestemde visualisaties, wat door veel opdrachtgevers, managers, beleidsmedewerkers, stuur-groepleden, ontwikkelaars en leveranciers als ondoor-grondelijk en lastig toepasbaar wordt geacht. PSA’s verschillen vaak inhoudelijk van focus, scope en diepgang. De ene PSA is meer een enterprise architec-tuur of referentiearchitectuur, de andere PSA is bijna ver-vangend voor een programma van eisen of het ontwerp van de oplossing.Maar toch is bijna iedereen het erover eens: elk project heeft een op het project toegespitst geheel van normen, standaarden, technieken en indelingen nodig, zodat het project zich met een zo hoog mogelijk succesgarantie kan richten op het ontwerpen, realiseren of implemente-ren van haar deel van een totaaloplossing. Omdat visua-lisaties beter werken dan tekst, heeft een PXA als vorm steeds vaker de voorkeur dan een PSA.

De PXA: uw verzekeringspremie voor succes met pro-jectenDe PXA is de innovatie op de PSA waarmee Dragon1, de open methode voor visuele enterprise architectuur, voor iedereen in de professionele omgeving een oplossing

Mark Paauwe



Het is belangrijk om te weten welk deel van de totaal

oplossing gerealiseerd dient te worden in het project

aanreikt die leerbaar is, bruikbaar is, en leidt tot veel ef-ficiency, effectiviteit en stuurbaarheid van vernieuwingen in projecten. Of het nu gaat om het vernieuwen van een bedrijfsproces of het ontwikkelen van een innovatief informatiesysteem: elk project heeft altijd een landschapskaart nodig van de huidige structuur en situatie van de onderneming en con-ceptschetsen, principetekeningen, bouwschema’s en fo-tografische beelden van de te realiseren oplossing voor de onderneming. Al deze architectuurvisualisaties, die worden verenigd in de PXA, geven opdrachtgevers, stuurgroepen en project-leiders een zeer effectief stuurinstrument om: 1. gemeenschappelijke beelden te creëren voor een

breed publiek over de beoogde oplossing en deze nauwkeurig te communiceren;

2. te tonen wat het ontwerp van de oplossing is op hoofdlijnen dat invulling geeft aan de gestelde eisen;

3. aan te geven hoe de oplossing dient te worden gerea-liseerd zodat deze past binnen de organisatie.

In figuur 1 wordt de relatie getoond tussen de onderne-ming en de oplossing en de informatie waarop de onder-neming en de oplossing gebaseerd zijn. Ook toont figuur 1 hoe de PXA met visuele beelden ervoor zorgt dat tussen de verschillende belanghebbenden een gemeenschap-pelijk beeld en begrip ontstaat over de oplossing, hoe de oplossing met functionaliteit gaat voldoen aan de gestel-

de eisen en hoe de architectuur van de oplossing past in de architectuur van de onderneming.Dragon1 stelt dat elk project dient te beschikken over een PXA. In de PXA staat 1) de architectuur van de oplossing die in het project wordt gerealiseerd, 2) in de PXA staat de enterprise architectuur van de organisatie waarin de oplossing wordt geïmplementeerd, 3) in de PXA staat de impact van de toepassing van de architectuur van de oplossing op de organisatie en 4) In de PXA staat welke regels, richtlijnen, standaarden en normen in het project dienen te worden gebruikt om met een zo goed mogelijk gevolg de oplossing verder te ontwerpen, te realiseren en te implementeren.

Figuur 2 (zie volgende pagina) is een voorbeeld van een structuurvisie van een onderneming die bijvoorbeeld in een PXA kan worden opgenomen.Een project dient volgens Dragon1 altijd te weten hoe iets specifiek voor het project geldt qua standaarden, richt-lijnen, regels, methoden en technieken. Dit zodat het


Figuur 1: De functie van de PXA; visuele afstemming voor effectieve sturing

De PXA helpt bij het creëren van een gemeenschappelijk

beeld van de oplossing

Identiteit,missie, visie op thema’s

van de organisatie

Strategischeuitgangs-

punten en bedrijfs-doelen

Randvoor-waarden en

legacy

Enterprisearchitectuur

van deorganisatie

Programmavan eisen

van deoplossing

Solutionarchitectuur

van deoplossing

(conceptenen principes)

Ontwerp vande oplossing

(standaarden,structuur en

indeling)

Implementatievan de

oplossing

Realisatievan de

oplossing(methoden entechnieken)

OndernemingBesturing

Bedrijven


ICT-Infrastructuur

Oplossing

Deeloplossing

Opdrachtgever(Directie)

Stuurgroep(Management)

Project(werkgroepen)

PXA(Architectuur-visualisaties)- schetsen

- tekeningen- diagrammen

- beelden

- Besturing?- Risicobeheersing?

- Besturing?- Risicobeheersing?

- Requirements Management?- Ontwerp?- Realisatie?- Implementatie?

project zo optimaal mogelijk, vanuit de gehele organisa-tie bekeken, haar deel van de oplossing realiseert. Deze projecties bij elkaar afgestemd op de focus en scope van een project is de PXA.Met de PXA is de opdrachtgever, veelal de directie, in staat aan te geven waar een oplossing aan dient te vol-doen zodat deze binnen de identiteit, missie en visie van de onderneming past. Met de PXA is de stuurgroep in staat om sturing te geven aan de manier waarop de ver-schillende deeloplossingen in detail worden ontworpen en gerealiseerd binnen de standaarden van de onderne-ming. Met de PXA is de projectleider in staat effectief en efficiënt de realisatie van de deeloplossing conform de gestelde eisen en architectuur te laten plaatsvinden.Projecten kunnen goed worden gebruikt om een archi-tectuur op hoofdlijnen te detailleren. In projecten dient echter niet de architectuur op hoofdlijnen te worden aan-gepast n.a.v. voortschrijdend inzicht. Indien dit toch ge-daan wordt dan is de architectuurfase voorafgaand aan het project onvoldoende goed doorgevoerd. Het project hoort dan even pas op de plaats te maken. De architec-tuur wordt dan opnieuw opgesteld, doorgerekend, aan-gepast en consistent gemaakt. Immers in het project heeft men vaak onvoldoende beeld van de gehele oplossing en haar impact op alle fronten. De PXA dient te worden gezien als bindend kader en niet als richtinggevend ka-der.

ArchitectuurvisualisatiesDe kracht van een architectuurvisualisatie overstijgt de best geschreven tekst gemakkelijk. Het creëren van een gemeenschappelijk beeld en begrip in zeer korte tijd bij een grote groep mensen kan het beste met visualisaties. Daarom is het verstandig om zoveel mogelijk op de be-langhebbenden afgestemde visualisaties te maken waar-mee de belanghebbenden de kwalitatieve ontwikkeling van de oplossing kunnen bijsturen.Met architectuurvisualisaties kan men heel snel inzichte-lijk maken wat duidelijk is en wat nog onduidelijk is. Wat is in beeld, wat weten we nog niet in detail of waar moet nog een keuze over worden gemaakt? Ook kan men met architectuurvisualisaties heel goed inzichtelijk maken in welke mate je met het ontwerp en de realisatie van een oplossing tegemoet komt of invulling geeft aan de gestel-de eisen van een oplossing. Geef bijvoorbeeld met een architectuurvisualisatie inzicht in het realiseren van de gestelde kwaliteitseisen als een open veilige en flexibele oplossing met veel hergebruik van elementen en veel gebruik van gestandaardiseerde componenten.

De inhoud van een PXAOm de PXA voor een project zeer concreet te maken schrijft Dragon1 een standaardlijst met visualisaties voor die gemaakt kunnen worden en zeer nuttig kunnen zijn in een project.


Figuur 2: Structuurvisie van een onderneming waarvoor een project een oplossing gaat realiseren

Onderneming

Markt

Doelgroepen Segmenten Assortiment Kanalen Concurrenten ...

Identiteit(en) Kwaliteit Transparantie Missie

Cultuur Kerncompetenties Compliancy Visies op thema’s

Bedrijf 1Bedrijfs-functie 1

Bedrijfs-functie 2

Bedrijfs-functie 3


Bedrijfs-functie 2

Bedrijfs-functie 3


Bedrijfs-functie 2

Bedrijfs-functie 3

Info

rmat

iebe

veili

ging

Gemeenschappelijke Informatievoorziening

Applicaties Gegevens Services ... ...

Gemeenschappelijke ICT-infrastructuur

Netwerken Servers Clients Apparatuur Software

Eigenaar van het verkoopbedrijf?

Eigenaar van de gehele informatievoorziening?

Eigenaar van de gehele ICT-infrastructuur?

Eigenaar van het verkoop informatiesysteem?

Dragon1 onderkent in hoofdlijnen vier soorten visualisa-ties: schetsen, tekeningen, diagrammen en fotografisch beelden. Schetsen, tekeningen en foto’s zijn informele vi-sualisaties, de diagrammen zijn formele visualisaties. De schetsen maakt u bijvoorbeeld met name voor directie en bestuur omdat ze er kneedbaar uitzien en een visie con-cretiseren. De tekeningen zijn met name bedoeld voor het management en de diagrammen met name geschikt voor ontwerpers, engineers en leveranciers. De foto’s werken goed richting medewerkers en klanten. In de PXA staan daarom ook verschillende soorten visualisaties voor de verschillende soorten belanghebbenden.

Dragon1 PXA - Enterprise Visualizations1. AS-IS & TO-BE Enterprise Strategy Analysis Sketch -

Management Overview2. AS-IS & TO-BE Stakeholder Domain Ownership Ana-

lysis Sketch - Enterprise Governance View3. AS-IS & TO-BE Global Logical Enterprise Structure

Framework Drawing - Management Overview (met identiteit, missie, visie, SU’s en doelen)

4. AS-IS & TO Global Enterprise Architecture Frame-work (Conceptual Structure) Drawing - Management Overview

Dragon1 PXA - Solution Visualizations1. Detailed Logical Solution Structure Framework (ele-

ments) - Management Overview 2. Detailed Physical Solution Structure Framework

(components & objects) - Designer Overview3. Detailed Solution Architecture Framework (concepts)

- Designer Overview4. Solution Architecture Concept Design Sketch5. Solution Architecture Principles Drawing - Manage-

ment Overview6. Solution Business - zaken doen7. Solution Work - gebruik8. Solution Service Management - beheer9. Solution Information10. Solution Application & Data11. Solution Technology12. Solution Security13. Artist Impression (foto’s) of the changed end user en-

vironment14. Requirements View - Welke kwaliteits- en prestatie-

eisen worden door belanghebbenden gesteld aan de functies van het oplossingsbouwwerk?

15. Design View - Uit welke standaarden, regels, richtlij-nen en technieken bestaat de nieuwe oplossing?

16. Realization View - Welke methoden / technieken wor-den gebruikt voor het realiseren van de oplossing?

Dragon1 PXA - Impact Visualizations1. Architecture / Conceptual Implementation Impact


Figuur 3: Projectie van een deeloplossing in een onderneming die wordt gerealiseerd door project 1

Onderneming

Markt

Doelgroepen Segmenten Assortiment Kanalen Concurrenten ...

Identiteit(en) Kwaliteit Transparantie Missie

Cultuur Kerncompetenties Compliancy Visies op thema’s


Bedrijfs-functie 2

Bedrijfs-functie 3


Bedrijfs-functie 2

Bedrijfs-functie 3


Bedrijfs-functie 2

Bedrijfs-functie 3

Info

rmat

iebe

veili

ging

Gemeenschappelijke Informatievoorziening

Applicaties Gegevens Services ... ...

Gemeenschappelijke ICT-infrastructuur

Netwerken Servers Clients Apparatuur Software

Oplossing

Deeloplossing die door project 1 gerealiseerd

dient te worden

Gedigitaliseerdverkoopproces

Online verkoopinformatiesysteem

Gevirtualiseerdeservers

View - Wat is de impact en waar is de impact in de organisatie vanwege het implementeren van de op-lossing in de organisatie.

2. Solution Impact Projection in Enterprise Architecture Framework

3. Solution Impact Projection in Logical Enterprise Structure Framework (elements)

Dragon1 PXA - Project & Process Visualizations1. Programme & Project Product breakdown Diagram2. Programme & Project Work breakdown Diagram3. Project-Environment-Analyze - Project Management

View4. Solution Requirements Management Process under

VEA5. Solution Design Process under VEA6. Solution Realization Process under VEA7. Solution Implementation Process under VEA8. Project Risk (Cost) & Solution Ownership View9. Project Design & Realization Standards & Norms Op http://www.dragon1.org en http://wiki.dragon1.org treft u meer informatie en een uitgewerkt voorbeeld van een PXA. Deze kunt u downloaden en direct gebruiken voor uw eigen project.

Het maken van een PXA voor een lopend projectHet is ook nuttig om voor projecten die al zijn gestart een PXA te maken. Voor projecten die al zijn gestart is binnen één dag met een PXA inzichtelijk te maken wat al duide-lijk is en wat nog niet duidelijk is, en wat zich dus elke keer wreekt in het project. In een Stakeholder/Views cross re-ference matrix kunt u bijvoorbeeld laten zien voor welke belanghebbenden (viewpoints) bepaalde inzichten en overzichten (views) niet of nauwelijks beschikbaar zijn, of waar twee of meer beelden (versies/scenario’s) van be-staan. De stakeholders in deze matrix zijn bijvoorbeeld: bestuur, directie, management, analisten, ontwikkelaars, engineers, gebruikers, beheerders. Views in deze matrix zijn bijvoorbeeld management view, design view, engi-neering view en implementation view. In de cellen van de matrix kan dan worden aangegeven in welke mate, versie of status, een view voor de stakeholder beschik-baar is.In het kader van risicobeheersing en besturing van het project is het bovenstaande van grote toegevoegde waar-de. Er is overigens wel een aandachtspunt betreffende belanghebbenden. Bij elk project zijn er wel belangheb-benden in en rondom het project die in eerste instantie geen belang hebben bij teveel transparantie, inzicht en overzicht. Men maakt immers wellicht transparant dat verwijtbaar en aanrekenbaar dingen zijn fout gegaan, niet zijn gedaan of in de toekomst onnodig tijd en geld gaan kosten. Het verstrekken van de opdracht voor het

maken van een PXA dient daarom zoveel mogelijk door de opdrachtgever / de hoogste baas te worden gedaan. Anders komt de opdracht er niet en is er teveel weer-stand bij het maken van de PXA.

ConclusieDe PXA is een visuele versie van de PSA en daarom vele malen krachtiger. De visualisaties van de architectuur van de oplossing, visualisaties van de impact van de oplos-sing op de organisatie en visualisaties van standaarden en richtlijnen, geven de opdrachtgever van een vernieu-wing directe sturingsmogelijkheden richting projecten. Een PXA is in zeer korte tijd te maken: Wat is al inzichtelijk en wat niet? Waar is gemeenschappelijk beeld en begrip over en wat zweeft in het project? De PXA is een praktisch en visueel stuurinstrument voor elk project.

Mark Paauwe is bedenker van de Dragon1 methode en directeur van Paauwe Research.http://research.paauwe.info


Dragon1 is een open methode voor Visual Enter-prise Architecture (VEA). Dragon1 beschouwt, an-ders dan andere architectuurmethoden, de archi-tectuur van een bouwwerk als het samenhangend geheel van toegepaste concepten in dat bouw-werk. Dat houdt in dat de architectuur van een on-derneming minimaal het geheel van toegepaste bedrijfskundige en informatiekundige concepten is binnen de onderneming.

De architectuur van een oplossing, zoals een in-formatiesysteem is dan minimaal het samenhan-gend geheel van toegepaste bedrijfskundige en informatiekundige concepten. De projectie van solution architectuur levert dan het inzicht op waar in de organisatie de architectuur dient te worden aangepast, danwel waar de oplossing al naadloos in de organisatie is te implementeren binnen de kaders van de enterprise architectuur. Ergo, een PXA maakt dan inzichtelijk welke weerstand er wel of niet in welke domeinen van de organisatie (naar alle waarschijnlijkheid) gaat komen.

De belangrijkste aspecten die in samenhang die-nen te worden opgesteld volgens Dragon1 staan verbeeld in het VEA-model. Het zijn deze aspecten waar in de PXA voor een oplossing binnen een or-ganisatie specifieke beelden voor dienen te wor-den gemaakt.

VEA op basis van Dragon1

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

De samenhang van de delen is bepalend voor het suc-ces van het geheel. Daarmee heb ik eigenlijk meteen mijn persoonlijke bevestiging uitgesproken vóór het be-lang van architectuur in grotere projecten. En dus zeker in grote IT projecten. Maar daarmee is de discussie over de rol van architecten in zulke projecten niet afgerond, maar begint deze juist pas. En hier wil ik zeker niet zo snel een positieve conclusie aan verbinden. Hoe krijg je de voordelen van een goede architectuur gerealiseerd in een groot project? Wat moet er dan door wie worden gedaan? En bij deze vraagstelling wil ik ook graag de te-genovergestelde vraag beschouwen. Wat moet er vooral niet gedaan worden?

Grote projecten kunnen op meer manieren mislukken, dan dat ze goed gaan. We moeten dus wel degelijk erva-ringen uit het verleden meenemen om succesvol te zijn. Deze ervaringen liggen gedeeltelijk vast in moderne me-thodologieën. Systematische aanpakken als Prince2 en MSP, beide van dezelfde bron OGC, zijn een prima hou-

De grote historische bouwwerken lijken te bevestigen dat architectuur ‘goed’ is. Dat wil zeggen, wat is

blijven staan. Maar zijn er ook bouwwerken die ‘onder architectuur’ zijn ingestort? En duurde het niet

eindeloos voordat zo’n kathedraal af was? De waarde van architectuur en de rol van architecten bij het

realiseren van moderne bouwwerken zoals grote IT projecten verdient zeker een reflectie. Er stort té

veel in, kost té veel, duurt té lang en is misschien niet wat we hadden gewild. Hoe passen architecten

in grote IT projecten?

vast en leidraad voor het pad naar de gewenste uitkomst. Want laten we wel wezen, het project is nooit het doel. Hooguit een middel om iets te bereiken. Hiermee wordt de vraagstelling wat specifieker. Wat kunnen architecten bijdragen aan het doel van een project?

Het doel van een projectIn de praktijk zie ik vaak dat het makkelijker is om pro-jecten te starten dan af te ronden. En het blijkt helemaal moeilijk om projecten te stoppen. Voor de start-, stop- en afrondproblematiek zijn legio redenen aan te voeren, maar vaak is het terug te voeren op gebrek aan richting en persoonlijk belang bij voortzetting. Laten we even te-ruggaan naar de relatie van een organisatie en haar pro-jecten. De enterprise formuleert haar visie op de wereld, haar missie daarin en vertaalt dit naar de strategie. De strate-gie reflecteert daarmee het voorgenomen pad naar het gestelde doel. En de enterprise probeert met ontwikke-lingen en innovatie deze te verwezenlijken in haar orga-nisatie. En daarmee is eigenlijk ook gezegd dat elke acti-viteit en dus ook de projecten een relatie moeten hebben met die strategie. Maar ja, de praktijk blijkt weerbarstig. Bij een strategiewijziging blijkt het in grotere organisa-ties toch een hele klus om al die activiteiten en projecten dan weer bij te sturen. De theorie definieert een project als een eenmalige ac-

Harry Potma


Mengen in de juiste verhouding

De relatie tussen architecten en IT projecten

Hoe krijg je de voordelen van een goede architectuur

gerealiseerd in een project?


tiviteit om een bepaald product te realiseren binnen de driehoek tijd, kwaliteit en kosten. Dit past eigenlijk niet goed bij de strategie, wat een voortdurend pad is met een langere horizon, wat verandert door de context van de enterprise. Hier komt de programma-aanpak om de hoek kijken, waarin projecten hun plek krijgen naast andere activiteiten om de gewenste blijvende veranderingen te realiseren. Programma’s hebben geen product als resul-taat, maar een voordeel voor de enterprise in lijn met de gekozen strategie. Programma- en projectmanagement zijn daarom ook erg verschillend van aard. Een goede projectmanager regelt dat het afgesproken resultaat behaald wordt binnen de gestelde scope, tijd en budget. Waar nodig worden dan hier en daar de nodige parameters gebogen. Het resul-taat is heilig en als de klus is geklaard, wegwezen en op naar de volgende klus. Een goede programmamanager daarentegen is veeleer bezig met belangen, acceptatie en borging in de organisatie. Hierin kan heel goed een project worden geofferd als dat goed is voor de gewenste uitkomst, opdat het voordeel van de organisatie wordt be-reikt. Een programma heeft dan ook veel meer activitei-ten dan alleen maar projecten. Communicatie is daar een sprekend praktijkvoorbeeld van. Om het nog iets meer aan te zetten; de projectmanager denkt in producten en resources, terwijl de programmamanager denkt in uit-komsten en belangen.

De rol van architectuur in een programmaDe programmaoptiek in de context van de organisatie en projecten kunnen we zien als een samenhangend ge-heel, dat ons is aangereikt door de wijze geesten achter de programma- en projectmanagement methodologieën. We zouden zelfs kunnen definiëren dat dit de ‘architec-tuur’ is van strategierealisatie. Maar laten we niet te ver afdwalen in het theoretische, want dat is toch al een val-kuil voor de architecten onder ons.Terug naar de vraagstelling hoe architectuur kan bijdra-gen aan de missie door het bereiken van het volgende strategische doel. Een enterprise heeft goede program-ma’s met de juiste richting nodig voor de realisatie van haar strategie. Een programma heeft de goede activi-teiten nodig met de juiste richting om de gestelde uit-komsten en voordelen te realiseren. Een project heeft de goede werkpakketten nodig om de juiste producten te realiseren. Hier lijkt een trend waarneembaar over de lagen van het model. Als architect en als IT-er geeft dat een goed gevoel.Als architectuur kan bijdragen aan ‘richting’, ‘goed’, en ‘realisatie’, dan zijn we proper bezig. Anders gezegd, ar-chitectuur moet ondersteunen bij kaders stellen, kaders controleren en creatie. En dat is eigenlijk best voor te stel-len als je door zo’n kathedraal loopt als ware je de betref-fende architect: ‘We gaan een groot kruisvormig gebouw maken met een koepel! Zijn deze stenen onder deze


Figuur 1: Programmamodel

Programma

Project

Verandering

Enterprise

Product

Blijvendeverandering

Output

Strategie

Outcome Benefit

hoek gemaakt? Ik teken wel even hoe je die verbinding moet maken.’Architectuur kan dus dienstbaar zijn door kaders te stel-len, deze te controleren en te ondersteunen bij de cre-atie. Maar dan moet het wel passen in het totaal. Dus de architectuur moet op de juiste laag op de juiste wijze wor-den gebracht. Teveel detail of te weinig duidelijkheid zijn voedingsbodems voor de antipathie tegen architecten. ‘Architecten maken alleen maar wolken’ of ‘Architecten bemoeien zich teveel met de details’ zijn bekende kreten uit de praktijk.

De uitdagingen van een architectArchitecten zijn die mensen die bezig zijn met de archi-tectuur, dus met ‘richting’, ‘goed’ en ‘realisatie’. Solution architecten kunnen bijvoorbeeld in een project meehel-pen om het ontwerp voor een infrastructuur uit te werken. Maar als ze in het project blijven herhalen dat iets niet kan of niet mag dan zal de projectmanager waarschijnlijk ingrijpen en de betreffende architect wegsturen.Enterprise architecten bijvoorbeeld stellen principes op voor alle delen van de gehele enterprise. Duidelijk ka-der stellend. De praktijk laat voorbeelden zien van veel te veel detail, eindeloze discussies over de wijze van for-muleren en een heel traag proces van acceptatie. Het is gemakkelijk om hier de gebruikelijke fout van ‘doel en middel’-verwisseling te begaan. De principes zijn niet

het doel, ze zijn slechts een middel om richting te geven aan de programma’s en dan is het niet nodig om te gede-tailleerd te zijn. Het gaat om de richting en op dit niveau bijvoorbeeld niet om het specificeren van de versie van de software voor de eindgebruiker.Acceptatie van principes is een andere uitdaging voor de architect. Mocht er al een forum zijn waarin de principes kunnen worden geformuleerd, dan is dat slechts het be-gin van de tocht ter accordering van die principes. En wil je werkelijk programma’s kunnen controleren, dan moet je dus met de mensen boven de programma’s aan de slag. Nu zijn deze mensen juist aangesteld op basis van hun drive en persoonlijkheid, dus niet de makkelijkste karakters voor een discussie over controle. Als de argu-mentatie niet direct gerelateerd is aan de strategie en is geformuleerd in business taal, dan is de architect verlo-ren en liggen uitstel, afstel en nivellering van de rol in het verschiet.Een valkuil op projectniveau is de langsvliegende ar-chitect. Het project is al een tijdje onderweg en heeft al een aantal keuzes gemaakt voor de realisatie. Naar goed gebruik is er regulier een projectoverleg waar de senior architect altijd voor uitgenodigd is, maar in verband met agenda, drukte en belangen op een hoger niveau niet eerder is verschenen. Als de architect dan uiteindelijk een keer in de vergadering verschijnt, is het niet onwaar-schijnlijk dat er met principes gegooid worden die geen


Figuur 2: Architectuur in het programmamodel

Project

Enterprise

Verandering

Programma

Architectuur

C? E

C? E

C? E

C? E

van de project teamleden kent, er geconcludeerd wordt dat het project dus niet goed bezig is en dat de architect ook altijd alles zelf moet doen om iets goed te krijgen. Zie hier de valkuil van drie rollen tegelijk uitvoeren ge-combineerd met de valkuil van het doorsnijden van de verschillende niveaus in het programmamodel.‘Te mooi’ is een ander bekend fenomeen uit de praktijk. De architect binnen een project moet een ontwerp ople-veren, maar het is te laat. De projectmanager wordt on-rustig en dringt aan op voortgang. Hier kan het hart van de architect om mooie dingen te maken, die voor altijd blijven staan, de overhand krijgen en het project komt nooit af.Dit zijn enkele illustratieve voorbeelden van de uitdagin-gen van de rol van de architect. Hoe balanceer je ‘rich-ting’, ‘goed’ en ‘realisatie’? En hoe balanceer je tussen de lagen van het programmamodel? Als je als architect je bewust bent van deze verschillen, dan gaat het al een stuk beter.

Organisatie en de plaats van de architectMaar hoe kunnen we nu de architecten helpen in hun toch wel belangrijke rol? Daarvoor kunnen we de positie van de architect in de organisatie beschouwen. De drie aspec-ten van architectuur geven drie verschillende verhoudin-gen tot de activiteiten in de enterprise. Het is moeilijk om van binnenuit richting te geven en daarom kan dit beter van bovenaf gedaan worden. Dus vanuit de ene laag de richting aangeven voor de onderliggende laag. Daarmee zou de architect wel onderdeel kunnen zijn van een pro-gramma, maar staat dan wel boven de projecten.Controleren wordt ook bij voorkeur niet van binnenuit gedaan, maar vanuit een neutrale rol buiten de sturende lijn. En controle is iets anders dan correctie. De correctie moet niet vanuit de architect komen, maar vanuit de lijn. Architecten en lijnmanagers hebben een verschillend ka-rakter en deze moeten niet verkeerd ingezet worden.Het realisatie aspect ligt binnen een activiteit. Dus bij-voorbeeld als teamlid in een project. Maar daarmee is de architect ook ondergeschikt aan de projectmanager. Op deze wijze kan het voorkomen dat er iets gemaakt wordt wat niet goed strookt met de principes en dan moet de architect zich schikken.Dit leidt ertoe dat de architectuurfunctie in een organisa-tie bij voorkeur naast de programma- en projectenstruc-tuur geplaatst wordt en gelaagd wordt opgezet. Dit geeft onafhankelijkheid per activiteit en consistentie over de verschillende activiteiten. Richting geven kan dan vanuit de architectuurfunctie plaatsvinden met deelname van de betreffende belanghebbenden en gelaagd om details en domeinen naar beneden toe verder uit te werken. Controle kan vanuit de architectuurfunctie worden aan-geboden aan de rollen die in het programmamodel daar-voor opgesteld staan. Dus bijvoorbeeld een Senior User

in een Project Board kan voor de Q&A rol een architect uit de architectuurfunctie vragen. Echter, de eventuele cor-rectie is niet de taak van de architect, maar van de ver-antwoordelijke in het project. Een ander voorbeeld is de deelname van een architect in een audit team. Voor het realisatie-aspect is het anders. De architect wordt onderdeel van het team en staat daarmee ook onder aan-sturing van de teammanager. Als het er dan op aankomt, gaat de teamscope voor de architecturale schoonheid. Dit zou ook vanuit de programma- en projectenstructuur kun-nen worden gedaan, maar voor synergie en verbinding naar het grotere geheel heeft de organisatorische ophan-ging in een aparte architectuurafdeling de voorkeur.Een separate architectuurfunctie leidt de architect beter op in het rollenspel over de drie aspecten. Daarmee is de architect goed gepositioneerd voor de verschillende aspecten in, voor en over de programma activiteiten (in-clusief de projecten). Een ander voordeel is dat de archi-tecten nu ook een groeipad kan worden geboden over de lagen heen. En niet te vergeten zijn met een separate architectuurfunctie ook de programma- en projectmana-gers beschermd tegen de architect die buiten zijn rol valt.

ConclusieArchitectuur is zeer waardevol voor de strategie van een enterprise, maar architectuur is geen doel op zich. Het doen van architectuur ten dienste van de doelen van pro-gramma’s en ook van projecten heeft een belangrijke bij-drage aan het totale succes. Binnen architectuur zijn drie aspecten te onderscheiden, ‘richting’, ‘goed’ en ‘realisatie’, die bepalend zijn voor de aard en wijze van het doen van architectuur. Het vervloei-en van deze aspecten in de uitvoering door de architect en het onbewust doorsnijden van de niveaus van het pro-grammamodel zijn de valkuilen voor de architect.De architectuurfunctie in een organisatie is bij voorkeur separaat van de inrichting van het programmamodel, op-dat architecten beter (op)geleid worden in hun verschil-lende rollen en de projecten programmamanagers op hun beurt beter beschermd zijn tegen de architect.

Harry Potma is Principal Consultant tussen ICT en business bij Atos Consulting. www.nl.atosconsulting.com


De architectuurfunctie in een organisatie is bij voorkeur separaat van de inrichting van het programmamodel

Poster:

‘Gouda geeft Antwoord©’


De opdrachtFrans Breedveld heeft de opdracht voor het maken van de poster verkregen van het diensthoofd Publiekszaken. Het verzoek was om voor de beoogde verbetering in de dienstverlening van de gemeente Gouda geen lijvig do-cument te schrijven, maar de kern op heldere wijze te vi-sualiseren en te beschrijven op een grootformaat poster. De poster is daarmee een praatplaat geworden die tijdens deze verbeterslag wordt ingezet om het thema toe te lich-ten en het uiteindelijke doel op treffende wijze kenbaar te maken bij een breed publiek. De poster is gemaakt voor communicatie richting de gehele organisatie en is met name voor de stuurgroep Informatievoorziening en directie tot nu toe een waardevol hulpmiddel gebleken. De inhoud van de poster is vastgesteld en goedgekeurd door de themasponsor bestaande uit het afdelingshoofd Publiekszaken en de stuurgroep Informatievoorziening, waar een viertal diensthoofden zitting in hebben en het afdelingshoofd INA. Dit geeft het belang en de inhoud van de poster extra gewicht mee.

InhoudDe poster heeft betrekking op de verbetering in dienst-verlening van de gemeente Gouda. Bij deze verbetering staat het efficiënter indelen van de klantprocessen cen-traal en hierbij is de filosofie van het landelijke project Antwoord© gebruikt als handvat. Eigenlijk toont de archi-tectuurposter hoe de ‘fabriek’ gemeentelijke producten en diensten levert aan de (stads)winkel en daarmee zorgt voor een voorraad die altijd voldoende op peil is. De ge-meente Gouda zet hoog in op het beginsel dat een klant (burger, instelling of bedrijf) nooit misgrijpt bij het eerste contact met de gemeente. De medewerkers in de stads-winkel hebben bijvoorbeeld altijd informatie over alle producten en diensten voorhanden en zijn altijd in staat

om de burger of klant vriendelijk te adviseren om tot de keuze van het juiste product of dienst te komen danwel om de klant door te verwijzen. Vervolgens is de gemeen-te ook altijd in staat om conform de leveringsvoorwaar-den te voldoen aan de wensen en eisen van de burger of klant. Hoe de gemeente Gouda dit voor elkaar gaat krij-gen staat uitgewerkt op de architectuurposter.

OntwikkelprocesDe poster is ontwikkeld door Frans Breedveld in samen-werking met het diensthoofd en de afdelingshoofden Publiekszaken. John Pape en Sjaak Aalten hebben als informatie architect ook hun medewerking verleend. Voor het afstemmen en bepalen van de inhoud van de poster zijn diverse interviews en workshops gehouden met de diensthoofden, afdelingshoofden, proceseigena-ren en de afdeling communicatie. Hierin zijn ondermeer de uitgangspunten van de gemeente als organisatie met betrekking tot de verbetering in dienstverlening verza-meld. Tevens is er gebruik gemaakt van referentie infor-matie van het landelijke project Antwoord©. Om ervoor zorg te dragen dat de belangrijke aspecten in geval van het communiceren van een organisatiebrede verbetering aan bod komen, heeft Frans Breedveld het architectuurposter-sjabloon van Dragon1 gehanteerd. Dit borgt dat op de architectuurposter overzichtelijk aan-dacht en ruimte is voor onder andere de volgende on-derwerpen: belanghebbenden, missie, visie, strategie, uitgangspunten, randvoorwaarden, doelen, eisen, het vraagstuk, de oplossingsrichting, de communicatiebood-schap aan de doelgroep, documentbeheer/versie-infor-matie, postertitel, beschouwingsperiode, bronliteratuur/referentie-informatie, de principes, concepten, elemen-ten en componenten die onderdeel zijn van de oplos-singsrichting.

Het doorvoeren van verbeterslagen binnen een organisatie is vaak een lastige klus. Om de verande-

ringen succesvol door te voeren is het belangrijk dat er een gemeenschappelijk beeld is van welke

veranderingen er plaats gaan vinden en wanneer en hoe deze gaan plaatsvinden. Het beschrijven van

een helder afgebakend einddoel is hierbij ook van belang. Voor de verbetering in dienstverlening van

de gemeente Gouda heeft Frans Breedveld daarom een architectuurposter ontwikkeld waarop deze

zaken op treffende wijze zijn weergegeven.

Frans Breedveld


Het is niet toegestaan om de afbeelding te kopiëren en / of te gebruiken zonder toestemming van de illustrator.

Voor het vervaardigen van de poster zelf zijn in eerste instantie veel schetsen gemaakt om te bepalen hoe de verschillende informatie het beste kan worden weerge-geven in een overzichtelijk geheel. Om de poster een grotere belevingswaarde te geven zijn er bij de diverse steekwoorden die op de poster aanwezig zijn passende afbeeldingen gezocht. Het kleurenschema van de poster is afkomstig van het thema “Gouda geeft Antwoord” en dit is gedaan om de poster het gezicht van het thema mee te geven.

GebruikDe poster wordt gebruikt bij het ontwikkelen van de visie op de verbetering in dienstverlening en het maken van scenario’s van hoe deze verbetering bereikt kan worden, ondanks de geplande bezuinigingen. De poster vervult in vergaderingen met betrekking tot dit thema een belang-rijke rol als praatplaat. Momenteel wordt de poster overi-gens ook gepresenteerd via interne kanalen zoals het in-tranet en via Yammer, zodat deze beschikbaar is voor de gehele organisatie. Er moet nog een communicatiecam-pagne worden opgezet om de poster organisatiebreed nog meer bekendheid te geven. Een leuke bijkomstig-heid is dat inmiddels twee andere gemeenten interesse

hebben getoond voor de poster, waarvan één gemeente de poster zelfs integraal wil overnemen.

DoorontwikkelingOp de poster wordt periodiek onderhoud en beheer gepleegd om deze zo actueel mogelijk te houden. Daar-naast dienen er op korte termijn verschillende scenario’s weergegeven te worden op de poster; deze scenario’s worden momenteel uitgewerkt. Op dit moment is er nog geen toelichtingdocument en flyer beschikbaar voor de poster. Beide documenten staan echter wel op de plan-ning om op korte termijn te worden gerealiseerd in sa-menwerking met de afdeling Grafische vormgeving en de afdeling Communicatie.Tot slot geeft Frans Breedveld nog de volgende tip mee voor anderen die ook een dergelijke poster willen ma-ken: “Ga goed in gesprek met de opdrachtgever en pro-beer de verwachtingen ten opzichte van elkaar helder te krijgen en maak een roadmap van hoe men tot het vast-gestelde doel wil komen. Verwerk deze zaken in een pos-ter en je hebt een prima praatplaat.”

Frans Breedveld is programmamanager Dienstverle-ning bij de gemeente Gouda

Voor deze poster is gebruik gemaakt van de viewlayout uit deopen methode Dragon1 voor Visuele Enterprise Architectuur

Aanleiding voor de GKN architectuurDe afgelopen 10 jaar is Groen Kennisnet (GKN), de infor-matie-infrastructuur van de Groene Kennis Coöperatie, uitgebouwd tot een veelzijdige verzameling van applica-ties die allen op projectbasis gerealiseerd zijn. Integraal functioneel en technisch beheer ontbrak hier echter bij. Het regieteam van Groen Kennisnet kwam daarom ruim een jaar geleden tot de conclusie dat dit beter kon en dat er werk gemaakt moest worden van een fundament voor de informatiearchitectuur en de inrichting van het GKN informatiemanagement. Het doel hiervan is dat er

vanuit deze basis de komende vier jaar bewuste keuzes gemaakt kunnen worden over het opschonen en verder uitbouwen van Groen Kennisnet. Jonkers over de start van het traject: “Uiteindelijk ben ik begin 2010 door Dick van Zaane, voorzitter regieteam GKN en opdrachtgever voor dit traject, gevraagd om expertise en procesbegeleiding

Architectuur bij Groen Kennisnet

In 2010 is Groen Kennisnet (GKN) gestart met een traject om concrete invulling te geven aan het wer-

ken onder architectuur. In dit traject is onder meer de business- en informatiearchitectuur van GKN

uitgewerkt en het GKN informatiemanagement ingericht. Het uiteindelijk doel: meer grip krijgen op

de ontwikkeling en het beheer van de diensten die GKN aanbiedt. Het resultaat van dit traject is ver-

pakt in een aantrekkelijk document waarin de architectuur van GKN op compacte en heldere wijze

voor meerdere doelgroepen inzichtelijk is gemaakt. In dit traject heeft Bas Jonkers een belangrijke rol

vervuld als inhoudelijk adviseur en procesbegeleider.

in te brengen. Samen met de leden van het regieteam en een expert op het gebied van de Groene Informatie-voorziening zijn we aan de slag gegaan als de werkgroep BIAM (Business-, Informatiearchitectuur & Informatiema-nagement). Het regieteam GKN valt onder het dagelijks bestuur van de Groene Kennis Coöperatie. Om met het

Informatiearchitectuur

Bas Jonkers


Architectuur tussen kennisvraag en -aanbod

Groen Kennisnet (GKN) is een onderdeel van de Groene Kennis Coöperatie (GKC), het samenwer-kingsverband van alle Groene onderwijsinstellin-gen in Nederland. GKN verzamelt kennisbronnen op het gebied van Voedsel en Groen in Nederland en maakt deze publiekelijk beschikbaar via de website www.groenkennisnet.nl en diverse web-services. Hiermee stimuleert GKN het delen van kennis op het gebied van Voedsel en Groen en is GKN inmiddels uitgegroeid tot een onmisbare schakel van het Groene Kennissysteem, dat bestaat uit alle kenniswerkers en –organisaties (overheid, onderzoek, onderwijs, bedrijfsleven, maatschap-pelijke organsiaties) werkzaam in het domein van voedsel en groen.

Over Groen Kennisnet

De architectuur helpt bij het maken van bewuste keuzes

over het opschonen en uitbouwen van GKN

aan te slaan bij de betrokkenen.Vervolgens was het vrij eenvoudig om in een aantal lo-gische stappen, van processen via functionele domeinen en uiteindelijk de logische informatiesystemen, toe te groeien naar de concrete situatie. Ten slotte hebben we de GKN-servicemanager gevraagd om op basis van de modellen het actuele applicatielandschap te schetsen, wat probleemloos bleek te gaan.”Een ander belangrijke onderdeel van de GKN architec-tuur zijn de architectuurprincipes. “Om te komen tot de GKN architectuurprincipes hebben we met name de

NORA 3.0 principes als referentiekader genomen en be-wust gekeken naar wat wel en niet van toepassing was voor GKN, en vervolgens, wat we nog misten toegevoegd. Voor de inrichting van het Informatiemanagement heb-ben we BISL als kapstok genomen en uitgekleed tot pro-porties die passen bij de omvang van GKN.” geeft Jon-

resultaat aan de slag te kunnen gaan was goedkeuring door het dagelijks bestuur noodzakelijk.”

Ontwikkeltraject van de GKN architectuur“Wat me bij de aanvang van het traject opviel was dat er bij informatiearchitectuur onmiddellijk heel concreet ge-dacht werd over de aansluiting tussen de werkprocessen van GKC en het applicatielandschap. Mijn dilemma was echter dat met alleen een goed overzicht van alle huidige toepassingen niet goed te bepalen valt hoe het landschap er over een x-aantal jaar uit moet zien”. De eerste stap in het traject was dan ook pas op de plaats maken. “IT-toepassingen zijn leuk, maar hebben op zichzelf geen nut. Ze krijgen pas toegevoegde waarde als ze daadwerkelijk gebruikt worden. Om een gevoel te krijgen bij waar de behoeften aan IT-ondersteuning in het groene domein zit-ten, zijn we eerst aan de slag gegaan met de processen. Welke transacties vinden er op hoofdlijnen plaats?” Dit laatste bleek ook meteen de meest complexe stap te zijn, maar wel één met een verrassend resultaat. “De drie verschillende transactiemodellen (één voor elk van de GKC-werkprocessen – te weten: Kenniscirculatie, Onder-wijsvernieuwing en Samenwerking) waarmee we begon-nen, groeiden gedurende het proces steeds meer naar elkaar toe tot één algemeen transactiemodel. De transac-tie als uitgangspunt was losjes gebaseerd op de DEMO-methodiek van J. Dietz en deze aanpak bleek heel goed


Figuur 1: Transactiemodel tussen kennisvraag en -aanbod

Voor het opstellen van de architectuurprincipes zijn de

NORA 3.0 principes als referentiekader genomen

VerzamelenVraag Aanbod

Ontwikkelen

Toepassen

kers te kennen. Het uiteindelijke resultaat is vervolgens voorgelegd aan een aantal reviewers waaronder een architectuur-expert, de beheerorganisatie, informatiema-nagers van verschillende onderwijsinstellingen en een bestuurlijke beleidsgroep van de GKC. “Op het resultaat werd enthousiast gereageerd en met name de opmerking dat het nog strakker en met minder ‘blabla’ kon, hebben we ter harte genomen”, zegt Jonkers.

Het eindresultaatBas Jonkers over de gekozen presentatievorm van de GKN architectuur: “Wat mij betreft heeft het geen zin om pro-ducten op te leveren die zichzelf niet kunnen verkopen. Willen mensen ermee aan de slag gaan, dan moet het ze aanspreken en moeten ze het (met minimale toelichting) kunnen begrijpen. Alleen op die manier zullen ze het zich eigen maken en als ambassadeur voor het gedachtegoed optreden. Anders verwoord: iedereen moet het in een discussie op tafel durven leggen om er zijn punt mee te onderbouwen.”Het uitgangspunt bij de beschrijving van de architectuur was dat het vooral beknopt en behapbaar moest blijven om überhaupt kans te maken bij bestuurders. “De review en discussie met de gebruikerskant wees dus uit dat wat wij vanuit de werkgroep beknopt vonden nog best wat strakker en minder wollig kon. Zo zijn we toe gegroeid naar wat ik laatst een keer de ‘minimale essentie’ heb

genoemd; je doorlopend proberen te beperken tot de kleinst mogelijke set van relevante zaken.” De mooiste complimenten over het architectuurdocu-ment kreeg de werkgroep van de bestuurders uit de Be-leidsgroep ondersteuning. Eén bestuurder vertrouwde het eigenlijk niet omdat het allemaal zo logisch en be-grijpelijk in elkaar viel en een ander vond dat IT op deze manier ‘sexy’ werd. Het mooiste impliciete compliment kwam echter van de servicemanager die met een kwar-tier toelichting binnen een aantal uur het woud aan appli-caties wist te plotten op de aangereikte modellen. Door de bank genomen is er dus zeer positief gereageerd op het document en de GKN architectuur. “Het blijft echter wel van belang om met name binnen de beheerorgani-satie draagvlak te creëren en dit ook in stand te houden” , zegt Jonkers.

Doorontwikkeling en borging van de GKN architec-tuurOp de vraag hoe de architectuurfunctie momenteel is in-gericht binnen GKN geeft Jonkers het volgende antwoord: “Op dit moment ligt er een voorstel voor een nieuwe or-ganisatie-inrichting rondom GKN, waarbij de architectuur structureel geborgd wordt binnen het onderdeel ‘infor-matiemanagement’. Tot die tijd ligt de verantwoordelijk-heid voor de architectuur bij het regieteam GKN en le-vert een andere organisatie, zoals ik het afgelopen jaar


Figuur 2: GKN Applicatielandschap (oktober 2010)

Redactieomgeving

Reviewomgeving

Ontwikkelomgeving

Ontwikkelen

BI (analyse)omgeving

Z&Vomgeving Zoekmachine Referatory

Feedbackomgeving Leer/Werk omgeving Voorbereidings

omgeving

Verzamelen

Samenwerkomgeving

Gebruiker

A&Asysteem

Identiteitsgegevens

Profielgegevens

Profielensysteem

Kennisverzameling

Repository

Objecten

Object-feedback

Repository

Toepassen

OPKI CTvO Samenwerking Algemeen

Redspider

Entree

SSOLL-account

directory

Kennisattendering

Websites Reddoten Sharepoint

Sharepoint

Livelink/Reddot

Java en PHPLL-Content store

Dossiers / Artik+

LL-Projectomgeving Groene LabLL-CoP’s

LL-reporter

WebanalyticsLL-search

SOLR

Schakelbord

GKN portaalKennis attendering

KennisLoketZoekportaal

ECCLL-Intranet

FlexC.

Line.

LL-Competentieregistratie

Proces Portfolio

Wikiwijs-arrangeren

KI

nisatie. Voor deze persoon is ook een belangrijke functie weggelegd om toe te zien op de handhaving van de prin-cipes en actualisering en eventuele verdere uitwerking van de GKN architectuur. De precieze invulling van deze functie zal nader worden vormgegeven als de nieuwe or-ganisatie is ingericht.

Het document ‘Architectuur tussen kennisvraag en -aanbod’ waarin de GKN architectuur beschreven is kunt u bekijken op http://issuu.com/kennisnet/docs/architectuur-tussen-kennis-vraag-en-aanbod.

Bas Jonkers is sinds kort Senior Adviseur Stra-tegisch Informatiemanagement bij de Nieuwe Voedsel- en Warenautoriteit.

vanuit Stichting Kennisnet, de architectuurexpertise. Het uitgangspunt is dat de opgestelde architectuur gebruikt wordt in de programma’s en projecten die binnen het groene domein worden opgestart.” Het eerste succes op dit gebied is inmiddels al binnen. Jonkers geeft aan dat de werkgroep Architectuur van het programma GroenGelinkt (Natuur en Milieu Educatie) begin dit jaar de GKN architectuur onverkort als basis heeft overgenomen en hier eigen aanvullingen op heeft gedaan.Om de GKN architectuur in de toekomst haar rol te laten spelen binnen de verdere ontwikkeling van GKN is het volgens Jonkers van groot belang dat er een voorvechter is (de beoogd informatiemanager) die het belang van de GKN architectuur weet over te brengen binnen de orga-


Voorbeeld van een GKN principe:

Behoeften van de groene instellingen zijn uit-gangspunt voor aanbod van diensten

ToelichtingGKN gaat uit van vraagsturing. Dit sluit overigens niet uit dat door middel van experimenten de vraag eerst geprikkeld wordt (denk hierbij aan Proof of Concepts / Pilots / trial & error-aanpak).

ImplicatiesIn de opstartfase van een (door)ontwikkeltraject wordt objectief in kaart gebracht welke behoeften met de dienst ondersteund moeten worden. Vervol-gens wordt bekeken of de beschikbare middelen en andere randvoorwaarden toereikend zijn om de behoefte te realiseren. Zo niet, dan wordt of de busi-ness case bijgesteld, of het traject gestaakt.

Relatie NORA principes• Nr. 18 - Perspectief Afnemer

GKN architectuurprincipesEen belangrijk onderdeel van de GKN architectuur zijn de architectuurprincipes. In totaal zijn er 19 architec-tuurprincipes opgesteld die onderverdeeld zijn in vier categorieën: GKN, Dienstverlening, Informatie en Be-heer/Ontwikkeling. Elk architectuurprincipe is voorzien van een korte toelichting en een beschrijving van de implicaties. Daarnaast wordt ook aangegeven aan welke NORA 3.0 principes het architectuurprincipe gerela-teerd is. Hieronder worden twee voorbeelden gegeven van de GKN architectuurprincipes:

Voorbeeld van een informatie-principe:

Informatieobjecten zijn identificeerbaar en een-duidig beschreven

ToelichtingElk informatieobject heeft een eigen id(entifier), waarnaar verwezen kan worden. Daarnaast is elk type informatieobject helder beschreven gegeven de context waarbinnen zij relevant is.

Implicaties• GKN-systemen zijn zo ingericht dat elk informa-

tieobject een unieke id krijgt. Alle gegevens (dit hoeft niet puur tekstueel te zijn, maar ook bijv. een afbeelding) omtrent het object worden ge-relateerd aan dit id.

• Van elk informatieobject is beschreven wat haar betekenis is in een bepaalde context (dit kun-nen er meerdere zijn). Deze beschrijvingen zijn op een uniforme manier vastgelegd en zodanig beschikbaar gemaakt(bijv. in een catalogus) dat er naar verwezen kan worden.

Relatie NORA principes• Nr. 15 - Identificatie informatieobjecten• Nr. 16 - Informatieobjecten systematisch be-

schreven


Interview met Gerco Grandia

Professionals over architectuur

Is momenteel bezig met…Aan welke projecten of opdrachten werkt u momenteel en welke rol heeft architectuur hierbij?

Ik werk eigenlijk altijd aan meerdere zaken tegelijkertijd. Momenteel werk ik als Systeem Architect aan het ontwerp van de tunnel- en verkeerstechnische installaties bij de nieuwe Coentunnel. Zeker niet een typische IT architec-tenrol, maar uitermate leuk en uitdagend en mijn toege-voegde waarde zit in mijn ervaring in het ontwerpen van grote, complexe systemen en de processen die daarvoor

nodig zijn. En dat je dan opeens over ventilatoren praat in plaats van over bijvoorbeeld servers, went weer snel.Daarnaast help ik een wereldwijde leider op het gebied van web content management systemen met hun strate-gische product architectuur, waarbij op dit moment de

nadruk ligt op het benutten van de mogelijkheden die cloud computing ons biedt. We hebben daar net een aan-tal pilots afgerond en zijn nu bezig met de integratie in het producten portfolio.Als laatste heb ik net een project, eigenlijk een erg groot (dat is: miljarden) bid afgerond, waarbij ik voor de prime contractor, een bouwbedrijf in het Midden Oosten, de Technical Design Authority rol ingevuld heb over het IT gedeelte van de oplossing, dat geleverd wordt door grootmachten als Boeing en Thales.

Toegevoegde waarde van architectuurWelke rol of functie dient architectuur te hebben om van toegevoegde waarde te zijn?

Architectuur is mijn inziens nooit een doel op zichzelf, ook al zou je die indruk soms wel krijgen. Ik ben dan ook een beetje wars van al te theoretische discussies, al zijn die wel degelijk broodnodig. Maar dan niet tijdens de uit-voering van een project graag!Er zijn talloze definities van architectuur, maar een aardi-ge vind ik wel de aspecten van een systeem die in een later stadium het lastigste te wijzigen zijn. De essentie van het architectuurproces is communicatie, het stelt je in staat je ideeën aan het papier toe te vertrouwen en te communi-ceren met je stakeholders. Met als belangrijkste voordeel dat het individuele en gezamenlijke denkproces op gang

Naam: Gerco Grandia

Functie: Technical Manager / Solution Architect

Bedrijf: 4Synergy

Leeftijd: 40

Motto: Schoonheid door eenvoud

Momenteel werk ik aan het ontwerp van de tunnel- en

verkeerstechnische installaties bij de nieuwe

Coentunnel

43

komt terwijl het nog alleen het (geduldige) papier raakt en niet pas als het al is bestendigt in processen, software en infrastructuur.Architectuur dient zaken te vereenvoudigen. Het wordt daarmee niet simpel, maar dient het besluitvormings-proces te ondersteunen. Architectuur en architecten heb-ben helaas nogal de reputatie zaken moeilijk te maken. Voor een deel is dat onvermijdelijk, het is uiteindelijk onze taak om een onderwerp van meerdere kanten te be-schouwen en ook de nadelen te belichten. Wat echter wel een valkuil is, dat we als vakgroep te veel focussen op onze eigen favoriete kwaliteitsattributen (als flexibiliteit, schaalbaarheid, onderhoudbaarheid), maar nog te wei-nig oog hebben voor de wat meer opportunistische as-pecten zoals time-to-market, kosten, uitstraling e.d. Maar die zouden wel eens veel belangrijker kunnen zijn.

Do’s & Dont’sWat wilt u anderen meegeven over het werken onder architectuur?

Het zal niet verrassend zijn dat ik voorstander ben van de kreet ‘Werken onder Architectuur’. Echter, stel jezelf wel altijd de vraag wat het doel is van bepaalde archi-tectuur deliverables. Te vaak worden platen getekend en documenten opgesteld die los staan van het uiteindelijke product en als logisch gevolg in de spreekwoordelijke la verdwijnen. Eeuwig zonde en ook slecht voor de reputa-tie van Architectuur. Eén van de oorzaken is mijn inziens het gebrek aan diep-gang wat vaak tentoongespreid wordt. De kreet Power-point Architect wordt vaak genoemd en uiteindelijk is dit niet wat de resultaten levert.Ik heb nogal wat discussies gehoord over wanneer archi-tectuur ophoudt en ontwerp begint. Mijn pragmatische kant is een beetje wars van dit soort discussies. Een ar-chitect is iemand die als eerste het overzicht heeft over zijn/haar domein, dat kan het IT landschap zijn, het pro-duct, het securitybeleid, het netwerk etc. Maar zeker in een projectomgeving is het cruciaal dat hij of zij ook snel kan schakelen en op zijn minst een volwaardig gespreks-partner is met de specialisten in het team. Een architect is geen specialist, maar moet wel specialistische kennis snel kunnen absorberen om de impact op het geheel te kunnen inschatten en besluiten te kunnen nemen.Het resultaat daarvan is dat een architect vaak een ma-

nusje van alles is in de kritieke fases van een project en dat zijn kennis van het totaal domein gebruikt om de pleisters op de juiste plekken te plakken. Misschien min-der romantisch, maar bijzonder waardevol.

Trends & OntwikkelingenVan welke trends en ontwikkelingen binnen het architec-tuur vakgebied of uw expertisegebied(en) heeft u hoge verwachtingen?

De specialist is dood, lang leve de generalist! Vele trend-watchers betogen dit al langer, dus ik kan geen buil vallen door dit te beamen: architectuur en de rol van de archi-tect verschuift naar de voorkant. Tergend langzaam, maar desalniettemin wordt er meer en meer gebruik gemaakt van beschikbare bouwstenen, of dat nu applicatie servi-ces zijn, cloud computing, frameworks of combinaties van deze bouwstenen.Het integreren van die beschikbare bouwstenen vergt andere, meer generalistische kennis dan het creëren van zo’n blokje zelf. En die specialistische kennis zal meer en meer verschuiven naar de grote productiebedrijven en geografisch gezien geleverd zal worden uit de zoge-naamde lage lonen landen. En dan niet eens omdat de kosten altijd zoveel lager zijn, maar simpelweg omdat deze hooggeschoolde capaciteit in onze regio niet in vol-doende mate voorhanden is.Wat altijd plaatselijk ter plekke zal moeten zijn, is de brugfunctie. De link tussen vraag en aanbod, de relaties tussen de verschillende disciplines. Dat vereist generalis-ten, maar dan wel generalisten met diepgang.Er zal een grote vraag ontstaan naar de technische ma-nager. Ervaren architecten die meerdere disciplines kun-nen overzien, maar die ook het proces kunnen sturen. De technische manager stuurt de inhoudelijke aspecten van een project en programma, schouder aan schouder met de project manager en delivery manager. Deze mensen zijn echter zeer schaars, niet in het minst omdat ze niet of nauwelijks opgeleid worden door de grote IT dienstver-leners. 4Synergy beweegt zich in dit veld door de bun-deling van zeer ervaren architecten, en het opleiden van medior architecten tot de hierboven beschreven genera-listen.

Gerco Grandia is werkzaam als Technical Manager / Solution Architect bij 4Synergy

maart 2011 XR Magazine

Heeft u ook interesse om uw mening, visie, kennis en ervaring te delen via de serie Profes-sionals over architectuur? Stuur dan een e-mail met uw naam, functie en naam van uw huidige werkgever naar: [email protected]

http://www.xr-magazine.nl/advertenties/advertentie-vea-training-mag-21.html

Volgende editie van XR Magazine:

Auditen, testen en reviewen


In de april editie van XR Magazine staan de onderwerpen Auditen, testen, reviewen onder architectuur én van architectuur centraal. Heeft u een duidelijke mening, eigen visie of boeiende praktijkcase over dit onderwerp? Dan zitten de lezers van XR Magazine op uw bijdrage te wachten!

Het ontwikkelen of beschrijven van een architectuur is één ding, maar het vaststellen of hetgeen dat uiteindelijk gere-aliseerd is deze gewenste architectuur heeft is vaak een ander verhaal. Hoe bepaalt men in welke mate de gewenste architectuur gerealiseerd is? En aan welke eisen dient de architectuurdocumentatie te voldoen om dit meetbaar te maken? Een ander vraagstuk is of de ontwikkelde architectuur zelf wel deugt en of het de juiste architectuur voor de juiste situatie is. Op welke wijze kan men dit vaststellen? In de april editie van XR Magazine staan deze vraagstukken centraal.

Wij zijn bijvoorbeeld op zoek naar artikelen met de volgende onderwerpen:• Wanneer is architectuurdocumentatie geschikt als testbasis?• Is IT-architectuur geschikt voor IT-auditing?• In welke mate draagt architectuur bij aan het realiseren van kwalitatieve oplossingen?• Hoe test of review je een architectuur?• Wanneer is de TO-BE of SOLL architectuur gerealiseerd?• De rol van architectuur in het testproces• Testen binnen een Service Oriented Architecture• Testen binnen een Cloud gebaseerde architectuur

Bijdragen voor de april editie kunnen ingezonden worden tot dinsdag 29 maart.

Indien u van plan bent een artikel te schrijven stuur dan zo snel mogelijk een e-mail naar [email protected] met daarin een globale omschrijving van de inhoud en onderwerp van het artikel. Op deze wijze kan plaatsing van het artikel in het magazine eerder gegarandeerd worden.

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. Het XR web-site bezoek groeit momenteel elke maand met 25%.

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.

Hoofdredacteur: Koen van Boekel, 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

BiZZdesign Academy

WWW.EAM-CONGRES.NL

‘Get Inspired’EAM2011 gaat vanuit de praktijkervaring van een groot

aantal organisaties in op de toegevoegde waarde van

enterprise architectuur voor de bedrijfsvoering van organi-

saties. Vragen als wat is de waarde van enterprise architec-

tuur, hoe creëer en gebruik je enterprise architectuur, en wat

bereik je met enterprise architectuur, staan tijdens EAM2011

centraal. Best-practices en voorbeelden uit de dagelijkse

praktijk worden gedeeld en besproken. Schrijf je dus vandaag

nog in via: www.eam-congres.nl.

Woensdag 16 maart

Advertentie in XR_v1.1.indd 1 13-12-2010 11:24:31

http://www.xr-magazine.nl/advertenties/advertentie-eam-2-mag-21.html

Date post:	20-Mar-2016
Category:	Documents
Upload:	redactie-xr-magazine
View:	216 times
Download:	3 times

XR_Magazine_21_2011

Documents