xr_magazine_26_2011

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

Editie 26 | September 2011www.xr-magazine.nl

Thema

ICT-infrastructuur

Stop Device Technologie en herstart de Informatie Technologie Infrastructuurarchitectuur

Tijd voor focus op functionaliteit en kwaliteit TOGAF en SABSA

Integratie is een stap dichterbij

Architectuur vóór informatie en niet tégen gebruikers

http://www.xr-magazine.nl/advertenties/26/advertentie-lac-mag-26-1.html

http://www.xr-magazine.nl/advertenties/26/advertentie-vnu-mag-26.html

In deze editie van XR Magazine staan nieuwe ontwikkelingen, visies, opinies en best practices op ICT-infra-structuur architectuurgebied centraal. De auteurs gaan in de artikelen onder meer in op de vragen: Wat is ICT-infrastructuur? Welke trends en technologieën zijn er op ICT-infrastructuur gebied? Hoe modelleer je de archi-tectuur van de ICT-infrastructuur? Dit en meer leest u deze maand in XR Magazine.

ICT-infrastructuur architectuur

Inhoud

Een IT infrastructuur model 4

Architectuur vóór informatie en niet tégen gebruikers 6

Infrastructuurarchitectuur: tijd voor focus op functionaliteit en kwaliteit 18

De ideale ICT-infrastructuur architectuurplaat 12

Implementatie van IPv6 in de ICT-infrastructuur 26

Hoe duurzaam koopt de overheid ICT in? 30

september 2011 XR Magazine

Do you know how to

eXceleRate? We do!

3

Thema

De artikelen in XR Magazine beslaan onder andere opiniestukken, ver-diepingsartikelen, best practices, interviews en recensies op het gebied van enterprise architectuur, bedrijfs- en ICT-architectuur en aanverwan-te vakgebieden. Dit magazine is samengesteld op basis van artikelen die op de website van XR Magazine zijn geplaatst.

Column: Teveel IT 34

Integratie van TOGAF en SABSA een stap dichterbij 35

Overheid en service-oriëntatie: beschrijving van een SOA audit 36

‘Visuele Enterprise Architectuur hoort thuis in hoger onderwijs’ 50

Een eenvoudig alternatief voor de Data Vault 44

Rubrieken

http://www.xr-magazine.nl/advertenties/26/advertentie-vnu-mag-26.html

Het woord infrastructuur is samengesteld uit de woorden infra (onder) en structuur. Het omvat alle componenten die beschikbaar zijn “onder de structuur”. Welke struc-tuur bedoeld wordt is afhankelijk van het gezichtspunt. In de fysieke wereld verwijst de term infrastructuur vaak naar openbare nutsvoorzieningen, zoals water, elektrici-teit, gas, riolering en telefoondiensten - onderdelen let-terlijk onder de structuur van een stad.

Infrastructuur is meestal onzichtbaar en vanzelfsprekend. Als de bedrijfsprocessen worden beschreven, is de in-formatie die wordt gebruikt in het proces erg belang-rijk. Voor de business analist maakt het vervolgens niet uit hoe deze informatie wordt beheerd met behulp van IT-systemen. Voor hem speelt zich dat af “onder de op-pervlakte”. Hij beschouwt IT-systemen dus als infrastruc-tuur. Voor gebruikers van IT-systemen zijn applicaties be-langrijk. De manier waarop ze worden geïmplementeerd is onzichtbaar (onder de oppervlakte), zij beschouwen dat als infrastructuur. En voor systeembeheerders is het

gebouw waarin de servers worden gehost en het elektri-citeitsbedrijf deinfrastructuur. Dus wat infrastructuur om-vat, is sterk afhankelijk van aan wie je het vraagt!Enkele algemene IT infrastructuur kenmerken zijn:• IT infrastructuur levert diensten aan applicaties.• IT infrastructuur wordt meestal gedeeld door meer-

dere applicaties.• IT infrastructuur is meer statisch en permanent dan

de applicaties die erop draaien.• Het beheer van de infrastructuur is gescheiden van

het beheer van de applicaties die er gebruik van ma-ken.

Als infrastructuur architect heb ik natuurlijk mijn eigen standpunt. Mijn definitie van IT infrastructuur is: ‘IT infrastructuur is de totale set van de fundamentele bouwstenen en niet-functionele eigenschappendie het mo-gelijk maken applicaties te laten functioneren.’Om een afbakening te maken van wat er wel en wat er niet onder infrastructuur valt, hanteer ik het model (raam-werk) dat is weergegeven in figuur 1.Het model toont de bouwstenen die samen de IT infra-structuur vormen. Deze bouwstenen zijn (van boven naar beneden):• End User Devices - De apparaten die worden ge-

bruikt door eindgebruikers om te werken met appli-caties, waaronder pc’s, laptops, thin clients, mobiele

4 XR Magazine september 2011

IT infrastructuren bestaan al een hele tijd. Maar opvallend is dat er geen algemeen aanvaarde defini-

tie van IT infrastructuur lijkt te bestaan. Veel mensen hebben een ander beeld van wat wordt verstaan

onder IT infrastructuur. In dit artikel geef ik een definitie en introduceer ik een IT infrastructuur model

(raamwerk) met bouwblokken waaruit een infrastructuur bestaat.

Sjaak Laan

Een IT infrastructuur modelEen afbakening van zaken onder de oppervlakte

ICT-infrastructuur

Wat infrastructuur omvat, is sterk afhankelijk van aan

wie je het vraagt!

Reageren op dit artikel? Klik hier.

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

apparaten en printers.• Besturingssystemen - Een bestu-

ringssysteem is een verzameling programma’s die in een server de interne werking beheert: het geheu-gen, de processors, de randappara-tuur en het bestandssysteem.

• Virtualisatie - Virtualisatie fun-geert als een abstractielaag tussen het besturingssysteem en de server hardware. Virtualisatie zorgt dat een fysieke machine kan draaien met meerdere besturingssystemen.

• Opslag - Servers kunnen beschikken over interne opslag, zoals harde schij-ven, maar ze kunnen ook gebruik maken van externe opslag. De op-slagbouwsteen bevat harde schijven, tapes, Direct Attached Storage (DAS), Network Attached Storage (NAS) en Storage Area Networks (SAN).

• Netwerken - Het netwerk is een zeer belangrijke bouwsteen van een infra-structuur. Afhankelijk van de omge-ving kan een netwerk zeer complex worden. De netwerk bouwsteen om-vat routers, switches, firewalls, WAN (Wide Area Network), LAN, dial-in, internettoegang en VPN’s (Virtual Private Network) en relatief eenvou-dige diensten, zoals DNS, DHCP en NTP, die noodzakelijk zijn voor de in-frastructuur zelf.

• Servers - Servers zijn de computers, draaiend in het datacenter.

• Datacenters - Over het algemeen is hardware geïn-stalleerd in een datacenter. Datacenters leveren (on-onderbroken) stroomvoorziening, koeling, computer racks en beschikbaarheids- en veiligheidsmaatrege-len.

Verticaal staan drie essentiële niet-functionele attributen van de infrastructuur:• Beveiliging - Infrastructuur beveiliging omvat voor-

namelijk technische oplossingen, zoals VPN’s (Virtual Private Networks), IDS (Intruder Detection Systems), toegangscontrole en encryptie.

• Beschikbaarheid - Beschikbaarheid omvat zaken als backup, restore, business continuity, failover, high availability clustering en replicatie.

• Performance - De performance van een IT infra-structuur is afhankelijk van schaalbaarheid, virtua-lisatie, caching, load balancing, Quality of Service (QoS) en high-performance clusters.

Deze niet-functionele eigenschappen worden beïnvloed door de configuratie van elk van de infrastructuur bouw-stenen. Hoewel nog veel meer niet-functionele eigen-schappen kunnen worden gedefinieerd, zijn deze drie bijna altijd de essentiële eigenschappen binnen IT infra-structuur architecturen. De niet-functionele eigenschap-pen dienen niet alleen binnen de infrastructuur te worden geïmplementeerd, maar ook in de bovenliggende lagen (zoals middleware, databases, applicaties, processen en informatiestromen). Daarom zijn deze verticale balken ook door alle lagen heen getekend.Om het model heen staat systeembeheer als het centrale proces voor het onderhouden van alle componenten in het model. Integraal systeembeheer zorgt voor een sta-biele omgeving, nu en in de toekomst.

Sjaak Laan werkt bij Logica als Principal IT Architect en heeft 22 jaar IT ervaring.www.sjaaklaan.nl

5september 2011 XR Magazine

Figuur 1: IT infrastructuur model

End User Devices

Datacenters

Servers

Networking

Storage

Virtualization

Operating Systems

Middleware / Databases

Processes / Information

Applications

Systems Management

Avai

labi

lity

Perf

orm

ance

Secu

rity

Infrastructure

De nieuwe media, en inmiddels ook de oude, staan vol van de goodies op het gebied van ICT. De vooruitzichten van kostenverlaging, functionaliteit uitbreiding en inte-gratie zijn legio. De business verwelkomt dit van harte. Uit marktoverwegingen of misschien ook uit onvrede met de huidige ICT dienstverlening?Het voorbeeld van de smartphone is al bijna versleten. “Waarom kan ik dat niet gewoon met mijn telefoon doen zoals thuis?” Deze vraag is zowel onterecht als terecht. Het is onterecht, omdat diezelfde business jarenlang heeft gehamerd op veiligheid en controle. De verantwoording

voor informatiebeveiliging werd volledig naar de ICT ge-schoven, die vrijwel automatisch de schuld kreeg in geval van een incident met betrekking tot continuïteit en/of vei-ligheid. Het is dan ook helemaal niet gek, dat het instinct van de huidige ICT managers op controle is gebaseerd.De vraag is anderzijds ook wel terecht, want ICT kan toch

zo makkelijk mee schakelen met de veranderende be-hoefte? Het is toch zo flexibel en modern? Dus vanuit dat oogpunt is het logisch dat de business op tafel gooit, dat de gemiddelde consument veel meer kan dan de gebrui-ker in zijn eigen bedrijf.Wat zijn nu de trends en hoe komen we uit deze impasse?

Macro trendsVerschillende ontwikkelingen kunnen worden onder-scheiden die op hoog niveau de richting van ICT diensten beïnvloeden. En die dus meegenomen moeten worden in architectuurbeschouwingen. Een paar voorbeelden:

De gebruiker wordt ‘ICT slimmer’ICT is een integraal onderdeel van vele opleidingen. Dit is al een tijdje zo en dus is de jonge generatie erg gemak-kelijk in ICT. Dit is tweeledig. Enerzijds zijn ze gewoon technisch handig en kunnen een heleboel zelf doen en oplossen. Anderzijds weten ze zeer goed voordeel te trekken uit ICT functionaliteit. Het is gewoner om naar Google te grijpen, dan een intern informatiesysteem te gebruiken.

De werknemer wordt ‘losser’De arbeidsverhoudingen veranderen en begrippen als pensioen en jubileum zijn welhaast archeologische be-grippen voor de nieuwe werknemer. Ook zien we de


De cloud schuurt tegen de oude infrastructuur aan en dat geeft gedonder. De grote voordelen van een

goede infrastructuur architectuur, aldus de architecten, zijn flexibiliteit en toekomstvastheid. Waarom

past die cloud dan niet in mijn infrastructuur? Infrastructuur op basis van controle over gebruikers en

hun systemen voldoet niet meer aan de vraag van de business. Terug naar de basis, de informatie. Wie

was daar ook alweer eigenaar van? Hoe ontsluiten we dat naar de gebruikers? Waar en hoe dan ook.

Harry Potma

Architectuur vóór informatie en niet tégen gebruikersStop Device Technologie en herstart de Informatie Technologie

ICT-infrastructuur

De verantwoording voor informatiebeveiliging is in de

loop der tijd volledig naar de ICT geschoven



werkgever meebewegen (of sturen ze juist deze ontwik-keling?) en is loyaliteit ingeruild voor flexibiliteit.

De locatieonafhankelijke kenniswerkerWerkzaamheden worden veel meer kennis dan fysiek gedreven. Er moet voortdurend geleerd worden en de processen worden steeds ingewikkelder. De locatie van waaruit gewerkt wordt is niet meer van belang, als er maar toegang is tot de betreffende informatie.

De business is locatieonafhankelijk, globaal en erg dyna-mischProducten gaan de hele wereld over. Een ‘Nederlands’ productie bedrijf kan zijn producten ontwerpen in Italië, laten maken in China en service verlenen vanuit Polen. En dat kan dan morgen weer anders zijn als er een bedrijf wordt toegevoegd of een leverancier wordt ingewisseld voor een andere leverancier.

De keten wordt echt integraalDe lopende band van vroeger met grondstof aan de ene kant en eindproduct aan de andere kant bestaat nog wel, maar ligt nu globaal en is samengesteld uit vele schakels. Maar de verschillende bewerkingsstations moeten nog steeds goed aansluiten. En met de beweging naar een compositie van diensten en niet meer van fysieke hande-lingen aan het product verschuiven ook de ICT behoeftes.

Voeg daarbij nog het delegeren van details en het sturen op verantwoording van onderaannemers, dan is de infor-matie meteen ook overal. Maar deze informatie moet wel overal toegankelijk zijn en uiteindelijk ook weer gecom-bineerd kunnen worden.

ICT infrastructuur architectuur van gisterenDit zijn wat voorbeelden van trends waar het ICT domein het moeilijk mee lijkt te hebben. Laten we eens terugkij-ken naar de ICT infrastructuur van gisteren. Wat bepaalt nu de gedachtegang? Wat is nu kenmerkend voor de in-

frastructuren die over de afgelopen jaren en decennia zijn gemaakt?Eerst was er slechts een centrale computer waar je fy-siek bij moest zijn om er überhaupt iets mee te kunnen doen. Later kwamen hier terminals bij, die vaak nog in afgesloten rekencentra stonden; in grote zalen. Maar


Wat is nu kenmerkend voor de infrastructuren die over de afgelopen jaren en decennia

zijn gemaakt?

Foto

: Kon

stan

tin

Kik

vid

ze /

Shu

tter

stoc

k.co

m

alles draaide centraal, de eindgebruiker had slechts een kijkgaatje via een ‘domme’ terminal. Kortom, de gebrui-ker onder controle, binnen de beveiliging.Met de komst van netwerken tussen de centrale delen en de eindgebruiker en met de opkomst van de rekenkracht bij de gebruiker kwam er een nieuwe uitdaging. Wat deed die gebruiker? Is dat wel zuivere koffie? De busi-ness werd ongerust, de ICT nam de verantwoording aan en probeerde de eindgebruikers weer onder controle te krijgen. De werkplekken werden binnen de grenzen van de organisatie getekend en elke verbinding met de bui-

tenwereld werd kritisch bekeken. Nu is internettoegang gewoon, maar nog niet zo lang geleden moest een eind-gebruiker daar specifiek toestemming voor vragen.De architectuur kenmerkt zich dus door het onder con-trole houden van de totale infrastructuur, dus inclusief de devices van de eindgebruikers en de boze buitenwereld. Dat vroeg de business toch?

ICT trendsKijken we met een ICT oog naar de macro trends, dan kunnen we de volgende onderwerpen onderkennen:• De gebruikersgemeenschap is niet meer in te delen

in intern en extern. Er zijn tijdelijke krachten, die werkzaamheden binnen het bedrijf uitvoeren. Er zijn vaste medewerkers, maar ook die blijven niet lang. Er zijn anonieme consumenten, die toegang hebben tot bijvoorbeeld productinformatie en een bestelling plaatsen. Er zijn medewerkers van leveranciers, die diep kunnen ingrijpen in het kernproces, van buiten af.

• De gebruikersgemeenschap is ook erg dynamisch. Door het tijdelijke karakter van de werknemer-werk-gever relatie is er al dynamiek, maar door de reor-ganisatie en fusiedrang van de business komt er nog het een en ander bij.

• De eindgebruiker devices tonen een grote variatie met snel opeenvolgende modellen aan smartphones, tablets en PC’s. Ook de locatie ervan is niet meer con-stant. Daarnaast is het gebruik van deze apparaten ook sterk dynamisch. De functionaliteit groeit vanuit een technologische push, maar ook vanuit de nieuwe Y-generatie. Voeg daar nog bij een vermenging van privé en zakelijk gebruik, dan krijgen we werkelijk:


any place, any time, any device.• Informatie en de toegang daartoe wordt steeds kri-

tischer. Processen zijn erg geïntegreerd en worden overal uitgevoerd door allerlei partijen op verschil-lende locaties. En alles moet veilig volgens wette-lijke verplichtingen en of volgens business ongerust-heid.

• Cloud diensten zijn gearriveerd. ICT partijen op de markt hebben weer een aantal treden op de waar-deladder genomen en willen direct aansluiten op de procesgedachte. Kant-en-klare functionaliteit, direct

op het bureau van de eindgebruiker. Echter, verantwoording, koppe-ling en ondersteuning zijn oude uitdagingen waar de wolk nieuwe di-mensies aan geeft.

Een reflectieAls we dit dan zo over-

wegen, dan lijkt het één grote ellende en is werken in de ICT infrastructurele diensten meer een straf dan een car-rière. Waar is de uitweg?Informatie Technologie blijft de juiste benaming van het vakgebied. Techniek (even inclusief de betreffende diensten) om informatie te ontsluiten naar de gebruikers daarvan; en die vormen de business.Dit zegt niets over eigenaarschap van of verantwoording voor de informatie zelf. Over de jaren heen is - haast on-gemerkt - de verantwoording naar de ICT afdeling ge-schoven. Als we dat nu eens opnieuw bekijken, dan vin-den we wellicht de uitweg. De informatie bepaalt het proces en de business bepaalt daarvan het belang, de inhoud, de eigenaar, de beveiligingseisen etc. De gemakkelijke weg van ‘alles bewaren’ en ‘alles is belang-rijk’ is niet meer te handhaven als gevolg van de totale omvang en de compositie van verschillende partijen over de processen heen. De business moet het eigenaarschap van de informatie weer terugkrijgen en hiernaar hande-len.Ook techniek verdient een evaluatie. In mijn beleving be-treft het techniek, die té ver van de gebruiker zelf staat. De analogie met de telefoon is sprekend. Vroeger moest je een gesprek aanvragen en was er een dienst die de technische handelingen verrichtte om de verbinding tot stand te brengen. Nu drukt iedere gebruiker zelf zijn nummer in. Dat is dus geen ‘techniek’ meer. En het wordt tijd, dat we dit toepassen op de eindgebruiker devices van vandaag. Op basis van deze reflectie kunnen we de volgende uit-gangspunten formuleren:• De business is verantwoordelijk voor de informatie;• De eindgebruiker devices zijn geen techniek meer.

Controle houden over de totale infrastructuur, inclusief de devices van de

eindgebruikers en de boze buitenwereld. Dat vroeg de business toch?



ICT infrastructuur architectuur van morgenVanuit deze uitgangspunten kunnen we de oude basis- gedachte van vele infrastructuren laten varen; de grens-verdediging. Het is een verloren strijd om te bepalen wat de grens nu weer is en wie er dan binnen of buiten is. In plaats daarvan moeten we een Toegang-gedachte invoe-ren. En dan betreft het toegang tot de informatie van de business.De business - als eigenaar van de informatie - bepaalt, wie, wanneer, waartoe toegang moet hebben. Pas daarna is het een taak voor de ICT om dat te regelen.Door de eindgebruikersystemen eigenlijk los te laten, re-aliseren we een grote verlichting aan de ICT kant en ook aan de eindgebruiker kant. Wel even oppassen, dat we niet het ene dogma voor het andere inruilen. Die gebrui-kers die nog wel een gemanagede werkplek willen met

bijbehorende support moeten dat kunnen krijgen. Maar dat zijn dan ook de ‘gemakkelijke’ gebruikers.De belangrijkste uitdaging van de nieuwe ICT infrastruc-

tuur is vervolgens het regelen van toegang op sessie ba-sis. De ervaring met Identity Management en Single Sign On van de laatste jaren stemmen hoopvol, maar hier


De business - als eigenaar van de informatie - bepaalt

wie, wanneer, waartoe toegang moet hebben

Figuur 1: Van grens verdediging naar toegang verdediging

Toegang verdediging

Grens verdedigingGebruiker - bekend

Gebruiker - onbekend

Device - managed

Device - unmanaged

Informatie

Trend

Defensie

Legenda:

ligt nog wel huiswerk. Ook aan de applicatie kant, want de applicaties als toegang naar de informatie zullen zich moeten ‘gedragen’ in de nieuwe architectuur.

Het pad naar de nieuwe infrastructuurVanzelfsprekend is dit niet van vandaag op morgen ge-regeld. Factoren voor de migratie zijn mind-set, legacy, kosten en vooral het terugbrengen van de informatiever-antwoordelijkheid naar de business. We hebben dan ook naast een technische uitdaging een verandermanage-ment uitdaging te pakken. Niet echt een talent van de ICT sector...Toch zijn er legio pragmatische middelen om in te zet-ten; centraliseren van applicaties, Server Based Compu-ting oplossingen, web technologieën, virtualisatie etc. We kunnen de moderne ICT gereedschapskist gewoon inzet-ten.En voor de nieuwe ontwikkelingen moeten we meteen de juiste manier van inpluggen toepassen. Iedere dienst moet de toegang definiëren en beleggen bij de business. Vervolgens faciliteert ICT, bij voorkeur via een generieke oplossing zoals een enkelvoudige identity repository.

En die cloud dan?Cloud diensten zijn gewoon ICT diensten. En die moe-ten zich dus ook conformeren aan de toegangsgedachte. Generieke diensten uit de cloud (bijv. storage) kunnen


direct gekoppeld worden in het groene hart. Functione-le diensten (bijv. CRM) moeten ook via het groene hart, want daar wordt bepaald wie, wat, wanneer mag benade-ren. En dit is dus inclusief situaties waarbij de informatie uit de cloud teruggehaald moet worden.

ConclusieOver de jaren hebben we de verantwoording voor de in-formatie laten afdwalen naar het ICT domein. Dit moet weer terug naar de business, waarbij ICT slechts facili-teert. De eindgebruiker devices, zoals iPhones, tablets en thuis pc’s, zijn geen techniek meer en hoeven dus ook niet meer te worden gecontroleerd vanuit de ICT functie.

Harry Potma is Principal Consultant tussen ICT en business bij Atos Consulting. www.atos.net

Figuur 2: De cloud aangesloten op de informatie van de business

Cloud diensten zijn gewoon ICT diensten en moeten zich dus ook conformeren aan de

toegangsgedachte



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

Hoewel infrastructuur vaak stereotype wordt afgebeeld als een kast met ijzer waar wat draadjes met stekkers uithangen is de infrastructuur laag van de ICT natuurlijk meer dan dat. De zeven belangrijkste bouwblokken van iedere ICT-infrastructuur zijn eindgebruikersapparaten (o.a. desktops, PDA’s, tablets en smartphone’s), opslag-systemen, servers, informatiebeveiliging, communicatie en netwerk, middleware en infrastructuur software en ten slotte ICT management systemen t.b.v. operations. Dat lijkt een simpel en overzichtelijk geheel, maar zodra je je er wat in verdiept, blijkt een en ander in belangrijke mate geïntegreerd te zijn met elkaar. Voor je het weet kij-ken we tegen een complex[1] samenwerkend geheel aan, wat goed op elkaar afgestemd moet zijn om er optimaal rendement uit te halen. Een complex geheel wordt echter weer eenvoudig te begrijpen wanneer we het in logische componenten uiteen laten vallen. In dit artikel wordt dit dan ook gedaan aan de hand van de Inter Access Infra-structuur Referentie Architectuur.

