De CIO spreekt: Kees Jans, CIO Schiphol Group

Hotze Zijlstra, Daan Rijsenbrij en Paul Laagland, vrijdag 26 september 2008

De CIO is veelal de directe of indirecte opdrachtgever van de digitale architect. Maar heeft de CIO zelf ook een visie op digitale architectuur? En wat vindt hij of zij van het werk en functioneren van de digitale architecten? In deze serie interviews gaan we op zoek naar de antwoorden.

Als CIO van Schiphol Group stelt Kees Jans digitale architectuur centraal bij alle beslissingen die hij neemt en alle vernieuwingen die hij doorvoert. Zonder architectuur is volgens hem innovatie niet mogelijk. “Je moet eraan bouwen om te kunnen veranderen”, zegt hij. Niet eenmalig, maar continu. De samenhang tussen de applicaties, infrastructuur, de door de IT geleverde diensten en de luchthavenprocessen evolueert namelijk voortdurend. Die boodschap moet echter wel worden uitgelegd aan de business.

Waar doorgaans de term ‘digitale architectuur’ wordt gebruikt, spreekt Kees Jans binnen Schiphol van ict-architectuur. “Maar de kans is groot dat dit aansluit bij met wat jullie bedoelen met digitale architectuur.”

Daan: “Wanneer ik naar buiten kijk, dan zie ik fysieke architectuur. Als je praat over de architectuur van ict, zet ik daar om ruzie te voorkomen met fysieke architecten altijd ‘digitaal’ voor. En dat ‘digitale’ omvat in principe bijna alles. Dat zijn de infrastructuur en de applicaties, maar dat zijn ook de informatiestromen en de steeds verder digitaliserende aspecten van de business. Als je ict-architectuur zegt, dan denken velen slechts aan zaken als de topologie van het netwerk. Wat ons betreft gaat het dus veel verder.”
Kees: “Dan denk ik dat onze beelden overeen komen. Bij ons geeft ict-architectuur de samenhang weer: hoe de bedrijfsprocessen van invloed zijn op het applicatielandschap en hoe die vervolgens weer ingrijpen op de infrastructuur. Bij ons is digitale architectuur dus met name het inzicht in de totale samenhang van al die aspecten.”
Om dit te illustreren naar de klanten, heeft Jans een zogeheten ‘Architectuurwijzer’ uitgebracht: een boekje waarin het belang van werken onder architectuur wordt uitgelegd. Ict-architectuur wordt hierin vergeleken met een stadsplan, in het geval van Schiphol de AirportCity. De ict-architectuur wordt gezien als het geheel van luchthavenprocessen, producten en diensten van de ict-organisatie, applicaties en tenslotte de infrastructuur.
Kees: “Of het ook echt begint met de businessprocessen is moeilijk te zeggen, omdat het begin en het einde bij een samenhang niet zo makkelijk zijn aan te geven. Maar de processen zijn wel heel belangrijk. Dat is ook onze boodschap naar de klanten, omdat voor hen de architectuur bij de processen begint. Anders krijg je vanuit de business al heel snel de vraag wat men ermee moet. Als je praat over architectuur wordt immers al snel gedacht dat jij alleen daar vanuit de IT verantwoordelijk voor bent.”
Daan: “Je gebruikt het begrip ict-architectuur dus voor de communicatie naar de businessmanagers?”
Kees: “Ja, maar dat is geen doel op zich. Het gaat erom dat je de business kunt laten zien dat er een samenhang is tussen alles. Dan snappen ze ook dat ze er wat mee te maken hebben en dat een doordachte ict-architectuur van nut is. Maar goed, als het belang vervolgens duidelijk is, dan moet je het ook echt gaan doen; formatieplaatsen gaan regelen en zo. Dat was een aantal jaar geleden nog niet zo vanzelfsprekend. In een mainframe-omgeving bedacht IBM de architectuur en daar deed je het mee. Als de architectuur niet goed was, dan had je een probleem met IBM. Dat is allemaal veranderd, je moet er nu zelf over nadenken. Maar als je daar de ruimte en het geld voor vrij wilt maken, dan moet je aan de partijen die het betalen duidelijk maken wat het nut is voor de business.”

