Colofon

©2017 Daniël Jumelet

ISBN 978 94 92190 41 3
ISBN epub 978 94 92190 91 8

Boekverzorging: LINE UP boek en media, Groningen
Eindredactie: Minke Sikkema
Boekontwerp en dtp: Riëtte van Zwol en Bas Ekkers

Auteursfoto: Jeroen Jumelet
Overige foto’s: Pexels p. 2, 8, 12, 26, 66, 120, 140, 194, 202, 210, 234; Shutterstock p. 30, 48, 52, 74, 106, 128, 146, 174, 226; Jeroen Jumelet p. 50, 51, 240; Zolore p. 166

In dit boek gebruikte merknamen:
DYA®: Sogeti Nederland B.V.
ArchiMate®: X/Open Company Limited trading as The Open Group
DEMO®: Sapio B.V.
TOGAF™: X/Open Company Limited trading as The Open Group
AgilePM®: Dynamic Systems Development Method Limited

Alle rechten voorbehouden. Behoudens de in of krachtens de Auteurswet 1912 gestelde uitzonderingen, mag niets uit deze uitgave worden verveelvoudigd, opgeslagen in een geautomatiseerd gegevensbestand of openbaar gemaakt in enige vorm of op enige wijze, hetzij elektronisch, mechanisch, door fotokopieën, opnamen of enige andere manier, zonder voorafgaande schriftelijke toestemming van de uitgever. Hoewel aan de totstandkoming van deze uitgave de uiterste zorg is besteed, kan voor de afwezigheid van eventuele (druk)fouten en onvolledigheden niet worden ingestaan en aanvaarden de auteur(s), redacteur(en) en uitgever deswege geen aansprakelijkheid voor de gevolgen van eventueel voorkomende fouten en onvolledigheden.

All rights reserved. No part of this publication may be reproduced, Stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the publisher’s prior consent.

Notitie bij het uitbrengen van het e-book

Een architectuurboek hoort er geweldig uit te zien, met veel aandacht voor opmaak en grafische details. Het oorspronkelijke boek, de papieren versie, is ook zo gemaakt. Omdat ik het heel belangrijk vind om de inhoud zo laagdrempelig mogelijk te delen, is een e-book beschikbaar gesteld. Ik hoop dat het lezen je in ieder geval inspiratie en plezier zal bieden! Als het boek waardevol voor je is en je het boek echt wilt ervaren zoals het is bedoeld, dan raad ik je aan een papieren versie aan te schaffen. Dat kan het makkelijkst via de webshop van de uitgever. Een digitale preview is daar in te zien.

Iedere aankoop van het boek is een extra steun in de rug voor de verdere ontwikkeling van het architectuurvak. Zoals zo vaak is ook in dit geval de kost voor de baat uitgegaan. Laat anderen weten wat je ervan vindt en raad ze aan om hun eigen exemplaar te downloaden of te bestellen. Veel dank hiervoor en succes met je werk!

Woord vooraf

Het geeft mij veel voldoening om kennis en ervaring met anderen te delen en zo met elkaar nieuwe inzichten op te doen. Daarom heb ik met veel plezier in dit boek vastgelegd hoe ik mijn weg heb gevonden in de IT-architectuur. Mijn technische achtergrond is die van IT-infrastructuur. Vanaf het begin bleek dat juist binnen dit domein nog veel te ontdekken en te pionieren was als het gaat om architectuur. Het is een domein dat in de meeste organisaties voorbehouden is aan specialisten en dat moeilijk te doorgronden is voor mensen met een andere expertise. Om toch zinvol met verschillende doelgroepen samen te werken op het vlak van vormgeving en ontwikkeling van infrastructuurlandschappen, moesten extra stappen worden gezet. Hieruit is de Open Infrastructure Architecture method ontstaan (OIAm). OIAm is een methode die infrastructuur eerst in termen van functionaliteit en kwaliteit onder woorden brengt en definieert, om van daaruit het ontwerp van de constructie richting te geven.

Veel van datgene wat ontwikkeld is binnen OIAm, is naar mijn inschatting ook toepasbaar binnen andere domeinen. Bovendien zijn bij het gebruik en bij de verfijning van de methode dingen ontstaan die voor IT-architectuur in het algemeen nuttig zijn. Dit alles is gebundeld in dit boek. Het is bedoeld als een praktische gids voor iedereen die het vak van IT-(infrastructuur)architect wil beoefenen. Methodisch gezien vertrekt het boek vanuit OIAm en infrastructuurarchitectuur. Van daaruit is er uitgesproken aandacht voor de ArchiMate®-semantiek die binnen OIAm wordt gebruikt om functiemodellen te maken. Ook zijn er expliciete verbanden met elementen uit de TOGAF™-, DYA®- en DEMO®-architectuurmethoden. Het boek is zo opgezet dat de inzichten die hier worden aangereikt, gemakkelijk te combineren zijn met deze en andere architectuurmethoden. Mijn ervaring is dat de meeste IT-architecten hun gereedschapskist vullen met verschillende aanpakken. Een divergente aanpak is in ieder geval ten zeerste aan te bevelen, dit is immers een bron van vernieuwing.

Het boek behandelt een aantal verschillende onderwerpen die van belang zijn bij de uitoefening van het vak en het naar behoren uitvoeren van de belangrijkste taken. Zo wordt ingegaan op het ontwerpproces, de rol van architectuur daarin en het maken van functiemodellen. Dit onderdeel is het meest OIAm-specifiek. Ook is er aandacht voor de producten die een architect vervaardigt en de (herbruikbare) ingrediënten waarmee die producten samengesteld worden. Samenwerken met collega's en andere IT-disciplines is heel belangrijk voor het inbedden van architectuur, een belangrijke randvoorwaarde voor een effectieve beoefening van het vak. Vandaar dat ook hier uitgebreid bij wordt stilgestaan. Naast dit theoretische kader is een aparte verhaallijn door het gehele boek heen geweven, die verschillende ervaringsverhalen uit de praktijk omvat. In een aanvullend hoofdstuk wordt speciaal stilgestaan bij de koppeling tussen (infrastructuur)architectuur en IT-beveiliging, omdat op dit snijvlak dikwijls cruciale beslissingen moeten worden genomen in de afweging tussen gebruikersvriendelijkheid, vernieuwingskracht en veiligheid.