Inter Access Infrastructuur Referentie Archi-tectuur (IAIRA)De plaat, zoals weergeven in figuur 1, is bij Inter Access over de afgelopen jaren met vele collega’s ontwikkeld en dit artikel bevat de eerste op zichzelf staande korte be-schrijving daarvan. De naam is de Inter Access Infrastruc-tuur Referentie Architectuur, of kortweg IAIRA (spreek uit

Aira). De IAIRA is opgebouwd door middel van vijf lagen en twee kolommen zoals afgebeeld in figuur 1. De blok-ken beschrijven het volgende:• Presentation Services - Deze laag beschrijft de ar-

chitectuur waarop applicaties aan de gebruikers be-schikbaar worden gesteld;

• Applications - Deze laag beschrijft welke applicaties gebruikmaken van de ICT-infrastructuur (infrastruc-tuur applicaties, kantoorautomatisering en Business applicaties);

• Infrastructure Services - Deze laag beschrijft welke infrastructuur services nodig zijn om de applicaties gebruik te kunnen laten maken van de ICT-infrastruc-tuur en de voorzieningen die nodig zijn om beheer uit te kunnen voeren;

• Platform Services - Deze laag beschrijft de plat-formen waarop de infrastructuur services draaien. Denk hierbij aan (gevirtualiseerde) servers, storage, netwerkcomponenten – tezamen ook wel core infra-structure genoemd;

• Datacenter services - Deze laag beschrijft de as-pecten die van belang zijn bij het huisvesten en aan-sluiten van de ICT hardware;

• Security Services - Deze laag geeft kaders en con-text in relatie tot informatiebeveiliging waaraan de overige lagen moeten voldoen qua Beschikbaarheid, Integriteit en Vertrouwelijkheid (BIV);


De ideale ICT-infrastructuur architectuurplaat? Een tamelijk prestigieuze aanhef voor een modellering

van iets waar net zoveel mogelijkheden voor zijn, als antwoorden op de vraag ‘Wat is ICT-infrastruc-

tuur?’ Want infrastructuur heeft verschillende betekenissen voor mensen. Bestaat de ideale plaat dan?

Nee, maar in dit artikel wordt wel een plaat beschreven waarmee de gehele infrastructuur goed mee

te positioneren valt en waarmee ook de applicatie-, informatie- en business architecten goed uit de

voeten moeten kunnen.

Vincent AWG Jansen

De ideale ICT-infrastructuur architectuurplaatIntroductie Inter Access Infrastructuur Referentie Architectuur

ICT-infrastructuur



• Management Services - Deze laag geeft kaders en best prac-tices voor management en or-ganisatie van (onder andere) de infrastructuur op basis van ITIL v3 en legt daarmee de relatie tussen infrastructuur, processen en mensen.

In de volgende paragrafen wordt de plaat van onder naar boven en van links naar rechts behandeld. De ge-laagde vorming maakt het mogelijk om per laag een onderwerp min of meer af te bakenen. Elke volgende laag maakt gebruik van services die zijn behandeld in de onderlig-gende laag (en dus in voorgaande paragraaf) wat tot een logische en gefundeerde opbouw leidt.

Datacenter ServicesIn figuur 2 staat een onderverdeling weergegeven van de datacenter services. Het gaat hier in essentie om de housing: de plaats waar de centrale apparatuur komt te staan. Het kan zowel om een bezemkast gaan als een tier-3 gecertificeerd professioneel datacenter.Items die hier altijd terugkomen staan in figuur 2 afgebeeld: de lo-catie dient over voldoende stroom te beschikken voor de hardware en ook voor de koeling daarvan. Er dient een noodstroomvoorzie-ning te zijn (aggregaat of tweede type aansluiting) en/of een ‘batte-rij’-voorziening om een normale shutdown te kunnen draaien bij stroomuitval. Er dient berekend te worden hoeveel ‘racks’ er dienen te zijn en de daarmee af te nemen m2 vloerruimte. Er dient bepaald te worden wie wanneer toegang mag hebben tot het gebouw/ruimte. Het dient bekend te zijn welke brandblusmaatregelen er zijn getroffen en hoe de ope-rator wordt gealarmeerd bij ongeregeldheden. Deze zijn deels ingegeven door het vraagstuk beschikbaarheid en continuïteit. Andere overwegingen vanuit informatie-beveiliging zijn: Waar staat het pand? Kan het onder wa-ter lopen? Zijn er aardbevingen? Is er uitwijk geregeld naar een ander pand? Hoeveel moeite gaat het kosten om deze locatie aan te sluiten op het bedrijfsnetwerk? Belangrijke kenmerken die op dit niveau al spelen zijn

de Recovery Point Objective (RPO) en de Recovery Time Objective (RTO) die respectievelijk informatie verschaf-fen over hoeveel tijd verstreken mag zijn sinds de laat-ste volledig herstelbare back-up (het punt in het verle-den dan na uitval teruggehaald kan worden) en de tijd die het mag duren voordat relevante informatiesystemen voldoende hersteld zijn zodat gebruikers ze weer kunnen gebruiken (gemeten na het ontstaan van de uitval tot het moment dat gebruikers weer kunnen werken). In beide begrippen zit behoorlijke diepgang die hier niet verder verkend zal worden. De tendens is dat aan beide steeds hogere eisen gesteld worden en beide dus steeds kor-


Figuur 1: Inter Access Infrastructuur Referentie Architectuur

Figuur 2: IAIRA laag 1 - Datacenter Services

ter worden, bijvoorbeeld RPO=24h en RTO=24h, en dit vraagt om pas-sende maatregelen op datacenter niveau.

Platform ServicesDe Platform Services zijn gebaseerd op de voorzieningen in de Datacen-ter Services laag. Zoals figuur 3 laat zien bevat deze laag de core infra-structuur componenten Servers, Storage en Network en in zekere ab-stracte vorm ook de End User Devi-ces. Op de platformlaag moeten dus hardware keuzes gemaakt worden, inclusief de kenmerken en keuzes op het gebied van virtuele hardware (server virtualisatie, netwerk virtua-lisatie, storage virtualisatie etc.)Op deze laag worden tevens keu-zes gemaakt ten aanzien van stan-daardisatie op fysieke en virtuele hardware en bijbehorende software zoals het server besturingssysteem, netwerk besturingssysteem, fabrics etc. Het loont vaak de moeite om op deze laag al hard te standaardiseren op merk en type (hardware, firmwa-re en software).Ook hier spelen weer vragen van-uit beschikbaarheid: Hoe zorg ik ervoor dat mijn data beschikbaar is in een ander datacenter? Welke opslagvoorzieningen moeten ge-troffen worden? Welke performance is nodig voor mijn opslag (IOPS) en servers (snelheid van processo-ren)? Welke capaciteit is benodigd (aantal processoren/servers, hoe-veelheid geheugen etc.) en welk aantal en type disken. Wat is de verwachtte toename in dataopslag? Welke bandbreedte heb ik nodig om aan te sluiten op het bedrijfsnetwerk en voor de replicatie van data naar een ander datacenter? En is clustering van servers noodzake-lijk? Welke voorzieningen moeten worden getroffen om ongewenst netwerkverkeer buiten de deur te houden ter-wijl legitieme gebruikers en beheerders normaal kunnen werken? Worden de telefoonlijnen en –centrales geïnte-greerd in het netwerk en werkplek (VOIP)? Van invloed is ook het vervangings/afschrijvingsbeleid, de bewaar- en archieftermijnen voor gegevens en andere beleidsregels. Met de antwoorden op deze en vele andere vragen wordt het WAN en LAN plaatje gemaakt, de opslaginrichting


bepaald en het serverplatform vorm gegeven.

Infrastructure ServicesDe Infrastructure Services (zie figuur 4) bevat de services die gebaseerd zijn op de core infrastructuur componen-ten en bieden de mogelijkheden om deze te laten gebrui-ken door eindgebruikers en applicaties. Dit zijn tevens de componenten waarmee operationeel beheer in de meest voorkomende omgevingen vaak op dagelijkse basis mee te maken heeft. De behandeling van deze laag beperkt zich hier tot enkele hoofdcomponenten.Identity & Access management draait om het toepassen

Figuur 3: IAIRA laag 2 - Platform Services

Figuur 4: IAIRA laag 3 - Infrastructure Services



van een of andere vorm van Directory Services - waar-in o.a. de gebruikers accounts opgeslagen worden - en het integreren ervan met andere systemen. Voorbeelden hiervan zijn Microsoft Active Directory en Linux Realms, maar ook het uitvoeren van Role Based Access Control (RBAC). Anti-malware omvat onder andere voorzieningen voor integrale bestrijding van virusssen en ongewenste e-mail op desktops, servers, firewalls, document manage-ment systemen en meer.OS deployment services zijn er voor om de geautomati-seerde installatie en inrichting van besturingssystemen op servers en desktops goed te laten verlopen. Daarnaast speelt Application Deployment, of tegenwoordig liever Application Delivery, een belangrijke rol om de gebrui-kers te laten beschikken over de door hen benodig-de applicaties, afgestemd op het end user device van hun keuze. Hierin is applica-tie virtualisatie belangrijk, maar ook desktop virtuali-satie – het ontkoppelen van de visuele desktop van het onderliggende end user de-vice – en de beschikbaarheid van webbrowser gebaseer-de applicaties. Ook vinden we hier de hulpmiddelen voor Workspace management ten behoeve van een consisten-te gebruikerservaring, ongeacht het endpoint device, ge-koppeld aan eenvoud van beheer. Direct gerelateerd aan OS deployment en Application Delivery zijn de Configu-ration Management Services waarmee een configuratie baseline ingericht en bewaakt kan worden op consisten-tie en afwijkingen en patches worden toegepast.Databases services bevat de gestructureerde opslag van data in de vorm van databases en database services om die data te ontsluiten aan applicaties. Er wordt doorgaans onderscheid gemaakt tussen database inrichting voor in-frastructurele applicaties (alle infrastructure services die een database nodig hebben) en Line Of Business applica-ties. In het laatste geval fungeert database services vaak als een hoeksteen voor de Enterprise Service Bus.De integrale bewaking van ICT componenten op alle la-gen in IAIRA is een taak voor Monitoring services. Door al of niet visuele gezondheidsdiagrammen wordt inzich-telijk of de infrastructuur en applicaties naar behoren functioneert en presteert. Er worden in meer of mindere mate geautomatiseerde acties uitgevoerd bij afwijkin-gen of een event afgetrapt in het incident management proces en gerapporteerd over het nakomen van Service Level Agreements (SLA). Met data protection & recovery services wordt de back-up en hertel acties op de core in-frastructuur laag aangestuurd en de archivering van in-formatie geregeld. File & Print services zorgen ervoor dat gebruikers hun bestanden kunnen opslaan op de opslag-

ruimte en documenten kunnen afdrukken. Remote Ac-cess services zorgen ervoor dat gebruikers ook buiten de kantoormuren gebruik kunnen maken van de geboden voorzieningen, bijvoorbeeld door middel van een veilige portal of gebruikersvriendelijke VPN verbindingen. Met Licensing worden services ingericht die grenzen stelt aan het gebruik van software om in compliance te blijven met afgenomen licenties en/of rapporteert over gebruik van software. De network services tenslotte zorgen er onder andere voor dat netwerkadressen automatisch worden toegekend en dat computernamen in adressen worden vertaald. Hier horen ook de componenten thuis waarmee het netwerk (verkeer) verder geoptimaliseerd wordt, de zogenaamde traffic managers en - shapers.

Application ServicesOp de applicatielaag van IAIRA (figuur 5) komen we een driedeling van applicaties tegen die allen gebruikmaken van de onderliggende lagen. Grofweg behelst de driede-ling die van:1. de typische business applicaties die elke organisatie

uniek maakt;2. front-end applicaties die op iedere desktop moeten

voorkomen met een look and feel van een lokale im-plementatie (office applicaties zoals een rekenblad, presentatiesoftware, webbrowser, e-mail etc.), kort-weg de Kantoorautomatisering (KA) genoemd;

3. de back-end applicaties die in bijna elke organisatie voorkomen, maar waarvoor het niet praktisch is een business eigenaar aan te wijzen als eigenaar (e-mail service, document management, telefonie en confe-rencing service etc.).

Er zijn altijd wel een aantal herkenbare business applica-ties zoals een HRM systeem, financieel systeem of bran-che specifiek informatiesysteem. Anders dan 2 en 3 is dit echter volledig het domein van de informatie & applicatie architectuur, kortweg informatisering. De opname hier-van op deze plek in IAIRA is meer uit oogpunt van kennis nemen van het applicatielandschap met het oog op ge-meenschappelijk gebruik, capaciteitsplanning en toe te passen standaarden in de infrastructuur zoals databases. Op dat punt hebben infrastructuur en informatisering ge-meenschappelijke belangen. Vanzelfsprekend is er vaak ook een front-end gedeelte van business applicaties


Application Delivery speelt een belangrijke rol om gebruikers te laten beschikken over de benodigde applicaties, afgestemd op het

end user device van hun keuze

die beschikbaar worden gemaakt door de infrastructuur adequaat in te richten, zie Deployment Services en Application Delivery op de Infra-structure Services laag.De kantoorautomatisering is juist wel weer volledig onderdeel van de infrastructuur. Het betreft hier de relatief eenvoudige applicaties zoals eerder genoemd. Wie echter al eens een poging heeft onderno-men om te migreren van de ene of-fice suite naar de andere (MS Office naar Open Office en vice versa) of een upgrade van een of meer ver-sies weet als geen ander hoe weinig eenvoudig dat kan zijn. Dat komt omdat de KA applicaties vaak heel veel relaties hebben met andere applicaties en men ook meteen de productiviteit van eindgebruikers aantast en de beschikbaarheid van informatie in het geding komt.De laatste categorie is Collabora-tion. Deze back-end applicaties zijn de toepassingen die typisch door grote delen van de organisatie ge-bruikt worden en nodig zijn om me-dewerkers in staat stellen om goed samen te werken, zoals e-mail en portals. Een relatief nieuwe verza-melnaam voor enkele collaboration toepassingen is Unified Communi-cations. Dit laat e-mail en voicemail bij elkaar komen, maakt onderling chatten mogelijk als tussenvorm tussen bellen en mailen. Het toont presence informatie en stelt gebrui-kers op eenvoudige wijze in staat zelf voice en video conferencing te starten. Door al deze middelen te in-tegreren met vaste telefonie, Voice over IP en mobiele telefonie ontstaan nieuw mogelijkhe-den die de productiviteit een boost geven. Veelal zijn dit de technologie bouwstenen voor het moderne leren, ont-dekken, leiden, innoveren en samenwerken – of kortweg ‘het nieuwe werken’.

Presentation ServicesDe Presentation Services laag ten slotte (zie figuur 6) is de laag die applicaties zichtbaar maakt voor gebruikers en hier vindt dan ook de interactie met gebruikers plaats. Key point is dus de hedendaagse enorme hoeveelheid aan endpoint devices die al dan niet ondersteund of zelfs


beheerd moeten worden.Indien een endpoint device wordt verstrekt door de or-ganisatie en locked down beheerd wordt is er sprake van een trusted endpoint. Organisaties die kiezen voor een Bring Your Own Device (BYOD) beleid of onbeheer-de thuiswerkplekken, werken in principe met untrusted endpoints. Daarnaast zijn nog andere, hybride, vormen denkbaar. De keuzes (of requirements) die organisaties hierin maken (of hebben), hebben vergaande conse-quenties voor de manier waarop ‘de werkplek’ wordt aan-geboden op ‘het device’. Dit geldt, zoals al blijkt, niet in de laatste plaats voor de informatiebeveiligingsaspecten

Figuur 5: IAIRA laag 4 - Application Services

Figuur 6: IAIRA laag 5 - Presentation services



die samenhangen met de manier van werken.Gelukkig maakt virtualisatie het mogelijk om de functionaliteit los te koppelen van de onderliggende hardware. Met desktopvirtualisatie in de vorm van Server Based Com-puting (SBC) t.b.v. desktop- of appli-cation publishing is al veel ervaring opgedaan in menig organisatie. Re-latief nieuw zijn de individueel ge-virtualiseerde desktop besturings-systemen, VDI (Virtual Desktop Interface), die veilig in het datacen-ter draaien en meer te personali-seren zijn. Daarmee is echter niet ineens een zaligmakende oplossing geboren. VDI is een goede uitkomst voor een kantoor waar gebruikers beschikken over een toetsenbord + muis + beeldscherm of rondreizen-de medewerkers met een laptop met een dataverbinding. Maar op een smartphone of tablet scoort de gebruikers-ervaring hierbij onvoldoende. De infrastructuur dient dus bij voorkeur in staat te zijn om te detecteren met welk ap-paraat de medewerker zich aanmeldt en op basis daarvan de technologie te gebruiken om een daarbij passende weergave van de applicatie te tonen. Op een smartphone is dat wellicht een web gebaseerde App of een browser gebaseerde applicatie, maar die zijn vaak (nog) niet of onvoldoende voorhanden. Belangrijk is het om eerst in te schatten met welk type gebruikers en hun mobiliteit de organisatie te maken heeft en de keuze van ondersteunde devices daar op af te stem-men, te standaardiseren of te beperken.Organisaties die te lichtzin-nig kiezen voor diverse hy-bride vormen van Presen-tation Services zullen dat merken aan hun budget: het aantal licenties dat afgetikt moet worden maakt een der-gelijk aanpak vanuit TCO standpunt voorlopig niet eco-nomisch haalbaar, mede dankzij diverse aanvullende tooling om die vormen op elkaar aan te sluiten. Organisa-ties die weloverwogen hybride vormen kiezen zullen zich nadrukkelijk bewust zijn van de voordelen die het hen oplevert en de prijs die daarvoor betaald wordt.

Security ServicesDe Security Services (zie figuur 7) zijn gebaseerd op de beginselen van informatiebeveiliging en de daaruit voortkomende aspecten Beschikbaarheid, Integriteit en

Vertrouwelijkheid (BIV, of in het Engels CIA). Vanzelfspre-kend is deze plaat het domein van informatiebeveiliging. De vraag of er een separate beveiligingsarchitectuur op-gesteld moet worden of dat informatiebeveiliging een onderdeel is van iedere laag in IAIRA laat zich echter niet eenvoudig beantwoorden.Zoals ook al uit de beschrijving van onderliggende lagen (Datacenter, Platform en Infrastructure Services) blijkt, is met name ‘beschikbaarheid’ een onderwerp dat groten-deels direct vanuit de infrastructuur opgepakt moet wor-den. De genoemde RPO en RTO zijn hierin belangrijke uitgangspunten.

Wat deze plaat met name wil uitdrukken is dat er verant-woordelijke stakeholders zijn die iets te zeggen hebben of beleid hebben over de in figuur 7 afgebeelde onder-werpen m.b.t. informatiebeveiliging. En daarmee aan-zienlijke invloed uitoefenen op de infrastructuur. Want hoe vaak ook geprobeerd wordt een beveiligingsmaat-regel te treffen op een business- of applicatielaag, de maatregel moet uiteindelijk vaak geheel of gedeeltelijk worden geïmplementeerd op de infrastructuurlaag.Het gaat immers niet om het vermijden van risico’s, maar om het managen van risico’s. Een BIV analyse vooraf


Figuur 7: IAIRA - Security Services

Met name het aspect ‘beschikbaarheid’ is een onderwerp dat grotendeels

direct vanuit de infrastructuur opgepakt moet worden

kan de organisatie veel opleveren, omdat beveiligingsmaatregelen achteraf ingrijpend en dus vaak kostbaar uitpakken. Vragen die bij een BIV analyse aan de orde komen zijn onder andere: Welke schade zou ontstaan indien informatiesyste-men niet beschikbaar zouden zijn voor een uur, een dag, een week etc.? Zouden er verkeerde manage-ment beslissingen genomen wor-den indien informatiesystemen niet beschikbaar zouden zijn voor een uur, een dag etc. en wat is de schade daarvan? Daarnaast is er vaak spra-ke van imagoschade (waarde?) en herstelschade (kosten?).Om de beschrijving van IAIRA kort te houden wordt voor een meer ge-detailleerde beschrijving van dit gedeelte verwezen naar het domein informatiebeveiliging.

Management ServicesHet laatste onderdeel in IAIRA wordt afgebeeld in figuur 8. Hoewel hier met name ITIL v3 zaken op afgebeeld staan zouden dit net zo goed ITIL v2 zaken kunnen zijn. Waar deze plaat de aandacht op wil vestigen is dat een goed werkende infrastructuur niet alleen afhankelijk is van technologie. Het gaat om de balans tussen Mensen, Pro-cessen en Technologie.Al is de technologie nog zo goed voor elkaar, als er geen afspraken worden gemaakt en vastgelegd in processen waarin mensen samenwerken dan zal het niet gaan func-tioneren. Evengoed geldt dat als je afspraken en techno-logie goed zijn je niet buiten de mensen en hun expertise kunt om de technologie te bedienen. Vrijwel ieder onder-deel in figuur 8 heeft een beslag in de infrastructuur.Om de beschrijving van IAIRA kort te houden wordt voor een meer gedetailleerde beschrijving van dit gedeelte verwezen naar het domein service management.

ConclusieDe beschrijving van de IAIRA is aanzienlijk ingekort op de volledige beschrijving, maar dat er meer komt kijken bij een infrastructuur dan het bekende rack met ijzer en wat kabeltjes dat wist u al voordat u dit artikel ging lezen. Toch verschaft de Inter Access Infrastructuur Referentie Architectuur inzicht op welke laag een bepaald onder-werp geplaatst moet worden en van welke onderliggende zaken dat afhankelijk is dankzij de gelaagde architectuur. De beschrijving is geheel vendor-neutraal gehouden. De referentie architectuur is mede hierdoor generiek en kan enkele jaren meegaan. Voor elk onderwerp kunnen snel


meerdere vendoren worden aangewezen die goed aan-sluiten bij een specifieke organisatie, al is het goed mo-gelijk om bij het toepassen van IAIRA al voor te sorteren.Een concrete implementatie op basis van IAIRA verloopt door middel van technische ontwerpen met daarin invul-ling van merken, modellen en typen als gevolg van het invullen van requirements, sizing en het matchen van fea-

tures. Met een dergelijke concrete afgeleide van IAIRA kan dan bijvoorbeeld een “Werkplek 2013” of “Het nieu-we werken 2014” solution ontwikkeld en gepland worden.Of de IAIRA hiermee de ideale infrastructuur architectuur is die in uw organisatie bijvoorbeeld een plekje krijgt in uw ‘architecture continuum’ als common systems archi-tecture of een concrete afgeleide daarvan in uw ‘soluti-ons continuum’, laat ik graag aan u over. Uw feedback op deze referentie architectuur is uiteraard welkom!

Referenties

[1] Veroorzakers van complexiteit, Vincent Jansen, Computable, 2009

Vincent AWG Jansen is werkzaam als ICT Architect bij Inter Access.www.interaccess.nl

Figuur 8: IAIRA - Management Services

De IAIRA is vendor-neutraal gehouden; mede hierdoor

is het een generieke referentie architectuur



http://paauwe.info/training/trainingen/visuele-enterprise-architectuur/autumn-course-inzicht-controle-ict-uitgaven-met-vea

Constructiedenken dominantInfrastructuur en architectuur lijken sinds jaar een dag een ongelukkige combinatie te vormen. Vooraanstaande IT-architecten hebben lang volgehouden dat infrastruc-tuur helemaal geen onderwerp van architectuur is, maar dat dit puur een engineering-domein zou betreffen. En een kritische beschouwing van veel architectuurmetho-den leert - dat als het om infrastructuur gaat - er grofweg twee benaderingen zijn, die beide niet goed werken: of-

wel infrastructuur wordt oppervlakkig en globaal bena-derd (infrastructuur als applicatieplatform of -container, netwerk, opslag), ofwel er is een zeer technische benade-ring te onderkennen met uitwerkingen op het niveau van constructies en topografieën (zoals stacks en netwerk-diagrammen). De eerste aanpak werkt niet, omdat er te weinig mee wordt uitgedrukt. Infrastructuur blijft dan een vaag en abstract begrip en de ontwikkeling van een in-