Informatiemanagers


Daan: “Nog niet zo lang geleden was architectuur in grote lijnen vooral een technische aangelegenheid.”
Kees: “Inderdaad. Wanneer ik kijk naar onze informatiemanagers, die vanuit de business nadenken over architectuur, dan denken die vooral in bedrijfsprocessen. Die kijken naar applicaties en systemen, maar met name naar de informatiestromen en de processen. Voor hem of haar is dat waar het begint. Voor iemand die verantwoordelijk is voor de infrastructuur begint daar de ict-architectuur. En vanuit zijn perspectief heeft hij ook gelijk.”
Paul: “Je kunt misschien beter niet spreken van architectuurproces in de zin van een stapsgewijze aanpak; eerst dit doen en vervolgens dat. Of maak je binnen Schiphol wel gebruik van een dergelijke methodiek?”
Kees: “Er zal door de architecten ongetwijfeld een of andere methodiek worden gebruikt, maar er zit uiteindelijk toch niets anders op dan aan alles tegelijk te werken en vast te stellen dat je bepaalde verbanden moet gaan leggen. Begin je bij de infrastructuur, dan kom je er al snel achter dat je te weinig van de processen in kaart hebt gebracht. Begin je bij de processen, dan merk je dat je te weinig weet van de functionaliteit van je applicaties en je informatiestromen.”
Daan: “Werk je ook vanuit bepaalde concepten? Een gemeente maakt bijvoorbeeld de onderverdeling tussen midoffice, frontoffice en backoffice. Of er is bedacht op welke wijze klanten moeten worden geholpen? Dat kan een belangrijke invoer zijn voor je architectuur. Heb jij daar ook voorbeelden van?”
Kees: “Oh ja. Zo hebben wij het begrip ‘self service’. De hele airportindustrie gaat hier steeds meer naartoe. Daarnaast worden steeds meer diensten die je vroeger per definitie op de luchthaven deed tegenwoordig ‘off airport’ uitgevoerd. Een ontwikkeling die samenhangt met self service. Inchecken doen mensen bijvoorbeeld gratis en met veel plezier thuis. De transfers zijn een ander voorbeeld. Dankzij mobiel internet en bellen weet je straks al in de ‘kist’ dat je je aansluiting niet gaat halen en kun je met je mobiele telefoon een andere transfer regelen.”
Daan: “Je bent dus bezig met een verrijking van je businessprocessen en daarvoor heb je een gigantische hoeveelheid informatie nodig en een goede infrastructuur.”
Kees: “Je ziet een verandering in het proces. Transfer-informatie is niet alleen meer nodig als de kist aankomt, omdat de passagiers er dan pas uit komen. Nee, bij de passagiers bestaat de behoefte aan die informatie al in de lucht. Dat betekent dat je je systemen zo moet ontsluiten dat ze mobiel benaderbaar zijn.”
Daan: “De vraag komt van boven en de ‘enabling’ van beneden. Hoe werkt dat bij jullie?”
Kees: “Dat hangt af van het specifieke voorbeeld. Als je kijkt naar het inchecken, dan wordt dat mogelijk gemaakt door de technologie waarover wij en de consumenten de beschikking hebben. Voldoende bandbreedte in dit geval. Wat dat betreft kijkt de business altijd goed mee naar de eventuele nieuwe mogelijkheden. Neem bijvoorbeeld de toepassing van RFID en location based services. De techniek is er nog niet echt, maar nu al denken we na over wat het betekent voor het bedrijfsproces wanneer we precies weten waar de passagier zich bevindt. Maar het is zeker niet alleen maar een push vanuit de IT, het zijn ook de klanten die een bepaalde behoefte hebben.”

Scheiding