Het boek kan op verschillende manieren worden gelezen: als inleiding in OIAm, als praktijkgids voor het toepassen van IT-architectuur of als doorkijkje in de manier van werken van een vakgenoot. Ik laat het graag aan de lezer over om eruit te halen wat van zijn of haar gading is en dit naar hartenlust te combineren met eigen inzichten en werkwijzen. Ik hoop dat dit leidt tot nieuwe inzichten in en ontwikkeling van dit vakgebied, want dat is per slot van rekening ook de basis van dit boek.

Wat mij betreft staat IT-architectuur als vak nog steeds in de steigers, in vrijwel alle facetten. Er is nog genoeg te doen om het vak verder te professionaliseren door te bouwen aan een gestructureerde, methodische manier van werken. Met dit boek wil ik graag een steentje bijdragen aan de ontwikkeling van het IT-architectuurvak. Want het is een vak dat in veel organisaties onmisbaar is geworden om IT succesvol en efficiënt in te zetten. IT is namelijk zodanig complex geworden dat ontwerp meer dan ooit nodig is bij veranderingen. Aan de manier waarop dat ontwerp tot stand komt, worden bovendien hoge eisen gesteld. De IT moet zodanig vormgegeven worden dat deze als geheel passend is bij de doelen en het karakter van de organisatie. Dat betekent dat zowel bij visieontwikkeling alsook bij veranderingen alle belanghebbenden moeten worden betrokken. Dit op zo'n manier dat ze ook daadwerkelijk hun behoeften en bezwaren kunnen inbrengen in de discussie (ofwel het discours) over de te kiezen inrichting.

In veel landen, zoals Nederland en Groot-Brittannië, is er geen wettelijke basis voor het voeren van de titel IT-architect, businessarchitect, informatiearchitect, infrastructuurarchitect of welke IT-variant daarvan dan ook. In deze landen kent de wet alleen architecten die bouwkundige ontwerpen maken. De titel architect is beschermd. Om deze titel te mogen dragen dienen architecten zich gekwalificeerd te hebben door het volgen van een degelijke en op het vak toegespitste opleiding op hbo- of wo-niveau en moeten ze zich hebben ingeschreven in een register. Het is de taak van registers om de bescherming van de architectentitel te handhaven en op te treden tegen onrechtmatig gebruik. Veel registers hebben het standpunt geformuleerd dat ze het gebruik van de titel architect in de context van de IT gedogen, mits helder is dat het om een ander soort architecten gaat dan bouwkundige en er in de markt geen verwarring kan ontstaan. Het belangrijkste doel van registers is namelijk het tegengaan van beunhazen in de bouwsector. Echter, tegelijkertijd roepen registers de aan de IT gelieerde architecten en architectenverenigingen regelmatig op om ervoor te zorgen dat, als de titel van architect zo gewild en geliefd is, deze in de context van de IT te legaliseren. Dit door de juiste opleidingen te organiseren en certificering op hoog niveau te realiseren. Wat mij betreft betrachten we aan de ene kant de bescheidenheid die bij de stand van de ontwikkeling van IT-architectuur past, terwijl we aan de andere kant alles op alles te zetten om het vak naar een hoger plan te stuwen. Daarbij goed kijkend naar 'echte' architecten.

Bouwkundig architecten zijn bij uitstek in staat om zowel met opdrachtgevers als leveranciers en aannemers te communiceren. Zij zijn het die inhoudelijk de brug slaan tussen de vraag- en de aanbodzijde. Dit begint bij het verhelderen van de vraag van de opdrachtgevers en een inventarisatie van alle mogelijke belanghebbenden bij een project. Door te ontwerpen wordt een oplossing op een gestructureerde manier vormgegeven, in een iteratief en interrogatief proces met opdrachtgevers en andere betrokkenen. Vervolgens worden vanuit het ontwerp de haalbaarheid onderzocht en de mogelijke constructiewijze(n) bepaald. In samenspraak met leveranciers en aannemers wordt de technische realisatie verder uitgewerkt en begeleid. Het is de architect die het overzicht houdt, de passendheid van de oplossing in de context bewaakt en ervoor zorgt dat de constructie gaat voldoen aan alle vereisten die eraan worden gesteld vanuit het gebruik, het beheer en de beveiliging.

In die zin zijn ook in de digitale wereld echte architecten nodig, als 'boven de constructie uitstijgende vormgevers'. Maar hoe kun je die rol spelen? Hoe ga je te werk? Wat lever je op en voor wie? Hoe kun je met architectuur van toegevoegde waarde zijn voor de organisatie(s) waarvoor je werkzaam bent? Vragen genoeg. Met dit boek wil ik handvatten geven voor het beantwoorden van deze vragen aan iedereen die zich wil toeleggen op de vormgeving van de IT van een organisatie. Ik hoop dat het een inspiratiebron is voor een vak dat dienend het best tot zijn recht komt.

Culemborg, januari 2017

Inhoud

Omslag

Colofon

Notitie bij het uitbrengen van het e-book

Woord vooraf

Hoofdstuk 1 Inleiding

1.1 Belangrijke taken van de IT-architect

1.2 Inzichten en vaardigheden van de IT-architect: indeling van en leeswijzer bij het boek

1.3 Belangrijkste boodschappen van dit boek

Persoonlijke praktijkverhalen

Enkele terzijdes

Hoofdstuk 2 De rol van architectuur in het ontwerpproces