frastructuurlandschap kan er dan ook niet mee worden gestuurd en gevormd. De tweede aanpak is feitelijk engi-neering, want het is gericht op de technische constructie, dus op ‘hoe het in elkaar zit’. Vanwege de hoge mate van detail en het gebruikte jargon is deze manier van vastleg-gen niet toegankelijk voor andere architecten en disci-plines.TOGAF®v9 is hierin een goed voorbeeld, omdat het bei-de benaderingen in zich heeft: enerzijds wordt infrastruc-tuur teruggebracht tot ‘Platform’ in het Content Metamo-del, anderzijds is onder het Technical Reference Model een enorme stapel technische componenten onderge-bracht die met toevoeging van het woord ‘service’ nog enigszins een functioneel tintje moeten krijgen. Uiteraard is TOGAF®v9 op allerlei fronten bruikbaar, maar niet om infrastructuur mee te modelleren en te ontwikkelen. Dit leidt tot de onvermijdelijke vraag: welke benadering voor infrastructuurarchitectuur werkt wél? Het antwoord komt van vaderlandse bodem.

Blaauw: de drie ontwerpstappenHet is ‘onze eigen’ professor Gerrit Blaauw die al in 1972(!) in zijn zoektocht naar een gestructureerd ontwerpproces voor mainframes een goed hanteerbare workflow voor de ontwikkeling van geautomatiseerde systemen defi-nieerde. Blaauw onderscheidt drie abstractieniveaus die overeenkomen met drie stadia van ontwerp: Architectuur,


Echt architectuur op infrastructuur toepassen? Dat is heel goed mogelijk! Met een nieuwe, functionele

benadering van het voortbrengingsproces van infrastructuur. Hiermee kunnen architecten hun verant-

woordelijkheid binnen dit vakgebied beter invullen én praktisch handen en voeten geven.

Daniël Jumelet

Infrastructuurarchitectuur: tijd voor focus op functionaliteit en kwaliteit

ICT-infrastructuur

Infrastructuur en architectuur lijken sinds jaar en dag

een ongelukkige combinatie te vormen


http://www-set.win.tue.nl/UnsungHeroes/heroes/blaauw.html


Implementatie en Realisatie [a].• Architectuur is de fase waarin de benodigde functio-

naliteit wordt bepaald, waarbij die functies volstrekt technologieneutraal worden vastgelegd. In deze fase wordt gebruik gemaakt van archetypen en grond-structuren om de functionaliteit te modelleren en vast te leggen.

• In de Implementatiefase wordt de architectuur ver-taald naar een model voor een specifieke manier van toepassing van die functionaliteit, waarbij principes en richtlijnen voor de technisch ontwerper worden vastgesteld.

• In de Realisatiefase ten slotte, wordt vastgesteld met welke middelen de oplossing wordt gemateriali-seerd en wordt een technisch ontwerp opgesteld.

Een nieuw vocabulaire voor infrastructuur-architectuurDe stadia van Blaauw zijn heel goed toe te passen op het voortbrengen en aanpassen van infrastructuurlandschap-pen. Wat hiervoor nodig is, is een vocabulaire waarmee de functies kunnen worden uitgedrukt die in het infra-structuurlandschap voorkomen. Het standaard infrastruc-tuurjargon voldoet niet, omdat het te technisch is. Daarom is vanuit de methodiek DYA|Infrastructuur en de commu-nity die zich hier omheen heeft gevormd een nieuwe set aan definities ontwikkeld. Er zijn, gebaseerd op het ge-

Een mooi voorbeeld om de drie stadia van ont-werp van Blaauw mee te verduidelijken is dat van de analoge klok. De architectuur van de analoge klok (de grondstructuur) kan worden beschreven als het ‘tijd aangeven’ met een grote wijzer, een kleine wijzer en een wijzerplaat. Alle analoge klok-ken voldoen aan deze structuur. Dit maakt, dat als een kind eenmaal klok heeft leren kijken, het dit overal kan, ongeacht de aard of vormgeving van de klok. Met andere woorden: het kind (her)kent de architectuur van de analoge klok.Wanneer het principe van de analoge klok wordt toegepast voor een specifiek doel, dan komen implementatiekenmerken in beeld. Het speci-fieke doel vraagt om een specifieke methode van vormgeving van de klok. Neem een stationsklok. Een belangrijke eigenschap is dat binnen een station en op ieder perron de klokken gelijk die-nen te lopen. Zouden ze dat niet doen, dan zou dit verwarring en onzekerheid oproepen bij de reizi-gers: “Kan ik mijn trein nog halen en welke klok kan ik wel of niet vertrouwen?” De architect dient een keuze te maken tussen verschillende manie-ren waarop meerdere klokken synchroon kunnen lopen. Zo kan hij kiezen voor de toepassing van zeer secure uurwerken die per maand hoogstens een afwijking kennen van luttele seconden. Bij een klein aantal klokken in een geïsoleerde context misschien een prima keuze. Maar wanneer het om grote aantallen gaat over een grote hoeveelheid locaties, dan is het zeer waarschijnlijk dat het be-ter is om tussen eenvoudige klokken een netwerk aan te leggen, waarmee de klokken per minuut gesynchroniseerd kunnen worden. Uiteindelijk is ook deze oplossing gekozen door de Nederlandse Spoorwegen. Te herkennen aan de secondewij-zer, die iedere minuut eventjes ‘wacht’ tot hij door kan lopen. N.B. Ook in dit stadium zijn de richtlij-nen nog technologieneutraal en worden nog geen technische componenten vastgelegd. Uiteraard is het wel mogelijk om in richtlijnen naar technische componenten en/of protocollen te verwijzen, maar de beschrijving zelf is niet op dit niveau. Dit is na-melijk het onderwerp van het volgende stadium.In de realisatiefase worden de door de architect opgestelde richtlijnen toegepast in een technisch ontwerp, waarmee de constructie van de oplos-sing wordt uitgewerkt. Dit is dus de blauwdruk van de stationsklok die door de constructeur wordt gebruikt om één of een heleboel fysiek identieke exemplaren van deze klok te bouwen.


Een voorbeeld

http://www.sdu.nl/catalogus/9789012581868

dachtegoed van Blaauw, vier verschillende soorten defi-nities te onderscheiden, die infrastructuurfunctionaliteit uitdrukken:• Enkelvoudige functies op architectuurniveau (Bouw-

bloktypen)• Samengestelde functies op architectuurniveau (Pa-

troontypen)• Enkelvoudige functies op implementatieniveau

(Bouwblokvarianten)• Samengestelde functies op implementatieniveau

(Patroonvarianten)

Een Bouwbloktype heeft voor de architect het karakter van een atomaire of ondeelbare, universele infrastruc-tuurfunctie. Van een Bouwbloktype kunnen één of meer-dere Bouwblokvarianten worden afgeleid, die voor een specifiek doel de instantiatie van dit type zijn. Een voor-beeld is het universele functietype ‘Message Engine’, waarvan een specifieke variant kan worden gedefinieerd die geschikt is voor het verwerken van applicatieberich-ten, en een andere specifieke variant wordt vastgelegd die het afhandelen van gebruikersmail beschrijft.Twee of meer Bouwbloktypen vormen samen een Pa-troontype, die op universele, technologie- en organisa-tieneutrale wijze een model voor een infrastructuurop-lossing beschrijft. Een voorbeeld hiervan is ‘Message Handling’ dat een aantal functies bundelt tot een model voor een totaaloplossing die berichten afhandelt. Dit Pa-troontype bevat naast ‘Message Engine’ onder andere ook de functies ‘Message Store’, ‘Message Distribution’ en ‘Message Filtering’.Uit één of meerdere Patroontypen worden Patroonvarian-ten afgeleid, die oplossingen beschrijven voor een spe-cifiek doel, waarbij de Patroontypen als grondstructuren functioneren. De Patroonvarianten bestaan daarbij uit twee of meerdere Bouwblokvarianten. Dit ziet er in mo-delvorm uit als weergegeven in figuur 1.


Het complete informatiemodel (met daarbij ook kwali-teitsattributen en andere definities die in de modellering een rol spelen) is hier te vinden.

De rol van de communityHet is gebleken dat het ontwikkelen van een nieuw voca-bulaire nog geen sinecure is. Tot op heden zijn er geen harde regels voor ontdekt en is het een kwestie van afwe-gen wat het beste werkt door het vocabulaire te toetsen in de praktijk. Om in het voorbeeld van de klok te blijven: Is het handig om de korte en de lange wijzer als twee afzon-derlijke functies te zien (waarbij de ene de uren aanduidt en de andere de minuten). Of zijn het twee varianten van eenzelfde type, namelijk de functie ‘wijzer’? Een ander voorbeeld, meer in het infrastructuurdomein: Is ‘Authen-tication’ een functie, of is het een proces dat wordt onder-steund door een combinatie van de infrastructuurfuncties ‘Identity Validation’ en ‘Identity Store’? Meestal zijn meer-dere mogelijkheden valide, maar wordt de keuze be-paald door een bepaald idee over de modellering rond de functie(s).Al bij het begin van de ontwikkeling van het nieuwe vo-cabulaire is de community rondom DYA|Infrastructuur bij de vorming ervan betrokken. De definities op het ni-veau dat Blaauw architectuur noemt (Bouwbloktypen en Patroontypen) zijn dermate archetypisch, dat ze feitelijk zonder wijziging bruikbaar zijn voor elke organisatie. De vastlegging van deze definities leidt daarmee dus tot een referentiearchitectuur die direct bruikbaar is voor elke infrastructuurarchitect.Voor het vastleggen is gekozen voor een kennissysteem op basis van een semantische wiki: de DYA|Infrastructure Repository (DIR). De universeel geldige onderdelen van deze repository zijn onder een soepele licentie (Creative Commons) via het Internet zonder beperkingen ter be-schikking gesteld. Belangrijke effecten van het beschik-baar komen van (de inhoud van) deze repository zijn

onder andere dat de community van infra-structuurarchitecten sterk is gegroeid. En dat er voor veel infrastructuurarchitecten een laagdrempelige instap beschikbaar is gekomen om vanuit een functionele bena-dering het vak uit te oefenen. Dit betekent niet dat het nieuwe vocabulaire af is. Het is een taal die zich binnen de community steeds verder ontwikkelt en wordt fijn ge-slepen. Handige ingangen tot de DIR zijn de overzichten van Bouwbloktypen en van Patroontypen.

De stappen van Blaauw in de infra-structuurpraktijkMet het nieuwe vocabulaire wordt het voor infrastructuur mogelijk om de ontwerp-

Figuur 1: Gedeeltelijk informatiemodel, dat de samenhang tussen Functies (Bouwblokken) en Patronen en die tussen Typen en Varianten weergeeft


https://dya-knowledge.sogeti.nl/dir/BT.MW.Message_Engine

https://dya-knowledge.sogeti.nl/dir/PAT.Asynchronous_Message_Handling

https://dya-knowledge.sogeti.nl/dir/PAT.Asynchronous_Message_Handling

https://dya-knowledge.sogeti.nl/dir/BT.MW.Message_Store

https://dya-knowledge.sogeti.nl/dir/BT.MW.Message_Distribution

https://dya-knowledge.sogeti.nl/dir/BT.MW.Message_Filtering

https://dya-knowledge.sogeti.nl/dir/DyA_Infrastructure_decomposition_and_modeling#Information_Model

http://dya-knowledge.sogeti.nl/

http://dya-knowledge.sogeti.nl/

https://dya-knowledge.sogeti.nl/dir/Building_Block_Type_Overview

https://dya-knowledge.sogeti.nl/dir/Pattern_Type


stappen van Blaauw gestructureerd en efficiënt te door-lopen. De Patroontypen worden als grondplaat gebruikt, om van hieruit Patroonvarianten te definiëren, waarmee infrastructuuroplossingen voor een specifieke toepas-sing worden gemodelleerd. Hoe dit in zijn werk gaat? Hieronder wordt een voorbeeld gegeven voor het creë-ren van een architectonische beschrijving van een Cloud hosting service die wordt gebruikt om interne applicaties te hosten met een Best Effort beschikbaarheid.

De eerste stap in het ontwerpproces is het selecteren van één of meer Patroontypen die de basisstructuur vormen voor de uiteindelijke oplossing. Deze Patroontypen func-tioneren als grondplaat voor het te ontwikkelen model in de volgende stap, de Patroonvariant. De architect start met het ter hand nemen van het Patroontype Application Hosting [b] zoals weergegeven in figuur 2.Aangezien het Patroontype een grondplaat vormt, dient de architect voor elk van de optionele (geärceerd weer-gegeven) onderdelen te bepalen of die onderdeel gaan uitmaken van de oplossing. Tevens zouden er andere Patroontypen of losse Bouwbloktypen toegevoegd kun-nen worden. Voor ons voorbeeld van de Cloud Hosting service besluit de architect de Scheduler en Transaction

Coordination functies niet nodig te hebben. Daarnaast zal de uiteindelijke oplossing geen gebruik hoeven maken van (een variant van) Data Storage, omdat Data Manage-ment voldoende is. Samengevat kan worden gesteld dat in deze stap de concepten worden geselecteerd die van toepassing zijn in het vormgeven van de gevraagde op-lossing.

De tweede stap is het definiëren van een Patroonvari-ant, in het geval van dit voorbeeld op basis van boven-staand Patroontype. Rekeninghoudend met de volgende functies, eisen en kenmerken, wordt een Patroonvariant geschetst:

PAV.Application Hosting.Cloud – Internal use only, Best Effort

Beschrijving: Deze Patroonvariant beschrijft de implemen-tatierichtlijnen van een oplossing die applicatiehosting le-vert, met een Best Effort beschikbaarheid, gebruikmakend van een Cloud service.

Doel: Deze oplossing is bedoeld om te worden gebruikt voor experimentele en/of korte termijn business ap-


Figuur 2: Architectuurmodel van de oplossing Application Hosting (Patroontype)

plicatiehostingbehoeften. Het is bedoeld voor interne toe-gang/intern gebruik, en moet beschikbaar worden gesteld aan eindgebruikers door middel van de Cloud Portal die dient als een interface voor toepassingen van Cloud-geba-seerde applicaties. Omdat deze oplossing bedoeld is om zeer snel te leveren, kunnen er geen wijzigingen worden toegepast op de standaardoplossing.

Kenmerken en aanwijzigen voor gebruik• Zeer snelle levering voor het hosten van experimentele

en / of korte termijn businessapplicaties• Alleen interne toegang toegestaan tot de gehoste ap-

plicaties• Alleen best-effort beschikbaarheid gegarandeerd• Maakt gebruik van standaarden van Cloud Providers;

het is het niet mogelijk om additionele componenten toe te voegen

• Er dient gebruik te worden gemaakt van Cloud Integra-tion-oplossingen die reeds aanwezig zijn, indien nodig:• Data Management - Cloud Internal Usage• Asynchronous Messaging - ESB• Workflow Orchestration - Common Cloud Applica-

tion Direction• Maakt gebruik van interne Authentication & Autorisa-


tion diensten; gebruik van extra Identity & Permission Validation voorzieningen zijn niet toegestaan.

Op basis van deze schets, zou een mogelijke invulling van een Patroonvariant, er zo uit kunnen zien zoals weergege-ven in figuur 3 [c].Merk op dat voor elke infrastructuurfunctie die is geko-zen, een specifieke variant wordt aangewezen. Deze func-tievarianten kunnen oplossingspecifiek zijn, maar het is ook heel goed mogelijk dat deze varianten door een (groot) aantal toepassingen gemeenschappelijk worden gebruikt. Daarnaast is de infrastructuurvoorziening ge-koppeld aan naburige (al bestaande danwel nog te reali-seren) infrastructuurvoorzieningen.Op dit moment in het architectuurproces kan de architect ook de nodige infrastructuurspecifieke kwaliteitsaspec-ten van de te realiseren oplossing vastleggen (zoals be-schikbaarheid, toerekenbaarheid en beheerbaarheid), en de relevante architectuurprincipes van de organisatie koppelen en vertalen. Samengevat worden in deze stap de requirements vastgesteld voor de specifieke oplossing aan de hand van de in de vorige stap geselecteerde con-cepten. Deze requirements worden vervolgens vertaald naar richtlijnen voor het ontwerp.

Figuur 3: Voorbeeld van een implementatiemodel van de oplossing Application Hosting, toegespitst op een middels de Cloud gerealiseerde toepassing (Patroonvariant)



De derde stap is het vervaardigen van een Design Outline. De Design Outline functioneert als een artist impression oftewel een ontwerpstudie. Het beeldt uit (schetsmatig) hoe de architect de realisatie van de voorziening beoogt. De vorm waarin de Design Outline wordt gepresenteerd, is afhankelijk van de doelgroep van de architect en de middelen die hij heeft. Zo is het heel goed mogelijk om ook de constructie op min of meer abstracte wijze mid-dels Archimate® te verbeelden, omdat Archimate® de nodige taalelementen heeft die gebruikt kunnen worden voor het afbeelden van infrastructuurcomponenten. Ook is het mogelijk om netwerkdiagrammen en/of tekenin-gen met systeemsymbolen (zoals bijvoorbeeld Microsoft hanteert) te vervaardigen. In sommige gevallen is een goede werkvorm het beschrijven van de oplossing in al-ledaagse taal. Een mogelijke uitwerking van bovenstaand model is weergegeven in figuur 4, gebruikmakend van Archimate® (in een sterk versimpelde weergave).De Design Outline levert niet het ontwerp zélf, maar be-vat concrete aanwijzingen voor het ontwerp, in de termen (begrippen en technische specificaties) die in het ont-werp terug zullen komen. Het is in die zin nog abstract. Het geeft bijvoorbeeld geen invulling aan specifieke ser-vers, al dan niet in specifieke aantallen, zoals in een tech-nisch ontwerp zal worden gepreciseerd. Maar het geeft al wel duiding in de technische componenten die worden voorgeschreven voor (gemeenschappelijk) gebruik. N.B. In deze versimpelde Design Outline zijn (een deel van) de relaties met aanpalende functies/services niet opge-nomen. In een werkelijke Design Outline zal hier juist veel nadruk op liggen, aangezien dit de meerwaarde is die het toepassen van architectuur biedt, namelijk de sa-menhang van de elementen van de constructie met de context waarbinnen deze constructie functioneert.

Waarom infrastructuurarchitectuur beter móetHet toepassen van de workflow, zoals hierboven beschre-ven, is van toenemend belang in een tijd waarin infra-structuur steeds veelzijdiger en krachtiger, maar dus ook steeds complexer wordt. Het is voor de afnemers van in-frastructuurdiensten belangrijk om de benodigde func-tionaliteit en kwaliteit te definiëren en vast te stellen op welke manier deze functionaliteit moet worden toegepast en welke richtlijnen er dientengevolge gelden.Daarnaast wordt infrastructuur steeds meer als een pro-duct afgenomen (Cloud). Hierdoor is het steeds minder mogelijk om zélf de middelen te selecteren, het technisch ontwerp te genereren en de oplossing uiteindelijk te ma-

terialiseren (bouwen en construeren), zoals veel con- structiegeoriënteerde infrastructuurarchitecten en seniorinfrastructuurontwerpers tot nu toe deden. Waar lange tijd de architectuur van de oplossing een impliciet ge-geven kon zijn (die ervaren ontwerpers en constructeurs met zich meedroegen en zonder veel omzien of bezinnen toepasten), is het nu noodzakelijk dat de ene partij die de functionaliteit nodig heeft en de andere partij die de functionaliteit biedt, hier een heldere en ondubbelzinni-ge communicatie over voeren, zonder dat er a priori een discussie ontstaat over de technische invulling. Wat we wél willen, is inzicht in de functionaliteit en de kwaliteit van de producten die we selecteren en afnemen.Met andere woorden: de architectuur en de architectuur-keuzen moeten helder worden. De DYA|Infrastructure Repository bevat hiervoor de basismodellen als vertrek-punt voor dit discours. Het is een eerste aanzet voor een vocabulaire dat recht doet aan de functionaliteit en de kwaliteit die infrastructuurlandschappen leveren. Hier-mee is een goede basis neergezet voor een steeds betere ruimtelijke ordening van onze digitale landschappen.

Voetnoten

[a] “Computer Architecture”, Gerrit A. Blaauw, Elektronische Rechenanlagen,

1972 heft 4, pagina 154-159

[b] Zie voor de volledige beschrijving van het getoonde Patroontype de defini-

tie in de DYA|Infrastructure Repository. Voor het weergeven van de modellen

is Archimate® gebruikt, waarbij vooruit wordt gelopen op het (waarschijnlijk)

beschikbaar komen van de Infrastructuurfunctie als behavioural element. Bin-

nenkort komt een modelleergids beschikbaar in de Repository, waarmee de

regels voor het gecombineerd gebruik van Archimate® en DYA|Infrastructuur

zijn vastgelegd en van good practises voorzien.

[c] Zie voor een vollediger uitwerking van de getoonde Patroonvariant de de-

finitie in de DYA|Infrastructure Repository

Daniël Jumelet is Management Consultant In-frastructuur & Architectuur bij Sogeti.www.sogeti.nl


Figuur 4: Voorbeeld van een Design Outline, die de globale (deel)uitwer-king van het hiervoor getoonde implementatiemodel (Patroonvariant) toont

https://dya-knowledge.sogeti.nl/dir/PAT.Application_Hosting

https://dya-knowledge.sogeti.nl/dir/PAT.Application_Hosting

https://dya-knowledge.sogeti.nl/dir/PAV.Application_Hosting.Cloud_-_Internal_Access_Only_Best_Effort

https://dya-knowledge.sogeti.nl/dir/PAV.Application_Hosting.Cloud_-_Internal_Access_Only_Best_Effort

Wat is IPv6?IPv6, voluit Internet Protocol versie 6, is de nieuwe versie van het systeem dat op alle computers op de wereld de verbinding met internet mogelijk maakt. Tot nu toe is het internet gebaseerd op IPv4. In februari van dit jaar is de wereldwijde voorraad IPv4 adressen echter opgeraakt [1]. In Azië (APNIC) zijn ze inmiddels ook door de loka-le voorraad heen [2]. Europa (RIPE NCC) zal in 2012 de voorraad uitgeput hebben [3]. Vanaf dat moment kunnen bedrijven en internetproviders geen nieuwe adressen

meer krijgen. Hierna raken binnen enkele maanden de interne voorraden van de internetproviders leeg, waar-na ook consumenten en het MKB geen nieuwe adressen meer kunnen krijgen. Het einde van het huidige groeimo-del van het internet is in zicht.In de negentiger jaren is reeds een oplossing voor het IP-adrestekort bedacht: IPv6. Het belangrijkste verschil tussen IPv4 en IPv6 is dat de adreslengte vergroot is van 32 bits naar 128 bits. Hiermee is het aantal unieke adres-

sen onvoorstelbaar groot: 340.282.366.920.938.463.463.374.607.431.768.211.456, een getal met 39 cijfers. Dat is genoeg om bijvoorbeeld iedere zandkorrel op de aarde een eigen IP-nummer te geven. Ter vergelijking: het hui-dige IPv4 heeft “slechts” 4,3 miljard adressen. Een groot aantal, maar minder dan één adres per wereldburger. En dat terwijl bijvoorbeeld Nederland al 25 miljoen adres-sen voor 16,7 miljoen inwoners gebruikt.Om het mogelijk te maken dat het internet doorgroeit qua aantallen gebruikers en dienstverleners is de invoering van IPv6 dus noodzakelijk.

Waarom en wanneer overstappen?Wat veel mensen vergeten is dat IPv4 en IPv6 twee los-staande protocollen zijn. Iemand met alleen een IPv4 aan-sluiting kan niet communiceren met iemand met alleen een IPv6 aansluiting. Beide partijen moeten hetzelfde protocol spreken, of er zijn vertaalslagen nodig die dan door derden geleverd moeten worden. Organisaties die alleen een IPv4 aansluiting hebben, komen in de proble-men zodra één van hun leveranciers een dienst, zoals een website, on-line ordersysteem of cloud oplossing, alleen nog maar over IPv6 aanbiedt.De aanbieders van dergelijke diensten kunnen er ech-ter nog niet vanuit gaan dat hun gebruikers over IPv6 beschikken. Zo lang het mogelijk is om de dienst ook over IPv4 aan te bieden zal dat ook zeker gebeuren. IPv4