Paul: “Om nog even terug te komen op de vraag over het denken vanuit concepten: bij de voorbeelden die jij noemt gaat het vooral om het goed kennen van de business en de technologie om tot nieuwe producten en diensten te komen. Maar je kunt zaken ook vanuit de applicatiestructuur of infrastructuur inrichten en daarvoor bepaalde principes of concepten gebruiken. Frontoffice-backoffice is ook zo’n principe. Je kunt zeggen: laat iedereen maar integraal alles doen, of je kunt het gaan scheiden omdat de frontoffice-mensen heel klantgericht moeten zijn en de backoffice-mensen vooral naar de efficiency het proces moeten kijken.”
Kees: “Je hebt principes in verschillende lagen. Onze biometrie-oplossing is een business-issue. Wij kunnen als een van de weinig luchthavens mensen op basis van hun biometrische kenmerken de grens laten passeren. Dat is de businessvraag. Nu hebben wij in onze architectuur zitten dat de identificatie alleen gebeurt bij het frontoffice, dus daar waar de passagiers zich bevinden. Op die plaats bepalen we dus wie de passagier is. Dat doen we nu met een irisscan, maar wanneer dat straks met een vingerafdruk, gezichtsherkenning of nog iets anders gaat, dan blijft de architectuur gebaseerd op het herkennen van de passagier. Daar hebben we nu als oplossingen irisscan en een Priviumkaart voor. Maar als dat straks een chip in het paspoort in combinatie met een vingerafdruk zou worden, dan halen we de camera weg en zetten we er een paspoortreader en een vingerafdruklezer neer en kunnen we het backoffice helemaal hetzelfde laten. Dat zijn de principes die betrekking hebben op de laag onder de business-concepten. De ontkoppeling maakt ons veel sneller en adaptiever. We bouwen de zaken op zo’n manier dat we snel met de behoeftes van de business kunnen meebewegen.”
Paul: “Zijn er principes die je vanuit de IT, op basis van de kennis die je hebt, tegen de wensen van de business in realiseert?”
Kees: “Een heleboel. Een voorbeeld is het gebruik van standaardpakketten. Soms geeft de business aan behoefte te hebben aan een specifiek pakket van een bepaalde leverancier, waarvan wij weten dat er na de implementatie nieuwe behoeftes gaan komen die maken dat de boel gaat vastlopen. Standaardisatie is een klassiek voorbeeld van een situatie waarbij je nooit een honderd procent fit creëert en die voor de individuele gebruiker bovendien soms duurder is. Maar op de lange termijn moet je wel kunnen aantonen dat het voor het bedrijf het beste en het goedkoopste is.”

Business case


Paul: “Even nog over de relatie met de business. Je krijgt tegenwoordig haast geen project meer van de grond zonder een goede businesscase. Geldt dat ook voor architectuur? Heb je een businesscase voor ict-architectuur?”
Kees: “Die Architectuurwijzer is geboren, omdat we het met een businesscase in 2002 gewoon niet rond hebben gekregen. We zijn begonnen met na te denken over hoe we het werken onder architectuur binnen het bedrijf konden inpassen. Het werd te groot en er waren te veel mensen op verschillende vlakken bezig met hun eigen oplossingen, waarvan we niet meer konden garanderen dat ze dezelfde kant op gingen. Er was dus een besef dat we daar iets aan moesten doen, al noemde je dat in die tijd misschien nog geen architectuur. We hebben dus echt een businesscase gemaakt. Het idee was dat we de vooronderzoeken, dus lead time in projecten, aantoonbaar konden verkorten, omdat je al precies hebt uitgestippeld waar het geheel in moest passen. Dat betekende een besparing van vijftig procent op de vooronderzoeken en dertig procent op de totale kosten. We hadden berekend dat we daar drie of vier mensen voor nodig hadden. Maar vanuit de board kwam men vervolgens met het voorstel eens te beginnen met één, om na een jaar nog eens te kijken hoe we er voor zouden staan. Mijn conclusie was: dit gaat dus niet vliegen. Onze benadering was dus fout. Als je begint met een financieel verhaal, dan wordt er ook financieel naar gekeken. Toen hebben we besloten het anders voor het voetlicht te brengen. Door aan te tonen dat dit gewoon móet en dat het geld kost.”
Paul: “Heb je van tevoren het geld uitgegeven en mensen aangenomen of heb je het eerst beargumenteerd en de mensen pas later aangenomen?”
Kees: “We hebben het plaatje erbij gehaald en gewoon gezegd: dit is wat er gebeurt: ‘We doen veel meer dan vroeger met IT, het wordt steeds belangrijker, al die processen maken van elkaars informatie gebruik. Dus wij moeten die samenhang veel beter bewaren en dat ziet u in dit plaatje, het hangt allemaal met elkaar samen’ De business verandert de bedrijfsprocessen. Willen wij die verandering aankunnen, dan hebben we overzicht nodig, moeten we de samenhang vastleggen. En omdat we daar tijd voor nodig hebben, is dat opgenomen in ons budget. Het zit er automatisch in en is dus geen project, net zomin als een secretariaat een project is. Daar heb je doorgaans ook geen discussie over.”