2.1 Fasen van het ontwerpproces: de ontwerpcontinuüms

2.2 In detail: stappen in het architectuurcontinuüm

2.3 Betrekken van belanghebbenden

De rol van de community

Hoofdstuk 3 Het maken van functiemodellen: spil van het architectuurwerk

3.1 Patronen

3.2 Een begrippenkader voor infrastructuurfuncties

3.3 ArchiMate: een semantiek voor de modelleur

3.4 Toepassing van de OIAm-modelleeraanpak buiten het infrastructuurdomein

Omgaan met datacentertransities

Hoofdstuk 4 Werken met modellen: voorbeelden

4.1 Voorbeeld 1: de Exchange-migratie

4.2 Voorbeeld 2: Identity Management voor cloudoplossingen

Vormgeven van werkplekdiensten

Hoofdstuk 5 Ingrediënten van architectuurproducten

5.1 User stories

5.2 Servicebeschrijvingen

5.3 Kwaliteitskenmerken

5.4 Omgevingen

5.5 Gebruikerscategorieën

5.6 Principes

5.7 Architecture Building Block

5.8 Artist impressions

5.9 Solution Building Blocks

5.10 Dreigingsanalyses

Werken aan referentiearchitecturen

Hoofdstuk 6 Architectuurproducten

6.1 Organisatiecontextanalyse (OCA)

6.2 Business-IT-plan, roadmap en projectenkalender

6.3 Referentiearchitectuur

6.4 Businesscase/impactanalyse/haalbaarheidsstudie

6.5 Projectstartarchitectuur (PSA), sourcingstartarchitectuur (SSA) en Solution Foundation

6.6 Rootcause-analyse

Functioneel aanbesteden

Hoofdstuk 7 Inbedden van architectuur

7.1 Doelen

7.2 Processen

7.3 Rollen

7.4 Architectuurproducten

7.5 Strategische partners

7.6 Governance

7.7 Architectuur zichtbaar maken

Politiek op de werkvloer: beslissingsondersteuning

Hoofdstuk 8 Infrastructuurarchitectuur en IT-beveiliging

8.1 Strategiebepaling

8.2 Dreigings- en risicoanalyses

8.3 Mitigatie

8.4 Voorbeeld van een dreigingsanalyse

8.5 Beveiligingsbeheer

8.6 Privacybescherming

Omgaan met trends

Bijlage A Introductie OIAm

A.1 Wat is OIAm?

A.2 Focus van OIAm

A.3 Wat biedt OIAm?

A.4 Geschiedenis van OIAm

A.5 Wat blijft buiten scope voor OIAm?

Bijlage B Modelleerconventies voor toepassing van ArchiMate

B.1 Gebruik van ArchiMate

B.2 Voorkeursconcepten infrastructuur

B.3 Afspraken over relaties

B.4 Relaties tussen views en lagen

B.5 Niveau van detaillering

B.6 Afspraken over naamgeving

Bijlage C Clouddienstenarrangementen

C.1 Application Hosting

C.2 Web Hosting

C.3 Calculation

C.4 Data Management

Verklarende woordenlijst

Literatuur

Dankwoord

Daniël Jumelet

Hoofdstuk 1 Inleiding

Dit boek gaat over het toepassen van architectuur op de IT van een organisatie. Wat zijn de taken van een IT-architect? Welke werkwijzen en hulpmiddelen staan een IT-architect ter beschikking bij de uitvoering van zijn of haar werk? Welke producten worden vervaardigd in de uitoefening van de rol van architect? Hoe wordt de architectuurfunctie in een organisatie ingebed en hoe ziet de samenwerking met andere rollen eruit? Kortom, wat betekent het om een volwaardig IT-architect te zijn?

De term 'IT-architectuur' wordt consequent gehanteerd om een onderscheid te maken met andere vormen van architectuurbeoefening, zoals bouwkundige of civiele architectuur. De term omvat alle vormen en domeinen van IT-architectuur. Als een specifiek domein wordt bedoeld, dan is dit expliciet aangegeven. Veel van wat in dit boek de revue passeert is ook bruikbaar ten aanzien van IT-gerelateerde architectuur (zoals enterprisearchitectuur en informatiearchitectuur). Dit is belangrijk, omdat er op een wederkerige manier interactie is tussen procesinrichting en informatievoorziening aan de ene kant en de inrichting van de IT aan de andere kant. Voor de eenduidigheid wordt in dit boek de vormgeving van de IT als perspectief gekozen.

Dit boek is ontstaan in het kader van de ontwikkeling van de Open Infrastructure Architecture method (OIAm). OIAm richt zich op de vormgeving van infrastructuurlandschappen en -voorzieningen vanuit het perspectief van functionaliteit en kwaliteit. Dit gebeurt aan de hand van functiemodellen, waarvoor OIAm tal van hulpmiddelen aanreikt, zoals generieke functiepatronen, functiedefinities en een ontwerpworkflow.¹ In de loop van de tijd zijn hieromheen allerlei 'good practices' ontstaan en uitgewerkt. Zowel de ontwerpmethode van OIAm als de werkwijzen eromheen zijn behalve voor infrastructuurarchitecten ook voor architecten in andere domeinen toepasbaar en handig. Vertrekkend vanuit OIAm geeft dit boek handreikingen voor het pragmatisch en tegelijkertijd methodisch invullen van de IT-architectuurfunctie.