Implementatie van IPv6 in de ICT-infrastructuur

De voorraad IPv4 adressen raakt op, dat is ondertussen algemeen bekend onder ICT specialisten. Het

invoeren van IPv6 is uiteindelijk de enige toekomstbestendige oplossing voor dit probleem. Er zijn

echter veel ICT’ers die denken: ‘Onze organisatie heeft nog voldoende IPv4 adressen, dus waarom

tijd besteden aan IPv6?’. Er zijn echter andere partijen op het internet die onvoldoende IPv4 adressen

hebben en dus al overstappen op IPv6. Zonder IPv6 zal uw organisatie in de toekomst niet optimaal

met deze partijen kunnen communiceren via internet. Invoering van IPv6 is dus voor iedereen belang-

rijk, alleen de timing hiervan verschilt per situatie. In dit artikel wordt ingegaan op de noodzaak van

de invoering van IPv6 en op welke wijze dit het beste gedaan kan worden.

Sander Steffann

Invoering van IPv6 is belangrijk, maar doe het op de juiste wijze

ICT-infrastructuur

In februari van dit jaar is de wereldwijde voorraad IPv4 adressen opgeraakt



blijft voorlopig nog de manier om een zo groot mogelijke doelgroep te bereiken. Andersom geldt hetzelfde. Zolang het mogelijk is om IPv4 verbindingen aan te bieden zul-len internetproviders dat doen, want daarmee bereiken hun klanten een zo groot mogelijk deel van het internet.De vraag is dus: ‘Wanneer komt het moment dat óf een aanbieder van een dienst, óf een gebruiker van zo’n dienst gedwongen wordt om het zonder IPv4 te doen?’ En dat is een vraag die moeilijk te beantwoorden is. Alle organisaties hebben tegenwoordig zowel de rol van dien-staanbieder (op zijn minst in de vorm van een website en een e-mailserver) als de rol van gebruiker van der-gelijke diensten. Er moet dus gekeken worden naar alle communicatie waarbij uw organisatie gebruik maakt van internet. Dus alle websites, alle diensten (Voice-over-IP, bestandsuitwisseling, koppelingen tussen systemen etc.), alles waar verbinding mee gemaakt wordt en alles wat verbindingen ontvangt. Door het veelvuldige gebruik van internet bij veel werkzaamheden is dit vaak al moei-lijk te inventariseren.Er is dus een reële kans dat uw organisatie opeens IPv6 communicatie nodig heeft. Dit kan zijn omdat één van uw leveranciers in de situatie komt dat ze alleen nog maar over IPv6 kunnen communiceren (hun website en/of or-dersysteem is alleen over IPv6 bereikbaar, hun cloud dienst ondersteunt alleen nog maar IPv6 etc.). Maar het kan ook zijn dat één van uw ketenpartners, klanten en/

of gebruikers geen volwaardige IPv4 verbinding meer heeft. De verwachting is namelijk dat deze laatste groep de eerste zullen zijn die zonder IPv4 adressen komen te zitten. Bij internetaansluitingen voor consumenten wor-den de meeste IPv4 adressen per dag in gebruik ge-nomen, en die zullen dus het snelste door de voorraad heen zijn. De ‘oplossing’ hier is zowel simpel als storend: meer NAT (Network Address Translation). Consumenten krijgen geen eigen IPv4 adres meer, maar moeten hun IPv4 adres met anderen delen. Één van de problemen

voor een aanbieder van bijvoorbeeld een website is dat traceerbaarheid heel moeilijk wordt. Achterhalen wie verantwoordelijk is voor acties op het internet wordt erg lastig als honderden gezinnen allemaal met hetzelfde af-zenderadres communiceren.En stel dat uw organisatie zelf een nieuwe internetverbin-ding nodig heeft en deze wordt met extra NAT geleverd. Het open zetten van poorten voor binnenkomende ver-bindingen zal niet meer mogelijk zijn. Toepassingen


Er is een reële kans dat uw organisatie opeens IPv6

communicatie nodig heeft

Foto

: Vla

dru

/ S

hutt

erst

ock.

com

zoals Voice-over-IP, maar ook het opzetten van VPN ver-bindingen en het draaien van een eigen web- of e-mail-server is op zulke verbindingen niet mogelijk.In al deze situaties is er maar één echte oplossing: IPv6 gebruiken. Daarmee krijgt iedereen ruim voldoende adressen. Om precies te zijn 18.446.744.073.709.551.616 adressen per LAN. Zo goed als oneindig veel dus. Ik ben tenminste nog nooit een switch tegengekomen met zo veel poorten. En het aantal LANs zal ook geen probleem zijn. Elke organisatie krijgt voldoende adressen voor 65.536 LANs. Dit zijn voldoende adressen om een prakti-sche indeling te maken waarbij bijvoorbeeld het beveili-gingsbeleid eenvoudig in te richten is [4].

Hoe IPv6 op juiste wijze in te voeren?Het is dus belangrijk om bewust te zijn van de noodzaak voor IPv6. Dat betekent echter niet dat nu overal hals over kop IPv6 ingevoerd moet worden. Sterker nog: als IPv6 slecht ingevoerd wordt kan dat een risico voor de wer-king en beveiliging van de ICT-infrastructuur opleveren. Als IPv6 ingevoerd wordt dan moet het op zijn minst in alle opzichten gelijkwaardig zijn aan IPv4. De beveiliging, maar ook de betrouwbaarheid en de performance kun-nen niet onderdoen voor IPv4.Voor een goede invoering van IPv6 is allereerst goede kennis van IPv6, maar ook van IPv4 en netwerken in het algemeen, noodzakelijk. Afhankelijk van wie de verant-woordelijkheid over het netwerk heeft zullen uw eigen ICT mensen of uw ICT-dienstverleners zich moeten laten scholen. IPv6 is op veel punten makkelijker dan IPv4. Zo heeft elk IPv6 netwerk standaard een bijna oneindig aan-tal adressen, waardoor het vooraf inschatten hoeveel IP adressen er per netwerk gereserveerd moeten worden oftewel SLAAC) van PC’s, smartphones, tablets en andere apparatuur maakt het invoeren van IPv6 eenvoudiger. Bij het inrichten van koppelingen en het beveiligingsbeleid,


of bij het oplossen van storingen, is het erg prettig dat er geen NAT meer is. Elk IPv6 adres is wereldwijd uniek waardoor verwarring wordt voorkomen. Op andere pun-ten is het, mede doordat de werking van IPv4 zo ingesle-ten is, juist wat ingewikkelder. Juist de afwezigheid van NAT is voor veel netwerkbeheerders in het begin onwen-nig. Ook de combinatie van SLAAC met DHCPv6 is an-ders dan we met IPv4 gewend zijn. Ook het feit dat elk systeem meer dan één IPv6 adres kan hebben, is soms verwarrend. Al deze wijzigingen zijn echter bewust inge-voerd en kunnen, mits goed ingezet, het leven van een netwerkbeheerder eenvoudiger maken.Nadat de betrokkenen theoretische kennis hebben op-gedaan, is het tijd om praktische kennis en ervaring op te doen. Veel netwerkbeheerders doen IPv6 ervaring op doordat ze het in hun thuisnetwerk uitproberen. Door dat aan te moedigen kan een organisatie een groot voordeel behalen. Het sponsoren van een IPv6 geschikte router voor thuisgebruik is dan helemaal niet zo gek. Ook bin-nen het bedrijfsnetwerk een testnetwerk opzetten is heel nuttig. Daar kunnen de hardware en software [5] uitvoerig getest worden in een veilige omgeving.

En dan is het tijd om naar de productienetwerken te kij-ken. Als voorstander van IPv6 zou ik het natuurlijk fantas-tisch vinden als iedereen overal direct IPv6 zou kunnen invoeren. Dat is echter niet te managen en brengt veel te veel risico’s met zich mee. Bij een reële invoering van IPv6 zal eerst gekeken moeten worden naar de plekken waar IPv6 het snelst nodig is en de plekken waar een on-verwachte noodzakelijkheid tot invoering van IPv6 voor veel problemen kan zorgen binnen uw organisatie. Een niet goed voorbereide invoering van een nieuwe techno-logie als IPv6 is risicovol voor zowel de beveiliging als de stabiliteit van de infrastructuur.Doordat de eigen beheerders controle hebben over

het interne netwerk zullen hier niet snel verrassingen optreden. Communicatie met externe par-tijen gaat ook gedeeltelijk over het interne netwerk, dus dit zal ook niet helemaal buiten schot blijven. Veranderingen in de rest van de wereld dicteren echter de snelheid waarmee IPv6 voor ex-terne communicatie ingevoerd moet worden, dus hier is de kans op een verrassing veel groter. Begin daarom stap voor stap met de meest cruciale onderdelen die nodig zijn voor deze externe communicatie: onderdelen die zeker niet overhaast veranderd mogen worden.

Foto

: jad

ey91

9 /

Rg

bst

ock.

com



Een belangrijk element hierbij is de verbinding met de internetprovider. Goede zakelijke internetproviders zijn zich al jaren aan het voorbereiden op IPv6. Let hierbij wel goed op de beveiliging. IPv6 mag natuurlijk geen achter-deur naar het interne netwerk bieden. Eerst de beveili-ging controleren voordat een IPv6 aansluiting geïmple-menteerd wordt, is een absolute noodzaak.Dan is het tijd voor de eerste toepassingen. De DNS / do-meinnaam infrastructuur is hier een goed voorbeeld van. Bijna alle communicatie gebruikt domeinnamen, en deze zullen dus zeker met IPv6 moeten werken. Het netwerk tussen de koppeling met de internetprovider en de DNS servers moet hierbij van IPv6 voorzien worden, net als de DNS servers zelf. Als dit alles ingericht is moet dat ook aan de partij die de domeinnaam heeft geregistreerd worden doorgegeven. Zij zullen zorgen dat ook de buitenwereld weet hoe de DNS servers over IPv6 bereikbaar zijn.

Hierna zijn er wat meer keuzemogelijkheden. Eerst de websites, of toch eerst de e-mailservers? Of toch mis-schien eerst zorgen dat uw medewerkers diensten van anderen over IPv6 kunnen bereiken? Dat zijn keuzes waar geen direct antwoord op gegeven kan worden, maar als uw organisatie zo ver is gekomen dan hebben de betrok-ken mensen inmiddels alweer zo veel meer inzicht in de materie dat ook de volgende stap goed te zetten is.

Waar is IPv6 nu al in gebruik?In Azië worden organisaties nu gedwongen om gebruik te gaan maken van IPv6 aangezien daar de IPv4 voorraden al op zijn. In Europa wordt echter ook al jaren gewerkt aan de IPv6 infrastructuur van internetproviders. Zo is de Am-sterdam Internet Exchange (AMS-IX), één van de grootste internetknooppunten ter wereld, al sinds 1998 bezig met IPv6.Ook binnen bedrijven zijn er al veel systemen die met IPv6 werken, al is dat niet altijd bewust. In moderne be-sturingssystemen zoals Windows Vista, Windows 7, Mac OS-X en Linux staat IPv6 standaard aan. Microsoft heeft aangegeven dat IPv6 vanaf Windows 7 en Server 2008 een integraal onderdeel uitmaakt van het besturingssysteem en dat er niet meer getest wordt met IPv6 uitgeschakeld [6]. Het uitschakelen van IPv6 levert daardoor een niet door Microsoft ondersteunde configuratie op. Goede IPv6 beveiliging in het netwerk is daardoor belangrijk, ook al wordt er nog niet actief gebruik van gemaakt.

ConclusieHet invoeren van IPv6 is voor iedereen van belang. Som-mige organisaties zullen eerst geconfronteerd worden met diensten die over IPv6 aangeboden worden. Andere organisaties zullen juist zelf diensten zoals websites en e- mail over IPv6 moeten aanbieden, omdat hun klanten en/of gebruikers geen volwaardige IPv4 verbinding meer

kunnen krijgen. Wanneer dit moment komt is moeilijk te voorspellen en hangt af van de aanwezige communica-tiestromen. Dat moment kan echter snel komen en op het laatste moment overhaast een nieuw netwerkprotocol in-voeren is nooit een goede keuze. Daarom is het voor elke organisatie belangrijk om zich voor te bereiden op IPv6. Daarmee kunnen een hoop kosten, beveiligingsrisico’s, operationele problemen en stress voorkomen worden. Voor de meeste organisaties is internet een cruciaal deel van de bedrijfsvoering geworden, en dat moeten we toe-komstbestendig inrichten.

Links en referenties

[1] De centrale voorraadschuur van internetadressen is uitgeput!

[2] APNIC begint aan laatste blok IPv4-adressen

[3] http://www.potaroo.net/tools/ipv4/plotend.png

[4] IPv6 - nummerplan opstellen / Handleiding

[5] Internet Protocol versie 6: loopt u risico?

[6] Support for IPv6 in Windows Server 2008 R2 and Windows 7

Sander Steffann is zelfstandig ondernemer en richt zich op het adviseren van organisaties over netwerkarchitectuur. www.steffann.nl


Stipv6 brengt helderheid op het gebied van IPv6De Stichting IPv6 Nederland, kortweg Stipv6, is in 2010 opgericht door een groep ICT-ondernemers. Zij zien naast de noodzaak van de invoering van IPv6 een grote behoefte aan concrete en bruik-bare kennis over IPv6. Doel van Stipv6 is dan ook om helderheid te brengen op het gebied van IPv6-kenmerken van hardware, software, diensten en organisaties. Stipv6 brengt die helderheid door middel van publicaties, trainingen, adviezen en on-demand testing.

In het eerste jaar van haar bestaan heeft de stich-ting al een aantal belangrijke wapenfeiten op haar naam gezet. Meest in het oog springend zijn daar-onder de vermelding van IPv6 geschiktheid op Ben Woldring’s Internetten.nl, het zichtbaar maken van de IPv6 geschiktheid van de Top 100 websites op www.IPv6Ready.nl en het onderzoeken van de IP-versie afhankelijkheid van applicatiesoftware in samenwerking met de Software Improvement Group (SIG). Uit dat onderzoek kwam bijvoorbeeld naar voren dat 1 op de 12 applicaties problemen zou gaan ondervinden bij combinatie met IPv6.

Voor informatie over de stichting en het downloa-den van whitepapers: www.stipv6.nl

http://www.stipv6.nl/persbericht-20110201

http://www.ispam.nl/archives/21527/apnic-begint-aan-laatste-blok-ipv4-adressen/

http://www.potaroo.net/tools/ipv4/plotend.png

http://www.surfnet.nl/Documents/handleiding_IPv6_nummerplan_v10.pdf

http://www.sig.eu/nl/Nieuws%20%26%20publicaties/Publicaties/931/__Internet_Protocol_versie_6:_loopt_u_risico__.html

http://technet.microsoft.com/en-us/magazine/2009.07.cableguy.aspx

De overheid koopt jaarlijks voor vijftig miljard euro in. Al enkele jaren voert de overheid een programma ‘duur-zaam inkopen’ uit. Hiermee wil ze de markt voor duur-zame producten en diensten een flinke impuls geven. In het programma zijn doelstellingen vastgelegd om de verschillende overheidsinstanties duurzaam te laten in-kopen.

Het streven voor 2010 was dat de Rijksoverheid voor 100% duurzaam zou inkopen, gemeenten 75%, provincies en waterschappen 50%. Het doel is dat alle overheidsin-stanties in 2015 100% duurzaam inkopen.Het programma onderscheidt 45 productgroepen waar-voor duurzaamheidscriteria zijn opgesteld. ICT is zo’n productgroep naast bijvoorbeeld de inkoop van bedrijfs-kleding, leerlingenvervoer en papier. Agentschap NL (onderdeel van het Ministerie van Economische Zaken, Landbouw en Innovatie) stelt in overleg met de over-

heidsorganisaties en leveranciers de criteria op. Indien een instantie bij haar inkoop aan de criteria van die pro-ductgroep voldoet, zou er sprake zijn van duurzame in-koop.

Duurzame ICT is een hoofdcategorieICT is een van de hoofdcategorieën waarvoor gezamen-lijke duurzaamheidscriteria zijn opgesteld. Onder ICT vallen de productgroepen: • hardware;• netwerken, telefoniediensten, telefoonapparatuur; • en reproductieapparatuur.

De categorie hardware bestaat uit desktops, laptops en monitoren. De categorie netwerken, telefoniediensten, telefoonapparatuur bestaat uit datacenters, UPS, breed-bandapparatuur en draadloze telefoons. De categorie reproductieapparatuur bestaat uit tonercartridges en to-nerpoeder. De belangrijkste elementen waar de criteria op gebaseerd zijn, zijn energieverbruik en de ‘footprint’ door het materiaalgebruik van de apparatuur.

Monitor duurzaam inkopenOm te controleren of de overheid duurzaam inkoopt, houdt het Rijk elke twee jaar een monitor ‘duurzaam in-kopen’. De monitor duurzaam inkopen is het meet- en rapportage-instrument om te bepalen of de doelstellin-


Hoe duurzaam koopt de overheid ICT in?Overheid koopt bijna 100% duurzame ICT in - of lijkt dat maar zo?

ICT-infrastructuur

Het doel van het programma ‘duurzaam inkopen’ is dat alle

overheidsinstanties in 2015 100% duurzaam inkopen

De overheid vindt duurzaam inkopen belangrijk en presenteert graag haar goede resultaten op dit

gebied. Op het eerste gezicht lijkt de overheid het goed te doen met bijna 100% duurzame ICT inkoop.

Maar in de praktijk blijkt duurzaam inkopen wel héél gemakkelijk te zijn.

Aarnoud Bijleveld



gen met betrekking tot duurzaam inkopen gerealiseerd worden.Uit de eerste twee monitoren duurzaam inkopen (2006 en 2008) bleek dat ICT hardware het meest (82%) duurzaam ingekocht werd van alle productgroepen. Uit de monitor duurzaam inkopen van 2010 blijkt dat 99% van de inko-pen voor ICT hardware duurzaam is geweest en 100% voor reproductieapparatuur (was 62% in 2008) volgens de gestelde criteria.

De criteria – de werkelijkheidHet lijkt dan ook dat de overheid het goed doet met duur-zaam inkopen en specifiek met de inkoop van duurzame ICT. Maar als men zich echter verdiept in de ICT criteria dan vallen er enkele zaken op:1. Per productgroep zijn er slechts enkele criteria;2. Criteria zijn gemakkelijk te halen en zijn niet onder-

scheidend;3. Criteria zijn minder relevant (geworden);4. Criteria zijn aangepast.

Per productgroep zijn er slechts enkele criteria:• Voor de productgroep hardware is er voor de desk-

top en laptop en voor de monitoren slechts één eis. Deze eis gaat over energie-efficiëntie;

• Voor de productgroep netwerken, telefoniedien-sten en telefoonapparatuur is er voor het datacenter,

UPS, breedbandapparatuur en draadloze telefoons (DECT) één eis (over energie- efficiëntie) per onder-deel;

• Voor de productgroep reproductieapparatuur is er ook maar één eis voor de apparatuur en voor cartridges twee eisen. Bij de apparatuur gaat het ook over energie-efficiëntie en bij de cartridges gaat het over recycling van cartridges en het gebruik van mi-lieuvriendelijk tonerpoeder.

Criteria zijn gemakkelijk te halen en niet onderschei-dend:• In de productgroep hardware moeten de desktop,

laptop en monitoren voldoen aan de eisen van Ener-gy Star [a] voor computers. Energy Star stelt energie-gebruik en efficiëntie-eisen aan ICT apparatuur. Te-genwoordig voldoen (bijna) alle desktops, laptops en monitoren die in Nederland te verkrijgen zijn, aan de Energy Star eisen. Alleen als je speciale PC’s bestelt (met bijvoorbeeld extreem veel rekenkracht) zou je nog systemen kunnen kopen die niet aan de Energy Star eisen voldoen. Dit is echter apparatuur die de overheid in het algemeen niet inkoopt;

• In de productgroep netwerken, telefoniediensten en telefoonapparatuur wordt er voor het datacenter een energie-efficiëntie (DCiE [b]) van 50% geëist. Dat be-tekent dat het datacenter evenveel energie nodig


“Uit de monitor duurzaam inkopen van 2010 blijkt dat 99% van de inkopen voor ICT hardware

duurzaam is geweest volgens de gestelde criteria.”

Foto

: Luk

iyan

ova

Nat

alia

- fr

enta

/ S

hutt

erst

ock.

com

heeft voor UPS, koeling, verlichting etc. als de ICT apparatuur van het datacenter gebruikt. Tegenwoordig haalt een groen datacenter een DCiE van meer dan 67%. De laatste ontwikkelingen leveren data-centers op met een DCiE richting 83%.

Criteria zijn minder relevant (geworden):• In de productgroep netwerken, tele-

foniediensten en telefoonapparatuur wordt een eis gesteld voor draadloze telefoons (DECT). Net zoals bij de zake-lijke markt zie je bij overheidsorganisa-ties een verschuiving van vaste telefonie naar mobiele telefonie. Medewerkers krijgen steeds vaker standaard een mo-biele telefoon in plaats van een vaste te-lefoon. Dit geldt ook, in grote mate, voor medewerkers die nu nog een draadloze telefoon gebruiken. Een betere telefoni-sche bereikbaarheid, flexibeler werken en Het Nieuwe Werken zijn de redenen van deze verschuiving. Het inkoopvolu-me van draadloze toestellen neemt dan ook snel af. Een duurzaamheidscriteri-um voor dit onderdeel is daarom minder relevant geworden.

Criteria zijn aangepast:• In de productgroep reproductieappa-

ratuur zijn eisen voor dubbelzijdig af-drukken en kopiëren en het gebruik van gereconditioneerde tonercartridges vervallen;

• De productgroep software is vervallen. Software is het bepalende element voor het energieverbruik van ICT apparatuur. Software kan hardware zuiniger laten draaien door standby modes eerder in te schakelen, processor gebruik ef-ficiënt te laten verlopen etc.

Doet de overheid het dan goed?Soms blijkt dat eisen in de praktijk niet werkbaar zijn. Gereconditioneerde tonercartridges gaven bijvoorbeeld toch helaas wat vaker afdrukproblemen. Het is vanzelf-sprekend om eisen naar aanleiding van ervaringen aan te passen. Maar in het algemeen kan je stellen dat de huidige eisen voor duurzame ICT niet echt uitdagend of vooruitstrevend zijn.Het programma loopt nu meer dan vijf jaar. In het begin is een gewenningsperiode voor leveranciers en de over-heidsorganisaties prima. Nu blijkt dat de overheid haar inkoopdoelstellingen ruimschoots en gemakkelijk haalt. Ik ben van mening dat het de hoogste tijd is om een vol-


gende slag in ICT duurzaamheidscriteria te maken. Er is nog zoveel te verbeteren op het gebied van duurzaam-heid in de ICT sector. Mogelijkheden zijn: vraag het totale energieverbruik van aangeboden netwerken en appara-tuur uit en vergelijk de opgegeven vermogens, standaar-diseer op mobiele telefoonladers ongeacht merk of type, focus op standaard software en voorkom maatwerk. Over-heid zet die stap!

Voetnoten

[a] Energy Star: zie www.energystar.gov

[b] DCiE: Datacentre infrastructure Efficiency – Dit is het verhoudingspercen-

tage van de energiezuinigheid van een datacenter.

Aarnoud Bijleveld is adviseur bij Verdonck, Klooster & Associates (VKA) en is ICT- en aan-bestedingsexpert.

“Het is de hoogste tijd om een volgende slag in

ICT duurzaamheidscriteria te maken.”

Foto

: Luk

iyan

ova

Nat

alia

- fr

enta