Competenties


Paul: “Wie stelt binnen de Schiphol Group de digitale architectuur op. Wat voor soort mensen betreft het en wat zijn hun competenties?”
Kees: “We hebben een afdeling binnen het concern die we concern-informatiemanagement noemen. Deze bestaat uit informatiemanagers en architecten. Hierbij hebben onze acht informatiemanagers de verantwoordelijkheid om te komen tot informatieplannnen. Dat wil zeggen dat de ontwikkelingen binnen de business in verband worden gebracht met de ontwikkelingen in de IT. Vervolgens wordt geschetst hoe we al deze dingen samen gaan brengen. Al deze afzonderlijke informatieplannen hangen onder het centrale masterplan IT, waarin wordt bepaald wat er dit jaar gebeurt en wat het volgende jaar. Een van de taken van de architecten is te bekijken wat er op basis van zo’n informatieplan moet gebeuren op het gebied van de architectuur. Dan worden onder meer de gemeenschappelijke zaken eruit gehaald, zoals de location based services, maar ook dingen als activity monitoring. Er zitten veelal op verschillende plekken componenten die hierop aansluiten en daaronder bouwen we de wat meer technische architectuur. Hiermee heb je de eerste drie lagen gehad. Daar komt dan later nog de de infrastructuur onder.”
De specifieke invulling van die infrastructuur vindt Kees Jans niet zozeer een taak voor de architect. Maar de beheerders van de infrastructuur moeten wel goed duidelijk maken wat men de komende jaren verwacht. “Bijvoorbeeld als het gaat om bandbreedte en redundancy. Vroeger kon een systeem er nog wel eens een kwartiertje uit liggen, maar als we straks vijf minuten uit de lucht zijn, wordt er ook vijf minuten niet gevlogen en hebben de airlines misschien al een miljoen schade. Dan is een investering van miljoenen om je beschikbaarheid te garanderen absoluut te valideren. Dat soort principes moet binnen de onderste laag goed duidelijk zijn. Laat de beheerder dan vervolgens regelen hoe die beschikbaarheid zo hoog mogelijk kan worden gehouden. Dat vindt hij nog leuk ook.”
Paul: “Wat is dan het verschil tussen wat de informatiemanager doet en wat de architect?”
Kees: “De informatiemanager is beter in staat om met de business te praten over het hoe en waarom van het proces. Vervolgens zegt de architect wat dat allemaal betekent voor de techniek. Voor mij is de informatiemanager de persoon die door de business als collega moet worden gezien en al de businessinformatie vertaalt in een informatieplan.”
Paul: “Je hoort vaak zeggen dat architecten beter moeten leren luisteren naar hun klanten, maar als ik jou begrijp kun je dat beter vergeten en moeten ze vooral analytisch blijven nadenken.”
Kees (lachend): “Van technische mensen, zoals architecten, mag je best verwachten dat ze zich uitdrukken in technische termen. Maar als je een informatiemanager tegenkomt op de gang, dan moet niet je eerste gedachte zijn dat deze vast wel op de IT-afdeling zal werken. Dat moet duidelijk iemand van de business zijn.”