Het boek is bedoeld voor iedereen die zich een beeld wil vormen van en/of zich verder wil bekwamen in het vak IT-architectuur. Allereerst betreft dit iedereen die al op de een of andere manier als IT-architect werkzaam is en zich bezighoudt met het ontwerpen en ontwikkelen van bedrijfsprocessen en applicatie- en infrastructuurlandschappen. Ervaring met IT en kennis van IT-architectuurmethoden als DYA, TOGAF, DEMO, Novius en in het bijzonder ArchiMate helpen daarbij, omdat het boek vooral gericht is op de verdieping van de beoefening van het vak. Maar ook wie nog aan het begin staat van een carrière van IT-architect, moet zijn of haar voordeel ermee kunnen doen, in ieder geval ten aanzien van de visie op IT-architectuur die het boek uitdraagt. Behalve voor IT-architecten bevat het boek ook voor andere doelgroepen nuttige elementen. Zo biedt het beslissers een kijkje in de keuken van de IT-architect, zodat de rol van de architect in de totstandkoming en de verdere ontwikkeling van IT duidelijker is en inzichtelijk wordt hoe deze de besluitvorming ondersteunt. Voor tal van andere disciplines, zoals projectmanagers, businessanalisten, informatiemanagers, requirementsmanagers, servicemanagers, inkopers, IT-beveiligers, IT-ontwikkelaars, technisch specialisten en beheerders, bevat het boek interessante elementen, in ieder geval als het gaat om de manier van samenwerken en welke extra's dit oplevert. In de leeswijzer is aangegeven welke onderwerpen het boek behandelt en voor wie deze nuttig zijn. Maar in deze inleiding allereerst aandacht voor wat er van een IT-architect verwacht mag worden.

1.1 Belangrijke taken van de IT-architect

Het toepassen van architectuur is ondersteunend van aard. Het is vooral nodig wanneer de bedrijfsinrichting en het onderliggende IT-landschap zodanig complex zijn (geworden) dat deze een ordenende ontwerpfunctie behoeven om hanteerbaar en aanpasbaar te blijven. Het bestaansrecht van IT-architectuur kan op basis hiervan als volgt worden geformuleerd:

IT-architectuur levert toegevoegde waarde aan een organisatie als op een effectieve manier inhoudelijk zorg wordt gedragen voor een consistent, toekomstvast en efficiënt benut IT-landschap, in harmonie met de procesinrichting en de informatievoorziening van een organisatie.

Dit betekent dat IT-architectuur de beslissende factor is bij het vormgeven (ontwerpen en ontwikkelen) van een IT-landschap en de voorzieningen die in dit landschap een plek hebben. Dit wordt doorvertaald naar de volgende taken, waarvoor de IT-architect inhoudelijk verantwoordelijk is:

1.
Visieontwikkeling. Hoe moet het IT-landschap van een organisatie worden voorbereid op toekomstige veranderingen in de organisatie, bedrijfsactiviteiten, wet- en regelgeving, et cetera? Hoe om te gaan met kansen die technische innovatie biedt? Wat is de impact die deze ontwikkelingen hebben op de IT-diensten die een organisatie benut en welke veranderingen zijn op de middellange en lange termijn te verwachten?

2.
Vaststellen van de veranderingsbehoeften en de vereisten aan nieuwe oplossingen. Wat zijn de behoeften van de verschillende belanghebbenden bij een verandering en hoe zijn deze met elkaar in overeenstemming te brengen in één consistente set aan vereisten? Zijn er passende oplossingen voorhanden en hoe haalbaar en/of hoe profijtelijk is het om deze oplossingen te implementeren? Hoe wordt de veiligheid van voorzieningen geborgd?

3.
Ontwerpbegeleiding. Hoe worden vereisten aan een oplossing vertaald naar eisen aan de constructie en richtlijnen voor constructieontwerpers en -bouwers? Waar kunnen oorzaken gevonden worden als zich structurele problemen in de constructie voordoen en hoe worden deze verholpen?

4.
Ondersteuning van besluitvorming. Door het ontwerpproces te begeleiden en te faciliteren kunnen architecten van bijzonder groot belang zijn voor de besluitvorming in een organisatie. Hoe worden alle belangrijke belanghebbenden op de juiste manier meegenomen in het ontwerpproces? Dat wil zeggen, hoe wordt ervoor gezorgd dat iedereen begrijpt waar het over gaat en de inbreng levert die past bij de rol die men heeft, en dat beslissers in staat zijn weloverwogen keuzes te maken die op draagvlak kunnen rekenen in de organisatie?

De bovenstaande taken kunnen worden samengevat met de term 'digitale ruimtelijke ordening'. Om dit gestructureerd en voorspelbaar te doen is een aantal specifieke inzichten en vaardigheden onmisbaar. Het is langs die lijn dat het boek is ingedeeld. Met andere woorden: wat moet een IT-architect allemaal doen om zijn werk effectief uit te voeren?

1.2 Inzichten en vaardigheden van de IT-architect: indeling van en leeswijzer bij het boek

Handige werkwijzen, toegepast vanuit een goedgekozen perspectief en ingebed in een goede samenwerking, vergemakkelijken het werk. Maar wat meer is, ze leiden tot resultaten die beter onderbouwd zijn en aantoonbaar tot nut zijn voor de organisatie. Essentiële onderwerpen bij de digitale ruimtelijke ordeningen die in dit boek aan de orde komen, zijn:

• | De rol van architectuur in het ontwerpproces. Waar en hoe maakt een IT-architect het verschil bij het vormgeven en ontwikkelen van IT-voorzieningen en -landschappen?
• | Het maken van functiemodellen: spil van het architectuurwerk. Hoe wordt het ontwerpproces gefaciliteerd met modellen, hoe worden die opgesteld en hoe worden hiermee enerzijds de juiste ontwerpvragen gesteld en anderzijds behoeften, vereisten en eisen gerangschikt?
• | Voorbeelden van het werken met modellen. Enkele illustraties om aan te geven hoe het ontwerpproces eruitziet wanneer functiemodellen worden gebruikt.
• | Architectuurproducten en hun ingrediënten. Welke architectuurproducten zijn handig voor welke situatie en welke doelgroepen? Met welke (herbruikbare) ingrediënten worden deze producten vervaardigd?
• | Inbedding van architectuur. Over het organiseren van optimale samenwerking, zodat de architectuurfunctie effectief en efficiënt in een organisatie werkzaam is.