/ S

hutt

erst

ock.

com



IT experTIse for enTerprIses

Antwerp Management School Sint-Jacobsmarkt 9-13 | BE-2000 AntwerpT +32 (0)3 265 49 44 | E [email protected] www.antwerpmanagementschool.be

IT expertise is no longer a luxury. IT is a critical part of almost every enterprise.

Antwerp Management School, founded in 1959 as the first real business school, offers a broad range of short- and long-term IT management programs to stay ahead of the game:

2011

• Part-time Executive Master of - IT Governance and Assurance (start: October, 13)- IT Architecture (start: October, 13)

• Master Class IT Governance, Alignment and Value (start: October, 27)

• ERP and Business Value (date: December, 15)

2012

• Next Generation Workplace (date: February, 16)

• Contemporary Approaches for Value Management in European Organizations (date: March, 29)

• Legal Issues on Cloud Computing (date: April, 19)

• Business Process Innovation (start: May, 24)

• Master Class Information Security Management (start: spring)

Discover all about these programs on: www.antwerpmanagementschool.be/ITmanagement

Uw vacature gratis op deXR website?XR Magazine biedt een overzicht

van vacatures voor architecten, ont-

wikkelaars, managers en andere

professionals binnen diverse secto-

ren. U kunt zelf gratis vacatures plaat-

sen op de XR website. Kijk voor meer

informatie op:

www.xr-magazine.nl/vacatures


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

http://www.xr-magazine.nl/vacatures


Als je als IT consultant regelmatig over de vloer komt bij middelgrote organisaties zoals provincies of ZBO’s (zelfstandige bestuursorganen), dan valt het op hoe-veel ingewikkelde informatietechnologie daar ont-wikkeld, gehuisvest en onderhouden wordt. Er lopen in dergelijke organisaties mensen rond met verstand van allerlei moeilijke onderwerpen als storage, net-werkbeveiliging, document-management systemen, applicatie-virtualisatie etc. Er wordt vergaderd over de vraag of een nieuwe applicatie in Java, DotNet, Oracle of Progress moet worden gebouwd en of er misschien een Enterprise Service Bus moet worden gerealiseerd. Allemaal zaken die heel ver afstaan van de kerntaken van de organisatie en die veel geld en aandacht vragen.Vergeleken met hun grotere soortgenoten zoals ban-ken of ministeries hebben deze organisaties het pro-bleem dat ze moeilijk de echt goede IT-ers aan zich kunnen bin-den, omdat er gewoon-weg niet voortdurend voldoende interessant werk voor hen is. Door inhuur is dit wel enigs-zins op te vangen, maar het tijdelijke karakter daarvan is een risico voor de samenhang van het IT landschap in de tijd.Zou het voor zulke organisaties dan ook niet veel beter zijn om hun applicaties zoveel mogelijk, veel meer dan nu het geval is, af te nemen als kant en klare dienst, als “Software as a Service” (SaaS)? De kosten en zorgen van hosting en technisch beheer verminde-ren daarmee navenant en het functioneel beheer kan aanzienlijk beperkt worden als men bereid is de ei-gen processen af te stemmen op datgene wat door de applicaties wordt geboden. In de praktijk blijkt trou-wens dat functionele beperkingen door gebruikers eerder worden geaccepteerd van een SaaS applicatie dan van een in-house applicatie.SaaS is overigens niet identiek met “Cloud Compu-ting”. We hebben het hier over het afnemen van stan-daardapplicaties over het internet. Hoe deze appli-caties gehost worden bepaalt of er sprake is van een cloud maar dat is voor de gebruikers tamelijk oninte-ressant. Waar het hier vooral om gaat is de uitbeste-ding, waardoor de organisatie ruimte krijgt om zich op

zijn kerntaken te richten. Het veelgehoorde bezwaar van de veiligheid van de gegevens bij uitbesteding is op zichzelf serieus maar moet kritisch worden bezien. Er wordt vaak te weinig rekening gehouden met het feit dat lang niet alle gegevens echt gevoelig zijn en dat ze in het eigen rekencentrum ook wel degelijk aan gevaren blootstaan. Veelal zal de beveiliging van de rekencentra van een (cloud-) service provider veel beter zijn dan die van de eigen omgeving.Op vele gebieden zijn tegenwoordig uitstekende SaaS oplossingen voorhanden. Voorbeelden zijn applica-ties voor het beheer van medewerkers (HRM), klanten (CRM), logistiek/financiële systemen (ERP) en niet te vergeten kantoorapplicatie-suites. Ook faciliteiten voor kennisdeling en projectbeheer zijn goed als SaaS af te nemen en bieden dan vaak zelfs meer functiona-liteit dan lokaal gehuisveste applicaties. De aanpas-

singsmogelijkheden van SaaS applicaties zullen vaak geringer zijn dan bij een in-house applicatie maar dit kan ook een voor-deel zijn; de eenmalige en terugkerende kos-

ten van het aanpassen van applicaties worden altijd sterk onderschat. Door samen te werken met collega-organisaties in hetzelfde werkveld kan kennis worden uitgewisseld en gezamenlijk de leverancier tegemoet worden getreden. Dit laatste is met name interessant in een zgn. Community Cloud, bestaande uit SaaS ap-plicaties bedoeld voor een groep van organisaties in dezelfde branche. De kosten van ontwikkeling, on-derhoud en hosting worden hierbij tussen de deelne-mende organisaties verdeeld en men kan gezamenlijk eisen stellen aan de geboden functionaliteit.Mijn advies aan middelgrote organisaties luidt dan ook: kies voor SaaS en beperk de hoeveelheid in-house IT tot hoogstens enkele zeer specifieke applica-ties. Het ontwikkelen en onderhouden van een eigen omgeving vol ingewikkelde informatietechnologie is niet zinvol meer.

drs. Michiel Perdeck is een senior IT En-terprise Architect en adviseur op het gebied van informatiebeveiliging (CISSP en CISA).

Column

‘Teveel IT’

Het valt op hoeveel ingewikkelde IT middelgrote organisaties in huis hebben

Reageren op deze column? Klik hier.


Twee grote namen op het gebied van enterprise archi-tectuur standaarden (The Open Group en het SABSA Instituut) slaan de handen ineen met een gezamenlijke publicatie van een white paper die in oktober 2011 zal verschijnen. Deze white paper geeft een aanzet tot de in-tegratie van SABSA in TOGAF. De integratie van SABSA in TOGAF is een enorme stap voorwaarts voor het architec-tuur en security vakgebied. Het levert een aantal belang-rijke voordelen op, zowel voor de architecten als voor de organisaties waarin zij werken.Misschien wel de belangrijkste winst is het feit dat er-kend wordt dat security architectuur een vanzelfspre-kend onderdeel uitmaakt van de enterprise architectuur. Een van de meest in het oog springende aanbevelingen van de white paper is dat het team dat zich bezighoudt met security architectuur, volledig geïntegreerd dient te worden met het enterprise architectuurteam. Vanuit de historie werd security altijd gezien als een vreemde eend in de bijt. Deze white paper ademt volledig uit dat security geen los aanhangsel is dat als apart onderdeel behandeld kan worden (en dan nog vaak pas in een laat stadium van de architectuurontwikkeling). Security dient een integraal onderdeel uit te maken van de enterprise architectuur.De white paper legt de nadruk op het idee dat enterprise architectuur feitelijk draait om het creëren van de opera-tionele capaciteiten van een organisatie, en als zodanig dus nauw verbonden is met operationeel risicomanage-ment. In de white paper staat letterlijk vertaald ”de enige rol van de enterprise architect is het tot stand brengen van een operationele omgeving waarin operationeel ri-sico kan worden geoptimaliseerd, teneinde de kans op succes te maximaliseren en de kans op verlies of schade voor de organisatie te minimaliseren.”SABSA biedt een meetbare benadering voor het mana-

Geruime tijd wordt al nagedacht over een verbetering van de security paragraaf in TOGAF. Met de

binnenkort te publiceren white paper over de integratie van SABSA in TOGAF wordt een eerste con-

crete stap gezet. Een opvallende nieuwe invalshoek is het sterke verband dat wordt gelegd tussen

enterprise architectuur en operationeel risicomanagement.

gen van operationeel risico, wat zorgt voor afstemming tussen de doelstellingen van de organisatie en de ar-chitectuur. Met name de Business Attribute Profile van SABSA zal worden geïntegreerd in TOGAF als implemen-tatie van requirements management in TOGAF ADM.De white paper meldt ook het voornemen om het huidige hoofdstuk 21 van TOGAF 9 (Security architecture) volle-dig te herzien. Dit zal worden opgenomen in de volgende, herziene versie van TOGAF in 2014. Het leidende thema van de white paper, en de daarop volgende revisie van TOGAF is dat eisen aan de architectuur direct voortko-men uit het managen van organisatierisico’s.In een volgende bijdrage (na de geplande publicatie van de white paper begin oktober) zal in een uitgebreider artikel meer inhoudelijk worden ingegaan op de TOGAF-SABSA integratie.

John Sherwood is de geestelijk vader van het SABSA-model. Momenteel is hij werkzaam als principal consultant van IRM Company.

Marcel Westerhoud is bedrijfseconoom. Hij is managing director van IRM Company.www.irm-company.com

John Sherwood en Marcel Westerhoud

Integratie van TOGAF en SABSA een stap dichterbij


Foto

: Rev

enan

t / S

hutt

erst

ock.

com

Security



Vragen vóór de kernvraagTijdens de voorbereiding van de audit werd al snel dui-delijk dat, gegeven de doelgroep van het rapport zijnde het managementteam van de Divisie Middelen, er enke-le vragen vóór de in de inleiding benoemde kernvraag beantwoord dienden te worden: wat is service georiën-teerdheid? Wat is een service georiënteerde (ICT) ar-chitectuur? En waarom zou een organisatie een service georiënteerde architectuur willen hebben? Logische vragen. Daar waar de meeste enterprise en ICT architec-ten het begrip “service georiënteerd” al jaren kennen, is dat voor niet-ICT-ers en niet-architecten vaak niet het geval. En achter “wat is”-vragen zit natuurlijk altijd een “waarom”-vraag. Zeker bij Nederlanders.Naar aanleiding van deze “wat” en “waarom” vragen kwamen al snel de ontwikkelingen onder de paraplu van “e-overheid” ter sprake. Hoe passen de e-overheid bouwstenen en initiatieven in een service georiënteerde architectuur? Hoe krijgt de e-overheid die service ge-oriënteerdheid? En de NORA, PETRA, GEMMA en MARIJ referentiearchitecturen, zijn die dan ook service georiën-teerd? Wederom logische vragen. En dus werd de beant-woording ervan opgenomen in de audit.

Vragen ná de kernvraagGegeven het bovenstaande lag het voor de hand om de huidige ICT architectuur van deze overheidsorganisatie

niet alleen te beoordelen op het wel of niet in overeen-stemming zijn met wat een service georiënteerde archi-tectuur vereist, maar om ook meteen te kijken naar de mate waarin die ICT architectuur voldeed aan de van toe-passing zijnde referentiearchitectuur. En daarbij te bepa-len welke e-overheid bouwstenen relevant zijn voor de organisatie, en wat de status van de implementatie daar-van is.Wederom logische vragen, cumulerend in de uiteindelij-ke eindvraag: “Wat kunnen wij verbeteren?” En zo werd de aanvankelijke relatief simpele kernvraag uitgebreid tot een “redeneerlijn”, een “business logic” die is weer-geven in figuur 1.

Wat is service georiënteerdheid?Een service georiënteerde (“oriented”) archi-

tectuur, een SOA, is niet alleen een technische aangele-genheid, maar draait ook om het inrichten van een or-ganisatie. SOA gaat over de informatiekoppeling tussen verschillende organisatieonderdelen, of tussen verschil-lende organisaties. SOA gaat dus over netwerken, over ketens van organisaties die weer kunnen deelnemen in meerdere ketens hetgeen de complexiteit zowel als het belang van die informatiekoppelingen vergroot.Als mensen zich buigen over ketens van met elkaar sa-menwerkende organisaties komt het vaak voor dat ge-dacht wordt in termen van werkstromen. Koppelvlakken


Enige tijd geleden werd ik benaderd door een overheidsorganisatie die een audit wilde laten uitvoe-

ren op haar ”service georiënteerde architectuur” (SOA). De kernvraag was of de ICT architectuur van

deze organisatie in overeenstemming is met wat een service georiënteerde architectuur vereist. In dit

artikel wordt ingegaan op wat service-oriëntatie is, en waarom een organisatie een SOA zou willen

hebben. Tevens beschrijft dit artikel hoe de aanvankelijke relatief eenvoudige kernvraag onderdeel

werd van een veelomvattende “business logic” voor de beantwoording van de onderzoeksvragen en

de totstandkoming van het bijbehorende rapport.

Tom de Ridder

Overheid en service-oriëntatie: beschrijving van een SOA audit

Overheid / SOA

Van een eenvoudige kernvraag naar een “business logic”

1



worden in dat geval beschouwd als overdrachtsmomen-ten. In SOA is een keten echter geen werkstroomketen, maar een keten van diensten. Een schakel in een keten is er niet primair om een deelproces uit te voeren, maar om toegevoegde waarde te leveren. Deze toegevoegde waarde definieert de rol van een schakel en wordt vast-gelegd in een dienstverleningscontract.Vervolgens dient elke schakel, elke dienst, zelf te bepalen hoe de dienst geleverd wordt en welke interne processen daarvoor ingericht dienen te worden. De focus ligt op de toegevoegde waarde en de manier waarop deze bin-nen de keten gecommuni-ceerd wordt. De schakel is vrij om te bepalen hoe hij die waarde levert.De reden om organisaties in een keten te schakelen is dat de keten als geheel een dienst verleent aan zijn klan-ten. Er dient één verantwoordelijke aanbiedende partij te zijn. Deze partij kan de uitvoering zelf ter hand nemen, maar ook (geheel of gedeeltelijk) uitbesteden. Vanuit de afnemer gezien is deze eventuele uitbesteding liefst on-zichtbaar. Alle benodigde coördinatie is een interne zaak van de aanbieder. En die verantwoordelijkheid kan niet worden uitbesteed.

Voor coördinatie in een keten bestaan twee modellen: operationele sturing en tactische sturing. Bij operatio-nele sturing zit de aanbieder zelf in de operationele uit-voeringsketen. Hij bewaakt en regisseert de inhoud en volgorde van de bijdragen van alle schakels. De schakels behoeven onderling geen contact. Deze vorm heet ook wel orkestratie: de aanbieder is als een dirigent die bij de uitvoering van een muziekstuk continu de coördina-tie voert. Bij tactische sturing besteedt de aanbieder de

contacten tussen de schakels uit aan de schakels zelf. Dat heet choreografie: de aanbieder is als een choreograaf die de interactie tussen dansers weliswaar vormgeeft, maar niet deelneemt aan de dans zelf.Informatie-uitwisseling tussen organisaties impliceert berichtenverkeer. In SOA worden service bussen gezien als de logistieke dienstenleveranciers die zorg dragen voor dat berichtenverkeer. Alle organisaties die aan-


Figuur 1: Business logic voor de SOA audit

Een service georienteerde architectuur is niet alleen een technische

aangelegenheid, maar draait ook om het inrichten van een organisatie

Wat is service georiënteerdheid?

Waarom service georiënteerdheid?

Hoe krijgt e-overheid service georiënteerdheid?

Zijn de referentie-architectu(u)r(en)

service georiënteerd?

Is de architectuur in overeenstemming met wat een SOA

vereist?

Voldoet de architectuur aan

de van toepassing zijnde referentie-

architectu(u)r(en)?

Wat kunnen we verbeteren?

Welke e-overheid bouwstenen zijn

relevant, en wat is de status van

implementatie?

1

72 3

4

5

6

8

gesloten zijn op een service bus vormen daarmee een soort logistieke gemeenschap.Dat wil niet zeggen dat aangesloten organisaties altijd zomaar van elkaars diensten gebruik kunnen maken. En ook niet dat zij geen gebruik zouden kunnen maken van diensten van partijen buiten deze logistieke gemeen-schap (en andersom). Vergelijk het met alle bedrijven die een eigen aansluiting hebben op het spoorwegnet, zoals dat een eeuw geleden vrij gebruikelijk was. Zij zijn logistiek verbonden en kunnen dus in principe goede-renverkeer met elkaar aangaan. Echter, zij hebben niet per se allemaal een zakelijke relatie. Andersom kunnen zij ook zaken doen met bedrijven die geen directe aan-sluiting hebben op het spoorwegnet. Daarvoor zijn over-slagpunten ingericht, waar goederen kunnen wisselen van transportmiddel. In een SOA bestaan ook van deze overslagpunten, en men noemt dat (diensten)loketten. Een loket is een voorziening die diensten uit haar eigen “achterland” ontsluit voor de buitenwereld. Loketten ma-ken gebruik van een dienstenregister om de door hen geleverde diensten te publiceren.Op basis van het bovenstaande is een set van principes te definiëren die een architectuur tot een SOA maken. De SOA principes zijn weergegeven in tabel 1.

Waarom service georiënteerdheid?“Alleen op de wereld”, en dan ook nog een we-

reld die amper verandert. Wat zou dat betekenen voor de informatiehuishouding van een organisatie? Een organi-satie hoeft zich dan geen zorgen te maken over koppelin-gen met andere organisaties. Zij hoeft zich geen zorgen te maken over toekomstige veranderingen aan bedrijfs-processen of informatiesystemen. Zij bouwt deze vanaf de bodem zelf op, zonder gebruik te maken van functies of componenten van derden. Het is niet nodig om scherp te zijn over wat een bedrijfsproces of informatiesysteem biedt, men komt toch wel naar die organisatie toe. Er is volledige vrijheid om bedrijfsprocessen aan te passen, en de technologie staat geen enkele wijziging in de weg.Maar dat is niet de wereld waarin wij leven. Organisaties, en zeker overheidsorganisaties, worden vandaag de dag geconfronteerd met toenemende eisen voor klantgedre-ven dienstverlening, die betrouwbaar, proactief, trans-parant, toegankelijk en vindbaar dient te zijn. Nieuwe maatschappelijke kwesties, prioriteiten of wetgeving zorgen voor voortdurende wijzigingen in bedrijfspro-cessen, informatievoorziening en applicatielandschap.


Voortschrijdende technologie, maar ook een continue druk om efficiënter te opereren zorgen voor nog meer wijzigingen, ook in de onderliggende infrastructuur. En het toenemend belang van samenwerking en informatie-uitwisseling vraagt intensief overleg over communicatie-standaarden. Een uitdaging dus, voor organisaties in het algemeen en specifiek voor mensen binnen deze organi-saties die verantwoordelijk zijn voor inrichting en beheer van bedrijfsprocessen en informatiesystemen.Een voor de hand liggende manier om naar deze uitda-gingen te kijken is door uit te gaan van het ideaal van een integraal ontworpen informatiefabriek, een zachtjes snorrend buizenstelsel waardoor informatie stroomt. Dat is een gevaarlijke metafoor omdat hiermee voorbij ge-gaan wordt aan autonomie die organisaties binnen een keten hebben, en omdat het volgens deze denkwijze een vereiste is dat er overzicht is, in de breedte en in detail, over alle ketens. Los van de vraag of deze mate van inte-gratie en centrale sturing überhaupt wenselijk is, is de realiteit dat binnen maar zeer zeker ook tussen organisa-ties dit praktisch gezien niet mogelijk of niet haalbaar is.Maar wat dan wel? Hoe kan er voor gezorgd worden dat er een structuur ontstaat die zo flexibel mogelijk kan in-spelen op veranderingsimpulsen, of deze nou een con-

textuele oorzaak, een inter-ne organisatorische oorzaak of een technologische oor-zaak hebben? Hoe kan recht gedaan worden aan een bepaalde mate van autono-mie van organisaties, en van organisatorische eenheden

binnen een organisatie, maar wel gezorgd worden voor samenwerking? Dat is waar een service georiënteerde architectuur, een SOA, om de hoek komt kijken.In SOA staan uitvoerings- en communicatieafspraken tussen “spelers in de keten” voorop en niet zozeer de interne werking van deze spelers. De werking van een organisatie of een informatiesysteem is er slechts om aan de afspraken te voldoen en dat is waar op gestuurd wordt. Een belangrijke vraag is dan wel wat er in zo’n afspraak zou moeten staan. Daarbij is het dilemma dat de afspraak strak en compleet genoeg moet zijn om het stelsel te la-ten functioneren, maar ook los genoeg moeten zijn om de spelers flexibel en autonoom te laten blijven, zowel ten aanzien van het inrichten van hun interne werking alsook het koppelen met andere partijen.Het antwoord op dit dilemma heet in SOA een dienst, vastgelegd in een dienstverleningsovereenkomst. Zo ap-pelleert SOA aan een perspectief waarin tegelijkertijd zowel de samenhang tussen als de beweeglijkheid van organisaties wordt gewaarborgd, transparantie en zake-lijkheid wordt bevorderd - aangezien wordt gestuurd op basis van heldere uitvoeringsafspraken en niet op ba-

2

Overheidsorganisaties worden vandaag de dag geconfronteerd met toenemende eisen

voor klantgerichte dienstverlening



Tabel 1: SOA principes


SOA principe Uitleg

Standardized service contract

Services bieden zich aan via een “service contract”. Services hanteren een eenduidige definitie, op-bouw en technische invulling van de samenwerkingafspraak tussen aanbieder en gebruiker. Service contracten dienen consistent, betrouwbaar en reguleerbaar te zijn.

Loose service coupling Services zijn zo opgebouwd dat afhankelijkheid van anderen zo laag mogelijk is. Er is een continue drang om de afhankelijkheid van de service implementatie een interne aangelegenheid van de service aanbieder te laten zijn. Zo zijn service gebruikers wel gekoppeld aan het service contract van een service, maar niet aan de implementatie van die service of aan de koppelingen met andere services.

Service abstraction Service contracten bevatten alleen de absoluut noodzakelijke (en dus de essentiële) informatie over de diensten (functies) die de service biedt. De gebruiker zal alleen deze informatie tot zijn beschik-king hebben en hoeven te hebben om gebruik te kunnen maken van de service.

Service reusability” Een service moet herbruikbaar zijn zodat andere services er keer op keer gebruik van kunnen maken. Het ontwerp van de service dient aandachtig bekeken te worden en getoetst te worden op herbruikbaarheid binnen de context van de architectuur.

Service autonomy Services dienen op de juiste wijze te kunnen beschikken over de resources en de omgeving waarin deze services draaien. Services waarvan andere services (in een keten) afhankelijk zijn dienen een groter niveau van autonomie te hebben.

Statelessness Services trachten de resources die ze gebruiken te minimaliseren door ofwel de informatie over de huidige status van de service niet zelf bij te houden, maar dit over te laten aan andere systemen, of de statusinformatie die door de service zelf wordt bijgehouden in ieder geval zo minimaal mogelijk te laten zijn.

Service discoverablity Indien een service gezien wil worden als een herbruikbare asset binnen het ecosysteem dient deze makkelijk te kunnen worden herkend en begrepen. Het gaat hier om de kwaliteit van de metadata die het service contract biedt. Het service contract dient kenbaar te maken welke functies en welk doel de service dient. Zo kan bij het zoeken naar herbruikbare services binnen de architectuur de service gemakkelijk worden gevonden.

Service composability Een service moet gemakkelijk gebruikt kunnen worden binnen een groter geheel van services, een keten. De eisen die aan het ontwerp van een service worden gesteld zijn gericht op het voorko-men dat een service binnen een bredere oplossing moet worden “gelepeld”. Van een service wordt verwacht dat ze gemakkelijk een rol kan vervullen binnen een keten, zonder dat daar bij het ontwerp van de keten expliciet rekening mee wordt gehouden. Het draait hier dus om “separation of con-cerns”.

Service optimization Wanneer meerdere services beschikbaar zijn die dezelfde functionaliteit bieden, gaat een service met een hogere kwaliteit boven de service met een lagere kwaliteit.