Labeltjes


Daan: “Ik begrijp helemaal wat je zegt, maar de labeltjes die je erop plakt zijn natuurlijk subjectief. Want wie bij jou de informatiemanager is, is elders misschien de business-architect.”
Kees: “Het heet bij ons officieel zelfs business-informatiemanager.”
Paul: “Ik wil graag nog even de parallel doortrekken met de fysieke wereld. De fysieke architect is veelal de eerste waar je als opdrachtgever mee praat. En die uiteindelijk je behoefte kan herformuleren en vertalen naar een gebouw waar jij je gewenste functionaliteit in kwijt kunt. En die architect schakelt vervolgens weer door met anderen. Is het dus niet zo dat de business-informatiemanager de eigenlijke digitale architect is en de mensen die je nu architect noemt de ontwerpspecialisten zijn?”
Kees: “Als je de vergelijking maakt met de fysieke wereld, dan ben ik dat wel met je eens. Maar misschien is iemand die wij architect noemen daar meer iemand van ruimtelijke ordening: iemand die bepaalt welke functionaliteit je waar moet onderbrengen.”
Paul: “De business-informatiemanager is dus eigenlijk een bedrijfsarchitect, al noem je hem niet zo.”
Kees: “Klopt.”

Eigenaarschap


Als CIO is Kees Jans eigenaar van de architectuur en wordt in die hoedanigheid naar eigen zeggen nooit overruled. Maar dat wil niet zeggen dat de architectuur als zodanig een statisch gegeven is. Wanneer er op basis van een nieuwe behoefte of nieuwe inzichten vanuit de business andere eisen worden gesteld, dan kan de CIO als eigenaar van de architectuur tot de conclusie komen dat deze moet worden aangepast. In die zin is binnen Schiphol Group sprake van een wisselwerking.
Paul: “Je kunt overigens praten over het ontwerp van de diensten die IT levert, maar je kunt ook praten over het ontwerp van het bedrijf zelf. Internetbedrijven zijn in feite digitale architectuur. De vraag is wanneer je, vanuit de principes die wij vanuit het vak neerzetten, binnen de bedrijfsvoering zodanig naar voren komt dat je ook verantwoordelijk wordt voor het bedrijf zelf.”
Kees: “Bij bedrijven die die kant opgaan, neem een internetbedrijf, dan moet je ‘m wat mij betreft omdraaien. Daar moet de business veel meer verstand krijgen van het CIO-schap in plaats van andersom. Als je mij dan ook vraagt of de CIO over vijf jaar overbodig is, dan is het antwoord ‘ja’ Omdat tegen die tijd de business het zelf moet doen. Transavia is wat dat betreft een goed voorbeeld, die zeggen gewoon: ‘wij zijn een internetbedrijf’ Dat betekent dus niet dat ik een CIO in de board moet hebben. Nee, dat betekent dat ik in de board allemaal mensen moet hebben met kennis op het CIO-vlak.”
Paul: “Je bent uiteindelijk de opdrachtgever. In welke mate stuur jij rechtstreeks je architect aan?”
Kees: “Bij mij valt het onder de afdeling concern-informatiemanagement en dat is de opdrachtgever. Het is belangrijk dat deze mensen zich hier ook verantwoordelijk voor voelen.”
Paul: “Laat ik het anders vragen: heb jij rechtstreeks werkoverleg met architecten?”
Kees: “Ik stuur ze zogezegd niet aan, maar ik heb wel overleg met de manager en die vertelt me precies wat hij aan het doen is. En als ze bezig zijn met door de architecten opgestelde architectuurprincipes, dan hebben we hier met het hele MT overleg over. De club architecten, of de vertegenwoordiger daarvan, komt dan vertellen waarom ze voor bepaalde principes hebben gekozen. Momenteel hanteren we er elf, maar dat verandert nog wel eens. Als een principe vanzelfsprekend is geworden kan deze vervallen, maar nieuwe inzichten die belangrijk zijn kunnen worden toegevoegd.”
Paul: “Zijn er zaken waar je tijdens zo’n MT-bijeenkomst extra op let? Welke vragen stel je bijvoorbeeld?”
Kees: “Architectuurprincipes moeten worden begrepen door de business. Als ik op het hoofd van bijvoorbeeld de HR-manager een groot vraagteken zie, dan zorgen we bijvoorbeeld om een extra toelichting. Een ander criterium is: spreken de principes mij zelf aan? Wat dat betreft snapt de manager best wel dat ik uiteindelijk verantwoordelijk ben.”
Paul: “Hoe is de governance geregeld?”
Kees: “Ieder project heeft een architect die verantwoordelijk is voor de toepassing van de architectuurprincipes binnen het project. De architect is lid van het projectteam en staat dus niet op afstand. De vijf architecten, op een totale IT-afdeling van 135 mensen, zijn overigens allen verantwoordelijk voor de integrale architectuur binnen de afzonderlijke projecten. Indien mensen onzeker zijn over een bepaalde aanpak, dan zullen ze die veelal voorleggen aan hun collega’s.” Soms wordt volgens de CIO zelfs contact gezocht met collega-architecten buiten het bedrijf.