Als extra onderwerp is hier de samenwerking tussen (infrastructuur)architectuur en IT-beveiliging aan toegevoegd. Dit omdat juist op dit snijvlak dikwijls cruciale beslissingen worden genomen met impact op gebruiksvriendelijkheid, vernieuwingskracht en veiligheid van het IT-landschap.

In de volgende tabel is per hoofdstuk aangegeven welk onderwerp aan bod komt en voor wie dit interessant is.

Hoofdstuk
Titel
Beschrijving
Voor wie?

2
De rol van architectuur in het ontwerpproces
Hoewel ontwerpprocessen creatief en associatief zijn en in veel gevallen ook iteratief, is het heel goed mogelijk om er een zekere structuur in aan te brengen. Dat kan door het ontwerpproces in verschillende continuüms in te delen die gefaseerd en iteratief worden doorlopen:
a. het architectuurcontinuüm, waarin het functieontwerp wordt gemaakt;
b. het oplossingscontinuüm, waarin het constructieontwerp zijn beslag krijgt;
c. het realisatiecontinuüm, waarin de fysieke verschijningsvorm gestalte krijgt.
Per continuüm is het mogelijk te vertrekken vanuit een generieke opzet (een archetype), om van hieruit de specifieke toepassing af te leiden, de implementatie in de context van de organisatie en de situatie.
De indeling van het ontwerpproces in continuüms zorgt enerzijds voor helderheid en anderzijds voor snelheid. Ze helpt ons bij nieuwe oplossingen de juiste ontwerpvragen te stellen, in de juiste volgorde, en voorkomt een herhaling van zetten bij de implementatie van bestaande oplossingen. Dit wordt in het eerste deel van dit hoofdstuk uitgewerkt.
Het tweede deel spitst zich verder toe op het architectuurcontinuüm. In de fase van het functieontwerp zijn drie stappen te onderscheiden die ervoor zorgen dat functie- en kwaliteitsvereisten gestructureerd worden opgehaald en eenduidig worden vertaald naar constructie-eisen. Dit door de juiste belanghebbenden te betrekken en hun behoeften te inventariseren en met elkaar in lijn te brengen.
Dit hoofdstuk maakt duidelijk wat de toegevoegde waarde van architectuur is in het ontwerpproces en hoe efficiënt richting kan worden gegeven aan dit ontwerpproces, zodat oplossingen worden gerealiseerd die passend zijn bij een organisatie en die op een gewogen manier rekening houden met de behoeften van alle betrokken belanghebbenden.
IT-architecten, chief information officers (CIO's), informatiemanagers, businessanalisten, requirementsmanagers, projectmanagers, inkopers, IT-beveiligers, technisch specialisten, ontwikkelaars en beheerders

3
Het maken van functiemodellen: spil van het architectuurwerk
In hoofdstuk 2 wordt de belangrijke rol van de architect in het ontwerpproces beschreven en geduid. Om die rol goed te kunnen invullen wordt sterk aangeraden te werken met functiemodellen. Deze modellen dienen naar twee kanten als kapstok: enerzijds helpen ze bij het identificeren van belangrijke ontwerpvragen en anderzijds ondersteunen ze het structureren van behoeften van belanghebbenden, vereisten aan services en eisen aan de constructie. Dit hoofdstuk biedt het theoretisch kader voor het maken van functiemodellen. Afhankelijk van de voorkeur van de lezer kan eerst dit hoofdstuk worden gelezen en daarna het hoofdstuk met een aantal voorbeelden (hoofdstuk 4), of juist andersom.
IT-architecten, requirementsmanagers, technisch specialisten, ontwikkelaars en beheerders

4
Werken met modellen: voorbeelden
Dit hoofdstuk is de tegenhanger van hoofdstuk 3 en geeft twee voorbeelden van het gebruik van functiemodellen. Het eerste voorbeeld vertrekt vanuit de techniek en laat zien hoe met functiemodellen via 'reverse architecture' de functionaliteit in de bestaande situatie helder wordt, om vervolgens aan de hand van functiemodellen de doelarchitectuur te schetsen. Het tweede voorbeeld laat zien hoe functiemodellen worden gebruikt om behoeften van belanghebbenden te structureren tot vereisten aan de functionaliteit en kwaliteit en deze te vertalen naar eisen aan de constructie. In beide gevallen wordt het volledige voortbrengingsproces geïllustreerd, waarbij uiteraard de meeste aandacht uitgaat naar de fase waarin het functieontwerp wordt opgesteld, het architectuurcontinuüm.
IT-architecten, requirementsmanagers, technisch specialisten, ontwikkelaars en beheerders

5
Ingrediënten van architectuurproducten
Dit hoofdstuk bevat een overzicht van alle herbruikbare ingrediënten die worden aangewend voor de samenstelling van architectuurproducten, die in hoofdstuk 6 worden beschreven. Hoewel nuttig en noodzakelijk, is dit – vergeleken met de rest van het boek – een hoofdstuk dat overwegend opsommend van aard is. Het is vooral handig bij het in detail inzoomen op het architectuurhandwerk. Daarom kan dit hoofdstuk ook worden overgeslagen, ten faveure van hoofdstuk 6, dat een aantal belangrijke architectuurproducten presenteert.
IT-architecten

6
Architectuurproducten
Van een IT-architect wordt verwacht dat hij/zij concrete producten oplevert. Deze producten moeten passen bij de situatie en de doelgroep(en) die in de betreffende situatie relevant zijn. Zo is een referentiearchitectuur vooral bedoeld voor IT-architecten zelf, in het kader van het werken aan architectuur. Wordt onder architectuur gewerkt, dan zijn sommige producten gericht op visieontwikkeling ten behoeve van beslissers (zoals een businessinfrastructuurplan of een roadmap), terwijl andere producten zich richten op projecten en de teams die hierin betrokken zijn (zoals de projectstartarchitectuur). In dit hoofdstuk worden de belangrijkste producten op een rijtje gezet, waarbij aangegeven is welke ingrediënten en welke betrokkenen bij de vervaardiging een rol spelen. Aan de hand hiervan kan in de eigen situatie bepaald worden welke producten het meest nodig zijn en/of het best geschikt zijn om de architectuurfunctie op de kaart te zetten.
IT-architecten, informatiemanagers, projectmanagers, servicemanagers, CIO's

7
Inbedden van architectuur
Het mooiste wat een IT-architect kan overkomen is dat hij/zij wordt gezien als 'onmisbaar oliemannetje' of 'talentvolle visionair'. In werkelijkheid is er echter in veel organisaties weerstand tegen of onbegrip voor de architectuurfunctie. Soms heeft dat te maken met de ontwikkelfase waarin een organisatie zich bevindt. Andere keren zijn het de ervaringen uit het verleden met de effectiviteit van IT-architectuur die een sceptische houding hebben gevoed. Hoe dan ook, IT-architecten kunnen veel bereiken door goed na te denken over de invulling van de samenwerking met andere IT-disciplines. Ook is het belangrijk architectuur een formele plek in de (besluitvorming van de) organisatie te geven en actief te werken aan de zichtbaarheid van resultaten.
IT-architecten, CIO's

8
Infrastructuurarchitectuur en IT-beveiliging
Dit hoofdstuk is een 'special' over de samenwerking van (infrastructuur)architecten met IT-beveiligers. Terwijl IT-beveiliging een absolute must is voor moderne organisaties, blijft het worstelen met de impact van beveiligingsmaatregelen op gebruikersvriendelijkheid en de ruimte om snel innovatie en vernieuwing toe te passen. Om die reden is het van groot belang dat behoeften vanuit IT-beveiliging op een directe manier worden meegenomen in het ontwerpproces. Dit hoofdstuk geeft hier een voorzet voor, in aanvulling op het brede scala aan IT-beveiligingsmethoden en -normen die in de industrie voorhanden zijn.
IT-architecten, IT-beveiligers, projectmanagers, technisch specialisten, ontwikkelaars en beheerders

Naast de hoofdstukken die de theorie beschrijven of deze ondersteunen, zijn in het boek enkele praktijkverhalen opgenomen. Deze zijn bedoeld zijn als illustratie en verlevendiging en zijn door het geheel van het boek heen geweven. De thema's die hierin naar voren komen zijn:

• | het ontstaan van OIAm en de rol van de community;
• | omgaan met datacentertransities;
• | vormgeven van digitale werkruimtes;
• | werken aan referentiearchitecturen;
• | functioneel aanbesteden;
• | politiek op de werkvloer: beslissingsondersteuning;
• | omgaan met trends.

Belangrijke begrippen en definities

Net als in veel andere vakgebieden worden in de IT termen gebruikt die meerdere betekenissen en afwijkende lading en gevoelswaarden kunnen hebben. Voor een goed begrip van wat in dit boek wordt beschreven, worden de belangrijkste begrippen hier op een rij gezet. Achter in het boek is een aanvullende verklarende woordenlijst opgenomen.

Service – Het geheel aan functionaliteit die een voorziening levert, zoals die door gebruikers wordt afgenomen en ervaren. ArchiMate noemt dat 'extern gedrag'.

Functie – Een werking die – eventueel in samenhang met andere werkingen – een service realiseert. ArchiMate noemt dat 'intern gedrag'. Een functie wordt alleen indirect afgenomen door gebruikers, via de service.

Constructie – Het geheel van componenten en verbindingen die functies uitvoeren.

Principe – Overkoepelende normatieve uitspraak die (mede) richting geeft aan het ontwerp.

Model – Een schematische weergave (reductie) van een onderdeel van de werkelijkheid, waardoor die aspecten worden uitgelicht die van belang worden geacht voor (ontwerp)uitspraken over dat onderdeel van de werkelijkheid.

Belanghebbende – Persoon of onderdeel van een organisatie die vanuit de rol binnen de organisatie een specifiek belang heeft bij de manier waarop voorzieningen moeten worden/zijn gerealiseerd. In veel Nederlandse literatuur wordt de Engelse term hiervoor gebruikt (stakeholder).

Vereiste (requirement) – Voorwaarde die door een belanghebbende aan het functioneren van een voorziening wordt gesteld. Dit kan zowel een vorm van functionaliteit zijn alsook een kwaliteitskenmerk, zoals beschikbaarheid, schaalbaarheid of duurzaamheid.

Continuüm – Een aansluitend geheel waarbinnen een specifieke beschouwingswijze of een specifiek perspectief wordt gehanteerd. De term 'continuüm' is ontleend aan TOGAF.

Voortbrengingsproces (ontwikkelproces) – Het proces waarmee nieuwe oplossingen aan het IT-landschap worden toegevoegd. Waar bij infrastructuur vaak wordt gesproken over voortbrenging (door samenvoeging van producten en componenten van leveranciers), wordt bij het realiseren van nieuwe applicaties dikwijls gerefereerd aan ontwikkelen (van applicatiecode) en wordt dit proces derhalve ontwikkelproces genoemd.

Ontwerpproces – Het gefaseerd en iteratief doorlopen van een ontwerpactiviteit.

1.3 Belangrijkste boodschappen van dit boek

Dit boek bevat een aantal belangrijke boodschappen. Om te voorkomen dat ze ondersneeuwen in de veelzijdigheid van onderwerpen die aan de orde komen, worden ze hier expliciet benoemd. Ze zijn bedoeld om in het achterhoofd te houden bij de verdere lezing van het boek.

Eerst duidelijkheid over functionaliteit en kwaliteit, de constructie volgt later.
Bewust of onbewust, bijna alle mensen denken 'constructiegeoriënteerd'. Eén horizontale lijn en twee kortere verticale lijnen eronder herkent vrijwel iedereen als een (zeer) abstracte weergave van een tafel. Als vervolgens de vraag wordt gesteld om de functie van een tafel te omschrijven, hebben de meeste mensen moeite om dit helder aan te geven. Het is dus best lastig om in termen van functionaliteit over zaken te praten. Datzelfde geldt ook voor kwaliteit, omdat het bij veel kwaliteitsaspecten ingewikkeld is om ze te concretiseren en te kwantificeren (denk bijvoorbeeld aan aanpasbaarheid). Voor het architectuurproces is het echter wel essentieel om juist hier te beginnen, want zowel functionaliteit als kwaliteit zijn dé zaken waar de meeste belanghebbenden overeenstemming over moeten bereiken. De constructie volgt hieruit. Het is dus de kunst om de aandacht van de constructie af te halen en deze te richten op functionaliteit en kwaliteit.

Behalve dat het ontwerptechnisch belangrijk is om deze volgorde te hanteren, zit er ook een communicatief aspect aan. Als het een IT-architect lukt om functionaliteit op de juiste manier ter sprake te brengen, kan iedereen meepraten en meedenken over de vereisten die men aan een oplossing stelt, ongeacht de (technische) IT-kennis die men heeft. Het voorkomt daarbij 'technische emotie' in de discussie bij mensen die wel over een technische achtergrond beschikken. Bovendien helpt het om een 'technology push' binnen de perken te houden. Iedere nieuwe ontwikkeling kan inhoudelijk worden getoetst op mogelijkheden die werkelijk interessant zijn voor de organisatie.

Het leggen van het primaat bij de functionaliteit is ook van belang in situaties waar bijvoorbeeld gebruikers of beheerders aankomen met een product dat ze graag geïmplementeerd willen zien – of dat ze al afnemen als clouddienst en waarvoor ze een betere integratie zoeken. Een dergelijke toepassing is meestal naar voren gekomen bij een zoektocht naar bepaalde functionaliteit in de markt. Op zich is het prima om goed te kijken naar datgene wat een gebruikersgroep in de markt heeft aangetroffen en wil gaan benutten, of al benut. Want dat verraadt in ieder geval (een deel van) de functionaliteit waar men behoefte aan heeft. Er moet echter wel worden doorgevraagd. Want een dergelijke 'productkeuze' kan nooit het sluitstuk zijn, maar is altijd het begin van een ontwerpproces. Al was het maar om vast te stellen hoe een reeds aangeschaft product op een fatsoenlijke manier wordt geïntegreerd in het geheel van het IT-landschap. Maar natuurlijk liever nog resulteert een architectuuringreep in een echt ontwerptraject (hoe beknopt en versneld uitgevoerd ook), waarbij ook andere oplossingsrichtingen nog openstaan.

Gebruik services als verbindend element voor digitale ruimtelijke ordening.
Als er één concept is dat geschikt is als koppelvlak voor de communicatie tussen IT-disciplines, dan is dat wel de 'service'. En dan in de ruwe, pure vorm, zoals ArchiMate dit begrip definieert: (beschrijving van) de functionaliteit die een voorziening levert, zoals die door gebruikers afgenomen en ervaren wordt. ArchiMate noemt dat 'extern gedrag'.² Services worden gerealiseerd door onderliggende 'functies', die door ArchiMate als 'intern gedrag' worden bestempeld. Er zijn meerdere reden waarom de service zich zo goed leent voor het verbinden van verschillende IT-disciplines:

•
Met het serviceconcept wordt een globale omschrijving van functionaliteit gegeven, vanuit het perspectief van de gebruiker. Iedereen kan deze omschrijving begrijpen zonder dat technische kennis nodig is. Een service is tevens het startpunt voor een meer gedetailleerde decompositie in onderliggende functies.

•
Een service is zelfstandig af te nemen of te koppelen. Het serviceconcept zorgt daarmee voor een perfecte afbakening van voorzieningen binnen het IT-landschap. Voor servicemanagers is het de primaire grootheid waar karakteristieken aan worden gekoppeld. Zowel voor inkopers als leveranciers is het een herkenbare entiteit. Projectmanagers kunnen het concept goed gebruiken om de scope van projecten te bepalen.

•
De aard van services en (onderliggende) functies blijft in de kern hetzelfde, hoe ze vervolgens ook geleverd worden en geconstrueerd zijn. Of een service nu op locatie in eigen beheer wordt gerealiseerd of als clouddienst wordt afgenomen, of dit nu gebeurt met behulp van virtualisatie of op een fysieke server, of er nu sprake is van een Software Defined Data Center of van een 'hyperconverged computing platform', het blijft eenzelfde soort service. Uiteraard kan er verschil zijn in kenmerken, maar dit heeft geen effect op de typering, de aard van de service. Dit maakt dat het vastleggen van een IT-landschap vanuit services en functies heel stabiel is.

Wanneer gewerkt wordt met ArchiMate, dan wordt per domein (business-, applicatie- en infrastructuurdomein) een apart servicelandschap vastgelegd. De koppeling tussen de domeinen vindt primair plaats door verbanden aan te brengen tussen services. In figuur 1.1 is een voorbeeld te zien van een typisch infrastructuurlandschap vanuit serviceperspectief.

In figuur 1.1 is goed te zien dat met behulp van services een mooie balans wordt gevonden in niveau van detail. Duidelijk wordt dat infrastructuur veel meer biedt dan platformen, datatransport en opslag. Tegelijkertijd blijft het geheel overzichtelijk.

Figuur 1.1 Voorbeeld van een infrastructuurservicelandschap

Services zijn te ontleden in een aantal onderliggende functies die deze service realiseren. Een decompositie van services in functies kan modelmatig worden weergegeven. Met deze functiemodellen is het mogelijk om gericht ontwerpvragen te stellen en gestructureerd vereisten te verzamelen en die te vertalen naar specificaties van een technische constructie die deze services moet leveren. Bovendien is de structuur van de functiemodellen in de basis heel voorspelbaar. Het zijn steeds dezelfde soort functies waartussen verbanden bestaan. Aan iedere service ligt een herkenbare basisstructuur ten grondslag. Dit noemt OIAm 'generieke patronen'. Met deze generieke patronen zijn snel specifieke modellen te maken, omdat de basisstructuur al bekend is.

Werk met goed gedefinieerde architectuurproducten waarvan duidelijk is welk doel ze dienen.
Wat mag een organisatie van een IT-architect verwachten? Hoe vult deze zijn rol in? De beste manier om dit concreet te maken is helderheid te verschaffen over de architectuurproducten die worden vervaardigd. Met andere woorden, 'aan de vruchten kent men de boom'. Het helpt om met opdrachtgevers af te stemmen welke activiteiten, processen en disciplines ondersteund moeten worden. In veel gevallen worden architecten gevraagd om projecten en projectmanagers te ondersteunen, bijvoorbeeld met behulp van projectstartarchitecturen (PSA's) en andere vormen van projectbegeleiding. Dit betekent dat in projecten oplossingen onder architectuur tot stand komen. Het is dan ook raadzaam om als achterliggend kader referentiearchitecturen vast te leggen en te onderhouden. Dit is meer werken aan architectuur. Het opstellen van langetermijnvisies met managementverantwoordelijken heeft een beetje van beide.

Architectuurproducten staan dus in relatie tot elkaar. Ze delen daarbij gemeenschappelijke ingrediënten die herbruikbaar zijn. Dat maakt het gemakkelijker om verschillende producten naast elkaar te ontwikkelen. Het is onmogelijk om complexe architectuurproducten (zoals referentiearchitecturen) in één keer in te richten. Het is raadzaam een goede basisstructuur te kiezen. Zoals eerder betoogd lenen servicelandschappen zich hiervoor bijzonder goed. Vervolgens worden de services gaandeweg tijdens projecten uitgediept en uitgewerkt. Met name integratievoorzieningen zullen daarbij als eerste aan de beurt zijn, zodat de samenhang in het landschap vanuit architectuur wordt geborgd.

Zoek optimale samenwerking in de organisatie voor het inbedden van de architectuurfunctie.
Een van de grootste uitdagingen voor de IT-architect is het creëren van draagvlak voor architectuurbeoefening in de organisatie. Misschien lukt dat wel het beste als architecten het steeds weer voor elkaar krijgen om draagvlak voor veranderingen in de organisatie te bewerkstelligen. Dit door behoeften van verschillende belanghebbenden in lijn te brengen en inhoudelijk de regie te voeren bij de samenwerking van de verschillende rollen in ontwikkel- en voortbrengingsprocessen.

Het is dus de kunst om de architectuurfunctie goed te positioneren in de organisatie en nauwkeurig na te gaan welke andere rollen binnen de IT-organisatie op welke manieren kunnen worden ondersteund. De paradox is dat juist architecten daarbij vanuit de rol van de ander moeten denken, in plaats van te vertrekken vanuit de eigen rol. Omdat een architect als het goed is sterk is op de inhoud, is hij/zij de aangewezen persoon om bruggen te bouwen tussen de verschillende disciplines. Als geen ander is de architect in staat belangen op waarde te schatten, te wegen en met elkaar in overeenstemming te brengen. Dat vraagt soms om een verrassende houding. Zo helpt het om in projecten als architect juist ook de kortetermijnproblemen op te pakken en daarin de projectleider te helpen. Uiteraard met als referentiepunt de lange termijn, waar de architect samen met de betrokken projectleider op moet sturen. Alleen op de lange termijn sturen, zonder de zorgen van de projectleider serieus te nemen (die graag het project binnen tijd, scope en budget wil afronden), leidt tot frustratie en onbegrip. Naast de ondersteuning van projecten is het heel belangrijk om korte lijnen te onderhouden met verantwoordelijken voor beheer en beveiliging. Dit omdat deze onderdelen van het IT-bedrijf essentieel zijn voor realisatie en continuïteit. Maar zeker ook omdat ze bij veel projecten ten onrechte het sluitstuk vormen.

Het is belangrijk dat de rol van architectuur formeel wordt geborgd in een evenwichtige governancestructuur. Daarbij moet het streven zijn dat samenwerking en verantwoordelijkheden van binnenuit groeien en belegd worden, in plaats van dat governance van bovenaf wordt opgelegd. Dat betekent dat managers en architecten bewust verantwoordelijkheid met elkaar delen. Zowel aan het begin, waar architecten managers inspireren bij het vormen van een visie op de ontwikkeling van de IT, als aan het eind, waar managers verantwoordelijkheid nemen voor beslissingen die in architectuurboards worden genomen.

Het zoeken van samenwerking op alle vlakken is mogelijk de belangrijkste succesfactor voor het slagen van de architectuurbeoefening in een organisatie, naast uiteraard het inhoudelijk vakmanschap. Dat maakt het werken als IT-architect behoorlijk uitdagend, maar zeker ook bijzonder boeiend.

Noten

1 | Al deze dingen zijn ondergebracht bij de website van de OIAm-community, de Open Infrastructure Architecture repository (OIAr), https://infra-repository.org.
2 | Gedrag kan zowel actief als passief zijn. Denk bij gedrag dat een passief karakter heeft, aan het bewaren van gegevens of het verlenen van toegang. Daarom wordt in dit boek soms de term 'functionaliteit' gebruikt om het geheel van gedragingen (zowel actief als passief) aan te duiden.