Service relevance Een service dient die functies aan te bieden die door een gebruiker ook als zinvolle functies worden gezien. Indien de functies te klein of juist te groot worden ontworpen dan daalt daarmee de waarde die de functies hebben voor de gebruikers van de service.

Service encapsulation Een service kan andere services inkapselen die niet in eerste instantie opgezet waren om te functio-neren binnen een SOA. Denk daarbij aan legacy systemen en databases waarbij een SOA service de functionaliteiten van die systemen kan publiceren om zo deze functionaliteit te kunnen laten mee-draaien in een SOA.

Service location transparancy

Een service zou overal moeten kunnen werken ongeacht waar de service zich fysiek bevindt. Hierdoor is het uitwisselen van services over geografische, technische en organisatorische grenzen heen mogelijk. Het gebruik van een “enterprise service bus”, waarin logische services gekoppeld zijn binnen een infrastructuur die voor de gebruiker onzichtbaar (encapsulation) blijft, is onderdeel van dit principe.

sis van interne werking van een proces of van technolo-gie - en hergebruik van diensten en informatiesystemen wordt bevorderd.Als gevolg van het bovenstaande geldt heden ten dage SOA als het overwegende paradigma om aan te slag te gaan met het organiseren van samenwerking, en dus van informatievoorziening, in en tussen organisaties. Dat geldt zowel voor vele bedrijfssectoren in ons land alsook voor overheden in Nederland en diverse andere landen.

Hoe krijgt e-overheid service georiën-teerdheid?

Om met de deur in huis te vallen: service-oriëntatie is een onderwerp met een reikwijdte en diepte die zo groot is, dat de overheidsorganisaties gezamenlijk moeten op-trekken om het te realiseren. Het is zoals eerder gezegd niet mogelijk om service oriëntatie als een technologi-sche ontwikkeling af te doen en haar dienovereenkom-stig te beleggen of uit te besteden. Er dient aandacht be-steed te worden aan ketensamenwerking, aan diensten zoals geleverd door spelers in de keten, aan informatie-uitwisseling, aan semantiek en syntax van communicatie etc. Daarom geldt dat de Nederlandse e-overheid dient te werken onder architectuur om service-oriëntatie, oftewel een SOA, te implementeren.

In een SOA zijn de onderdelen van de e-overheid alle-maal afnemers en/of aanbieders van diensten. Dat geldt zowel voor organisaties, voor afdelingen binnen organi-saties, voor bedrijfsprocessen binnen afdelingen en over afdelingen heen, als voor gebruikte applicaties. Om een SOA te implementeren, moet van alle huidige en toe-komstige werkzame onderdelen van de e-overheid een precieze dienstenbeschrijving gemaakt en onderhouden te worden. De verantwoordelijkheid daarvoor ligt bij de aanbieders van diensten. Om de samenwerking tussen organisaties mogelijk te maken en deze vervolgens effi-ciënt en effectief te maken, moeten zij kunnen beschik-ken over gezamenlijke principes, conventies en richtlij-nen voor dienstenontwerp.De e-overheid verleent diensten aan burgers en bedrij-ven. Organisaties die gezamenlijk die e-overheid vormen hebben veelal wettelijk vastgestelde taken. Overheidsor-ganisaties dienen te kunnen beschikken over richtlijnen en handreikingen over hoe wettelijke taken zich laten


vertalen naar producten en diensten.De inhoud van producten en diensten zal grotendeels sectorspecifiek, en zelfs organisatiespecifiek, zijn. Dat betekent niet dat de manier waarop de diensten wor-den gedefinieerd en worden beschreven anders dient te zijn. Sterker nog, een grote diversiteit beperkt de inter-operabiliteit. Voor de ontwikkeling van een service ge-oriënteerde e-overheid moet harmonisatie in gang wor-den gezet voor de manier waarop diensten beschreven worden, op basis van volwassen, open en internationale standaarden.Dienstenregisters vervullen een sleutelfunctie in een SOA, en vormen de basis voor de uiteindelijke koppe-lingen tussen organisaties. Voor de hand liggend is dat individuele organisaties hun eigen dienstenregister heb-ben. Omdat echter de overheid niet is op te delen in een aantal geïsoleerde diensteneilanden, zullen die registers onderling dienstenbeschrijvingen moeten kunnen kopi-eren of delen of onderling kunnen doorverwijzen. Ook hier geldt dat de toepasselijke standaarden zoveel mo-gelijk generiek dienen te zijn. Voor de ontwikkeling van een service georiënteerde e-overheid moet er harmoni-satie zijn ten aanzien van de toegang en koppeling van dienstenregisters, en ten aanzien van de formulering van dienstpublicaties en -overeenkomsten.

Voor een service georiën-teerde e-overheid is het van belang een beperkt aantal standaarden te hanteren voor de logistieke afhande-ling van dienstenverkeer, op basis van (zoals eerder aangegeven) volwassen, in-ternationale en open stan-daarden. Een service geori-

enteerde e-overheid vereist een samenhangend stelsel van servicebussen. Een dergelijk stelsel kan niet functi-oneren zonder de logistieke afhandeling van diensten te standaardiseren.SOA bevordert de zakelijkheid, de externe oriëntatie, de openheid en het hergebruik binnen de e-overheid. Maar ook met een service georiënteerde ontwerpstijl en expliciete publicatie van dienstenregisters en dienstver-leningsovereenkomsten blijven er nog flinke obstakels over. Wat nu als alle aanbieders volledig maatwerk zou-den maken van al hun diensten? Of als alle diensten hun inhoudelijke begrippen anders zouden definiëren? Of als alle diensten andere technische protocollen zouden vragen? Dat zou zeker niet bijdragen aan de mate waarin afnemers en aanbieders elkaar eenvoudig, snel en goed-koop zouden vinden, tot een vergelijk zouden komen en wederzijds diensten zouden verlenen. Anders gezegd, dat zou afbreuk doen aan de interoperabiliteit.Gelukkig is een groot deel van deze obstakels te bevech-

3

Service-orientatie is een onderwerp met een reikwijdte en diepte die zo groot is, dat de overheidsorganisaties gezamenlijk moeten

optrekken om het te realiseren



ten door te standaardiseren, dat wil zeggen, door op al-lerlei aspecten en onderdelen ervoor te kiezen overeen-komstige behoeftes en problemen op overeenkomstige wijze te lijf te gaan. En dus, zoals gesteld aan het begin van deze paragraaf, dient de Nederlandse e-overheid on-der SOA te werken om tot service-oriëntatie te geraken.

Zijn de referentiearchitecturen service georiënteerd?

NORA is de referentiearchitectuur voor de Nederlandse e-overheid. NORA stelt zich tot doel de inhoudelijke sa-menhang te bevorderen tussen de grote hoeveelheid pro-gramma’s, projecten en voorzieningen die de e-overheid rijk is en nog gaat krijgen. NORA biedt ontwerpprincipes, modellen en afspraken voor het (her)inrichten van de e-overheid, geordend in een raamwerk. De manier waarop NORA naar de wereld kijkt, kenmerkt zich door:• Het beschouwen van de wereld als een steeds ver-

anderend stelsel van werkzame onderdelen: organi-saties (gerangschikt in sectoren en overheidslagen), afdelingen, applicaties, voorzieningen, infrastructuur en mensen. De werking van deze onderdelen is deels gegoten in software, maar voor een belangrijk deel ook niet;

• De onderdelen van de e-overheid hebben interactie. Burgers en bedrijven nemen diensten af van de over-heid. Organisaties en hun afdelingen werken samen in ketens en netwerken. Organisaties en hun mensen gebruiken applicaties. Applicaties gebruiken infra-structuur;

• Interoperatibiliteit is een hoofddoelstelling van de e-overheid , en NORA spreekt hierover in termen van diensten en van dienstverlening;

• NORA gaat niet alleen over de randen van de e-over-heid waar diensten worden geleverd aan burgers en bedrijven, maar zeker ook over de binnenkant: de manier waarop overheidsorganisaties, hun afde-lingen, applicaties en voorzieningen zich tot elkaar verhouden. NORA gaat dus ook over keten- en net-werksamenwerking, koppelvlakken, integratie en standaarden;

• NORA ziet de e-overheid als een gemeenschap van onderdelen die elkaar diensten verlenen. Dienstver-lening is niet alleen een operationele en technische aangelegenheid. Dienstverlening vindt plaats op basis van zakelijke afspraken tussen de werkzame onderdelen van de e-overheid. NORA gaat daarmee ook over tactische aspecten van de e-overheid, na-melijk hoe deze afspraken eruit zien en hoe zij tot stand komen;

• Een grote uitdaging in de e-overheid is om haar werkzame onderdelen samen te laten werken zonder daarbij de eigen manoeuvreerruimte van de onder-delen te veel geweld aan te doen. Daarvoor zijn losse

koppelingen nodig, maar weer niet zo los dat de sa-menwerking aan waarde of kwaliteit inboet. Het dien-stenbegrip wil een antwoord zijn op dit dilemma: een dienstenafspraak regelt precies dat wat op het kop-pelvlak nodig is, maar laat de interne aangelegen-heden aan de individuele onderdelen zelf. In NORA wordt deze eis het subsidiariteitprincipe genoemd.

Op basis van de voorgaande paragrafen is duidelijk dat NORA gebaseerd is op SOA principes. Dat geldt ook voor “de dochters” van NORA, zoals PETRA voor provincies, GEMMA voor gemeenten, WILMA voor waterschappen, MARIJ voor rijksoverheidinstanties en ROSA voor het on-derwijsdomein. In NORA verband hebben de zussen dan ook regelmatig contact met elkaar. Overigens is er nog wel een groot verschil in de volwassenheid van de di-verse dochters, en blijkt het voor veel organisaties soms lastig om de generieke referentiearchitecturen aan te passen en in te passen in hun eigen architectuur. Veel ele-menten en componenten zijn niet of onvoldoende gedefi-nieerd om als kant-en-klaar raamwerk te dienen om een overheidsorganisatie haar eigen service georiënteerde architectuur te laten ontwerpen. Vanuit strategie, beleid en informatie management dient, met de principes uit de relevante referentiearchitectu(u)r(en) als kader, een eigen vertaalslag gemaakt te worden naar producten en diensten, naar bedrijfsprocessen, naar informatiestro-men, naar een applicatielandschap en naar infrastructu-rele componenten.

Is de ICT architectuur in overeenstem-ming met wat een SOA vereist?

En daarmee komen we weer terug bij de kernvraag, de oorspronkelijk aanleiding, van de audit. De beantwoor-ding van deze vraag werd opgedeeld in een aantal sub-vragen:• Voldoen de door de organisatie gedefinieerde ont-

werpprincipes aan de SOA principes?• Voldoet de enterprise service bus (ESB) implementa-

tie aan de SOA principes?• Voldoen de services aan de SOA principes?

Voldoen de door de organisatie gedefinieerde ont-werpprincipes aan de SOA principes?Allereerst werden de door de organisatie gedefinieerde ontwerpprincipes getoetst aan de SOA principes. Voor-beelden van de gedefinieerde ontwerpprincipes zijn:• Applicatieberichten, en -exceptions, worden gelogd

in de ESB;• Authenticatie vindt plaats op basis van Microsoft Ac-

tive Directory;• Berichtenverkeer via de ESB wordt gelogd in de ESB;• Communicatie tussen front-, mid- en backoffice vindt

plaats middels de ESB;


4

5

• De communicatie tussen de servers en de ESB vindt plaats middels SSL;

• De shared webservices zijn op basis van WCF ge-bouwd;

Het door de organisatie gebruikte technische framework (Windows Communication Foundation) bood een be-langrijke basis voor het voldoen aan de SOA principes. Andere ontwerpprincipes hadden geen relatie met SOA, maar zijn wel ondersteunend in het verwezenlijken ervan. De principes die SOA niet direct ondersteunden, deden sowieso geen afbreuk aan de SOA principes.De conclusie werd dan ook getrokken dat de door deze overheidsorganisatie gedefinieerde ontwerpprincipes een SOA ondersteunden.

Voldoet de enterprise service bus (ESB) implementa-tie aan de SOA principes?De SOA wordt georchestreerd door een Message Broker met behulp van Universal Description Discovery & Inte-gration (UDDI). UDDI is een op Extensible Markup Langu-age (XML) gebaseerd register waarmee het mogelijk is voor organisaties om zichzelf en de services die ze leve-ren via het Internet te presenteren. Het uiteindelijke doel is het stroomlijnen van online transacties door het voor bedrijven mogelijk te maken elkaar te vinden, en om hun systemen te kunnen laten samenwerken.De ESB en de Message Broker zijn geïmplementeerd door gebruik te maken van Microsoft BizTalk Server 2009. De ESB wordt gerealiseerd door de Microsoft BizTalk ESB Toolkit 2.0 implementatie op BizTalk. Er is een migratie gedaan van Microsoft BizTalk Server 2006 met Microsoft BizTalk ESB Toolkit versie 1.0 naar het huidige platform. De Message Broker is opgezet om alle in en uitgaande externe message handling te doen: dit is de enige plek waar informatie de organisatie in en uit gaat. De UDDI wordt geïmplementeerd door Microsoft UDDI services en bevat alle services en functies die via de ESB beschik-baar zijn. De conclusie werd getrokken dat de door de overheidsorganisatie geïmplementeerde Message Bro-ker, EUDDI en ESB een SOA ondersteunen.

Voldoen de services aan de SOA principes?Op basis van de onderkende hoofdprocessen en SOA ap-plicatieketens, en de relaties hiertussen, werd vastgesteld welke hoofdprocessen reeds gebruik maken van een SOA applicatieketen, en welke niet. Voor de SOA applica-tieketens werden vervolgens de gedefinieerde services in kaart gebracht . Overigens werd gebruik gemaakt van professionele architectuur tooling o.b.v. Archimate om de resultaten te analyseren en presenteren. De services werden stuk voor stuk beoordeeld op de SOA principes waarbij gebruik werd gemaakt van de technische imple-mentatiedetails van elke ontsloten service.


De algehele conclusie voor de onderzochte SOA services was dat deze in hoge mate voldoen aan alle SOA prin-cipes, met uitzondering van de zeer beperkte functio-naliteit van één specifieke service. Wel kan het “service discoverability” principe in sommige gevallen beter ge-implementeerd worden, waarbij dient te worden vermeld dat de huidige implementatie werkbaar is en ook effec-tief in gebruik is.

Voldoet de architectuur aan de van toe-passing zijnde referentiearchitecturen?

De architectuur van deze overheidsorganisatie is getoetst op alle principes uit de van toepassing zijnde referen-tiearchitecturen. De belangrijkste van toepassing zijnde referentiearchitecturen zijn NORA en PETRA geweest. Hierbij zijn de principes van deze architecturen gehou-den tegen de door de organisatie zelf opgestelde prin-cipes, eisen en wensenprogramma’s die zijn gebruikt voor het ontwikkelen van de ESB en gelieerde services. Wat duidelijk werd is dat de door de organisatie opge-stelde principes veelal pragmatisch en ook technischer van insteek waren. Waar vanuit de meer applicatie en in-frastructuur gerichte ICT verantwoordelijkheid gestuurd kan worden op de uitgangspunten en richtlijnen, heeft deze sturing plaats gevonden en vindt deze vandaag de dag nog steeds plaats. Echter, daar waar de verant-woordelijkheid voor de navolging van uitgangspunten en richtlijnen aan de functionele kant - ook wel de “informa-tiekant” of “business kant” genoemd - behoort te liggen, wordt hier door de organisatie (nagenoeg) geen invul-ling aan gegeven. Of, anders gezegd: de afdeling ICT doet wat zij kan doen, maar mist de interactie met een informatie management functie aan de gebruikerskant. En hiermee werd meteen de belangrijkste aanbeveling gevonden, waar verderop in dit artikel op terug zal wor-den gekomen.

Welke e-overheid bouwstenen zijn rele-vant en wat is de status van implemen-

tatie?Op basis van een overzicht van alle bouwstenen, projec-ten, initiatieven en ontwikkelingen die onder de paraplu “e-overheid” geschaard kunnen worden, is bepaald wel-ke bouwstenen etc. relevant zijn voor de overheidsorga-nisatie, en wat de status van de implementatie was.De organisatie bevindt zich in een complex speelveld, zowel ten opzichte van andere overheidsorganisaties als voor wat betreft het maatschappelijk speelveld waarin zij opereert. Vanuit de overheid wordt hard gewerkt aan het implementeren van de “Andere Overheid”. De hiervoor aangereikte e-overheid bouwstenen zijn in grote getale relevant. De status van de huidige implementatie van deze bouwstenen laat ruimte voor verbetering zien. Met name op het gebied van DigiD, DigiD Machtigen, Digimelding

6

7



en Digipoort dient een inhaalsslag gemaakt te worden. Ook verdient het aanbeveling om concreet aan de slag te gaan met e-Herkenning voor bedrijven, e-Inspecties, e-Formulieren en e-Facturen, alhoewel deze laatste drie e-overheidsbouwstenen geen verplichting zijn. Positieve uitzondering zijn de bouwstenen voor het gebruik en de verwerking van kadastrale gegevens.

Wat kunnen wij verbeteren?Als slotonderdeel van de audit is een advies gefor-

muleerd ten aanzien van de verbeteringen die deze over-heidsorganisatie zou kunnen c.q. “moeten” doorvoeren.Een van de belangrijke aanbevelingen betreft de imple-mentatie van de e-overheid bouwstenen. Om enerzijds wettelijke aansprakelijkheden en sancties te voorkomen en anderzijds de e-dienstverlening te optimaliseren dient vanuit de functionele kant van de organisatie de koe bij de horens te worden gevat, en bepaald te worden op wel-ke manier de diverse bouwstenen in met name de be-drijfs- en informatiearchitectuur, en uiteindelijk dus ook in de technische architectuur, geïmplementeerd gaan worden. Dit impliceert het formuleren van een hiërarchie van doelarchitecturen, de “soll”, zodat op basis van goe-de grip op de “ist” een migratiepad c.q. plateauplanning

vastgesteld kan worden.Om dit te bereiken dient aan de bedrijfsproceskant en informatiekant van “organiseren” explicieter invulling gegeven te worden. De informatie management functie van deze overheidsorganisatie is onvoldoende ingevuld. Vervolgens dienen alle te nemen stappen ten aanzien van de inrichting van de organisatie en de ondersteunende ICT architectuur plaats te vinden onder een duidelijke integrale sturing, primair vanuit bedrijfsprocessen en in-formatiemodellering en slechts secundair vanuit de ap-plicatie- en infrastructuurhoek.Overigens speelt dit ook een belangrijke rol bij het ef-ficiënter laten opereren van deze overheidsorganisatie, wat een van de belangrijke doelstellingen voor de ko-mende jaren is, gegeven de continue druk op kosten.De conclusies van de audit worden op het moment van schrijven van dit artikel besproken in het management-team van de Divisie Middelen van de betreffende organi-satie.

Tom de Ridder is werkzaam als principal con-sultant bij ValueBlue. Hij kan bereikt worden op [email protected].


8

http://twitter.com/xrmagazine

Data warehouse-architecturenData warehouse-architecturen kunnen vanuit verschil-lende perspectieven beschreven en vergeleken worden. In dit artikel wordt uitgegaan van de data-architectuur. Daarbij spelen dataopslag en datamodellering een be-langrijke rol. Andere aspecten, zoals metadata, foutafhan-deling, ongestructureerde data, archivering, big data en autorisatie zijn niet relevant in het kader van dit artikel en laat ik daarom buiten beschouwing.

De drie dominante data warehouse-architec-turenEind jaren ‘80 werd het normaliseren van gegevens ge-meengoed. Normalisatie van gegevens voorkomt redun-dantie (dezelfde gegevens meerdere malen opslaan). De grondlegger van het begrip data warehouse, Bill Inmon, schreef voor om de gegevens in het (enterprise) data wa-rehouse te normaliseren. De data marts (een verzameling van gegevens met een kleinere hoeveelheid aan gege-vens dan het gehele data warehouse en vaak ingericht voor een specifiek doel) zijn ook onderdeel van de data warehouse-architectuur van Inmon. Inmon gaf meerdere redenen voor het opnemen van data marts, bijvoorbeeld om ten behoeve van performance de gegevens te ag-gregeren, of vanwege beveiliging maar een deel van de gegevens ter beschikking te stellen. De data warehouse-architectuur van Inmon (Corporate information factory)

bestaat daarmee in basis uit de volgende opslaglagen:• Een data staging area voor de ontkoppeling van de

bronsystemen en het verzamelen van alle gewijzigde gegevens op één platform.

• Een data warehouse op basis van een genormali-seerd geïntegreerd datamodel inclusief historie en inclusief de resultaten van business rules (een busi-ness rule, ook wel transformatieregel genoemd, is bijvoorbeeld de berekening van de omzet).

• Data marts t.b.v. het eenvoudig en met hoge perfor-mance beschikbaar stellen van gegevens aan ge-bruikers.

Halverwege de jaren ‘90 groeide, onder aanvoering van Ralph Kimball, de populariteit van het dimensioneel mo-delleren [1] (sterschema’s). Het achterliggende principe van deze wijze van modelleren is dat bij data warehouses eenvoud en hoge performance belangrijker zijn dan het voorkomen van redundantie. Ofwel, Kimball staat redun-dantie toe in een dimensioneel model (overigens alleen in dimensies, juist niet in de omvangrijke feitentabellen). Kimball introduceerde met deze wijze van modelleren ook een andere architectuur dan Bill Inmon, namelijk de Kimball bus architecture. Deze architectuur bestaat uit de volgende opslaglagen:• Een verzameling van fysieke data marts die logisch

geïntegreerd zijn op basis van geconformeerde di-


De data warehouse-methode en datamodelleringswijze Data Vault van Daniel Linstedt staat momen-

teel enorm in de belangstelling in Nederland. Er verschijnen veel artikelen over de Data Vault in de

vakbladen, op ieder business intelligence seminar wordt erover gesproken en veel kundige data wa-

rehouse consultants zijn er enthousiast over. Waarom deze warme belangstelling? Omdat de Data Vault

een aantal problemen van de traditionele data warehouse-architecturen van Ralph Kimball en Bill In-

mon oplost. En toch deel ik het enthousiasme over de Data Vault niet. De problemen van de architectu-

ren van Kimball en Inmon worden weliswaar opgelost, maar deze kunnen ook op een veel eenvoudi-

gere en efficiëntere manier worden opgelost. Dit artikel beschrijft deze alternatieve oplossing.

Frank Habers

Een eenvoudig alternatief voor de Data Vault

Data warehousing

DWH-architectuur op basis van de historische data (staging) area



mensies (dus geconformeerde data marts). Een ge-conformeerde dimensie is bijvoorbeeld de klant-dimensie die wordt gebruikt in het sterschema ‘verkoop’ en tevens in het sterschema ‘verkoopfactu-ren’, waarbij een data mart bestaat uit één of meerde-re sterschema’s. Zodoende kan men logisch gezien spreken over één data warehouse, fysiek kan het data warehouse echter bestaan uit meerdere databases (of andere technologieën, zoals MDB OLAP).

• De data staging area voor de ontkoppeling van de bronsystemen en het (tijdelijk) verzamelen van alle gewijzigde gegevens op één platform. Formeel ge-zien maken de geconformeerde dimensies ook deel uit van de data staging area, zodat deze maar een-malig samengesteld hoeven te worden en vervolgens kunnen worden gedistribueerd naar de data marts.

De afgelopen jaren krijgt een derde stroming veel aan-dacht: de Data Vault. Daniel Linstedt is de grondlegger van de Data Vault, een methode van modelleren en een beschrijving van de bijbehorende architectuur [2]. De Data Vault is een hybride vorm van modelleren, met zowel eigenschappen van normaliseren als van een dimensio-neel model [3]. De architectuur van de Data Vault bestaat uit de volgende opslaglagen:• De data staging area voor de ontkoppeling met de

bronsystemen en het verzamelen van alle gewijzigde

gegevens op één platform.• De Raw Data Vault, waarin de historische brongege-

vens zonder de resultaten van business rules worden vastgelegd, met een lichte integratie op business keys (bijv. het klantnummer voor de identificatie van een klant).

• De Business Data Vault, waarin ook de resultaten van de business rules (berekeningen, transformaties etc.) worden vastgelegd.

• Data marts t.b.v. het eenvoudig en met hoge perfor-mance beschikbaar stellen van gegevens aan ge-bruikers.

Dan Linstedt brengt hierbij de nuance aan [4] dat van deze vier fysieke opslaglagen drie opslaglagen optio-neel zijn:• De data staging area. De gegevens zouden ook recht-

streeks in de Raw Data Vault kunnen worden geladen.• de Business Data Vault. De business rules (transfor-

maties) zouden ook verwerkt kunnen worden in het proces van de Raw Data Vault naar de data marts.

• De fysieke data marts. De data marts zouden ook vir-tueel kunnen zijn, bijvoorbeeld via SQL Views op de Data Vault-structuur.

Het is belangrijk om vast te stellen dat zowel Inmon als Lindstedt in hun architectuur ook plaats bieden aan


Foto

: whi

teho

une

/ Sh

utte

rsto

ck.c

om

een dimensioneel model. De data marts binnen deze ar-chitecturen kunnen namelijk een dimensionele structuur hebben. Inmon, Linstedt en Kimball zijn het er derhalve over eens dat dimensionele modellen goed geschikt zijn voor de analyse van gegevens. Hierbij moet de nuance worden aangebracht dat voor specifieke functionaliteit (denk bijvoorbeeld aan data mining) andere datastructu-ren beter geschikt zijn.Samengevat zijn er dus drie manieren om het data ware-house te modelleren: normaliseren (3NV), dimensioneel modelleren of de Data Vault. De wijze van modelleren gaat samen met een data warehouse-architectuur. In fi-guur 1 zijn de verschillende architecturen gevisualiseerd. De problemen van de architecturen van Inmon en KimballDe grote vraag is waarom Dan Linstedt deze derde mo-delleringswijze en architectuur heeft geïntroduceerd? Het antwoord daarop is dat hij een aantal problemen in


de architecturen van Inmon en Kimball op heeft willen lossen. Deze problemen hebben betrekking op de vol-gende aspecten:• De architecturen van Inmon en Kimball hebben geen

opslaglaag waarin alle (mogelijk relevante) bronge-gevens historisch zijn opgeslagen zonder enige vorm van selectie, aggregatie en (business rule-) trans-formaties. De Data Vault biedt wel een opslaglaag, de Raw Data Vault, waarin deze historische gege-vens zonder transformaties zijn opgeslagen. Deze opslaglaag (‘the system of records’) is noodzakelijk voor een auditable en compliant data warehouse. Een auditable data warehouse maakt het mogelijk te reconstrueren hoe een cijfer op een rapport tot stand is gekomen. In de architecturen van Kimball en Inmon worden de gegevens na de (vluchtige) data staging area (DSA) direct bewerkt waardoor de audittrail van bron naar rapport wordt doorbroken.

• Doordat de architecturen van Inmon en Kimball de

Figuur 1: Data warehouse architecturen van Inmon, Kimball en Linstedt. Hoofdletter ‘T’ betekent in dit schema dat business rules en structuurwijzigingen worden toegepast en de kleine letter ‘t’ betekent dat alleen structuur-wijzigingen worden aangebracht in de data. Let op, Inmon biedt ook allerlei uitbreidingen op deze architectuur, maar deze zijn niet relevant in dit kader. Linstedt benadrukt dat niet alle lagen verplicht zijn.

Sources

T

Data Staging Area Data Warehouse BI-AppsData Marts

tInmonCorporate Information Factory

Sources

T

Data Staging AreaConformedData Marts BI-Apps

KimballBus Architecture T

T

Conformeddimensions

Sources

t

Data Staging Area Raw Data Vault BI-AppsData Marts

TLindstedtData Vault

t

Business �Data Vault



gegevens al direct na de DSA interpreteren en inte-greren, zal deze interpretatie en integratie bij elke bronwijziging moeten plaatsvinden. Daarmee wordt de architectuur meer afhankelijk van bronwijzigin-gen. Indien deze interpretatie en integratie niet (di-rect) plaatsvindt, zoals bij de Data Vault, ontstaat er hogere mate van brononafhankelijkheid. Bronwij-zigingen kunnen bovendien eenvoudiger en gestan-daardiseerd worden verwerkt, resulterend in een kortere time-to-market.

Vanzelfsprekend kan men discussiëren of deze eisen voor ieder data warehouse belangrijk zijn. Een data wa-rehouse hoeft bijvoorbeeld niet altijd auditable te zijn. In dit artikel wordt er vanuit gegaan dat deze eisen worden gesteld aan het data warehouse.

De Data Vault oplossingDe Data Vault-architectuur lost deze problemen op door de introductie van de Raw Data Vault. Deze opslaglaag is een kopie van de brongegevens, maar in een andere structuur (hubs, links en satellites) waarbij ‘licht geïnte-greerd’ wordt op de business key. Deze opslaglaag legt de complete historie vast, de gegevens zijn een afspie-geling van de bron en de gegevens kunnen in deze laag eenvoudig geladen worden. De Data Vault lost dus een aantal essentiële problemen van de architecturen van Kimball en Inmon op.

De nadelen van de Data VaultVaak hebben oplossingen voor een probleem nadelige bijeffecten, zo ook bij de Data Vault. De Data Vault heeft twee nadelen: extra opslaglagen en de introductie van een extra modelleringstechniek, de Data Vault zelf. Dat vergt een toelichting.

Extra opslaglagen binnen het data warehouseIn een ideale wereld maak je rapporten en analyses rechtstreeks op de brongegevens en hoef je de gege-vens niet te kopiëren naar een aparte omgeving (het data warehouse). Immers, deze kopieslag moet ontwikkeld, onderhouden en beheerd worden. Bovendien vergt de kopieslag doorlooptijd, zijn de gegevens niet actueel en neemt de kopie schijfruimte in beslag. Toch zijn er vaak goede redenen om de gegevens wel te kopiëren naar een data warehouse, denk hierbij aan performance, integratie en eenvoud.Bij een data warehouse(-architectuur) moet dezelfde re-denering worden gehanteerd, een extra opslaglaag bin-nen een data warehouse moet voldoende toegevoegde waarde hebben. De architectuur van de Data Vault bestaat uit een DSA, een Raw Data Vault, een Business Data Vault en data marts. Dus mogelijkerwijs uit maar liefst vier op-slaglagen om uiteindelijk de informatie te kunnen rap-

porteren. Soms worden zelf nog meer opslaglagen gesug-gereerd (pre-staging, post-Data Vault, cubes, in-memory etc.). Al deze lagen vergen inspanning en kosten in ter-men van ontwikkeling, onderhoud en beheer. Bovendien gaan deze extra lagen juist door alle benodigde inspan-ning ten koste van een korte time-to-market bij wijzigin-gen. Daarnaast zijn impactanalyses lastiger uit te voeren, omdat de logica van elke laag moet worden begrepen. Ergo, het nadeel van de Data Vault is dat deze leidt tot een architectuur met extra opslaglagen en deze extra lagen leiden tot meer inspanning en kosten dan noodzakelijk.De nuance van Linstedt op deze kritiek is dat, zoals hier-boven genoemd, drie lagen (DSA, Business Data Vault en fysieke data marts) optioneel zijn. Daar plaats ik echter twee kanttekeningen bij: de Business Data Vault is naar mijn mening altijd noodzakelijk om te voorkomen dat business rules op meerdere plaatsen moet worden on-derhouden, namelijk in ieder Extraction, Transformation and Load (ETL) proces naar een data mart waarin het re-sultaat van deze business rule wordt gebruikt. Daarnaast zijn virtuele data marts (database views) wellicht moge-lijk in bepaalde situaties, maar de datastructuur van de Data Vault leidt tot een slechtere performance dan een dimensioneel model. De Data Vault vereist namelijk meer joins tussen (grote) tabellen en in het algemeen kan wor-den gesteld dat het koppelen van tabellen ten koste gaan van de performance.

De Data Vault als modelleringstechniekIn de Kimball-architectuur wordt maar één datamodel-leringstechniek toegepast: dimensioneel modelleren. Bij de Data Vault-architectuur wordt deze modelleringswijze ook toegepast (fysiek en/of virtueel), maar daarnaast is de Data Vault als modelleringswijze ook vereist. De gege-vens worden dus niet alleen meerdere keren opgeslagen, maar ook in meerdere structuren. Betrokkenen moeten kennis van zowel de Data Vault als dimensioneel model-leren vergaren en hiermee ervaring opdoen. De hiervoor benodigde inspanning (en doorlooptijd) moet niet on-derschat worden. Daarnaast zijn er inhoudelijk ook kri-tische opmerkingen [5] te maken over de Data Vault als modelleringswijze, maar deze worden buiten beschou-wing van dit artikel gelaten, omdat dit niet de kern van de kritiek is.

De opslaglagen van een data warehouseHet is duidelijk dat extra opslaglagen met een extra wijze van modellering leiden tot extra inspanning, hogere kos-ten, langer durende laadprocessen en langere doorloop-tijd van aanpassingen. Dus een belangrijk architectuur-principe is dat een opslaglaag alleen gerechtvaardigd is wanneer deze voldoende toegevoegde waarde heeft. Dat brengt ons bij de vraag: wanneer heeft een opslaglaag voldoende toegevoegde waarde? Deze vraag blijkt


verrassend eenvoudig te beantwoorden. Een data ware-house moet bestaan uit een achterkant (backroom) en voorkant (frontroom) omdat deze twee onderdelen ver-schillende doelstellingen hebben die niet te verenigen zijn in één opslaglaag:• De achterkant van het data warehouse moet gegevens

volledig historisch vastleggen, zonder enige wijze van interpretatie, zodat het data warehouse auditable en compliant is. Daarnaast moet deze laag eenvoudig zijn (in termen van ontwikkeling, onderhoud, beheer en laden) zodat wijzigingen in de bron snel kunnen worden opgevangen.

• De voorkant van het data warehouse moet de gege-vens op een eenvoudige wijze aan de gebruikers be-schikbaar stellen met de best mogelijke performance.

Een data warehouse bestaat dus in principe uit twee fy-sieke opslaglagen. Mochten de eisen van de achterkant niet worden gesteld aan het data warehouse, dan zijn er vaak nog technische redenen om deze achterkant zo in te richten, bijvoorbeeld t.b.v. herstelbaarheid of het be-schikbaar hebben van alle data op één platform in één formaat.


Het eenvoudige alternatief voor de Data VaultDe volgende vraag is op welke manier de gegevens in deze twee lagen gemodelleerd moeten worden. Daarbij komen we op het alternatief voor de Data Vault. Het alter-natief voor de Data Vault aan de achterkant van het data warehouse is verrassend eenvoudig en niet uniek.Deze achterkant bestaat uit de data staging area waarbij alle gegevens in een RDBMS historisch worden opgesla-gen in de datastructuur van de bron. Ofwel, de gegevens worden vanuit de bron 1:1 geladen in de historische data staging area, waarbij elke tabel twee extra attributen krijgt, datum_tijdstip_geldig_van en datum_tijdstip_gel-

dig_tot, gebaseerd op da-tum/tijdstip op het moment van extractie (of mutatie-datumtijdstip in de bron). Het laadproces naar de his-torische data staging area voert dus geen transfor-maties, aggregaties, scho-ning of selecties uit. Alleen indien de bron niet relatio-

neel is, bijv. XML of Cobol, vindt een technische vertaal-slag naar relationeel formaat plaats. De historische data staging area is een exacte kopie van de brongegevens, waarbij de historie wordt vastgelegd. In de historische data staging area wordt alleen de primary key benoemd (om vast te stellen of gegevens zijn gewijzigd), maar geen foreign keys. Deze oplossing stelt derhalve minimale ei-sen aan de datakwaliteit. Figuur 2 toont de werking van de historische data staging area.Deze achterkant van het data warehouse voldoet aan alle gestelde eisen: volledige historie, een kopie van de bron

Figuur 2: De werking van de historische data staging area. Voor de leesbaarheid is het tijdstip niet opgenomen in dit voorbeeld.

Klant_nr Naam Woonplaats datum_geldig_van datum_geldig_tot Actueel

1 Jan Jansen Utrecht 1-1-2011 31-12-9999 1

2 Piet Pietersen Amsterdam 1-1-2011 31-12-9999 1

3 Klaas Klaasen Rotterdam 1-1-2011 31-12-9999 1

Klant_nr Naam Woonplaats datum_geldig_van datum_geldig_tot Actueel

1 Jan Jansen Utrecht 1-1-2011 30-4-2011 0

1 Jan Jansen Woerden 1-5-2011 31-12-9999 1

2 Piet Pietersen Amsterdam 1-1-2011 31-12-9999 1

3 Klaas Klaasen Rotterdam 1-1-2011 31-12-9999 1

Klant_nr Naam Woonplaats Mutatiedatum

1 Jan Jansen Utrecht 1-1-2011

2 Piet Pietersen Amsterdam 1-1-2011

3 Klaas Klaasen Rotterdam 1-1-2011

Klant_nr Naam Woonplaats Mutatiedatum

1 Jan Jansen Woerden 1-5-2011

2 Piet Pietersen Amsterdam 1-1-2011

3 Klaas Klaasen Rotterdam 1-1-2011

Brontabel Historische Data Staging Area

Klant ‘Jan Jansen’ verhuist op 1 mei 2011 naar Woerden

De achterkant van het data warehouse moet gegevens volledig historisch vastleggen,

zonder enige wijze van interpretatie, zodat het data warehouse auditable en compliant is



zonder transformaties en bovendien is deze achterkant eenvoudig vanuit allerlei aspecten. En omdat de struc-tuur en het proces zo eenvoudig zijn, kunnen de ETL-processen van bron naar de historische data staging area volledig gegenereerd worden. In tegenstelling tot de (Raw) Data Vault kunnen de gegevens van nieuwe bron-systemen zonder inhoudelijke kennis van de data worden toegevoegd aan de achterkant van het data warehouse. Dat is een belangrijk voordeel. Gegevens uit nieuwe bronsystemen kunnen dus met minimale inspanning in zeer korte doorlooptijd worden opgenomen in de histo-rische data staging area. Bij het gebruik van de Raw Data Vault als achterkant van het data warehouse moet men de gegevens altijd eerst modelleren en dat vergt dus meer inspanning.Aan de voorkant van het data warehouse is het alterna-tief voor de Data Vault een geïntegreerd dimensioneel datamodel waarin de gegevens op het laagste detailni-veau worden vastgelegd en de resultaten van de business rules zijn verwerkt. Deze voorkant voldoet daarmee aan de doelstellingen: eenvoud en hoge (of optimale) perfor-mance. Hierbij wordt dus aangesloten op de architectuur van Kimball. Een belangrijk principe hierbij is dat bij de fysieke implementatie zo veel mogelijk wordt gestreefd naar één fysieke database zonder fysieke aggregaten om daarmee het beheer en onderhoud zo eenvoudig mo-gelijk te houden. Het gebruik van nieuwe technologie (appliances, column based databases, in-memory tech-nologie etc.) maakt dit prima mogelijk, omdat hiermee gegevens zeer snel te laden en op te vragen zijn. De inzet van bijvoorbeeld een data warehouse appliance maakt het dus mogelijk de architectuur te vereenvoudigen (of eenvoudig te houden). Rick van der Lans verwoordt dit

uitstekend in het artikel “The advantages of the data ware-house appliance revisited” [6].De alternatieve architectuur bestaat derhalve uit een his-torische data staging area aan de achterkant en een geïn-tegreerd dimensioneel model aan de voorkant, zie figuur 3. Deze alternatieve architectuur wordt in de praktijk al jaren toegepast bij een groot aantal organisaties in ver-schillende marktsegmenten met een grote variëteit aan bronsystemen met terabytes aan data. Deze architectuur voldoet daarbij prima.Hierbij geldt het architectuurprincipe dat data marts (ex-tra opslaglagen!) alleen worden geïmplementeerd indien nodig, bijvoorbeeld omdat specifieke functionaliteit of een andere datastructuur vereist is. Performance is geen reden om een data mart in te richten. Een voorbeeld is een situatie waarin data mining moet plaatsvinden o.b.v. klantgegevens. Veel data mining algoritmes vereisen dat alle relevante klantgegevens in één record beschikbaar zijn, terwijl in een dimensioneel model de aankopen, klachten, betaalgedrag en kenmerken van de klant ver-spreid zijn opgeslagen. In dat geval volstaat het dimensi-onele data warehouse dus niet en is een data mart nodig. Een ander voorbeeld zijn KPI-toepassingen. In dat geval worden Key Performance Indicatoren (meetwaarden) verzameld vanuit verschillende sterschema’s en worden deze opgeslagen in één apart KPI-sterschema. In dat ge-val ontstaat ook een data mart die overigens fysiek on-derdeel uitmaakt van de data warehouse database.Deze voorbeelden blijven echter uitzonderingen. Het overgrote deel van gewenste rapportages en analyses zijn direct gebaseerd op een dimensioneel model. Voor alle duidelijkheid, performance is geen valide reden meer om (geaggregeerde) data marts te maken. Met


Figuur 3: Data warehouse-architectuur met de historische data staging area

Sources

T

HistoricalData Staging Area

Data Warehouse BI-Apps

de huidige technologie is het mogelijk om grote hoeveel-heden data snel te analyseren.De conclusie is dat er een eenvoudiger alternatief is voor de Data Vault. De Data Vault als modelleringswijze biedt geen toegevoegde waarde ten opzichte van deze archi-tectuur met het oog op de doelstellingen van de voorkant en achterkant van het data warehouse. Daarmee heeft ook de Data Vault-architectuur geen toegevoegde waarde.

De mystiek van de Data Vault ontrafeldDe theorie van de Data Vault beschrijft nog aantal andere voordelen van de Data Vault. De Data Vault lijkt daarmee welhaast magische krachten toebedeeld te krijgen. Hier-onder worden deze argumenten en aanverwante onder-werpen ontrafeld en wordt daarmee aangetoond dat deze argumenten niet geldig of relevant zijn.

Eenvoudig realiseren van dimensionele data martsEen veel gehoord argument voor de Data Vault is dat van-uit de Data Vault eenvoudig een dimensioneel model kan worden gerealiseerd (of zelfs gegenereerd). Immers, de Data Vault heeft qua structuur veel weg van een dimen-sioneel model. Dit argument is ontegenzeggelijk waar. Echter, dat is daarmee nog geen valide argument, want al het werk is in de voorgaande (drie) lagen uitgevoerd. De vergelijking van inspanning moet plaatsvinden over de inspanning van de complete gegevenslogistiek van bron tot en met rapport. En dan leidt de Data Vault tot meer in-spanning, vanwege de extra modelleringswijze en meer-dere opslaglagen.

Het principe van ‘verdeel en heers’Dan Linstedt beschrijft dat de Data Vault is gebaseerd op het principe van divide and conquer (verdeel en heers). Het achterliggende idee is dat de gegevenslogistiek van bron naar rapport complex is en een complex probleem los je op door deze in kleinere eenheden (verschillende stappen en opslaglagen) op te delen. De verwijzing naar dit principe is terecht, daarom bestaat een data ware-house uit een voor- en achterkant. Echter, de theorie van

de Data Vault geeft geen valide argumenten waarom de gegevenslogistiek van het data warehouse altijd in nog meer stappen opgedeeld moet worden. Ik vind dat alleen in specifieke situaties een extra stap en opslaglaag ge-


rechtvaardigd is. Ofwel, wij hanteren hierbij het architec-tuurprincipe “Niet meer dan twee opslaglagen, tenzij er in een specifieke situatie een goede reden voor is”.

Een dimensioneel model kent ook een aantal nadelenEen dimensioneel model heeft ook nadelen. Een voor-beeld is het redundant opslaan van gegevens. Een ander nadeel is het effect van ‘cascading change impact’ van historische hiërarchische (snowflake) dimensies. Indien een parent tabel (bijv. productgroep) verandert, dan moet deze wijziging in alle onderliggende child tabellen (bijv. product) ook worden doorgevoerd. Nog een ander nadeel is de complexiteit van het maken van berekenin-gen met meetwaarden uit verschillende feitentabellen. Dit zijn allemaal nadelen die niet gebagatelliseerd moe-ten worden. Echter, ook in de Data Vault-architectuur is er een plaats voor het dimensionele model, namelijk in de data marts. De theorie van de Data Vault suggereert dat deze problemen zijn opgelost, maar dat klopt niet. De problemen zijn alleen verschoven naar een andere plaats in de gegevenslogistiek. Dus hoe dan ook, deze uitdagin-gen gelden voor elke architectuur.Daarnaast zou men nog kunnen stellen dat het dimensi-onele model niet volstaat als ‘centraal data warehouse’. Maar dan ontstaat er een definitiekwestie, wat is het cen-trale data warehouse? Dit artikel spreekt over een achter-kant en een voorkant, ‘centraal’ speelt hier geen rol. Wat een rol speelt zijn de eisen aan de achterkant en voorkant en de wijze van modelleren moet aan deze eisen voldoen. De voorkant moet gegevens eenvoudig en met hoge per-formance beschikbaar stellen, vanuit deze eisen is het dimensionele model de beste keuze voor rapportage en analyse. En zoals hierboven toegelicht, mocht voor be-paalde functionaliteit het dimensionele model niet vol-staan, dan pas wordt een data mart geïmplementeerd met een andere opslagstructuur.

Oplossing voor realtime-analysesVeel data warehouse-omgevingen worden dagelijks ge-actualiseerd. Operationele analyses kunnen echter ac-

tuelere gegevens vereisen. De gegevens in de analyse-omgeving moeten zodoen-de vaker worden geactua-liseerd, bijvoorbeeld per uur, per minuut of zelfs per split second. Deze eis heeft veelal impact op het laad-mechanisme, gegevens laden via batches is vaak niet

meer mogelijk. Gegevens moeten dan bijvoorbeeld real-time geladen worden vanaf een service-bus of op basis van database-triggers. Het is echter niet zo dat de ene architectuur zich beter leent voor realtime laden van ge-

Wij hanteren het architectuurprincipe “Niet meer dan twee opslaglagen, tenzij er

in een specifieke situatie een goede reden voor is”



gevens dan de andere architectuur. Immers, alle architec-turen hebben een data staging area waarin de gewijzigde gegevens snel kunnen worden geladen, zonder zware transformaties en afhankelijkheden tussen bronnen.Ook bij het analyseren van realtime-gegevens zijn de genoemde architecturen niet onderscheidend. Voordat geanalyseerd kan worden, moet (praktisch gezien) altijd geïntegreerd en getransformeerd worden. Geen enkele architectuur is hierin sneller. De vraag is zelfs of de ge-schetste data warehouse-architecturen wel geschikt zijn voor realtime analyses. Zou de operational data store een aparte omgeving moeten zijn naast het data warehouse, waarbij de operational data store de (benodigde) gege-vens snel laadt en integreert, wellicht zelfs op basis van andere technologie? De operational data store zou dan een bron voor het data warehouse zijn. Een uitgebreide analyse van de plaats en werking van de operational data store binnen de data warehouse-architectuur valt echter buiten beschouwing van dit artikel.