Overdraagbaar


Daan: “Hoe overdraagbaar is de digitale architectuur? Kun je je plaatje en de principes bijvoorbeeld ook gebruiken op Charles de Gaulle of Heathrow?”
Kees: “Naar de business toe kun je er negen of tien van de elf wel gebruiken op andere luchthavens. Maar sommige zijn gebaseerd op een strategische richting waarvoor we hebben gekozen. Bijvoorbeeld door alles zo veel mogelijk op basis van services te bouwen. En dat zou in Parijs wel eens heel anders kunnen zijn. Bovendien is de wet- en regelgeving van invloed op het bedrijfsproces en daarmee indirect op de architectuur. In Nederland moet je wettelijk andere partijen in staat stellen om hier het afhandelingsproces te doen, terwijl het in Frankfurt gewoon de airport is die het doet. Hier betekent dit dat deze partijen hun eigen systemen mogen meenemen en dat wij koppelvlakken moeten maken om met diverse afhandelingssystemen te kunnen communiceren.”
Daan: “Wat is de relatie tussen innovatie en architectuur?”
Kees: “Zonder goede architectuur is innovatie niet mogelijk. Je werkt aan een goed inzicht in de samenhang, zodat je weet wat je raakt als je iets nieuws wilt toevoegen. Wanneer je zoals wij als innovatieve luchthaven bekend wilt staan, die een aantrekkelijke vestigingsplaats is voor airlines en afhandelaren, was het in het verleden al voldoende als je een goede terminal had. Door de afhankelijkheid en de toenemende druk op kosten, want door de stijgende brandstofprijzen moet alles inmiddels veel efficiënter, moet je tegenwoordig ook een aantrekkelijke vestigingsplaats zijn op het gebied van informatievoorziening. Dat is essentieel. Om die reden moet informatie op Schiphol dus eenvoudig en goed ter beschikking gesteld kunnen worden. Ons service-idee sluit hier heel goed op aan. Als je door middel van een catalogus kunt overleggen welke informatie via welke webservices zoal beschikbaar is, en van welke partijen deze afkomstig is, dan helpt dat toch enorm. Partijen in de sector kunnen daar slim gebruik van maken. Neem bijvoorbeeld informatie over waar de passagier zich bevindt. Als deze drie uur van tevoren nog voorbij Arnhem in de file staat, dan kan zijn stoel duur worden verkocht aan iemand op de wachtlijst. Maar als iemand zich al via zijn Previum-pas heeft bekendgemaakt bij de parkeerplaats, dan weet men dat hij er is. De airline kan op die stoel dan al een kruisje zetten, want deze klant komt zeker. Sectorpartijen zouden van een dergelijke informatieservice sterk kunnen profiteren.”
Daan: “De essentie van SOA is dat je met een basis-set aan legoblokjes, volgens bepaalde granulariteitsprincipes ontworpen, van alles kunt gaat opbouwen. Voor veel bedrijven betekent het een gigantische inspanning om zover te komen.”
Kees: “Klopt, maar als je het vanuit de sector bekijkt wordt het juist weer een stukje makkelijker. Vanuit het bedrijf zit je vaak vanuit verschillende bedrijfsprocessen naar dezelfde informatie te kijken en vaak matcht dat net niet, omdat er verschillende definities worden gebruikt. Terwijl in de sector verschillende bedrijven participeren in één proces. Dan heb je het dus in feite wel over de zelfde dingen, alleen zit deze informatie in de verkeerde systemen. Maar de definities en de herbruikbaarheid van de informatie zijn geen issue.”
Paul: “Is er iemand die waakt over de architectuur van de keten? Is er overleg tussen de architecten van al deze onafhankelijke partijen?”
Kees: “Als het gaat om het initiatief van die services, zitten we concreet aan tafel met de belangrijkste partijen. In die zin is het belang van een ketenarchitectuur wel onderkend. Allereerst is er overleg op managementniveau en daaronder ook op architectenniveau. Een voorbeeld van dat samenwerkingsverband is het project ‘collaborative decision making’, waarbij we samen naar de informatie kijken. Op die manier komen we vervolgens tot sectorbrede architectuurprincipes. Daar is ook echt door alle partijen voor getekend en ik heb iemand in mijn MT die daarvoor verantwoordelijk is.”

