Verslag NAF-rondetafel ‘Architectuur van de Technische Infrastructuur’ Daan Rijsenbrij1 en Daniël Jumelet2
Inhoud 1. Inleiding 2. Key notes 3. Eisen aan het functioneren van een moderne infrastructuur 4. Strategische uitgangspunten en architectuurprincipes 5. Functionele bouwblokken & services 6. Visuele beschrijvingsvormen 7. Slotopmerkingen rondetafel 8. Deelnemers
1. Inleiding De technische infrastructuur is het fundament waarop alle andere IT-zaken worden gebouwd: businessapplicaties, gegevensverzamelingen, werkruimtes et cetera. Het pionierswerk van prof. Gerrit Blaauw aan de architectuur van IBM system/360 model 67 eind zestiger jaren en het toenmalige meesterwerk ‘structured computer organization’ van prof. Andy Tanenbaum uit de zeventiger jaren, doen vermoeden dat het architectuur-denken in de techniek (computers, netwerken en operating systems) al heel oud is. Toch constateren Daan Rijsenbrij en Daniël Jumelet dat bij veel ‘high level’-architectuurnotities heden ten dage bitter weinig staat over de architecturele beslissingen in en over de technische infrastructuur. Gelukkig ontstaat er bij veel bedrijven en overheidsorganisaties vanuit een architectuuroptiek een hernieuwde belangstelling in de technische infrastructuur als fundament, en in de services die het levert voor de architectuurlagen daarboven. Daardoor is er behoefte aan een verhaal over hoe een chief/lead architect hoort te kijken naar de technische infrastructuur; een beschrijving die tevens leesbaar is op het niveau van de CIO. Voor een daadwerkelijk bruikbare architectuurbeschouwing van de technische infrastructuur is allereerst een technologie- en organisatieneutrale infrastructuurbeschrijving nodig op conceptueel niveau. Uitgangspunt zou zijn een merkvrije opsomming van functionele bouwblokken, met een eenvoudige integratiefilosofie die optimale adaptiviteit borgt. Vervolgens kan die architectuur in stapjes worden geconcretiseerd naar op de markt aanwezigen componenten, outsourcingsmogelijkheden of cloud services. Om het denken in Nederland en Vlaanderen op te starten heeft het NAF Daan Rijsenbrij en Daniël Jumelet gevraagd een eerste inventarisatie te houden met de vragen: 1 2
Daan Rijsenbrij is zelfstandig, onafhankelijk architect in de Digitale Wereld. Daniël Jumelet is zelfstandig architect in de Technische Infrastructuur (IT2FIT) en oprichter van OIAm.
Wat zouden de belangrijkste architecturele aandachtspunten horen te zijn van een technische infrastructuur? Welke eisen horen te worden gesteld aan een volwassen technische infrastructuur? Welke volwassenheidsstadia zouden kunnen worden onderscheiden in de technische infrastructuur? Welke functionele bouwblokken kunnen worden onderscheiden? Welke beschrijvingsvormen blijken adequaat voor de verschillende stakeholders?
Op woensdagmiddag 2 april 2014 hebben Daan Rijsenbrij en Daniël Jumelet daartoe namens het NAF een rondetafel-bijeenkomst gefaciliteerd, ingericht als kenniscafé. Er waren vier tafels met elk een duidelijk gespreksonderwerp. Roulerend gingen uitgebalanceerde subgroepen van ongeveer 7 deskundigen langs de tafels om gedurende 40 minuten concreet te discussiëren bij elke tafel. Aernoud van de Graaff (VMware) heeft een key note verzorgd, getiteld ‘de architectuur van een future proof infrastructuur’. Hij heeft een technologievrije, merkloze beschouwing gegeven van de technische infrastructuur. Hij heeft wat pittige stellingen gelanceerd die hebben gediend als katalysator voor de brainstormingen aan de discussietafels. Vervolgens heeft Daniël Jumelet een korte toelichting gegeven over het doel en het functioneren van de community van infra-architecten. Tafel 1: eisen aan het functioneren van een moderne technische infrastructuur. De infrastructuur is het fundament waarop de rest van de IT wordt gebouwd: de applicaties, de gegevensverzamelingen en het informatieverkeer. Welke cruciale (kwaliteits)eisen gelden ten aanzien van het functioneren van een moderne intelligente infrastructuur, begrijpelijk voor de bestuurders? Waar komen die eisen vandaan? Tafel 2: strategische uitgangspunten en architectuurprincipes. Welke strategische uitgangspunten en architectuurprincipes leiden naar een adaptieve, intelligente technische infrastructuur? Waar komen die architectuurprincipes vandaan? Hoe zijn de relaties met andere (architectuur)principes, uit andere architectuurgebieden en uit het ecosysteem? Welke open standaarden horen bij een professionele infrastructuur? Tafel 3: functionele bouwblokken & services. Hoe wordt de technische infrastructuur beschreven in functionele bouwblokken / services? Welke eenvoudige taxonomie is voorhanden die begrijpelijk is voor niettechneuten? Hoe zou een Chief Architect, de CIO en de business moeten/kunnen kijken naar de technische infrastructuur? Welke functionele bouwblokken zijn als outof-the-box oplossingen op de markt aanwezig? Tafel 4: visuele beschrijvingsvormen. Wat zijn goede (visuele) beschrijvingsvormen van de technische infrastructuur voor niet-techneuten en hoe zijn die gerelateerd aan de beschrijvingsvormen die techneuten gebruiken? Welke stakeholders kunnen worden onderscheiden? Wat voor soort beslissingen kunnen worden gemaakt met die visualisaties? Zijn er succesvolle voorbeelden? 2
Het onderhavige verslag is een weergave van de resultaten van de rondetafel. Veel dank voor de inspanningen van alle deelnemers (zie paragraaf 8: deelnemers) voor hun waardevolle bijdragen en open deelname. Uit het verslag blijkt duidelijk dat deze rondetafel slechts een eerste aanzet is.
2. Key notes “Hoe zet je een toekomstvaste infrastructuurarchitectuur op?” Aernoud van de Graaff, Business Solutions Architect bij VMWare, heeft daar een duidelijke mening over. “Het begint bij het afstemmen van de inhoud op de taal die de beslissers begrijpen. Veel teveel zogenaamde architectuurdocumenten staan bol van de productnamen en technische termen. Hiermee is het onmogelijk om een zinvol gesprek aan te gaan met een CIO. Het gaat erom om requirements in termen van functionaliteit vast te leggen en de belangrijkste vragen van het C-level te beantwoorden over hoe de IT aan te laten sluiten bij de business. Enkele simpele noodzakelijke vragen voor de CIO: Waar staan wij? Wat hebben wij morgen nodig om de bedrijfsvoering te ondersteunen? Wat kost het? Hoe ziet ‘morgen’ eruit? Hoe komen wij daar? Wat zijn de implicaties, hoe ziet de transformatie eruit? Wanneer wordt wat geleverd? Hoe blijf ik in control? De antwoorden op deze vragen moeten op een aansprekende en overzichtelijke wijze gepresenteerd worden. Bijvoorbeeld in de vorm van een Heatmap, een TCOoverzicht of een fantasievolle praatplaat. Daarnaast is het goed mogelijk om vanuit de professie beslissers te inspireren, omdat veel ingrediënten van een moderne infrastructuur voorspelbaar zijn. Zoals virtualisatie, waarmee zowel flexibiliteit als robuustheid worden bevorderd en de verdergaande inzet van automatisering van beheer en het aanbieden van self-servicemogelijkheden voor gebruikers. Steeds meer infrastructuur wordt daarbij softwarematig geleverd, zoals de opkomst van het Software Driven Datacenter laat zien.” Het vak van infrastructuurarchitectuur komt steeds meer tot ontwikkeling. Daniël Jumelet, businessinfrastructure consultant bij IT2Fit: “Zowel de methode als de community rondom de Open Infrastructure Architecture method (OIAm) begint steeds meer volwassen te worden. Het geeft architecten het gereedschap in handen om infrastructuur vanuit functionaliteit en kwaliteit vorm te geven. Met behulp van consistente en door de community gedocumenteerde en beproefde modellen, wordt de architect in staat gesteld om requirements bij de verschillende gebruikersgroepen te inventariseren. Vervolgens kunnen deze worden vertaald naar richtlijnen voor de techniek, op een manier die technisch ontwerpers richting en ruimte geeft. De NAFrondetafel over infrastructuurarchitectuur is in dit kader een mooi ijkpunt van de stand van zaken binnen het vakgebied.”
3
3. Eisen aan het functioneren van een moderne infrastructuur gefaciliteerd door Daniël Jumelet en Marc Berenschot Hoe ziet een moderne infrastructuur er uit? Welke eisen kunnen aan het functioneren worden gesteld? Dat geldt ten aanzien van de kwaliteit, maar uiteraard ook wat betreft de functionaliteit. Wat doen we morgen niet meer, wat we vandaag nog wel doen, bijvoorbeeld onder invloed van diensten uit de cloud? Zijn in de toekomst aanvullende infrastructuurdiensten nodig, bijvoorbeeld om het gebruik van clouddiensten voor de eindgebruikers zo transparant mogelijk te maken? Daarbij is een belangrijke vraag: Is het mogelijk om vanuit architectuur zinnige uitspraken te doen over de kosten van infrastructuur en is het mogelijk om een kosten/batenanalyse te doen tussen verschillende scenario’s? Welke kwaliteitseisen zijn leidend? Hoe bewaak je die? Bij het vormgeven van infrastructuur is het belangrijk vast te stellen dat infrastructuur per definitie voorzieningen betreft die gedeeld zijn in gemeenschappelijkheid, waarbij enige variatie altijd aanwezig is (one size fits nobody). Infrastructuur staat dus niet gelijk aan hardware. Maatwerk hardware, nodig voor specifieke maatwerkapplicaties is in deze definitie geen infrastructuur, maar een bedrijfsoplossing. Een moderne infrastructuur kent de volgende kwaliteitskenmerken: Pay as you go (by use) / kosteneffectiviteit / waarde voor de business. Flexibiliteit / snel beschikbaar. Beschikbaarheid / precies goed beschikbaar / conform SLA. Perfomance / voldoende verwerkingscapaciteit / voldoende bandbreedte. Open standaarden / open API’s / koppelbaarheid over organisaties heen. Secure / compliant / voldoende veilig (voldoend aan wettelijke eisen, wet & regelgeving). Bij beveiliging dient gedacht te worden aan meerdere benaderingen, zijnde preventief, repressief, en correctief. Onderhoudbaarheid (begrijpelijk / simpel). Energiezuinig. Onbeperkte opslag (schaalbaarheid). Self-Service. Gemakkelijk bruikbaar en herkenbaar voor gebruiker / geïntegreerd, transparante gebruikerservaring. Welke kwaliteitseisen relevant zijn, is ook afhankelijk van de strategie die een organisatie kiest en vice versa. Sommige kwaliteitskenmerken leiden tot een oplossingsrichting in de vorm van zelf doen, zoals beveiligingseisen en / of regels rondom privacy. Andere kwaliteitskenmerken en beleidskeuzes zorgen ervoor dat de eigen infrastructuur steeds minder relevant wordt, waardoor organisaties zich in die gevallen op IT-gebied zich vooral bezig zullen houden met data en datamodellering en zoveel mogelijk voorzieningen uit de cloud betrekken. Transport en de nodige koppelvlakken naar de cloud is in dat geval het enige dat in de infrastructuur overblijft. Dit vraagt onder andere om de toepassing van data-classificatie en een eenvoudige en veilige toegang middels geconsolideerd Identity en Access (Permissie) Management en gebruiksvriendelijke portalen. De vraag om veiligheid levert in dit kader spanning op. De traditionele benadering van afscherming en 4
zonering blijkt in een aantal gevallen niet meer op te gaan, zeker niet in een situatie waarin er veel koppelvlakken zijn met de buitenwereld. Bij het afstemmen en bewaken van kwaliteitseisen moeten de spelregels worden gevolgd die in de bedrijfsvoering spelen (bedrijfspolitiek). Kwaliteitseisen zijn, zoals al genoemd, afhankelijk van het soort bedrijfsvoering. Bij een bank zijn veiligheid en compliance belangrijke eisen, een startup zal vooral gebaat zijn bij flexibiliteit. Infrastructuur moet beschouwd worden als nutsvoorziening, waarbij een middenweg gevonden moet worden in de afweging van de te hanteren kwaliteitseisen en kwaliteitsniveaus. De praktijk is weerbarstig, verschillende stakeholders hebben dikwijls conflicterende eisen. Het is de taak van de architect om tussen deze kwaliteitseisen de balans te vinden. Differentiatie begint steeds meer belegd te worden in de afspraken die in en rondom de SLA gemaakt worden. Hierbij kan de constructie eenduidig zijn, maar zijn de hiermee geleverde diensten verschillend. De keuze die aan afnemers wordt geboden dient beperkt te worden tot een aantal bruikbare varianten, waar op basis van behoefte van kwaliteit tussen gekozen kan worden. Op die manier wordt kwaliteit een stuurmiddel. Zonder vaste vormen leidt de invulling van kwaliteitseisen tot oncontroleerbare wildgroei. Waar op die manier enerzijds een streven ontstaat naar een eenduidiger constructie, gebeurt het anderzijds in de praktijk nog regelmatig dat dubbele oplossingen worden geïntroduceerd, bijvoorbeeld doordat leveranciers steeds meer appliances gaan leveren met veel standaard functionaliteit aan boord. Afwijken van de standaard is niet per definitie slecht, het kan juist tot innovatie leiden. Duidelijk is dat het wel bewust moet gebeuren en hierin speelt de architect een belangrijke rol. Welke voorzieningen / functionaliteiten zijn nodig voor een moderne infrastructuur? Afhankelijk van de strategie die een organisatie volgt (zelf blijven doen, juist veel uit de cloud afnemen, of ergens tussen in), zijn er tal van infrastructuurvoorzieningen die onmisbaar zijn in een moderne infrastructuur. Standaard hoofdcomponenten van de technische infrastructuur blijven: processing, transport en storage. Ook bij het in verregaande mate afnemen van clouddiensten, blijft het relevant om deze diensten vanuit de IT gecontroleerd af te nemen, zodat ze veilig, compliant en op basis van toegangscontrole worden benut door de organisatie. Met het afnemen van applicaties uit de cloud wordt integratieproblematiek geïntroduceerd, zodat er aandacht moet zijn voor een gecoördineerd bestandsbeheer en gecoördineerde berichtenafhandeling. Wanneer wordt gekozen voor afname van diensten “as-a-service”, dan dienen deze diensten ook naar afnemers als een service te worden gebracht. Hiervoor is een serviceportaal nodig, dat pay-per-use ondersteunt, het mogelijk maakt dat diensten direct beschikbaar zijn, op basis van self-service functioneert. Voor de gebruiker en zijn werkomgeving geldt dat vanuit de infrastructuur basisfunctionaliteit beschikbaar moet zijn, zoals e-mail, kantoortoepassingen en hulpmiddelen voor samenwerking (portalen). Self-service herstelvoorzieningen zijn hierbij essentieel, zoals het kunnen repareren van per ongeluk gewijzigde of gewiste bestanden of het herstellen van de configuratie van een afgenomen dienst. De 5
werkplek wordt steeds meer een virtueel gegeven. Op termijn is toegang via een webbrowser de enige vereiste (onafhankelijk van het type apparaat). Waar vroeger het afscheiden van netwerkzones werd ingezet om gebruik te reguleren, wordt nu “authenticatie en autorisatie” de nieuwe “plane of control”. Dit bevindt zich op de scheidslijn tussen infrastructuurfunctionaliteit en applicatiefunctionaliteit: rechten zijn gekoppeld aan de applicatie, het controleren en valideren van rechten valt onder infrastructuur. Permissie-structuren moeten universeel toepasbaar en overdraagbaar zijn en voor dit doel zo organisatieonafhankelijk worden opgezet, wanneer cloud-providers afnemers een granulaire rechtenstructuur willen kunnen aanbieden. Bij het inzetten van “authenticatie en autorisatie” als controlemiddel, hoort ook de toepassing van geautomatiseerde monitoring, zowel security als service level monitoring (zoveel mogelijk end-to-end, over de gehele keten heen). Daarnaast groeit de behoefte aan infrastructuurondersteuning voor auditing, omdat bij gebruik van cloud-toepassingen belangrijke bedrijfsprocessen elders worden uitgevoerd en hier data mee gemoeid is die bedrijfskritisch is en / of privacygevoelig. Diensten worden op basis van de volgende aspecten geleverd Op basis van service-tiering. Orchestrated managed provisioning, oftewel policy driven: Dit vergt constructieen life cycle-onafhankelijke inrichting (dus ook geen constructief onderscheid tussen OTA en P-omgevingen). Inclusief veilig koppelpunt externe partijen. Zoveel mogelijk op basis van virtualisatie. Niet altijd zijn end-user devices in beeld, diensten kunnen ook op basis van M2M worden afgenomen (machine-to-machine). Applicaties worden via een interne app-store verstrekt, indien gewenst Monitoring / Security monitoring om aan compliancy te kunnen voldoen. High-speed interconnectie. Bij het afnemen van diensten moeten privacy-aspecten worden meegenomen. Naast de infrastructurele voorzieningen blijven mensen met kennis nodig. Er zijn steeds meer ‘generalisten’ nodig, maar deze generalisten dienen op tenminste één onderdeel van het landschap over diepgang en diepgaande kennis te beschikken (TProfiel). Hoe worden kosten inzichtelijk gemaakt voor CIO / CFO vanuit de architectuur? Het inzichtelijk maken van de kosten voor CIO/CFO vanuit de architectuur is een erg lastige vraag, omdat architectuur zeer vroeg in de ontwikkelketen zit en zich vooral richt op functionaliteit en kwaliteit. Die functionaliteit kan nog op verschillende manieren vertaald worden naar constructies. Als de constructie bekend is, dan kunnen kosten accuraat berekend worden. Het zou echter mooi zijn als in eerdere stadia al zinvolle uitspraken over kosten gemaakt kunnen worden. Op basis van de veranderingsbehoefte kunnen namelijk verschillende scenario’s worden opgesteld. Deze scenario’s dienen ook op kosten en baten vergeleken te kunnen worden, om tot een zinvolle business case te kunnen komen. Het is prima mogelijk om architectuurstudies en -modellen te vertalen naar voorontwerpen. De beperking 6
hiervan is echter dat een reële inschatting van de sizing niet wordt meegenomen en hier zitten vaak de echte kostenposten. Eén manier om hier meer licht op te werpen is het gebruik van aannames op basis van ervaring en historische gegevens. Licentiekosten, beheerkosten (bemensing) zijn grootheden die hierbij helpen. Het opstellen van een business case blijft daarbij onverminderd lastig. Infrastructuur zelf brengt geen geld op, maar faciliteert andere zaken die geld opbrengen. Het is daarom belangrijk om inzichtelijk te maken wat de vruchten zijn die op basis van de aanwezige infrastructuur worden geplukt (op een andere plek in het IT-landschap of de organisatie), naast de TCO van de infrastructuur zelf. Hoe beter een organisatie de kostenstructuur in orde heeft, hoe makkelijker het is om op deze manier een kostenindicatie uit te voeren. Een andere insteek is een vergelijking maken met diensten die op basis van pay-peruse worden aangeboden en die als commodity ingekocht kunnen worden. In dat geval moet een inschatting gemaakt worden wat enerzijds de kwaliteitswinst is wanneer een oplossing in eigen beheer wordt gerealiseerd en wat anderzijds de meerkosten bedragen. In ieder geval levert het betrekken van de commodityoplossing een baseline op wat betreft de kosten en daarmee een redelijk hard vertrekpunt. Uiteraard is het mogelijk om beide aanpakken te hanteren. Aanvullend op hierboven geschetste financiële zaken nog een paar kanttekeningen: Kosten niet kwantificeren is euro’s, maar in laag / midden / hoog. Dit geldt met name bij het vergelijken van meerdere scenario’s. Hiermee wordt in ieder geval voorkomen dat verkeerde verwachtingen worden gewekt. Naast een financiële vergelijking is ook een afweging mogelijk op basis van een duurzaamheidsindex. Hiervoor dienen oplossingen op hoofdlijnen te zijn uitgewerkt. Gebruikmaken van benchmarks en referenties. Uitvraag van kostenindicaties bij leveranciers. Dit kan door RFI’s uit te zetten op basis van functionele modellen. Uit (laten) voeren van peer reviews. Hanteren van een uitgewerkt kostenmodel met kostensoorten: aanschaf, realisatie, beheer en onderhoudscontracten. Kijken naar de manier waarop een dienst georganiseerd is, dit bepaalt een groot deel van de kosten. Service- / functiepunten analyse. Voor softwareontwikkeling is dit beschikbaar, voor infrastructuur dient dit ontwikkeld te worden. Hanteren van metrieken op basis van factoren als organisatietype, servicemodel en kwaliteitsniveaus die op infrastructuurservices worden gemapt. Hanteren van frameworks, zoals COBIT v5. De wens om vooraf kosten inzichtelijk te hebben kent juist vanuit architectuur ook een tegenargument. Namelijk dat grootschalige architectuurbeslissingen juist niet moeten worden genomen op basis van een kostenschatting, maar op basis van strategische overwegingen. Gegeven de strategische overweging worden de architecturele beslissingen genomen, waarna geprobeerd wordt om die (bij de uitwerking van de details) zo goedkoop mogelijk te realiseren.
7
4. Strategische uitgangspunten en architectuurprincipes gefaciliteerd door Serge Bouwens en Debbie Tarenskeen Wat moeten de strategische uitgangspunten zijn met betrekking tot de toekomstige infrastructuur? Welke architectuurprincipes horen daar dan bij? In dit hoofdstuk worden de antwoorden van de deelnemers samengevat, en voorzien van een reality check: wat houdt ons tegen om die toekomst niet nu al te realiseren? Strategische Uitgangspunten Infrastructuur moet dienstverlenend en ondersteunend zijn aan het bedrijf. Tegelijkertijd wordt wel geconstateerd dat dit in de praktijk lastig is. Er bestaat in veel ondernemingen een gap tussen business(-architectuur) en infrastructuur(architectuur). Dit defect krijgt in de enterprise architectuur steeds meer aandacht, maar daar is het nog niet mee opgelost. Hopelijk draagt het resultaat van deze rondetafel er toe bij dat we de gap dichten. Dat vraagt een inspanning van twee kanten. De strategische uitgangspunten zijn te vangen onder vijf strategische thema’s: Managed Infrastructure. Cloud. Any Place – Any Time – Any Device. Interconnected. Security. Managed Infrastructure Infrastructuur wordt steeds meer een commodity, zegt men. Daarmee lijkt het alsof het net zo weinig aandacht behoeft als elektriciteit of water uit de kraan. Niets is minder waar. De infrastructuur – en zeker het deel dat in eigen beheer is – is randvoorwaardelijk voor het functioneren van het bedrijf, en de ontwikkelingen gaan razendsnel. Wij zien drie ontwikkelingen binnen het thema Managed Infrastructure. 1. De spanning tussen ‘user centric’ en ‘infra centric’ Het begrip ‘de gebruiker’ krijgt vanuit infrastructuur steeds meer diversiteit, terwijl we er vanuit beheeroptiek juist naar streven om te standaardiseren. Dit vraagt om een architectuur waarbij de infrastructuur services aanbiedt via goed gedefinieerde koppelvlakken. Maar de bal kan niet alleen maar bij de infra-beheerders worden gelegd. Met de toenemende mogelijkheden die de gebruikers krijgen, neemt ook hun verantwoordelijkheid toe: ‘With great power comes great responsibility’. 2. Agility versus duurzaamheid Het is een best practise om het vierluik ‘tijd, kwaliteit, geld en risico’s’ in samenhang te beheren. Toch valt niet aan de indruk te ontkomen dat de factor tijd steeds belangrijker wordt. De life cycle van technologie (óók in de infrastructuur) wordt steeds korter, terwijl de noodzaak van een kortere time-to-market steeds groter. De infrastructuur kan dit tempo alleen volgen als er voortdurend vernieuwd wordt (schaalbaarheid alleen is niet genoeg). Dit vraagt een uitgekiende balans tussen het uitnutten van het bestaande en het experimenteren met het nieuwe. Kennismanagement wordt belangrijker. 8
3. Financiering van de infrastructuur De ontwikkelingen in de IT gaan snel. Ook in de infrastructuur is er sprake van ‘disruptive technologies’: denk aan cloud, mobile, big data. Aan de ene kant willen we onze infrastructuur commoditizen, dus toekomstvast, goedkoop en efficiënt, het liefst met lange afschrijftermijnen. Aan de andere kant willen we een ‘adaptive’ infrastructuur waarmee we in staat zijn aan de snel veranderende behoeften van business en gebruikers te voldoen. Dit vraagt om inzicht in de kosten en om goede timing van financiële investeringen in de infrastructuur. Leveranciers maken het ons lastig met licentiestructuren, maar met onze interne verrekenstructuren maken we het nog ingewikkelder. Voorbeeldprincipes Infrastructuur wordt aangeboden in de vorm van services (niet: servers). Infrastructuurservices worden verrekend op basis van ‘pay-per-use’ (niet: gratis / niet: de eerste gebruiker betaalt). Bij investeringen in infrastructuur gaat de voorkeur uit naar OPEX boven CAPEX. Cloud Hoewel de term ‘Cloud’ weinig genoemd wordt, worden tal van kenmerken genoemd waar de toekomstige infrastructuur aan moet voldoen, die ook worden toegeschreven aan cloudoplossingen: Schaalbaarheid en flexibiliteit (in opslag, computercycles, bandbreedte). Marktconformiteit: de interne prijsprestatie is vergelijkbaar met wat de markt biedt. Intern de focus op core business. Continuous automated deployment. Software Defined Data Center. Duurzaam. In tegenstelling tot de indruk die we uit de pers kunnen krijgen dat iedereen overal met cloud bezig is, blijkt dat in de praktijk nog tegen te vallen. De consument (Facebook, LinkedIn, Twitter) en de grote leveranciers (Google, Microsoft, Apple, Amazon) beheersen de media. Toch realiseren we ons dat we in een wedloop zijn verwikkeld: ‘Shadow IT will happen’. SaaS-oplossingen (denk aan SalesForce.com) doen hun intrede in het bedrijf, en de infrastructuur zal de integratie met externe systemen moeten faciliteren. Nu de servers grotendeels gevirtualiseerd zijn, zet deze trend zich door naar de netwerk en storage hardware. Software defined data centers maakt verdere automatisering mogelijk. Zaken die bij deze ontwikkeling niet vergeten moeten worden zijn: 1. Het hebben van een exit strategie 2. Voldoende deskundigheid in huis om de infrastructuur te kunnen aansturen en beheren 3. Controle over de toegang tot data. Architectuurkennis is hier onderdeel van.
9
Voorbeeldprincipes Cloud before Buy before Make. We houden te allen tijde beheersing (d.w.z.: zeggenschap, beschikbaarheid, betrouwbaarheid, continuïteit, toegankelijkheid) over onze eigen gegevens. Bij het aanschaffen van IT-voorzieningen (van hosting tot applicaties) is een exit strategie onderdeel van de acquisitie. Any Place – Any Time – Any Device Dit zijn niet zo maar modekreten. Any Place betekent dat we er niet meer van uit kunnen gaan dat de gebruiker op kantoor is, en dus worden veiligheid, beschikbaarheid van data, en bandbreedte zaken waar de infrastructuur architectuur op moet worden herontworpen. Any Time (dus 7x24) betekent access en support voor wereldwijde tijdzones, in het bijzonder na 17 uur. Any Device is misschien nog wel de lastigste van het stel. De spanning tussen de wens van de gebruiker om vanaf zijn eigen pc, ipad, smartphone, e.d. te werken roept wederom vragen op op het gebied van beveiliging, privacy, kosten toerekenen, standaardisatie en beheerbaarheid. Voor de architectuur betekent dit dat de vraag naar zelf doen of uitbesteden aan de orde is. Ook standaarden en standaardkoppelvlakken zijn belangrijke onderwerpen. Voorbeeldprincipes De beschikbaarheid van de infrastructuurvoorzieningen voldoet aan de door de business gestelde eisen in tijd en plaats. Elke medewerker moet altijd en overal kunnen beschikken over de informatievoorziening en IT om zijn werk te kunnen doen. Medewerkers voldoen bij het gebruik van eigen devices en software aan de
voor veiligheid. Applicaties werken ook op een standaard werkplek. Infrastructuur-services worden device-agnostic aangeboden. Plug & Play: de applicatiefunctionaliteit is losgekoppeld van de infrastructuur. Interconnected Samenwerken en ketensamenwerking zijn dominante ontwikkelingen in veel organisaties. Deze samenwerking zal door de IT / infrastructuur moeten worden gefaciliteerd. In het bijzonder wordt aandacht gevraagd voor de non-profit sector. Is het mogelijk dat het hier sneller dan in het algemeen afspraken worden gemaakt (lees: standaarden)? Of moeten we dit juist niet willen, en moeten we juist aansluiten bij internationale internet standaarden? Een heel andere opkomende trend is het ‘Internet of Things’. Vanuit het idee dat straks alles ‘connected’ is, betekent dat er in het configuratiebeheer behoefte is aan opschaling (enkele ordegroottes) en automatisering. Voorbeeldprincipes Interfaces met de buitenwereld maken gebruik van open (internet) standaarden. De extended infrastructuur (inclusief de devices van / geleverd aan onze klanten) wordt centraal beheerd.
10
Security Al 30 jaar vinden we security héél belangrijk. En al 30 jaar blijkt het toch steeds weer het stiefkind te zijn van onze projecten. Hoewel de geschiedenis leert dat we niet leren van de geschiedenis, hebben we nu toch de hoop dat de aanhoudende stroom van incidenten – van DigiNotar tot NSA – ook de boardrooms bereikt. Beveiliging is bij uitstek een gebied waar alle architectuurdisciplines elkaar dienen te ontmoeten: ‘Infrastructure Architecture meets Enterprise Architecture’. Voorbeeldprincipes Applicaties en data zijn beveiligd met encryptie en role based access. Alle systemen dienen via Single Sign On (SSO) ontsloten te worden. Trust but verify. Beveiliging van data is gebaseerd op BIV classificatie. (Bedrijfskritische) applicaties en data worden beveiligd met de centrale IAM oplossing. Reality Check Oneindig veel flexibiliteit, capaciteit, volledig geautomatiseerd en tegen commodity prijzen. Dat zijn wensen van alle tijden. Maar hoever zijn we daar nu van af? Wat houdt ons tegen om de IT aan te passen volgens de eisen van de tijd? We zien bij elk van de vijf thema’s enkele obstakels die ons verhinderen om snel stappen te zetten Obstakels bij ‘Managed infrastructure’ Er is gebrek aan visie, strategie, leiderschap en aan beleidskeuzen die dan ook nog nageleefd worden. De gap tussen enterprise architectuur en infrastructuur architectuur heeft te maken met een kennis-gap, maar ook gebrek aan inzicht in de samenhang en i.h.b. de kosten spelen hierbij een rol. Een gevolg is dat er een technical debt (legacy systemen die van elke verandering een probleem maken) wordt opgebouwd door het initiëren van projecten zonder een bovenliggende visie op infrastructuur en zonder de samenhang tussen projecten aan te pakken. De huidige IT is vanuit het beheer en vanuit een beheerperspectief (ITIL) opgezet. De eisen van deze tijd vragen echter om een veranderperspectief. Er wordt teveel dichtgetimmerd, in plaats dat er gekeken wordt wat er voor de organisatie nodig is. De dominante IT-cultuur is veelal opgezet rond projecten. Elk project doet zijn eigen traject; samenhang ontbreekt of wordt niet aangebracht. Dit wreekt zich in de infrastructuur des te harder omdat de meeste aandacht uitgaat naar applicaties, terwijl infrastructuur vaak van iedereen is. Obstakels bij ‘Cloud’ Cloud is zowel een kans als een bedreiging voor de interne infra professional. Gebrek aan een duidelijke bedrijfsvisie werkt een snelle adoptie niet in de hand. Hoewel er geëxperimenteerd wordt, is een elastische infrastructuur in de meeste organisaties nog niet aan de orde. Obstakels bij ‘Any Place – Any Time – Any Device’ 11
Hoewel de ontwikkelingen in technische zin heel snel gaan, dreigt er weer een nieuwe vorm van legacy te ontstaan. Nu niet in de back office, maar in de clients en de koppelvlakken. Wildgroei en spaghetti infrastructuren dreigen, en buiten de deur houden lijkt geen optie. Standaardisatie is onze enige hoop, maar het aantal standaarden neemt toe.
Obstakels bij ‘Interconnected’ Standaardisatie is onze enige hoop, maar het aantal standaarden neemt toe. De Nederlandse overheid heeft last van een remmende voorsprong. In plaats van het adopteren van internationale en internet-standaarden definiëren we er nationaal duchtig op los. Dit wordt door ons als zeer onwenselijk gezien, ook al begrijpen we het dilemma op de korte termijn. De wetgeving is traag, de ontwikkeling van StUF standaarden is traag, en de adoptie door leveranciers is nog trager. Obstakels bij ‘Security’ Gewoon te weinig aandacht bij management en enterprise architecten voor dit thema. Hoe krijgen we het voor elkaar dat security niet steeds weer geschrapt / vergeten wordt?
5. Functionele Bouwblokken & Services gefaciliteerd door Edwin Strijland en Roland Bijvank Stakeholders Naamgeving en definities van de functionele bouwblokken moeten herkenbaar zijn voor de verschillende categorieën stakeholders. Belangrijke stakeholders die hierbij onderscheiden moeten worden, zijn enerzijds de verantwoordelijken voor bedrijfsvoering en het budget op basis waarvan het project gerealiseerd gaat worden en anderzijds eindgebruikers die de veranderingen aan den lijve gaan ondervinden. Tot de eerste categorie behoren doorgaans de Chief Information/Technical Officer, directeuren of management en in sommige gevallen ook de Nederlandse staat (denk o.a. aan wijziging wetgeving e.d.). Samen met eindgebruikers als directbetrokkenen noemen we deze twee categorieën stakeholders in het vervolg doelgroep #1. Daarnaast is er een stakeholder-groep die direct geconfronteerd wordt met de impact van de beoogde wijziging met betrekking tot realisatie, project- & applicatieportfoliomanagement, risicomanagement en operationele processen (zoals wijzigingenbeheer). Stakeholders, hierna gekenmerkt als doelgroep #2, zijn onder andere: Collega-architecten: Enterprise m.b.t. impact op de totale concernarchitectuur en applicatie-architecten (meestal middels infrastructuurdecomposities en kaders binnen een Project Start Architectuur (PSA)). Business users belast met risico-/impactanalyse, en gewoon als gebruikers. Interne audit diensten. IT Governance processen. Interne & externe exploitanten/dienstverleners van deelfuncties/services van de te realiseren dienst.
12
Niet in alle gevallen is in elke organisatie onmiddellijk duidelijk welke stakeholders betrokken moeten zijn. Dit is overwegend gebaseerd op onduidelijkheden m.b.t. portfoliomanagement en eigenaarschap: Business functies: Infrastructuur levert generieke functieservices t.b.v. het applicatielandschap. Meestal projectmatig uitgevoerd met duidelijke stakeholder(s). Specifieke applicaties: De stakeholders voor deze applicaties zijn meestal duidelijk. Generieke applicaties & commodity diensten zoals bijvoorbeeld een e-mail voorziening): Voor de meeste bedrijven een bedrijfskritische voorziening zonder duidelijke business eigenaar (vraag organisatie) waarbij de IT-organisaties vaak zowel de vraag- als aanbodzijde vertegenwoordigen. Interesses & behoeften De interesses en behoeften zijn divers bij de stakeholders en sterk afhankelijk van de casus en business impact. Interesses en behoeften zijn per doelgroep te onderscheiden: Doelgroep #1 Hergebruik & standaardisatie (efficiëntie en beheersbaarheid). Kwaliteitscriteria in relatie tot business impact. Waar worden welke maatregelen getroffen? Zowel non-functioneel (zoals performance, schaalbaarheid, capaciteit, beschikbaarheid) als functioneel (in relatie tot infrastructuur bijvoorbeeld: informatiebeveiliging). ‘Scherp krijgen’ van de (complete) eigen behoefte. Vermeldenswaard: overwegend geen interesse in technische details en complete visualisaties van functies en services van de infrastructuur. Eenvoudige maar doeltreffende ‘platen’ als hulpmiddel voor communicatie en verkrijgen van draagvlak. Doelgroep #2 Hergebruik & standaardisatie (efficiëntie en beheersbaarheid). Kaders en uit te werken services / functies in de functionele en technische ontwerpen. Kwaliteitsattributen in relatie tot services / functies (zoals schaalbaarheid, beschikbaarheid, performance, continuïteit). Overzicht services / functies in relatie tot producten en aanvullend (eventueel) de impact op de licentieportfolio. Impactbepaling op de totale verandercapaciteit. Impactbepaling op de beheerorganisatie (infrastructuurbeheer, (technisch) applicatiebeheer, functioneel beheer, processen). Met name de integratie van deze beheerdomeinen is een aandachtspunt. Transformatie / kanteling van silo gerichte inrichting naar service(s) georiënteerde architectuur (SOA). Authenticatie & autorisatie in relatie tot informatieclassificatie & risicoanalyse. Integratie-architectuur (EAI). Koppelingen en scheiden van responsibilities (taken, verantwoordelijkheden en bevoegdheden (TVB)) bij meerdere exploitanten/dienstverleners. 13
Te hanteren functionele bouwblokken Er wordt gedacht in verschillende building blocks afkomstig uit de volgende zes werkgebieden: client, middleware, netwerken, security & support, server, storage. Hier worden de meeste infrastructuurprojecten mee afgedekt. Patterns zijn vanzelfsprekend daar een onmiskenbaar onderdeel bij, zij vertegenwoordigen daarbij verschillende best practices die al vaak in hoofden van ervaren ontwerpers aanwezig zijn. Zodoende voorkom je als (beginnend) ontwerper dat je het wiel opnieuw uitvindt. Een obstakel hierbij is dat een voldoende uitgebreide pattern database nog niet beschikbaar is. Er zijn hoopgevende ontwikkelingen in de OIAm-context, maar ook daar is er behoefte aan een bredere bijdrage uit de community. Input vanuit referentie-architecturen Bekende referentie-architecturen zijn NORA (overheid), GEMMA (gemeenten), CORA (woningcorporaties), WILMA (waterschappen), maar deze zijn niet echt eenvoudig te noemen. Daarom hanteren een beperkt aantal bedrijven hun eigen referentie-architectuur. Interessant is om te kijken naar de gemeenschappelijke kenmerken van dit soort bedrijfsspecifieke referentie-architecturen. Hiernaast bieden methoden zoals OIAm (enige ‘open’ methode) en EAI patterns handvatten en een taxonomie voor visualisatie van de infrastructuur. Ondanks het feit dat deze methoden inspringen in een duidelijk ‘gat’ in het vakgebied is er (nog) geen sprake van een brede adoptie of opname in standaardwerkwijzen. De bekende referentie-architecturen zijn nogal omvangrijk en daardoor onhandig in het dagelijks gebruik. Daardoor wordt er in de dagelijkse praktijk toch nog veel van vrije methoden gebruikgemaakt ondersteund met behulp van diverse technische tools (bijvoorbeeld: Visio). Algemene opmerkingen Het lijkt erop dat een standaardwerkwijze ontbreekt, die past bij elke situatie. Functionele bouwblokken en services gebaseerd op standaard beschikbare referentie-architecturen of modellen worden slechts sporadisch toegepast en dan voornamelijk voor communicatie en/of alignement met architectuurcollega’s (Enterprise & Solution). De meest gekozen vorm is een vrije en interactieve vorm zoals bv. samen tekenen in Visio of PowerPoint, ondersteund door een mix van praatplaten en delen uit referentiearchitecturen die deels gebaseerd zijn op OIAm en gemodelleerd zijn in ArchiMate. In een enkel geval werd specifiek benoemd dat beschikbare functionele decomposities vooral helpen als gespreksondersteuning en ‘checklist’ voor compleetheid van noodzakelijke functies/services. Food for thought De wereld verandert harder dan je als (infrastructuur)architect kunt bijhouden. Onafhankelijk van het tool blijft de kwaliteit van architecten van belang (a fool with a tool is still a fool)! Over welke kwaliteiten moet een goed infrastructuurarchitect beschikken om zijn stakeholders te bedienen en gezamenlijk deze veranderingen als kansen te benutten? Te denken valt aan zaken als: 14
Beheersing van je methoden en technieken; Visualisatievermogen; Communicatieve vaardigheden / soft skills; Ondernemerschap.
Interessante sites ArchiMate: http://www.opengroup.org/subjectareas/enterprise/archimate EAI patterns: http://www.eaipatterns.com Open Infrastructure Architecture method (OIAm): https://www.infra-repository.org SysML: http://www.omgsysml.org Literatuurlijst
ArchiMate 2.1 Specification; The Open Group. Beheren onder Architectuur - het richting geven aan de inrichting van beheerorganisaties; Bart de Best. DYA Infrastructuur - architectuur voor de fundering van de IT; Daniël Jumelet. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions; Gregor Hohpe, Bobby Woolf. SysML distilled - A Brief Guide to the Systems Modeling Language; Lenny Delligatti.
6. Visuele Beschrijvingsvormen gefaciliteerd door Rik Willems en Jan Hellings Inleiding Visuele beschrijvingsvormen worden veelal gebruikt om een bestaande technische architectuur in kaart te brengen, voor het ondersteunen van de IT Operationele teams van een organisatie. Het ondersteunt de engineers en ontwikkelaars bij het oplossen van incidenten en problemen in het technische landschap en bij het ontwerpen ervan. Ook worden visuele beschrijvingsvormen gebruikt in de ontwerpfase van het technische landschap, meestal ter ondersteuning voor investeringsbeslissingen en ter bewaking van de beheersbaarheid van dat landschap. Daarnaast worden technische architectuurmodellen en beschrijvingen (bv lijsten van systemen en networkcomponenten) gebruikt bij een migratie van data centra, het outsourcen van (delen) van het technische landschap, waarbij grote investeringen een rol spelen. Deze technische architectuurmodellen en beschrijvingen helpen dan bij: (1) het bepalen van het migratie/investeringsbudget, (2) het maken van keuzes rondom de omvang (scope) van de migratie. Technische architectuurmodellen staan niet op zich zelf, maar hebben een duidelijke samenhang met het architectuurwerk wat in andere domeinen plaats vindt: business15
, informatie- en applicatiearchitectuur. Om deze samenhang vast te leggen en te bewaken, wordt er in veel architectuur frameworks met meta-modellen gewerkt, die naar de wensen van een bedrijf kunnen worden aangepast. Het ArchiMate 2.1 Metamodel is een voorbeeld hiervan, waarbij de samenhang beschreven wordt tussen elementen in de business, applicatie en infrastructure layer van een enterprise architectuur. Stakeholders “Wie zijn de belangrijkste belanghebbenden (stakeholders) van goede technische architectuurmodellen en wat voor soort stakeholders kun je onderscheiden?” Een voor gesprekspartners acceptabel model, gebaseerd op een model van Jan Schoonderbeek:
Figuur 1 Stakeholders Infra-architectuur gebaseerd op model Jan Schoonderbeek Gebruikte modellen Technische architectuurmodellen worden binnen een organisatie gebruikt voor roadmaps en vooral het overbrengen van de boodschap, waarbij vooral de transparantie belangrijk is. De modellen moeten de transparantie en het doel van de 16
gewenste situatie goed weergeven. Het is belangrijk dat de modellen de boodschap van de architect goed ondersteunen. De modellen moeten ook niet-functionele aspecten zoals beveiligingskwesties goed weergeven, de belangen van andere stakeholders goed aangeven en begrip kweken tussen de verschillende stakeholders. Tussen de architecten onderling speelt vooral het uitwisselen van concepten en informatie over de oplossingen, daarbij gaat het vooral over hoe je de zaken aanpakt. ArchiMate is hiervoor een goed fundament. Bij het hoger management gaat het meer over het overtuigen en het geven van aanbevelingen. Hier dienen de modellen een ander doel: het overbrengen van de meest essentiële kenmerken van het ontwerp en de daaruit voortvloeiende effecten voor de organisatie waarin de systemen geplaatst gaan worden. Karakteristieken van de modellen Een goed model is helder, fit for purpose, to the point, begrijpelijk en voorzien van argumentatie. Een van de belangrijkste aspecten is dat een model heel goed moet aansluiten bij de behoefte van de opdrachtgever en het beoogde publiek. Soms is een Mickey Mouse communicatieplaatje nodig en soms een complex ArchiMate model. Een model kan ook zeker analogieën bevatten, die voor de stakeholder begrijpelijk zijn. Aanbevelingen: probeer aan te sluiten bij de belevingswereld van de persoon kijk goed naar de stakeholder en gebruik de persoon en de rol die de persoon heeft goed in je model is de persoon technisch geïnteresseerd, verwerk dat ook in het model, ondanks dat deze persoon bijvoorbeeld een businessmanager is Representatievormen Er zijn verschillende modeltypen (viewpoints) en representatievormen (lijsten, matrices, story boards) te onderscheiden: Het is de algemene overtuiging dat alles kan werken, als het maar het doel dient. Moet het een striptekening zijn gebruik die dan. Moet het een video zijn, maak die dan. Een lijst van presentatievormen: Iconografie. Iconen voor de belangrijkste principes. Poster voor de eindgebruikers. Story boards. Interactief met white board. PowerPoint-presentaties. Bijpraat sessies. Treemap. Een ‘doorklikbaar’ model, waarbij in- en uitgezoomd kan worden op een probleem. Het allerbelangrijkste blijft toch dat het model is toegespitst op de toehoorders en stakeholders. Architectuur is voor 50% communiceren. Het is belangrijk om goed na te denken over de te gebruiken modelleringsvormen. ArchiMate wordt wel gezien als een goed vertrekpunt. Het vormt vaak de basis voor de andere modellen. 17
Metamodellen en patronen Als metamodellen om de samenhang tussen technische infrastructuurmodellering en de andere architectuurdomeinen (business, informatie/data, en applicatie) te beschrijven en te bewaken, worden ArchiMate views gebruikt. Daarnaast zijn er OSA (Open Security Architecture) en de aanbevelingen gedaan op het ‘Platform voor Informatiebeveiliging’. Veelgebruikte patronen en patroonbronnen (bijv. OIAm, Service Design Patterns) zijn vooral OIAm en de informatie security patronen van het platform informatiebeveiliging. Algemene opmerkingen Het toepassen van architectuur is nog vooral een ambacht. De associatie van architectuur met ‘kunst’ is een brug te ver. Veel hangt dan ook af van het vakmanschap van de architect, terwijl de visuele beschrijvingsvormen veeleer een instrumentarium vormen, maar niet bepalend zijn voor het eindresultaat. Veel is nog in ontwikkeling en staat nog niet vast. Het is lastig om een goede richtlijn te maken voor een goede communicatie via de modellen. Wel zijn er enkele kenmerken van een goede communicatie te noemen: Achterhaal de interesses van de persoon waarvoor gepresenteerd wordt. Hoe staat deze bekend? Waar is de stakeholder op zoek naar? Waar ligt hij / zij wakker van? Des te hoger in de organisatie des te belangrijker wordt het communicatiedeel. Wat belangrijk wordt geacht zijn tips en de competenties voor een succesvolle architect.
7. Slotopmerkingen rondetafel Het wordt de hoogste tijd voor een merkvrije, organisatievormonafhankelijke architectuurbeschouwing van de technische infrastructuur. Voorkom vendor lock-in en zorg dat oplossingen technologieonafhankelijk worden gepositioneerd in de architectuurplaten. Houd rekening met patterns en leveringsvormen. Borg de regie over de aanbodzijde. De business is in feite ‘accountable’ voor de technische infrastructuur, net zoals van elke andere architectuur. Maar de CIO en de chief architect zijn ‘responsible’. Last but not least dient de eindgebruiker er prettig mee te kunnen werken, ook al zal hij die technische infrastructuur meestel slechts ten dele gewaar zijn. Er zijn dus eenvoudige, duidelijke architectuurviews nodig vanuit de business, vanuit de eindgebruiker, vanuit de chief architect en vanuit de CIO, zodat alle stakeholders vanuit hun eigen wereld weten hoe het fundament in elkaar zit. Om te borgen dat de technische infrastructuur aansluit bij de businessbehoeftes is een precedentieanalyse nodig van kwaliteitseisen, via architectuurprincipes, wellicht via patterns naar implementatievormen. De architectuur voor de technische infrastructuur wordt nog veel belangrijke als alles met alles wordt verbonden: ‘The Internet of Things’.
18
Cruciale vragen die bedrijven en overheidsorganisaties zich moeten stellen om meer bewust te worden van de waarde van de technische infrastructuur zijn: Welk deel van het IT-budget wordt besteed aan de technische infrastructuur (bouw, licenties en beheer)? Sluit de technische infrastructuur daadwerkelijk aan op de bedrijfsbehoeften? Is de infrastructuur de enabler van veranderingen, of staat de infrastructuur die juist in de weg? Heeft de business en de CIO inhoudelijk inzicht in nut en noodzaak van investeringen in de technische infrastructuur? Kunnen die investeringen worden gerelateerd aan bedrijfsdoelen? Of wordt vertrouwd op architecten / specialisten / leveranciers? Is er een duidelijke roadmap voor de ontwikkeling van de technische infrastructuur? Zo ja, wie hebben die opgesteld en wie is daarvoor ‘accountable’? Is er een ‘Letter of Responsibility (LOR)’ getekend ten aanzien van de veiligheid van de technische infrastructuur of wordt er op een andere manier formeel verantwoordelijkheid daarvoor genomen? Is de technische infrastructuur een ‘strategic asset’ om voordeel op de concurrentie te behalen of is het een ‘commodity’? Wordt er op outsourcing van technische infrastructuur gestuurd? Zo ja, wat zijn de criteria om (delen van) de technische infrastructuur te outsourcen? Wordt er al grootschalig gebruik gemaakt van (infrastructuur uit) de Cloud? Zo nee, waarom niet? Zo ja, welke problemen zijn er daarbij? Uit de mondelinge evaluatie aan het einde van deze NAF-rondetafel bleek dat deze brainstorming nuttig was om de gemeenschappelijke opvattingen expliciet de revue te laten passeren. Er is diepgaand gediscussieerd over reële concerns aan de hand van daadwerkelijke praktijkvoorbeelden. Het werd als jammer ervaren dat door de beperkte tijd niet meer diepgang kon worden bereikt. Enkele gemiste onderwerpen: Relatie technische infrastructuur met andere disciplines / verantwoordelijkheden. Kostenbeschouwingen. Security-overwegingen. Succesfactoren voor de infrastructuurarchitect. Organisatie van de architectuurfunctie binnen de architectuur van de technische infrastructuur gezien de vele specialisten op dit terrein. Morele/ethische onafhankelijkheid van de architect. Aan het NAF (de initiatiefnemer van deze rondetafel) wordt geadviseerd om in een volgende sessie enkele onderwerpen nader te laten uitdiepen. Voorts wordt het als cruciaal gezien dat de feedback door de stakeholders op dit verslag wordt geïnventariseerd.
8. Deelnemers Aad Koppenhol (EMC), Aernoud van de Graaff (VMware), Alexander van Holstein (Gemeente Tilburg.nl), Charles Hendriks (Luchthaven Schiphol), Daniel Jumelet (IT2FIT), Debbie Tarenskeen (Hogeschool Arnhem Nijmegen), Ed van der Winden (DoITogether), Edwin Strijland (SVB), Evert van Schooten (Capgemini), Frank Derks (SNS REAAL), Frans Beentjes (SNS REAAL), Hans Spek (Rijkswaterstaat), Harco 19
van Hees (Gemeente Tilburg), Herman Hartman (Capgemini), Immanuël Noorman (PGGM), Jan Hellings (Hogeschool Amsterdam), Jan Schoonderbeek (Architecting.nl), Johan van Teeffelen (Rabobank), Jurre Kesting (Cnox), Marc Berenschot (Universiteit Twente), Marcel Buijs (NCCW), Marco Muishout (StoltNielsen), Marco van Weerden (Hogeschool van Amsterdam), Mark van Leeuwen (Rijkswaterstaat), Matthias Pyck (AE), Michiel van Rijnsoever (Equens), Mike Rodenburg (KLM), Robert Kuijvenhoven (Simac), Roderick Derks (Simac), Rik Willems (Philips), Roland Bijvank (Hogeschool Utrecht), Ron van Workum (DoITogether), Serge Bouwens (Inspearit), Tom van Sante (KPN), Wim de Jong (Rabobank).
20