De Data Vault biedt flexibiliteit in de relaties (cardina-lity) tussen tabellenTussen tabellen bestaan relaties. Een eigenschap van deze relatie (link) is de cardinality, denk hierbij aan ma-ny-to-many, many-to-one (of one-to-many) of one-to-one relaties. Het modelleringsprincipe van de Data Vault is dat tussen twee entiteiten (hubs) een link-tabel wordt geplaatst. Indien de cardinaliteit in de bron tussen twee entiteiten wijzigt, heeft dit geen impact op de structuur van de Data Vault. Dit is ontegenzeggelijk een voordeel van de Data Vault, het model is vanuit dit oogpunt flexibel. Echter, hierop zijn twee nuances te maken. De historische data staging area legt geen relaties vast in het datamodel en biedt daarmee ook deze flexibiliteit. En ondanks dat dit flexibiliteit biedt in de Data Vault, moet dit probleem nog steeds aan de voorkant (in de dimensionele data marts) worden opgelost. Ook hier geldt, de theorie van de Data Vault suggereert dat deze problemen zijn opge-lost, maar dat klopt niet. De problemen zijn alleen ver-schoven naar een andere plaats in de gegevenslogistiek. Dit probleem moet nog steeds in de (dimensionele) data marts worden opgelost en dat geldt daarom voor alle ar-chitecturen.Deze constatering kan ook breder worden getrokken. Bronwijzigingen hebben impact, welke modelleringswij-ze ook wordt toegepast. De uitdaging is om deze bron-wijzigingen zo eenvoudig mogelijk te kunnen verwerken. Daarbij is niet alleen het datamodel aan de achterkant belangrijk, maar nog veel meer om de gegevenslogistiek eenvoudig te houden, zodat de wijziging op zo min moge-lijk plaatsen wordt doorgevoerd.

SamenvattingDe Data Vault is populair. Enerzijds is dat goed te begrij-

pen, de Data Vault lost een aantal problemen op van de architecturen van Kimball en Inmon. Echter, deze proble-men zijn eenvoudiger (met minder inspanning en kosten) op te lossen met een historische data staging area aan de achterkant van de data warehouse-architectuur en een geïntegreerd dimensioneel model aan de voorkant van de data warehouse-architectuur. Deze alternatieve archi-tectuur voorkomt de implementatie van een extra data-modelleringswijze (de Data Vault) en voorkomt de imple-mentatie van extra opslaglagen die extra inspanning en kosten vergen en leiden tot een langere time-to-market.

AfsluitendRené Veldwijk heeft in een column [7] prachtig, en met treffende voorbeelden, verwoord dat op het vakgebied van database-ontwerp bepaalde ideeën tijdelijk hoogst populair kunnen zijn, maar naderhand schadelijk blijken te zijn als leidraad voor (database-)ontwerp. Hoe verder je in het verleden kijkt, hoe eenvoudiger deze ideeën te herkennen zijn en omgekeerd geldt, hoe recenter de ideeën, hoe lastiger deze te herkennen zijn. Toch kun je deze schadelijke ideeën nu al herkennen door op twee aspecten te letten: wordt er onderscheid gemaakt tussen een patch en een structurele oplossing en treedt er een mate van ideologische verblinding op waarbij courante ideeën niet meer op nuttigheid worden getoetst?Ik adviseer dan ook de Data Vault te toetsen op basis van deze twee vragen, zodat duidelijk wordt of de Data Vault toegevoegde waarde heeft. Mijn mening laat zich eenvou-dig raden. Hoe dan ook, de toekomst zal uitwijzen of de Data Vault een structurele oplossing is of een patch met te veel overhead.

Voetnoten en referenties

[1] Zie http://www.kimballgroup.com/html/books.html

[2] Dan Linstedt stelt dat de Data Vault geen architectuur(-framework) is, maar

een implementatieplan voor een data warehouse. Voor de leesbaarheid van

dit artikel wordt dit onderscheid niet gemaakt.

[3] Meer informatie over de wijze van modelleren van de Data Vault is te vin-

den op www.danlinstedt.com en www.learndatavault.com.

[4] Dan maakt dit duidelijk in discussie met mij: http://bi-buzz.nl/2011/08/res-

ponse-to-dan-linstedt-what%E2%80%99s-the-added-value-of-the-data-vault/

[5] Zie bijvoorbeeld de kritiek van Dejan Sarka: http://blogs.solidq.com/dsar-

ka/Post.aspx?ID=7&title=Data+Vault+Modeling+Critics

[6] http://www.b-eye-network.com/view/13506

[7] http://bi-buzz.nl/2011/09/data-vault-ideologische-verblinding/

Frank Habers is business developer bij Inergy Analytical Solutions B.V.www.inergy.nl


Hoe ben je ertoe gekomen om architect te wor-den in Visuele Enterprise Architectuur?‘Al vroeg maakte ik in mijn werk als business en ICT con-sultant kennis met werken onder architectuur. In de jaren tachtig en negentig was enterprise architectuur echt een vakgebied in opkomst met een aantal grote beloften. Met name complexe projecten in goede banen leiden, zodat we ICT-oplossingen konden realiseren die voor lange duur het werk van mensen aangenamer maken. Ik merkte echter dat de beloften niet werden ingelost en dat enter-

prise architectuur flink verschilde van gewone architec-tuur. Ik ben op enig moment begonnen om enterprise architectuur te bekijken zoals bouwkundige architecten dat doen. En ik merkte dat dit de toegevoegde waarde van enterprise architectuur deed toenemen. Vooral het creëren van globale overzichtsvisualisaties (structuurvi-sies en blauwdrukken) waarin duidelijk werd met welke

oplossing bepaalde doelstellingen worden gerealiseerd, viel in zeer goede aarde. Als je dan merkt dat je jezelf daarmee onderscheidt van de rest is het logisch om je daarin verder te specialiseren.’

We komen er niet onderuit om deze vraag te stellen. Wat versta je onder architectuur en visuele enterprise architectuur?‘Architectuur is een begrip waar je een gevoelsdefinitie bij kunt plaatsen en een analytische definitie. Architec-

tuur is voor mij qua gevoel iets dat zich als een alles-omvattend geheel presen-teert en veel meer is dan al-leen zichzelf. Bijvoorbeeld de Erasmusbrug is meer dan een brug; het is bijna een monument voor Rotter-dam als logistiek centrum. Ook de oude Opera in Pa-

rijs is meer dan een opera. Het is de bron voor sagen en legenden zoals de ‘Phantom of the Opera’; het was een mijlpaal in de stalen constructiebouw en is qua kunst en muurschilderingen van zeer grote artistieke en histori-sche waarde. Kortom de Opera is meer dan een opera. De opera is architectuur.Visuele enterprise architectuur is een begrip waar meer

Enterprise Architectuur


Visuele Enterprise Architectuur hoort thuis in hoger onderwijs

Tekst: Dragon1 Architecture Foundation

Interview met Mark Paauwe over de open methode Dragon1

Vooral globale overzichtsvisualisaties waarin duidelijk wordt met welke oplossing

bepaalde doelstellingen worden gerealiseerd, vallen in zeer goede aarde

Mark Paauwe (1970) is Thought Leader op het gebied van Visuele Enterprise Architectuur. Mark heeft

de methode Dragon1 ontwikkeld om visuele enterprise architectuur op een eenvoudig wijze te kunnen

toepassen binnen organisaties. In zijn promotieonderzoek op het gebied van architectuurprincipes en

architectuurvisualisaties, koppelt Mark inzichten uit het onderzoek en ervaringen uit de praktijk terug

naar praktische oplossingrichtingen om ondernemingen duurzaam en innovatief te laten zijn. Samen

met de Dragon1 Architecture Foundation is hij bezig om Dragon1 als open methode in te zetten op

hogescholen en universiteiten.



en innovaties in goede banen te leiden. En goed inge-zet is visuele enterprise architectuur een aanvulling op strategie, beleid en informatieplanning. Op het moment dat men dit ook ziet is het genieten om te zien welke re-sultaten men ermee kan bereiken. Dit wil ik ook graag studenten meegeven. Zij worden straks de toekomstige architecten en managers van Nederland en gaan zich met deze uitdagingen en vraagstukken van organisaties be-zighouden.’

Waarom ben je een open methode voor visuele enterprise architectuur gaan ontwikkelen?‘Je staat niet op een dag op en je denkt bij jezelf: Laat ik eens een methode gaan ontwikkelen. Als ik de film terug-haal dan komt het erop neer dat ik met een aantal mensen vaststelde dat we op een geheel andere, maar meer suc-cesvolle, wijze architectuur in organisaties aan het toe-passen waren dan dat gangbare methoden voorschreven. Al die jaren ben ik in feite op zoek naar op welke wijze dat dan wordt gedaan. En ik denk dat we nu zover zijn dat Dragon1 het dichtst in de buurt komt bij het correct be-schrijven van een voorspelbare en herhaalbare succes-volle wijze van werken onder architectuur in organisaties. Drie aspecten die steeds voorop zijn gesteld op het mo-ment dat we doelbewust de methode gingen doorontwik-kelen waren: eenvoud van toepassing, het puur houden van de theorie en proof of concepts uit de praktijk. Dit

een analytische definitie voor architectuur op past. Als we een onderneming als een bouwwerk beschouwen, dan is de architectuur daarvan het samenhangend geheel van toegepaste economische, sociale, bestuurskundige, be-drijfskundige, informatiekundige en technologische concepten die er samen voor zorgen dat het bouwwerk een samenspel is van een sterke constructieve dimensie, operatieve dimensie en decoratieve dimensie. Wat een organisatie nu te doen staat is om enerzijds in beeld te brengen waarom welke concepten zijn toegepast of noodzakelijk zijn en anderzijds hoe goed de concepten zijn toegepast en waar verbeterkansen voor het oprapen liggen. Doe je dit, dan kun je het succes van een organisa-tie besturen via visuele enterprise architectuur.’

Je bent zeer enthousiast over de mogelijkhe-den die visuele enterprise architectuur biedt in de organisatie, hoe komt dat?‘Veel uitdagingen en vraagstukken van organisaties van-daag de dag, zoals e-dienstverlening, zaakgericht werken en ketengericht werken, kunnen zo complex worden, dat ze de organisatie gaan tegenwerken in plaats van hel-pen te innoveren en te concurreren. Dan worden tijd en geld en wellicht banen onnodig verspild. Ik zet me graag met veel energie in om mensen in de organisatie te la-ten inzien dat visuele enterprise architectuur een perfect strategisch stuurinstrument is om bedrijfstransformaties


heeft geresulteerd in een methode die bestaat uit meer dan twintig open standaarden die door een organisatie los van elkaar te gebruiken zijn, een methode die met een gebruikersvereniging en een stichting op open wijze wordt doorontwikkeld.’

Je bent nu bezig om Dragon1 gebruikt te krij-gen in het onderwijs. Wat voegt Dragon1 toe bovenop wat nu al aan bod komt in colleges?‘In de bedrijfskundige en informatiekundige opleidingen is nog veel plaats en ruimte in het grondiger bestuderen en überhaupt gaan visualiseren van de werking van de concepten die in die opleidingen worden aangedragen.

Neem bijvoorbeeld het concept van self service, bijna elke organisatie kan er zijn voordeel mee doen, maar wat is daar precies voor nodig? Waarom lukt het daar wel, maar hier niet? Hoe beter je als student de werking en randvoorwaarden voor de werking van een concept be-grijpt en kan visualiseren, des te beter ben je in je latere werk in staat de concepten succesvol toe te passen of te verbeteren. Nu is er wel aandacht voor architectuur in colleges, maar er is nog geen gerichte aandacht voor het analyseren en visualiseren van de werking van de princi-pes van de aangedragen concepten. Met Dragon1 kan dat wel. Ik denk dat deze manier van kijken naar organisaties en hun vraagstukken met behulp van Dragon1 weer nieu-we kennis en mogelijkheden geeft aan studenten naast alle huidige strategische managementtheorieën.’

Kun je eenvoudig aangeven hoe enterprise architectuur op een visuele wijze dan volgens jou werkt als strategisch stuurinstrument?‘Ik zal het proberen. Door als organisatie bewust bezig te zijn met het voorbestaan en het leveren van een bepaal-de kwaliteit in producten en diensten, vergroot je ook het voortbestaan en de kwaliteit van wat je levert aan klanten. Hiervoor moeten lastige strategische zaken zoals identi-teit, missie, visie op thema’s, uitgangspunten, beleid en bedrijfsdoelen in samenhang expliciet (visueel) worden gemaakt.Vervolgens kun je naar de inrichting of structuur in be-drijfsprocessen, organisatiestructuren en ICT-middelen kijken van een organisatie en deze in termen van compo-nenten en objecten visueel maken. De strategie en inrich-

ting van een organisatie moeten op elkaar zijn afgestemd, bij elkaar passen, anders versterken ze elkaar niet. Dan realiseer je niet je doelstellingen. Visuele enterprise architectuur is als het ware de lijm of smeerolie tussen strategie en inrichting van de organisatie. De strategie vraagt indirect om de inzet van bepaalde bedrijfskundi-ge en informatiekundige concepten, zoals bijvoorbeeld self service, procesmatig werken, het nieuwe werken en cloud computing. De inrichting van de organisatie maakt inzichtelijk hoe bepaalde bedrijfskundige en informa-tiekundige concepten fysiek zijn ingericht of geïmple-menteerd. Visuele enterprise architectuur is kortweg gezegd in feite het geheel aan toegepaste bedrijfskun-

dige en informatiekundige concepten. Door te werken met visuele enterprise ar-chitectuur wordt de noodza-kelijk inzet, het gebruik en de wijze van toepassing van bedrijfskundige concepten en informatiekundige con-cepten expliciet en visueel gemaakt.

Als men niet onder architectuur werkt dan is meestal dit conceptuele niveau niet expliciet en al helemaal niet visueel. Het expliciet en visueel maken van het concep-tuele niveau verbergt de complexiteit die aanwezig is op logisch en fysiek niveau in de organisatie en maakt het kiezen, bijsturen en toepassen van concepten beter stuurbaar door directie en beter realiseerbaar door en-gineers in de organisatie. Dus alles samengevat ga je met visuele enterprise architectuur alles in de organisatie aan elkaar linken of koppelen. Je gaat samenhang en afhanke-lijkheden zien en deze inzichten en overzichten visueel maken en gebruiken als stuurinstrument.’

In je promotieonderzoek richt je je op archi-tectuurprincipes en architectuurvisualisaties. Zijn dat twee onderwerpen waarin nog veel voor verbetering vatbaar is?‘Jazeker. Iedereen, als je het op de man af vraagt, vindt dat er meer gevisualiseerd dient te worden bij architec-tuur, maar beste practices op dit gebied ontbreken nog in hoge mate. En ook architectuurprincipes worden ge-zien door alle architecten als één van de belangrijkste pijlers. Standaardisatie en effectief gebruik echter van architectuurprincipes is nog in vele organisaties verre toekomstmuziek. Een aantal architectuuraanpakken en methoden duiden fragmenten op het gebied van visuali-satie en principes, maar in de praktijk loop je al snel over de grenzen heen die door deze aanpakken worden ge-schetst. En op dat moment ben je op jezelf aangewezen. Je moet dan als architect in feite steeds opnieuw het wiel uitvinden. Vragen die architecten nog steeds hebben is:


In de bedrijfskundige en informatiekundige opleidingen dient meer aandacht besteed te worden aan het visualiseren van de werking

van concepten en hun principes



Hoe moet ik dit aspect van de architectuur nu visualiseren voor de directie met het oog op het doel dat ik heb en dat ze het voldoende begrijpen? Is dit wel een principe wat ik nu formuleer en is dit wel het juiste principe voor de organisatie? Hoe zorg ik er nu voor dat er voor dit prin-cipe wordt gekozen en dat iedereen net zoals ik het prin-cipe belangrijk vindt. Om antwoord op deze vragen te kunnen geven voor architecten in het algemeen, ben ik in mijn promotieonderzoek op zoek naar een solide theorie die de bestaande manier van werken aanvult. Daarvoor is weer beter zicht op de huidige wijze van werken nodig.’

En hoe zorgt Dragon1 er dan voor dat voorde-len worden behaald?‘Dragon1 zorgt ervoor dat je kan laten zien aan je op-drachtgever welke impact bepaalde eisen en wensen hebben en welke impact een bepaalde oplossing met zich meebrengt. Door bijvoorbeeld het principe te visu-aliseren met een principetekening kun je de voor- en na-delen van een (deel)oplossingen letterlijk laten zien. Dit geeft je opdrachtgever het inzicht en ook de argumen-ten om de juiste beslissing te kunnen nemen. Op deze manier ben je als architect een ontwerper en tevens een strategisch adviseur voor de organisatie. Op basis van de gekozen oplossing door de opdrachtgever kan vaak veel geld voor de organisatie worden bespaard.’

Wat is voor jou een goede enterprise architect? Wat moet iemand dan in zich hebben?‘Omdat visuele enterprise architectuur voor mij de kunst en kunde van het ontwerpen, realiseren en innoveren van ondernemingen is, moet een enterprise architect een ervaren creatieve ont-werper zijn. Hij of zij moet het in zich hebben, de drive, om iets te willen ontwerpen en de realisatie ervan be-grijpen. Om te kunnen ont-werpen heeft hij enerzijds algemene kennis over be-drijfskundige en informatiekunde concepten die nodig zijn voor de moderne onderneming, maar net zo belang-rijk is het hebben van voldoende domeinkennis. Als je al-les weet van thuiszorg en woonzorg kun je beter voor een zorginstelling een visuele enterprise architectuur maken en toepassen dan wellicht bij banken of overheidinstel-lingen.’

Wat moeten de huidige en de toekomstige ar-chitecten in de organisatie doen om hun toe-gevoegde waarde te vergroten?‘Ga niet zitten wachten, maar ga de boer op. Zoek je po-tentiële opdrachtgevers op, veelal de CEO, CFO en CIO,

55 september 2011 XR Magazine

en zorg ervoor dat je een ontwerpopdracht krijgt. Maar een ontwerpopdracht krijg je pas als je aannemelijk maakt dat je de opdracht aankan. Dus wat ik doe is mijn opdrachtgever prikkelen met een voorbeeld van een glossy A3-formaat ontwerpboek (een platenatlas) en A0-architectuurposter met een organisatie in vier lagen (een soort strategische landkaart van de organisatie). Veel CxO willen dan ook graag dit soort visuele producten om te gebruiken ter ondersteuning van hun strategische ma-nagementbeslissingen en om beter de risico’s te kunnen beheersen van programma’s en projecten. Ook moeten architecten veel meer dan nu de werking (de principes) van oplossingen (concepten) gaan schetsen en tekenen en bij elk begrip of woord dat ze hanteren nadenken over de betekenis ervan en hoe iemand zich een begrip voor-stelt. Architectuur is wat dat betreft voor 50% communi-ceren. Als je je zo opstelt zoals ik doe, krijg je nooit de vraag: wat is de toegevoegde waarde van de architect? De opdrachtgevers zijn blij dat jij als een van de weini-ge je in ieder geval druk maakt over de issues die zij als CxO’s hebben.’

Hoe zie je enterprise architectuur zich in de nabije toekomst ontwikkelen?‘Ik zie dat we binnen twee jaar het tijdperk achter ons laten dat architecten het analysewerk van anderen doen: lijsten maken van producten en diensten en processen in kaart brengen en applicatiemodellen opstellen. Het werk van de architect is ontwerpen. De producten, diensten, processen, applicaties en servers moeten gewoon altijd up-to-date in beeld zijn, pas dan kan de architect echt aan

ontwerpen toekomen. Omdat architecten zich ook meer visueel gaan uitdrukken en hun klanten opzoeken zal in toenemende mate enterprise architectuur strategisch ge-bruikt gaan worden in de bestuurskamer en directieka-mer.Studenten zullen in de toekomst op verschillende ma-nieren met visuele enterprise architectuur hun voordeel kunnen doen. Vrijdenken en kruisbestuiving zijn hier de toverwoorden. Door als bedrijfskundige of informa-tiekundige student meer bewust naar concepten te kij-ken, wordt het ook in een studieomgeving mogelijk om vernieuwend onderzoek te doen aan een uniek nog niet verkend totaalconcept. Het kunnen onderzoeken van

Omdat architecten zich meer visueel gaan uitdrukken en hun klanten opzoeken zal in toenemende mate enterprise architectuur

strategisch gebruikt gaan worden

unieke combinaties van bedrijfskundige en informatie-kundige concepten zorgt voor vernieuwende inzichten. Dit is heel belangrijk omdat studenten in hoge mate out of the box kunnen denken. Ze worden niet afgeremd door blokkades die soms in het denken van ervaren medewer-kers bij organisaties al wel zijn opgebouwd. Studenten zullen gaan werken met een nieuw gemeenschappelijk denkkader en begrippenkader waardoor vraagstukken in ondernemingen anders benaderd gaan worden en de kans groter is om hier oplossingen voor te bedenken.’

Wie is jouw voorbeeld op architectuurgebied?‘Dat is een lastige vraag. Maar als ik dan iemand moet noemen, dan noem ik naast Vitruvius en de filosoof Kant, als mijn grote voorbeeld Leonardo da Vinci. Leonardo was iemand die minutieuze belangstelling had voor al-les op aarde. Hij kon dagenlang zich vastbijten in iets om te leren hoe het in elkaar stak en werkte, om vervolgens deze kennis en ervaring te hergebruiken op een heel ander gebied. Daarvoor heeft hij zichzelf een kunst en kunde aangeleerd van het objectief observeren, docu-menteren en visualiseren. Ook dacht hij over alles zelf na, ook over de basis theorie die hij gebruikte. Kijk en dit zijn allemaal precies die aspecten die ik ook in mijn werk

nodig heb en heb gehad om bijvoorbeeld te komen tot Dragon1 en de inzichten die ik nu heb op het gebied van architectuurprincipes.’

Wat doe je naast je werk bij PAAUWE?‘De wereld verkennen door te reizen en muziek te maken. Ik heb echt van mijn hobby mijn werk gemaakt. Als ik met mijn vrouw en dochter door Parijs loop en de Opera of het Louvre bezoek geniet ik van de gebouwen en de muziek. Er is nog zoveel te leren en te hergebruiken uit bouwkundige architectuur en muziek dat ik met 24 uur per dag te weinig tijd om van alles te horen, te zien en te genieten. Weten wat je ziet en begrijpen wat je ziet, en dan ervan hergebruik maken op een ander gebied. Dat is net zoals van Leonardo ook mijn persoonlijke ambitie.’

Wil je, naar aanleiding van dit artikel, meer weten over Dragon1 in het hoger onderwijs? Kijk dan op www.dragon1.org of op www.paauwe.info voor het promotieonderzoek van Mark Paauwe.

Mark Paauwe is thought leader Visual Enter-prise Architecture en Founder of Dragon1.http://www.paauwe.info

56 XR Magazine september 2011 Reageren op dit artikel? Klik hier.

http://tools.paauwe.info/index.php?page=shop.product_details&flypage=flypage-books.tpl&product_id=138&category_id=8&option=com_virtuemart&Itemid=110


Volgende editie van XR Magazine:

Strategie en beleidIn de maand oktober is ‘Strategie, architectuur en beleid’ het centrale thema van XR Magazine. Wij zijn daarom op zoek naar artikelen, columns, praktijkcases en opiniestukken waarin nieuwe ontwikkelingen, visies, uitda-gingen en best practices m.b.t. dit onderwerp centraal staan. Denk hierbij bijvoorbeeld aan onderwerpen als:

• Zit architectuur voor of na strategie of voor of na beleid?• Enterprise Architectuur als strategisch stuurinstrument• Identiteit en cultuur, vergeten we dat niet te vaak?• Missie, Visie en Strategie in Architectuur• Doelstellingen, eisen, wensen, (architectuur)principes, regels en richtlijnen: hoe zijn deze proposities aan elkaar

gerelateerd?• Architectuur in de boardroom: wat werkt wel en wat niet?• Architectuur op strategisch, tactisch en operationeel niveau• Governance architectuur• Informatiebeveiligingsbeleid en security architectuur• Top prioriteiten en concerns van de CIO en CEO

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

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

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

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

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

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

Colofon

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

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

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

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

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

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

Website: www.xr-magazine.nl

Foto voorkant: lightpoet / Shutterstock.com

http://www.xr-magazine.nl/advertenties/26/advertentie-lac-mag-26-2.html