Levende IT-architectuur Praktische toepassing
van een functiegerichte aanpak
Daniël Jumelet 52 |
BRINGING IT ARCHITECTURE TO LIFE
Colofon ©2017 Daniël Jumelet
ISBN 9789492190413
Boekverzorging: LINE UP boek en media, Groningen Eindredactie: Minke Sikkema
Alle rechten voorbehouden. Behoudens de in of krachtens de Auteurswet 1912 gestelde
Boekontwerp en dtp: Riëtte van Zwol en Bas Ekkers
uitzonderingen, mag niets uit deze uitgave worden verveelvoudigd, opgeslagen in een geautomatiseerd gegevensbestand of openbaar gemaakt in enige vorm of op enige wijze,
Auteursfoto: Jeroen Jumelet
hetzij elektronisch, mechanisch, door fotokopieën, opnamen of enige andere manier,
Overige foto’s: Pexels p. 2, 8, 12, 26, 66, 120, 140, 194, 202, 210, 234; Shutterstock p. 30,
zonder voorafgaande schriftelijke toestemming van de uitgever. Hoewel aan de totstandko-
48, 52, 74, 106, 128, 146, 174, 226; Jeroen Jumelet p. 50, 51, 240; Zolore p. 166
ming 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),
In dit boek gebruikte merknamen:
redacteur(en) en uitgever deswege geen aansprakelijkheid voor de gevolgen van eventueel
DYA : Sogeti Nederland B.V.
voorkomende fouten en onvolledigheden.
®
ArchiMate®: X/Open Company Limited trading as The Open Group DEMO®: Sapio B.V.
All rights reserved. No part of this publication may be reproduced, Stored in a retrieval
TOGAF : X/Open Company Limited trading as The Open Group
system, or transmitted in any form or by any means, electronic, mechanical, photocopy-
AgilePM : Dynamic Systems Development Method Limited
ing, recording or otherwise, without the publisher’s prior consent.
™
®
INHOUD Woord vooraf
9
3.4
Toepassing van de OIAm-modelleeraanpak buiten het infrastructuurdomein 64
Hoofdstuk 1 Inleiding 1.1 1.2 1.3
13 14
Omgaan met datacentertransities
67
en leeswijzer bij het boek
15
Hoofdstuk 4 Werken met modellen: voorbeelden
75
Belangrijkste boodschappen van dit boek
20
Belangrijke taken van de IT-architect Inzichten en vaardigheden van de IT-architect: indeling van
Persoonlijke praktijkverhalen
4.1
Voorbeeld 1: de Exchange-migratie
4.2
Voorbeeld 2: Identity Management voor cloudoplossingen 88
27 Vormgeven van werkplekdiensten
Hoofdstuk 2 De rol van architectuur in het ontwerpproces 31 2.1
75
Fasen van het ontwerpproces:
99
Hoofdstuk 5 Ingrediënten van architectuurproducten 107
de ontwerpcontinuüms
33
5.1
2.2
In detail: stappen in het architectuurcontinuüm
40
5.2 Servicebeschrijvingen
108
2.3
Betrekken van belanghebbenden
46
5.3 Kwaliteitskenmerken
109
5.4 Omgevingen
111
5.5 Gebruikerscategorieën
112
5.6 Principes
113
5.7
Architecture Building Block
114
De rol van de community Hoofdstuk 3 Het maken van functiemodellen: spil van het architectuurwerk
49
User stories
108
53
5.8
Artist impressions
116
3.1 Patronen
54
5.9
Solution Building Blocks
116
3.2
Een begrippenkader voor infrastructuurfuncties
57
5.10 Dreigingsanalyses
3.3
ArchiMate: een semantiek voor de modelleur
59
117
|5
Werken aan referentiearchitecturen
121
Hoofdstuk 6 Architectuurproducten
129
6.1
Organisatiecontextanalyse (OCA)
131
6.2
Business-IT-plan, roadmap en projectenkalender
132
6.3 Referentiearchitectuur
133
6.4 Businesscase/impactanalyse/haalbaarheidsstudie
135
6.5
Projectstartarchitectuur (PSA), sourcingstartarchitectuur (SSA) en Solution Foundation
6.6 Rootcause-analyse
136 138
Functioneel aanbesteden
141
Hoofdstuk 7 Inbedden van architectuur
147
7.1 Doelen
148
7.2 Processen
149
7.3 Rollen
152
7.4 Architectuurproducten
154
7.5
155
Strategische partners
7.6 Governance
163
7.7
164
Architectuur zichtbaar maken
Politiek op de werkvloer: beslissingsondersteuning
167
Hoofdstuk 8 InfrastructuurÂarchitectuur en IT-beveiliging 175
6|
LEVENDE IT-ARCHITECTUUR
8.1 Strategiebepaling
176
8.2
180
Dreigings- en risicoanalyses
8.3 Mitigatie
183
8.4
185
Voorbeeld van een dreigingsanalyse
Verklarende woordenlijst
235
191
Literatuur 237
Omgaan met trends
195
Dankwoord 239
Bijlage A Introductie OIAm
203
8.6 Privacybescherming
A.1 Wat is OIAm?
203
A.2 Focus van OIAm
204
A.3 Wat biedt OIAm?
206
A.4 Geschiedenis van OIAm
207
A.5 Wat blijft buiten scope voor OIAm?
207
Bijlage B Modelleerconventies voor toepassing van ArchiMate 211 B.1 Gebruik van ArchiMate
211
B.2 Voorkeursconcepten infrastructuur
212
B.3 Afspraken over relaties
217
B.4 Relaties tussen views en lagen
222
B.5 Niveau van detaillering
224
B.6 Afspraken over naamgeving
224
Bijlage C ClouddienstenÂarrangementen
227
C.1 Application Hosting
228
C.2 Web Hosting
228
C.3 Calculation
231
ďťż
|7
12 |
LEVENDE IT-ARCHITECTUUR
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 aan-
Hoofdstuk 1 inleiding
| 13
reikt, zoals generieke functiepatronen, functiedefinities en een ontwerpworkflow.1 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 1 Al deze dingen zijn ondergebracht bij de website van de OIAm-community, de Open Infrastructure Architecture repository (OIAr), https://infra-repository.org.
14 |
LEVENDE IT-ARCHITECTUUR
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, verHoofdstuk 1 inleiding
| 15
gemakkelijken 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 ordening 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 toege16 |
LEVENDE IT-ARCHITECTUUR
voegd. 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. 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.
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 infor mation officers (CIO’s), informatie managers, business analisten, requirements managers, 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, requirements managers, 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 doel architectuur 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
Hoofdstuk 1 inleiding
| 17
18 |
Hoofdstuk
Titel
Beschrijving
Voor wie?
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, informatie managers, 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 IT-architecten, ‘talentvolle visionair’. In werkelijkheid is er echter in veel organisaties weerstand tegen of onbegrip voor de archi- CIO’s tectuurfunctie. 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.
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.
LEVENDE IT-ARCHITECTUUR
IT-architecten, IT-beveiligers, projectmanagers, technisch specialisten, ontwikkelaars en beheerders
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 gereali-
seerd. 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.
Hoofdstuk 1 inleiding
| 19
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. 20 |
LEVENDE IT-ARCHITECTUUR
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 aange-
schaft 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’.2 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 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.
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 Hoofdstuk 1 inleiding
| 21
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. Services zijn te ontleden in een aantal onderliggende functies die deze service realiseren. Een decompositie
User Workspace
Connectivity
Collaboration
Computing
Data Management
Storage & Data Protection
Production Workspace
Datacenter Data Transport
Generic Application Hosting
Enterprise Service Bus
Central Mass Storage
Personal Workspace
Office Data Transport
Teleconference
Web Hosting
Database Management
Data Recovery
Printing & Scanning
Site Interconnect
Instant Messaging
Businss Rule Processing
Database File Handling
Archiving
Telephony
Cloud Interconnect
Presence
Calculation
Application File Handling
Platform Recovery
Knowledge Management Platform
End User File Handling
Deployment & Administration Platform Deployment
Application Deployment
Workspace Deployment
Network Management
Monitoring
Systems Management Platform
Internet Proxy
Data Transport Control
Security Authentication & Authorization
Identity Management
Security Monitoring
Figuur 1.1 Voorbeeld van een infrastructuurservicelandschap 22 |
LEVENDE IT-ARCHITECTUUR
Service Access Control
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 projectstartarchi tecturen (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 Hoofdstuk 1 inleiding
| 23
samenwerking van de verschillende rollen in ontwikkelen 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. 24 |
LEVENDE IT-ARCHITECTUUR
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.
30 |
LEVENDE IT-ARCHITECTUUR
DE ROL VAN ARCHITECTUUR IN HET ONTWERPPROCES HOOFDSTUK 2
De noodzaak voor het maken van een ontwerp neemt toe wanneer vraagstukken complexer en veelzijdiger worden, of als er meer belanghebbenden bij betrokken zijn. Ontwerpen is een associatief en creatief proces. Dit betekent dat steeds de inzet van menselijke inzichten en vakkennis nodig zijn. Die inzichten en die vakkennis kunnen impliciet blijven bij het doorlopen van een ontwerpproces, terwijl ze min of meer onbewust worden toegepast door betrokken architecten en ontwerpers. Hoewel dit in sommige situaties voldoet, heeft het expliciet en gestructureerd toepassen van inzichten en vakkennis een belangrijke meerwaarde. Door met een methodische aanpak het associatieve en creatieve proces te ondersteunen worden resultaten inzichtelijk, voorspelbaarder en dikwijls ook completer en van een hogere kwaliteit. Daarnaast maakt het een splitsing mogelijk in ontwerpverantwoordelijkheden. Dit is erg belangrijk bij bijvoorbeeld uitbestedingstrajecten, waarin de technische vormgeving, de inrichting en het beheer door een leverancier worden uitgevoerd, maar de functionele en kwalitatieve specificatie onder de eindverantwoordelijkheid van de opdrachtgever vallen. Dit hoofdstuk biedt een visie op de rol van architectuur in een gestructureerd ontwerpproces. Hoofdstuk 2 de rol van architectuur in het ontwerpproces
| 31
Architectuur is binnen het ontwerpproces de discipline die verantwoordelijk is voor het overkoepelend ontwerp. Dat wil zeggen: het ontwerpproces zodanig begeleiden dat de uiteindelijke oplossing enerzijds zo goed mogelijk aansluit bij de initiële doelstelling en de context waarbinnen deze oplossing wordt gebruikt, en anderzijds zo goed mogelijk past in het gehele landschap van oplossingen en in de organisatie als geheel. Een essentieel aspect hiervan is het structureren van het ontwerpproces zelf en de fasen die hierin een rol spelen. Een ander onmisbaar onderdeel hiervan is het betrekken van alle belanghebbenden (in jargon: stakeholders) bij het ontwerpproces. Op die manier kan een inrichting ontstaan die zo goed mogelijk past bij de eisen en wensen van die verschillende belanghebbenden. Het begeleiden van een ontwerpproces is echter om twee redenen ingewikkeld: 1 Belanghebbenden hebben afzonderlijk van elkaar vereisten en wensen die soms moeilijk met elkaar te verenigen zijn, zeker als het belanghebbenden ontbreekt aan mogelijkheden tot articulatie van die wensen en vereisten. Bovendien moeten die vereisten op een dusdanige wijze worden geformuleerd dat ze bruikbaar zijn in het ontwerpproces. Weill en Broadbent1 noemen dit de ‘expression barrier’ en de ‘specification barrier’. 1 Weill, P. & M. Broadbent (1998). Leveraging the New Infrastructures: How Market Leaders Capitalize on Information Technology. Boston: Harvard Business School Press.
32 |
LEVENDE IT-ARCHITECTUUR
2 De werkelijkheid doet zich in zijn verschijningsvorm(en) zo complex aan ons voor dat het moeilijk is orde te scheppen, structuren aan te brengen en de juiste ontwerpkeuzes te maken. De moeilijkheden die zich hier voordoen, worden door Weil en Broadbent de ‘implementation barrier’ genoemd. Daarbij komen ook de problemen van onvolledigheid en ambiguïteit om de hoek kijken, zoals De Wit en Meyer2 identificeren. Het is onmogelijk om een situatie volledig en eenduidig te analyseren, zodanig dat een vastomlijnd, algoritmisch proces wordt gevolg met een onweerlegbare uitkomst. Integendeel, het ontwerpproces is een associatief, creatief proces. Als het om IT-infrastructuur gaat, komt daar nog een extra uitdaging bij: 3 Bij het ontwerpen van IT-infrastructuurvoorzieningen zijn de constructie en de gebruikte techniek meestal dominant. Naast het feit dat de techniek dikwijls complex is, ontbreekt het de meeste belanghebbenden aan kennis om deze te doorgronden en hier uitspraken over te doen. Met name de laatste opgave heeft ertoe geleid dat OIAm zich is gaan richten op het zo veel mogelijk wegnemen van de belemmeringen in het ontwerpproces. Daarom is 2 Wit, B. de & R. Meyer (1999). Strategy Synthesis. Londen: International Thomson Business Press.
binnen OIAm gekozen voor een focus op functionaliteit en kwaliteit, omdat dit voor de meeste belanghebbenden de meest relevante aspecten omvat. Tevens wordt op deze manier aan het begin van het ontwerpproces maximale keuzevrijheid geboden, die gedurende het proces wordt ingevuld naarmate vereisten helderder worden. Tegelijkertijd maakt dit het mogelijk om aan het eind van het ontwerpproces objectief te toetsen of de constructie voldoet aan de gestelde functionele en kwalitatieve vereisten. Inhoudelijk maakt OIAm gebruik van modellen, zodat het discours met de belanghebbenden en het expliciteren van ontwerpkeuzes gestructureerd verloopt. Hoe het maken van modellen eruitziet wordt in de volgende hoofdstukken beschreven. Dit hoofdstuk richt zich eerst op de rol van architectuur in het ontwerpproces, waarbij OIAm het ontwerpproces langs drie continuüms structureert. Aan deze structurering kan een tweede dimensie worden toegevoegd, namelijk de indeling van het eerste continuüm, dat van het functieontwerp. De indeling van het ontwerpproces is dan als volgt: 1 fasering van het ontwerpproces: de OIAm-ontwerpcontinuüms; 2 in detail: stappen in de fase van het functieontwerp.
2.1 Fasen van het ontwerpproces: de ontwerpcontinuüms
In het vervolg van dit hoofdstuk worden deze twee dimensies verder uitgediept.
Blaauw onderscheidt in het ontwerpproces van een computer drie opeenvolgende stappen: Architecture, Implementation en Realization. Deze stappen omschrijft hij als volgt: ‘Architecture concerns the function that is provided
Vanuit de verantwoordelijkheid voor het overkoepelend ontwerp ziet OIAm in het begin van het ontwerpproces een leidende rol weggelegd voor architectuur. Naarmate het ontwerpproces vordert, verschuift dit naar een meer begeleidende rol. Deze visie is geïnspireerd door het werk van prof. dr. Gerrit Blaauw.
Gerrit Blaauw, geboren in 1924 in Den Haag, was in zijn werkzame leven computerpionier. Hij heeft diverse grote computersystemen helpen ontwerpen. Het bekendste systeem was het IBM Systems/360 mainframe, de eerste 8-bits computer en het eerste mainframe dat zowel voor commerciële doeleinden als onderzoeksdoeleinden gebruikt kon worden. Blaauw viel op door het hanteren van methodische ontwerpprincipes. Deze principes heeft hij aan het einde van zijn loopbaan gedocumenteerd in het boek Computer architecture: concepts and evolution, dat in 1997 verscheen als slotsom van diverse artikelen en dictaten over dit onderwerp.
Hoofdstuk 2 de rol van architectuur in het ontwerpproces
| 33
to the programmer, such as addressing, addition, interruption, and input/output. Implementation concerns the method which is used to achieve this function, perhaps a parallel data path and a microprogrammed control. Realization concerns the means used to materialize this method, such as electrical, magnetic, mechanical, and optical devices and the powering and packaging for them. Therefore, the realization also includes the visual appearance, the industrial design of the computer.’3 Het door Blaauw aangebrachte onderscheid in architectuur, implementatie en realisatie is in de ontwikkeling van OIAm verder uitgewerkt door hier twee richtingen in aan te brengen. Allereerst zijn drie opeenvolgende fasen in het ontwerpproces geïdentificeerd. Deze zijn in lijn met de driedeling die Blaauw toepast, maar zijn omwille van een duidelijker begrip omgedoopt in de fase van het functieontwerp (architectuurcontinuüm), de fase van het constructieontwerp (oplossingscontinuüm)4 en de fase van de realisatie (realisatiecontinuüm). Ten tweede wordt, in iedere fase afzonderlijk, de beweging van een generieke, universele structuur naar een specifieke invulling onderkend. Dit betekent dat het in iedere ontwerpfase mogelijk is vanuit generieke, archetypische principes en patronen 3 Blaauw, G.A. (1990). The persistence of the classical computer architecture. CWI Quarterly, Vol. 3, No. 4, pp. 335-348. Amsterdam: Stichting Mathematisch Centrum (Centrum Wiskunde & Informatica). 4 De termen ‘architectuurcontinuüm’ (‘architecture continuum’) en ‘oplossingscontinuüm’ (‘solution continuum’) zijn ontleend aan de architectuurmethode TOGAF.
34 |
LEVENDE IT-ARCHITECTUUR
te redeneren in de richting van een toepassing die aansluit bij de (gebruiks)context en de specifieke vereisten die in deze context zijn geïdentificeerd. Iedere ontwerpfase geeft van hieruit input en richting aan de volgende ontwerpstap, waarbij indien nodig iteratie wordt toegepast. Dit ziet er schematisch uit zoals in figuur 2.1 afgebeeld. Bij deze indeling in continuüms moeten met nadruk twee opmerkingen worden gemaakt: 1 Hoewel op deze manier een flow in het ontwerpproces wordt aangebracht, blijft het ontwerpproces een iteratief gebeuren. Vanuit ieder continuüm is het mogelijk om met aanvullende informatie één stap of twee stappen terug te doen en een eerder continuüm opnieuw te doorlopen. 2 Deze indeling van het ontwerpproces is onafhankelijk van de grootte van de ontwerpscope. Ze werkt voor zowel omvangrijke als kleine ontwerpopdrachten en laat toe dat ontwerpopdrachten worden opgedeeld in kleinere stukken die afzonderlijk van elkaar worden afgehandeld. Om de werking van de indeling in continuüms verder te verduidelijken wordt het schema uit figuur 2.1 toegepast op het voorbeeld van de stationsklok (zie figuur 2.2). Het voorbeeld van de klok wordt ook door Blaauw gebruikt. Door eenzelfde voorbeeld te gebruiken worden de over-
Archetype
Architectuurcontinuüm
Oplossingscontinuüm
Realisatiecontinuüm
Generieke functie(s)
Basisstructuur/ topografie
Generieke componenten/ artikelen
Implementatie
PAS TOE
PAS TOE
PAS TOE
Specifieke functie(s)
VERTAAL
VERTAAL
TERUGKOPPELING
TERUGKOPPELING
Specifieke constructie/ blauwdruk
Specifiek(e) exemplaar/ onderdelen
Figuur 2.1 Schematisch overzicht van de continuüms en het iteratieve ontwerpproces
eenkomsten met en de verschillen tussen de workflow van Blaauw en de continuüms van OIAm verder inzichtelijk. De eerste fase in het ontwerpproces is die van het functieontwerp (architectuurcontinuüm). De functie van
de stationsklok is gelijk aan die van alle andere klokken, namelijk tijdsaanduiding. Echter, de specifieke toepassing brengt aanvullende karakteristieken met zich mee.
Hoofdstuk 2 de rol van architectuur in het ontwerpproces
| 35
Archetype
Architectuurcontinuüm
Oplossingscontinuüm
Realisatiecontinuüm
Tijdsaanduiding
Mechanisch uurwerk
Mechanisch uurwerk - Mobatime DMU 160
Implementatie
PAS TOE
PAS TOE
PAS TOE VERTAAL
VERTAAL
TERUGKOPPELING
TERUGKOPPELING
Tijdsaanduiding op een treinstation
Blauwdruk stationsklok
Stationsklok Perron 2A
Figuur 2.2 Het voorbeeld van de stationsklok afgebeeld op de ontwerpaanpak
Vanuit het gezichtspunt van verschillende belanghebbenden worden daarom vereisten gespecificeerd. De klok dient onder andere: • duidelijk de tijd aan te geven; verschillende klokken moeten dezelfde tijd aangeven om verwarring te voorkomen (treinreiziger);
36 |
LEVENDE IT-ARCHITECTUUR
• bestand te zijn tegen vandalisme (beheerder, eigenaar); • gemakkelijk en goedkoop in grote aantallen te produceren zijn (eigenaar); • gemakkelijk te beheren zijn (beheerder).
De geformuleerde vereisten (in het jargon ook wel ‘requirements’ genoemd) zijn een mix van verdere functionele specificaties (zoals synchronisatie van tijdsaanduiding) en kwaliteitseisen (zoals robuustheid ofwel integriteit en beheerbaarheid). De manier waaróp tijdsaanduiding kan plaatsvinden, kent een aantal verschijningsvormen (of basisstructuren), zoals de zonnewijzer, de analoge klok of de digitale klok. Omdat de keuze hiertussen erg bepalend kan zijn voor ontwerpvragen en -keuzes (ook functioneel), is het handig om bij de specificatie van de functie verder over deze verschijningsvorm na te denken. In het geval van een stationsklok zal de zonnewijzer direct afvallen, omdat de condities die binnen stations bestaan deze verschijningsvorm ongeschikt maken. Bij de afweging tussen de toepassing van een digitale of een analoge klok kan als doorslaggevend argument worden ingebracht dat een analoge klok van grote afstand nog zonder vergissingen af te lezen is, terwijl bij een digitale klok bijvoorbeeld de cijfers 5, 6, 8 en 9 erg veel op elkaar lijken. Dit is in de context van een station, met als belangrijkste gebruiker de treinreiziger, namelijk zeer bepalend voor het nut van de stationsklok. Vanuit de afwegingen die voor de functionaliteit van tijdsaanduiding gelden in de context van het station, worden de volgende ontwerpkeuzes gemaakt: • De tijdsaanduiding zal worden vormgegeven als een analoge klok met een wijzerplaat die een indicatie
geeft van het uur, de minuut en de seconde. Dit is van belang voor de belangrijkste gebruiker van de tijdsaanduiding, de treinreiziger. • Om de productie- en beheerkosten laag te houden wordt een robuust maar simpel uurwerk gekozen. Dit is in het belang van de eigenaar van de klok, de spoorwegmaatschappij. • Klokken worden centraal gesynchroniseerd. Omdat het uurwerk simpel en derhalve minder nauwkeurig is, gebeurt dit a) met grote regelmaat en b) vanuit een centrale ‘master’-klok door een over een netwerk verzonden synchronisatiesignaal naar alle ‘slave’-klokken op de perrons. Gekozen wordt voor synchronisatie per minuut, zodat het begin van iedere hele minuut duidelijk wordt aangegeven. Hiermee wordt het belang gediend van zowel de treinreiziger (accurate tijdsaanduiding) als de eigenaar (kosteneffectieve oplossing) en de beheerder (weinig beheersinspanningen nodig voor het aanpassen van de tijdsaanduiding). Op deze manier worden de vereisten van de verschillende belanghebbenden vertaald naar richtinggevende uitspraken voor het volgende continuüm in het ontwerpproces, de fase van het constructieontwerp (oplossingscontinuüm). De genoemde richtinggevende uitspraken functioneren als eisen voor dit constructieontwerp. Het is belangrijk om op te merken dat dit op een manier gebeurt die voor iedere belanghebbende even toegankelijk en zin-
Hoofdstuk 2 de rol van architectuur in het ontwerpproces
| 37
vol is. Alle belanghebbenden kunnen meepraten over functionaliteit en kwaliteit, waarbij ook de eisen voor het constructieontwerp zo veel mogelijk op een technologieneutrale manier zijn verwoord. Desondanks zijn deze eisen van grote informatieve waarde voor de constructieontwerper, die ze kan toepassen op een standaardconstructiewijze voor mechanische uurwerken. Want ook in het oplossingscontinuüm is het mogelijk gebruik te maken van generieke, universele uitgangspunten. Zo heeft ieder mechanisch uurwerk bepaalde technische kenmerken die bij ieder uurwerk van dit type voorkomen, zoals de manier van integratie van aandrijfassen voor de verschillende wijzers of de werking van een centraal synchronisatiemechanisme. De constructieontwerper gebruikt deze als uitgangspunt bij het maken van een specifiek constructieontwerp, samen met de eerdergenoemde richtlijnen uit de vorige ontwerpfase. Enkele voorbeelden van keuzes in het constructieontwerp: • De klok krijgt een korte wijzer voor de uren die traploos rondgaat. • De klok krijgt een lange wijzer voor de minuten die getrapt, per minuut verspringt (de vertrektijden zijn op hele minuten). • De klok krijgt een secondewijzer die traploos rondgaat. • De behuizing wordt robuust uitgevoerd. • Vanwege de synchronisatie per minuut dient de secondewijzer een omwenteltijd te hebben die iets korter is dan een minuut, zodat het synchronisatiesignaal kan 38 |
LEVENDE IT-ARCHITECTUUR
worden afgewacht voordat de secondewijzer verder loopt. Deze uitgangspunten worden verwerkt in het eindresultaat, een constructieontwerp of blauwdruk. Met het creëren van een blauwdruk zal een constructieontwerper ook keuzes maken ten aanzien van te gebruiken componenten voor de uiteindelijke realisatie. Over het algemeen zullen standaardcomponenten worden geselecteerd die als catalogusartikel in de markt verkrijgbaar zijn, tenzij de vereisten zo bijzonder zijn dat maatwerkcomponenten moeten worden vervaardigd. Met het opleveren van een blauwdruk en een lijst met benodigde componenten wordt deze ontwerpfase afgesloten en wordt het laatste continuüm van input voorzien, de fase van de realisatie (realisatiecontinuüm). In het realisatiecontinuüm worden de voorgeschreven artikelen besteld en wordt een specifiek exemplaar samengesteld, waarbij de artikelen de onderdelen vormen waarmee het exemplaar is opgebouwd. Het resultaat van het realisatiecontinuüm, als onderdeel van het ontwerpproces, is een prototype, dat meestal als voorbeeld dient voor vele opvolgende exemplaren die in productie worden vervaardigd. In sommige gevallen wordt het prototype na een testfase zélf het operationele exemplaar, wanneer er geen andere exemplaren benodigd zijn, zoals bij de inrichting van een netwerk.
Het doel van het gebruik van de continuüms is dat het ontwerpproces gestructureerd kan worden doorlopen. Hierdoor worden op een effectieve manier vereisten verzameld en doorgevoerd binnen de opvolgende ontwerpfasen. De continuüms maken de ontwerpfasen expliciet, waarbij het uiteraard mogelijk is iteratie toe te passen. Wanneer in een latere fase in het ontwerpproces nieuwe ontwerpvragen aan het licht komen (bijvoorbeeld doordat men technische beperkingen tegenkomt), dan kan dit gerelateerd worden aan eerdere ontwerpfasen. Zo vindt een verfijning van het ontwerp plaats. Het zwaartepunt van de toepassing van architectuur bevindt zich vanuit het perspectief van OIAm in de eerste fase van het ontwerpproces, het functieontwerp. Een doelstelling van OIAm is dat in deze fase alle belanghebbenden op gelijke wijze kunnen meepraten. Omdat over infrastructuur dikwijls in technische termen wordt gesproken, is hiervoor een aanvullend ingrediënt nodig, namelijk termen waarmee de functionaliteit van infrastructuurvoorzieningen kan worden uitgedrukt. Deze komen aan de orde in hoofdstuk 3, waarin het maken van functiemodellen wordt behandeld. Uiteraard spelen architecten een rol in het tweede en het derde continuüm, maar die rol is meer op de achtergrond en richt zich vooral op ontwerpbegeleiding. Het maken van een constructieontwerp is inhoudelijk primair de verantwoordelijkheid van technisch specialisten. Architecten zullen dan ondersteuning bieden bij het ver-
talen van de in de eerste fase opgestelde eisen aan de technische constructie richting een concreet constructieontwerp. Dit kan onder andere door het verduidelijken van (de achtergronden van) eisen en eventueel noodzakelijke iteraties van het functieontwerp wanneer ontwerpeisen lastig in te willigen zijn, bijvoorbeeld vanwege technische complicaties die vooraf onvoorzien waren. Bij de realisatie van een oplossing zijn architecten verantwoordelijk voor de controle of een voorziening voldoet aan de gestelde eisen. Ook hier geldt dat zij ondersteuning kunnen bieden bij een iteratie in het ontwerpproces, mochten tijdens de bouw onvoorziene aanpassingen nodig blijken te zijn. De indeling in continuüms dient nog een ander doel. Wanneer namelijk standaarddiensten beschikbaar zijn, zal de diepgang een stuk minder zijn en dient het doorlopen van de eerste twee continuüms vooral om te verifiëren of de standaarddiensten voldoende geschikt zijn voor de beoogde toepassing. In zo’n geval wordt de flow als het ware van buiten naar binnen doorlopen. Bijlage C geeft een overzicht van veelvoorkomende servicearrangementen van diensten die meestal in combinatie met elkaar worden afgenomen. Deze zijn bij verschillende cloudproviders standaard als zodanig af te nemen.
Hoofdstuk 2 de rol van architectuur in het ontwerpproces
| 39
48
De rol van de community Op een zeker moment is rondom de ontwikkeling van infrastructuurarchitectuur een community ontstaan. Dit gebeurde min of meer bij toeval. Toen OIAm nog DYA|Infrastuctuur heette, begonnen mij een aantal dingen op te vallen naar aanleiding van een aantal landschapsinventarisaties (waar destijds globale taxonomieÍn mee werden opgesteld, een soort lichtgewicht referentiearchitecturen). Behalve dat steeds dezelfde functies terugkwamen in de analyses, bleken deze functies ook in een vergelijkbare relatie tot elkaar te staan. In de zomer van 2009 heb ik daarom een aantal vakgenoten uit verschillende organisaties gevraagd om samen een aantal verkenningssessies te houden. Het doel van de sessies was om een aantal patronen van samenhangende functies vast te leggen en te documenteren. Met een groepje van een man of zes legden we de eerste acht basispatronen vast. Op dat moment met alleen nog blokken en lijnen, de ontdekking dat ArchiMate een goed uitgangspunt voor het maken van modellen zou zijn, volgde later. Nadat er meer patronen waren verzameld, werd een online bibliotheek ingericht en gepubliceerd. Dit was een kopie van een wiki die voor een grote opdrachtgever was opgezet. Tot op de dag van vandaag ben ik deze opdrachtgever dankbaar voor zijn genereuze houding. Het is deze houding die ervoor zorgt dat daadwerkelijk innovatie plaatsvindt. Door succes te delen wordt succes vermenigvuldigd. Rondom de wiki zijn vervolgens een mailinglijst, een LinkedIn-groep en daarmee een community ontstaan. Bij wijze van experiment organiseerden we een community-meeting op locatie bij een andere opdrachtgever. Op deze eerste bijeenkomst kwamen uit het niets zo’n veertig vakgenoten af. Hoewel de bijeenkomst heel bescheiden werd georganiseerd (we brachten zelf drinken en hapjes mee voor de borrel achteraf), bleek deze direct in een
49
Traffic Filtering
Standard facility Optional facility
Intrusion Prevention/ Detection
Adjacent pattern facility Connection/interrelation
Load Balancing
Optional Connection/interrelation Portal Authentication Reverse Proxy
Encryption Endpoint
Authorization Traffic Filtering
Load Balancing
Presentation
Web
Authentication
Application Platform
Authorization
Een van de patronen van het eerste uur
50
Compression Endpoint
behoefte te voorzien. Gaandeweg zijn de aantallen bezoekers gegroeid tot een kleine honderd deelnemers per keer. Dat is aanzienlijk wat, als je kijkt naar de omvang van de populatie vakgenoten. Op een Landelijk Architectuur Congres komen ongeveer zo’n vijfhonderd bezoekers, vanuit allerlei architectuurdisciplines en andere IT-functies. Hier vormen infrastructuurarchitecten en -specialisten een kleine minderheid. De bijeenkomsten vormen nog steeds de ruggengraat van de community, daadwerkelijke ontmoeting en de mogelijkheid tot directe uitwisseling van ervaringen en ideeën blijven de motor die het geheel gaande houdt. Ook de inhoud van dit boek is in speciale reviewsessies met leden van de community tot stand gekomen.
Community-bijeenkomst bij Holland Casino, inclusief bezoek aan de ‘werkvloer’, 2012
In de praktijk blijken allerlei sociale media een stuk moeilijker in gebruik voor de ondersteuning van een community. Het bijhouden en modereren ervan rust vaak op de schouders van enkele enthousiastelingen en de frequentie waarmee mensen kijken of er iets nieuws te halen valt, is behoorlijk laag. Dat geldt ook voor de online wiki, de OIAm-repository. Het duurt soms lang voordat nieuwe inzichten, patronen en definities in de repository zijn ondergebracht. Dit heeft er deels mee te maken dat commentaar en aanvullingen op en draagvlak voor verandervoorstellen in de community worden gezocht. Het blijkt lastig om dat te organiseren. Hier speelt ontegenzeggelijk mee dat dit type kanalen pas gaan functioneren wanneer de omvang van een community boven een bepaalde kritische grens uitstijgt. Het is dan ook mijn hoop dat steeds meer mensen hun eigen ervaringen gaan delen met anderen. Want dat is wat mij betreft een van de belangrijkste manieren waarop de professionalisering van een vakgebied verder vorm kan krijgen.
51
De complexiteit van moderne IT-landschappen dwingt organisaties om veranderingen en vernieuwingen onder architectuur door te voeren. Maar dat is eenvoudiger gezegd dan gedaan. Want hoe beoefen je IT-architectuur in de praktijk? Wat zijn de taken van een IT-architect? Welke werkwijzen en hulpmiddelen staan een IT-architect ter beschikking? Welke producten maakt een IT-architect? En hoe zorg je ervoor dat die producten effectief zijn en toegevoegde waarde bieden aan een organisatie? Kortom, wat betekent het om een volwaardig IT-architect te zijn? Dit boek is een praktische gids voor de hedendaagse digitale architect. Het biedt inspiratie voor de verdieping van het vak. Het ‘wat’, het ‘waarom’ en het ‘hoe’ komen uitgebreid aan bod, zowel ten aanzien van het ontwerpen zelf alsook het vervaardigen van architectuurproducten en het succesvol maken van de architectuurfunctie in de organisatie. Ook voor andere doelgroepen is het boek interessant, omdat het een mooi kijkje geeft in de keuken van de IT-architect. Door in ruime mate persoonlijke praktijkverhalen door het boek heen te weven heeft de auteur ervoor gezorgd dat met recht gesproken kan worden van ‘leve(n)de IT-architectuur’.
Daniël Jumelet (1973) is een pionier op het gebied van IT-architectuur. Voortdurend is hij op zoek naar vernieuwing en verbetering, samen met collega’s en opdrachtgevers. Het is zijn passie om zijn jarenlange ervaring in een vak dat hij met hart en ziel beoefent, te delen met anderen.