Kopiëren


Ook tussen luchthavens onderling komt het overleg op gang. Met Parijs bijvoorbeeld, die dezelfde grote klant bedient, zijn al afspraken gemaakt over de toepassing van RFID. Bovendien ‘verkoopt’ Schiphol zijn technologie aan andere airports. Niet aan de kleintjes, zoals Rotterdam, want dat matcht niet vanwege de uiteenlopende mate van complexiteit en schaalgrootte, maar bijvoorbeeld in New York en Brisbane worden grote delen van het proces al door Schiphol uitgevoerd.
Kees: “Daarom is dat AirportCity-concept ook zo belangrijk voor ons. De kennis van de informatieprocessen en de daarbij horende systemen gebruiken we voor onze internationaal expansie. Dat was ook een van de achterliggende redenen van de privatisering. In het buitenland is het makkelijker wanneer je een bedrijf bent, dan dat je gepercipieerd wordt als een logge overheidsinstelling die daar even de airport komt overnemen. Maar goed, das war einmal.”
Daan: “Op welk architectuurconcept hier op Schiphol ben je echt trots?”
Kees: “De mate waarin we flexibel kunnen inspelen op de behoeften van de business. Stel dat niet de iris-, maar de vingerscan ineens de standaard wordt, dan zou de business in paniek kunnen raken, omdat wij hier alles op de iris hebben ingesteld. Maar wanneer ze dan bij ons komen, dan zeggen we: ‘jammer voor die tweehonderd dure camera’s, die moeten we vervangen door veel goedkopere vingerscanners en je security-niveau gaat omlaag, maar wat ons betreft is het geen groot probleem.’ Vroeger was dit precies omgekeerd.”

Hotze Zijlstra (Journalist), CIO Magazine
Daan Rijsenbrij (Interviewer), Via Nova Architectura, daan@rijsenbrij.eu
Paul Laagland (Interviewer), Via Nova Architectura, Paul.laagland@equaterra.com

[PDF]

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Sponsoren

Sessies

15-02: GIA sessie over digitale transformatiespel meer...

Advertenties

Je kunt hier adverteren

© 2018   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden