Rondetafelconferentie ‘Architectuur’ met enkele CIO’s uit de overheid. Den Haag, 30 september 2009.
Aanwezig:
Adriaan Blankenstein (IVENT), Hans Blokpoel (IND), Henk Bothof (ProRail), Lenny van Beek (LNV), Marjolein ten Kroode (SVB), Michel Bouten (ICTU), Richard van Breukelen (RWS) en Piet de Kam (HEC), Paul Laagland (EquaTerra), Daan Rijsenbrij (Rijsenbrij Digitecture).
Verslaglegging:
Hotze Zijlstra, hoofdredacteur CIO-Magazine.
Inleiding De noodzaak van digitale architectuur binnen de overheid wordt steeds nadrukkelijker onderkend. ICT Uitvoeringsorganisatie (ICTU) is druk bezig met de derde versie van NORA, een referentiearchitectuur voor de gehele publieke sector. Daarnaast wordt op specifiekere niveaus binnen de overheid druk gewerkt aan afgeleide referentiearchitecturen zoals MARIJ (voor de Rijksoverheid), PETRA (voor de provincies), GEMMA (voor de gemeentes) en de WILMA (voor de waterschappen). Dit zijn allemaal referentiearchitecturen, oftewel een soort sjablonen waaruit de individuele architecturen voor de verschillende overheidsorganisaties kunnen worden afgeleid. Geen architectuur zonder bekwame architecten. Mede door de rapporten van de Algemene Rekenkamer worden bij steeds meer overheidsorganisaties CIO’s aangesteld. In deze dynamische tijd die vraagt om lagere complexiteit, grotere adaptiviteit, hogere security, legacy-ontmanteling en snellere time-to-market voor overheidsproducten en -diensten, hebben veel CIO’s als rechterhand een Chief Architect aangesteld om richting te helpen geven. Wat is de juiste taakverdeling tussen de CIO en zijn Chief Architect? Het valt op dat bij verschillende overheidsorganisaties langs verschillende aanvliegroutes wordt getracht te komen tot een meer eenvoudige informatievoorziening. Zo is de Belastingdienst als onderdeel van haar architectuurprogramma bezig geweest met een groot complexiteitsreductieprogramma, UWV probeert door kanteling architectureel de uitvoering van de wetten en de bedrijfsprocessen te ontkoppelen en IND tracht een systematische splitsing van de ‘know’ en de ‘flow’ te bewerkstelligen. Alle drie met hetzelfde doel: complexiteitsverlaging en adaptiviteitsverhoging. Kortom, hoogste tijd om in een rondetafelconferentie tussen CIO’s in de overheid eens open te discussiëren over waar architectuur nu echt voor is bedoeld en wat er met architectuur kan worden bereikt. Het is belangrijk om met elkaar te spreken over de succesvoorwaarden voor architectuur en de verschillende gebruiksdoelen. Onderstaande gedachtenuitwisseling werd gefaciliteerd door twee ervaren architecten, Paul Laagland en Daan Rijsenbrij, die afgelopen jaar diepgaand een groot aantal CIO’s in de private sector hebben geïnterviewd over hoe zij denken over architectuur en hoe zij architectuur inzetten in hun handelen.
www.via-nova-architectura.org
januari 2010
1
Toelichting Daan Rijsenbrij: “Als je spreekt over architectuur, dan blijkt iedereen zijn eigen terminologie en zijn eigen beelden te hebben. Bij architectuur kunnen een aantal hoofdrolspelers worden onderscheiden. Allereerst is er de ‘vraagzijde‘. Hopelijk komt de vraag vanuit de klant, vanuit een businessmanager. De klant en de architect dienen een vertrouwensrelatie te hebben, vandaar dat ze elkaar in het plaatje aankijken. Achter de architect staat een engineer. Die analyseert of het gevraagde maakbaar is. Pas daarna, geheel rechts, staat de bouwer. Een eventuele pakketleverancier of een back office van een (outsourcing)provider zou nog verder naar rechts dienen te worden geplaatst.” Wat we volgens Rijsenbrij bij veel projecten zien, is dat de bouwer direct met de businessmanager (de vraagkant) spreekt, waarbij de architect wordt overgeslagen. Dit is volgens hem één van de belangrijkste redenen waarom op dit moment nog vaak de verkeerde zaken worden gebouwd. “Als je gelooft in de functiescheidingen van bovenstaand plaatje, geloof je tevens in het feit dat er drie soorten documentatie horen te zijn. Ten eerste de documentatie van de architect voor de businessmanager, ten tweede de documentatie die architecten onderling gebruiken of met hun engineer en ten derde de documentatie naar de bouwer toe. Elke soort heeft zijn eigen bedoeling, zijn eigen moeilijkheidsgraad en zijn eigen vormgeving. Ik zie nog te vaak dat moeilijke diagrammen die architecten onderling gebruiken, ten onrechte ook worden getoond aan de businessmanager. Het is daarom ook niet vreemd dat architectuur vaak niet zo populair is bij de business.”
www.via-nova-architectura.org
januari 2010
2
Toelichting Daan Rijsenbrij: ”Het tweede plaatje zoomt in op de relatie tussen de architect en de engineer. Het ligt in de aard van de architect om iets uitdagends te (willen) maken. Dat zien wij ook bij fysieke architecten. Het is aan de engineer om te kijken of het gevraagde inderdaad maakbaar is. Het (digitale) bouwwerk moet stevig zijn. Tevens toon ik dit plaatje om aan te geven dat er nog steeds een machtsstrijd gaande is tussen de architect en de engineer over de onderlinge positionering in een onderneming of overheidsinstelling.” “Veel huidige engineers noemen zich architect omdat dat meer cachet geeft. Terwijl engineer een even cruciale functie is als architect, doch met een totaal andere instelling. Het is belangrijk om deze twee bloedgroepen, die even belangrijk zijn, expliciet te (onder)scheiden. Je hebt mensen die tekenen en doen aan vormgeving, en je hebt mensen die rekenen. Dat laatste zijn de engineers.” “Ik kwam laatst bij een groot bedrijf, waar een topengineer was gepromoveerd tot architect. De salarisrangen van engineers liepen namelijk niet zo hoog dat ze hem binnen konden houden. Jammer, want die engineer is als gezegd net zo belangrijk als die architect. Je kunt wel in een leuk ontworpen auto zitten, maar als de motor niet naar behoren functioneert, heb je mooi pech gehad.”
www.via-nova-architectura.org
januari 2010
3
Toelichting Daan Rijsenbrij: ”De architect spreekt dus met de ‘engineer‘ of de ‘IT-architect‘ zoals sommigen hem of haar ook wel noemen. Aan de rechterkant staan de bouwer en de beheerder, die voeren uit. Aan de linkerkant heb je deskundigen als bedrijfsstrategen en businessanalisten, dat zijn echt andere beroepen met andere vaardigheden dan de architect. Ik zie echter nog teveel architecten die denken overal verstand van te hebben en denken dat ze de hele business aankunnen. Dergelijke architecten willen bijna op de plaats van de CEO gaan zitten.” “Het is heel belangrijk dat architecten weten wat hun rol is. Een echte architect hoeft zelfs geen diepgaande materiedeskundigheid te bezitten. Hij of zij moet goed kunnen luisteren en formuleren. De bedrijfskennis zit bij de businessstrategen en de businessanalisten.”
STELLING 1: Er hoort een architect tussen de opdrachtgever en de bouwer (project- of programmamanager) van een IT-intensief verandertraject.
Toelichting Daan Rijsenbrij: “Op grond van mijn observaties binnen de overheid en de strekking van de rapporten van de Algemene Rekenkamer, wordt de functiescheiding tussen architect en bouwer nog nauwelijks erkend. Het lijkt af en toe wel of Sylvia Roelofs – directeur van ICT~Office – op schoot bij de minister wil zitten. Volgens mij zou de minister zich moeten laten influisteren door een onafhankelijke, onpartijdige architect. ICT~Office vertegenwoordigt immers slechts de bouwers, de aanbodzijde dus. De ministers, de SG en de directeuren vormen de vraagkant.” Richard van Breukelen: “Ik heb een aanvulling op de situatieschets. Wat je ook ziet is dat veel mensen op de stoel van Sylvia Roelofs willen gaan zitten: opdrachtgevers die nadenken
www.via-nova-architectura.org
januari 2010
4
over IT-oplossingen in plaats van het goed definiëren van hun vraag. Dat is ook een deel van het probleem dat we te managen hebben.” Daan Rijsenbrij: “Ik draag Sylvia een warm hart toe. Ik begrijp dat ze opkomt voor haar leden, maar het gaat om de plaats die je inneemt in het eerste plaatje. De leden die zij vertegenwoordigt zijn voor het grootste gedeelte gewoon de bouwers. Schoenmaker houd je bij je leest!” Richard van Breukelen: “Het probleem is volgens mij fundamenteler. Wanneer je als opdrachtgever niet weet wat je rol is, wat je bij veel nieuw aangestelde CIO’s ziet, dan ga je je bezig houden met IT-oplossingen in plaats van met het bedenken van wat ze nu eigenlijk vragen. Daar kan een architect wel aan bijdragen, maar dat kan pas als men beseft wat nu eigenlijk de eigen verantwoordelijkheid is die men als opdrachtgever heeft. Die verantwoordelijkheid is niet het oplossen van een vraagstuk in het bedrijf door alleen een pakket of technologie te kiezen. In het verbeteren van die rolverdeling is nog heel veel werk te doen. Onderdeel daarvan is het neerzetten van architecturen, waarbij het draait om de vraag wat je nodig hebt om een goeie businessarchitectuur te kunnen maken. En als je een goeie businessarchitectuur hebt, kun je ook een goede domeinarchitectuur maken en dan heb je ook een goed referentiekader waarin je goede plannen kan toetsen, zodat ze uiteindelijk ook inpasbaar zijn.” Paul Laagland: “Dan zeg je dus dat het niet goed functioneren van architecten eerder de schuld is van de opdrachtgever dan van de kwaliteit van de architect.” Richard van Breukelen: “Ik praat niet over schuld. Het functioneert pas als er een keten is en als men overal binnen die keten beseft wat zijn of haar rol is.” Henk Bothof: “Ik ben het eigenlijk niet eens met de stelling. Ik ga ervan uit dat de opdrachtgever onderkent dat hij een belang heeft bij de architectuur. Architectuur is evenwel geen doel op zich en moet altijd in het belang van de business staan. Ik vind dat de opdrachtgever zelf goed moet weten en begrijpen wat hem aangeboden wordt. Als je daar een architect tussen zet, gaat die architect keuzes maken die eigenlijk de business zou moeten maken.” “Binnen de kaders die door de architectuur zijn geschetst, moet het gesprek plaatsvinden met de opdrachtnemer. De architect moet daarbij zitten als een soort bewaker van het gedachtegoed en de richting. De architect kan dan waarschuwen als er in het belang van de doorlooptijd of de snelheid ergens een ‘schuld’ wordt gerealiseerd binnen de architectuur, bijvoorbeeld omdat er een kort-door-de-bocht-oplossing wordt gerealiseerd. Een schuld die later zal moeten worden ingelost. Maar hij gaat er niet tussenin zitten, want in zo‘n geval hoor ik namelijk niet van de bouwer of de architect wat de alternatieven zijn.” Daan Rijsenbrij: “Ik zie vaak dat een opdrachtgever wel degelijk weet wat hij of zij wil. Hij of zij kan het alleen niet helder genoeg formuleren. En dan kun je een architect gebruiken om je vraag duidelijker te stellen en om te kijken of je vraag ook maakbaar is. Voorts kan een architect inspireren. Een goede architect is als het ware de regisseur van jouw beeldvormingsproces.” Henk Bothof: “Dat kan ik me voorstellen. Maar dan nog vind ik de stelling fout wanneer je zegt dat de architect er echt tussen zit.” Piet de Kam: “Ik ben het ook niet met de stelling eens. Mijn ervaring is dat je de architect moet laten meewerken aan de kant van de opdrachtgever. Ik probeer dan als opdrachtgever de wensen vanuit mijn bedrijfsdoelstellingen zodanig duidelijk te maken, dat we precies weten waar we het gemeenschappelijk over eens zijn. Die architect moet daaraan zijn medewerking verlenen. Ik wil bijvoorbeeld dat hij het getoetst heeft aan referentiearchitecturen, maar ook dat hij kan mee-adviseren als toch gekozen wordt voor een korte-termijnoplossing. Hij staat voor mij aan de kant van de opdrachtgever en zit dus niet tussen de opdrachtgever en de bouwer. Althans, zolang het gaat om de bedrijfsarchitectuur. Als het gaat om de architectuur van de IT, kan ik me wel een architect tussen opdrachtgever en bouwer voorstellen.” Adriaan Blankenstein: “Als business ben je eigenaar van hetgeen waarvoor je hebt gekozen. Daar begint voor mij ook in de digitale wereld het architectuurbegrip. Het gaat er daarbij allereerst om wat de businessarchitectuur en wat de procesarchitectuur is. Pas heel veel later
www.via-nova-architectura.org
januari 2010
5
kom je ook bij andere soorten architecten en engineers terecht. Het is dus wel belangrijk om te kijken welk type architect je inschakelt.” “Ik woon in een jaren-dertighuis dat ik heb verbouwd met de hulp van een architect. Ik had hiervoor twee soorten architecten gevraagd. Elk met een eigen smaak, stijl en geloof. De een wilde mijn huis verbouwen met staal en glas, de ander stelde voor het in de stijl van het huis te doen. Waar je in de digitale wereld voor kiest hangt af van de manier waarop je als businesseigenaar wilt omgaan met je business en hoe je dat vertaalt naar een veranderproces, dat later zijn beslag moet krijgen in nieuwe technologie. De vraag is daarbij eerder hoe de businesseigenaar omgaat met de architect, dan hoe de architect omgaat met de businesseigenaar. Ik ga namelijk uit van een solide eigenaarschap met een eigen wil en verstand van zaken.” Hans Blokpoel: “Klopt. Ik ben het fundamenteel oneens met de stelling dat de architect er tussen zou kunnen staan, omdat de architect daarmee impliciet keuzes over geld, doorlooptijd en andere zaken zou moeten maken. Volgens mij is hij daar niet voor. Volgens mij kán hij er niet eens tussen staan. Er zullen heel misschien gevallen zijn waarbij de stelling wel waar zou kunnen zijn, met dien verstande dat de architect nooit over het geld mag gaan. Maar in 99 procent van de gevallen is de stelling niet waar.” “Ik vind bovendien dat het begrip architect zo breed is, dat we eindeloos langs elkaar heen kunnen praten. Zelfs de mensen die de titel voeren weten vaak niet eens wat ze precies doen. Daar zit nog onder dat je eerst moet weten wat je beleidskeuzes zijn voordat je überhaupt kunt zeggen wat je rolopvatting is. IND heeft er bijvoorbeeld voor gekozen om voor een aantal oplossingen te zeggen: hier wordt niet de vraag gearticuleerd, maar er wordt simpelweg gekozen uit het bestaande aanbod. Neem het terrein van de infrastructuur, waarbij de businesskant niet eens met architecten mág gaan praten, maar men bij wijze van spreken moet gaan shoppen in de supermarkt. Vervolgens krijg je het assembleren van legoblokjes. In zo‘n geval heb je wellicht wat aan een assembleer-architect, maar als deze denkt dat hij iets anders kan doen, dan begrijpt hij het niet en heeft hij dus geen rol.” “Je moet vooraf dit soort keuzes maken en goed kijken naar de business- en de beleidskeuzes ten aanzien van specifieke oplossingen. Heb je al gekozen voor standaard dingen, dan is een architect op assemblageniveau interessant, maar niet in het gesprek met de opdrachtgever.” Piet de Kam: “Ik herken het beeld, maar als ik echt naar de opdrachtgever kijk, dus naar de businesskant, dan kijk ik tevens naar een businessarchitect: iemand die verdomd goed weet hoe processen van dienstverlening en handhaving moeten worden ingericht. Als ik op het tweede niveau kom, dus op het niveau van advies over producten, dan kies ik een andere architect. Als je voor de inschakeling van het type architect het onderscheid hanteert tussen functioneel en technisch, kom je er wel uit. Maar doordat architectuur veelal geheel vanuit de ict-wereld wordt benaderd, krijg je als opdrachtgever soms een verkeerde architect voor het vraagstuk waar je mee zit. Dan krijg je die tekeningen en grafieken waar je niet veel mee kunt.” “Het probleem is dat dit historisch zo gegroeid is. We zien aan de overheidskant dat de businessarchitecten onvoldoende geschoold zijn en dus onvoldoende vanuit de bedrijfskundige en bestuurskundige aard naar de processen van dienstverlening en handhaving kijken. Daar begrijpen ze soms te weinig van. Als je als opdrachtgever weet wat je wilt, kun je vervolgens een ander type architect inschakelen voor de engineering. Die buigt zich over de infrastructuur, de te gebruiken producten en de samenhang. Dat is een ander type architect. Omdat we de typen architecten niet systematisch onderscheiden, is er zo‘n enorme spraakverwarring. Ook de adviesbureaus maken onvoldoende onderscheid in het type architect dat zij inzetten.” Richard van Breukelen: “Je hebt twee niveaus van samenhang. Businessarchitecten moeten de samenhang tussen de businessprocessen scherp in de gaten houden, want binnen een wat complexere organisatie is de business veelal de voortrekker. Vanuit het doel dat de business wil bereiken, gedraagt deze zich begrijpelijkerwijs alsof men de volledige vrijheid heeft binnen het eigen domein. De rol van de businessarchitect is ervoor te waarschuwen dat wanneer je in het businessdomein wat gaat veranderen, dit effecten heeft op een andere businessomgeving. Dat moet dan worden mee-georganiseerd. De businesseigenaar is er verantwoordelijk voor om
www.via-nova-architectura.org
januari 2010
6
dat te regelen en die consequenties te overwegen voordat men wat gaan doen. Daarna kom je op het tweede niveau. Passen onze wensen vanuit technisch oogpunt binnen de infrastructuren die we al hebben en binnen het bestaande applicatielandschap? Dat is óók een complex vraagstuk, maar een IT-inhoudelijk vraagstuk. Het andere is een business-inhoudelijk vraagstuk.” “Er zijn geen veranderingen binnen de overheid die niet IT-intensief zijn, net zoals er geen medicijnen bestaan zonder bijwerkingen. Overigens heb je in beide gevallen toetsing nodig van de businessarchitect aan de voorkant, en van de IT-architect aan de achterkant. En dat moet je dan wel als een separate stap organiseren. Want je komt pas aan de tweede stap toe, als je inderdaad hebt bedacht wat je aan de voorkant wilde bereiken.” Daan Rijsenbrij: “Waar zitten die businessarchitecten eigenlijk? Bij sommige ondernemingen zie ik dat de businessarchitecten los staan van de CIO en er ook nauwelijks enige relatie mee hebben. Bij andere bedrijven zie ik dat de businessarchitecten in de centrale club zitten. Horen ze centraal bij de CIO of horen ze in de business units?” Michel Bouten: “Waar die architect zit maakt niet uit, zolang de vraag maar helder is.” Henk Bothof: “Een architect is vooral een adviseur van en voor de business. Hij heeft wat mij betreft geen eigen mandaat. Waar iemand gepositioneerd is, is inderdaad niet zo belangrijk. Het is wel aantrekkelijk om een pool te hebben van architecten, waarin die architecten onderling ook met elkaar praten. Dus de technische architecten moeten kunnen praten met de businessarchitecten en uitgeleend kunnen worden aan de business.” Richard van Breukelen: “Ik kies voor een pool van zowel businessarchitecten als IT- of domeinarchitecten. De prioritering waarmee de businessarchitecten zich bezig houden, komt bij mij vandaan en de toparchitect zit in mijn staf. En toch heb je er voor wat betreft de beeldvorming last van dat ze zijn ondergebracht in een pool die is afgeleid van het IT-bedrijf. Het is van groot belang dat de business- en de IT-architect heel dicht met elkaar praten, want de businessarchitect moet ook wel weten wat IT kan. Daarmee kan hij de business misschien op nieuwe ideeën brengen. Ook al heb je geregeld dat wie zich waarmee mag bezighouden niet wordt bepaald binnen het IT-bedrijf maar in de CIO-office, de positionering blijft toch altijd een communicatievraagstuk dat je niet moet onderschatten.” Henk Bothof: “In bepaalde sectoren is de IT echt een onderdeel van de business. De IT is bij ProRail als een van de bedrijfseenheden als een primair proces georganiseerd. Je zit met elkaar in de directie en je beseft dat je het in de combinatie zult moeten doen. Ik vind het heel aantrekkelijk wanneer die business- en IT-architecten heel dicht met elkaar communiceren, maar ze wel beseffen dat ze werken in het belang van de business. Net werd al treffend gesteld dat architecten niet gaan over tijd, geld en scope. Maar ze kunnen wel aangeven waar de risico‘s liggen en wat je later moet doen om dat risico weer in te wisselen. Dat je beseft wat je jezelf aandoet wanneer je voor een kort-door-de-bocht oplossing kiest.” Paul Laagland: “Wanneer wij in de automatisering een vergelijking proberen te maken met de bouw en de rollen uit de fysieke bouw proberen te plakken op de rollen die we uit de IT kennen, dan loopt het spaak. Als je zoals Daan de rol van architect schetst, dan past deze wel in de bouw, samen met engineers en anderen. Maar wij hebben binnen de IT een hele serie architecten, ik denk dat op dat gebied de vergelijking met de bouw mank gaat.”
STELLING 2: Architectuur dient de business. Een businessmanager hoort de eigenaar te zijn van de benodigde IT en dus ook van de architectuur.
Toelichting Daan Rijsenbrij: “Deze tweede stelling ligt in het verlengde van de vorige. Ik kwam laatst bij een businessmanager van de overheid, die legde een architectuurplaatje neer en vroeg mij: ‘begrijp je dit?’ Ik zei dat ik het wel begreep, maar dat ik het haar niet ging uitleggen. Want ik snap niet dat een architect binnenkomt met een plaatje dat je niet begrijpt en je hem vervolgens de deur uit laat gaan. Zeg dan gewoon, dat hij de volgende week terugkomt met een plaatje dat je wel begrijpt. Je kunt immers niet je handtekening zetten
www.via-nova-architectura.org
januari 2010
7
onder iets wat je niet snapt. Het is trouwens jouw schuld als opdrachtgever wanneer je iets anders krijgt dan je gevraagd hebt. Dan had je maar duidelijker aan de bel moeten trekken.” Hans Blokpoel: “Als je architectuur als containerbegrip hanteert, krijg je een moeilijke discussie. De business is verantwoordelijk voor de businessarchitectuur en hoe die wordt ingericht. Tegelijkertijd zullen de IT-diensten die daaruit voort vloeien steeds vaker uit shared services of outsoursingsconstructies ingekocht worden. De businessmanager mag zich gelukkig prijzen dat hij er niets mee te maken heeft hoe dat vervaardigd of ingekocht wordt. Ik denk dat je die IT-architectuur meer open moet maken, om duidelijk te maken waar je het over hebt. Maar eigenaarschap bij de business? No way.” Marjolein ten Kroode: “De businessmanager hoort de eigenaar te zijn van de architectuur, net zoals hij dit van alle andere bedrijfsfuncties is. Wel kan er sprake zijn van kaderstelling vanuit de Raad van Bestuur als het om generieke vragen gaat die voor meerdere businesseenheden gelden. Het tekent de ontwikkeling (van de kwaliteit van de relatie tussen business en IT) dat dit nogal eens zulke discussies geeft.” Richard van Breukelen: “De businessmanager is eigenaar van de inhoudelijkheid van de applicaties. Dus hij is eigenaar van de functionaliteit. In sommige gevallen wordt deze door een derde partij geleverd, maar ik moet er niet aan denken dat ik eigenaar wordt van wat die derde partij me allemaal levert. Wat voegt dat namelijk toe? Ik wil alleen maar zeker weten dat die functionaliteit mijn functionaliteit is en dat ik iets te vertellen heb over de verandering van die functionaliteit. Als ik iets geleverd krijg wat mijn idee was, dan is dat mijn applicatie, fantastisch! Maar de uiteindelijke vraag is: voldoet die applicatie ook aan wat ervan verwacht werd? Aan de generieke kant moet ik er overigens niet aan denken dat een businesseigenaar zich mede-eigenaar voelt van mijn generieke infrastructuur. Dan wordt het echt een puinhoop.” Henk Bothof: “De businessmanager zal gaan voor het systeem dat voldoet aan de businessbehoeften. Hij hoeft er geen eigenaar van te zijn, maar moet wel goed geïnformeerd zijn. Ik denk dat de business zelf beslist of die ergens eigenaar van is of niet.” Piet de Kam: “Die beslissing is naar mijn mening heel helder. Toepassing en inhoud zijn de verantwoordelijkheid van de businesskant. Kijk maar naar het eenvoudige model bij ProRail en Rijkswaterstaat, waarbij ze de infra en het gebruik van de infra weten te onderscheiden. Als je die functionaliteit wil wijzigen, dan moet je ook zelf aan het stuur zitten. Zie dat dan even als de invulling van de eigenaarsrol; dát vind ik heel belangrijk. Vervolgens kom je in gesprek met een IT- of infrastructuurafdeling, die zegt dat dit wel een prijs heeft. Daar moet je dan over onderhandelen.” Henk Bothof: “Bovenaan komt het uiteindelijk toch bij de business terecht, in de Raad van Bestuur bijvoorbeeld, en die beslist gewoon. Het is verstandig dat de business zich bezig houdt met de business en de IT zich bezig houdt met de IT. Maar uiteindelijk is er toch weer een businessman in de raad van bestuur die over de IT beslist.” Piet de Kam: “Waarom doen we zo moeilijk in het IT-vak? Wat maakt het uit of je hier bent gekomen met een taxi, je eigen auto of met een auto met chauffeur? Je kiest gewoon een bepaalde dienst. Als je zegt dat IT de business is, dan is dat prima. Maar dat beslist de eigenaar van het proces. Ik ben hier gekomen met een auto die niet van mij is, over wegen die niet van mij zijn, maar ik ben er wel. Dat ik iets te laat was lag overigens niet aan de auto, maar gewoon aan mij.” “Veel van de gewenste functionaliteit heeft consequenties voor de infrastructuur, het budget en de financiën. Dat moet je doordenken en in governance-structuren vormgeven. Daarom zie je vaak dat de business vraagt en dat een IT-architect vervolgens zegt dat dat niet mogelijk is. Omdat als het ware elke vraag uit de business impact heeft op die infrastructuur.” Henk Bothof: “Als je een goede architectuur hebt, dan kan dat meevallen.” Daan Rijsenbrij: “De business dient alleen maar geïnteresseerd te zijn in de functionaliteit van de applicaties. In mijn perceptie maak je daarvoor architectuur, de rest heet engineering.” Hans Blokpoel: “De business bepaalt wie er toegang heeft tot applicaties, wie er wat met de gegevens in die applicaties mag doen en wie die gegevens mag wijzigen. Maar dat is niet
www.via-nova-architectura.org
januari 2010
8
allemaal functioneel eigenaarschap.” Daan Rijsenbrij: “Maar ook hoe je door de applicatie heen navigeert? Zodat je weet waar je zit en je dus effectief en efficiënt kan werken.” Richard van Breukelen: “Als een businessman zich daarmee bezig kan houden, dan heeft hij kennelijk veel tijd over. Wat ik wil zeggen: het ding moet het handig doen, maar ik kan me geen businessmanager voorstellen die zich bezighoudt met het eigenaarschap van toegangspaden.” Henk Bothof: “Schermen hebben altijd een relatie met een proces, maar de manier waarop alles gebeurt is weer echt een IT-ding. Daar moet de business zich niet mee willen bemoeien. Als de IT-afdeling het op een gegeven moment terug geeft, moet de architect wel zeggen hoe het moet worden vormgegeven. De consequentie daarvan is misschien dat het wat langer gaat duren of dat het allemaal wat duurder is. Vervolgens komt toch ook de business even om de hoek, die bijvoorbeeld kan stellen dat het businessbelang om het allemaal op tijd af te hebben groter is. Je maakt in zo‘n geval dus schuld naar de toekomst toe. Als IT-bedrijf noteer je dan dat je die op een zeker moment moet willen inlossen. Maar uiteindelijk ben je als IT‘er voor de business.” “Er is wel een bepaalde afbakening nodig, zodat de business zich kan concentreren op de business en zich niet met de IT hoeft te bemoeien. Verder is het de vraag: voelt de business de afhankelijkheid van IT of niet? Als ze deze te sterk gaan voelen, willen ze zich ermee gaan bemoeien. Als ze het vertrouwen hebben dan wel de onafhankelijkheid niet voelen, dan doe je het goed.” Richard van Breukelen: “De standaardeis is: de navigatie moet altijd eigenlijk op dezelfde manier. Lukt dat in dit geval? En als dat niet lukt, dan heb je een vraag voor de business.” Henk Bothof: “Waarschijnlijk wordt die eis voornamelijk gesteld op basis van de financiële consequenties.” Paul Laagland: “Een eigenschap van functionaliteit en de service-eisen – hoe snel en hoe goed gebeuren dingen – die liggen bij business. En de spullen – software, hardware, infrastructuur – liggen bij de partijen die daarin voorzien. Dat kan intern of extern zijn. Die partijen hebben daarbij de verantwoordelijkheid om dat efficiënt aan te wenden.” Daan Rijsenbrij: “Je bent ook niet de eigenaar van je dienstauto.” Piet de Kam: “In juridische zin hoeft je ook geen eigenaar te zijn, maar het is wel relevant om aan te geven waar de verantwoordelijkheden liggen. Binnen een organisatie heeft niemand eigendom. Als je een IT-directeur hebt, dan kun je zeggen dat die eigenaar is van de hard- en software. Maar uiteindelijk is het concern dat.” Paul Laagland: “Maar Piet, je zei dat je eigenaar bent van de benodigde IT, maar ook verantwoordelijk voor de benodigde IT.” Piet de Kam: “Nee. Ik zei dat je daar over geïnformeerd moet zijn. Laat me even een vergelijking trekken. We weten wie de eigenaar is van de infrastructuur van het rijkswegennet en wie de beheerder. We zullen nooit zeggen dat Rijkswaterstaat de eigenaar is in juridische termen, want dat is de staat. Binnen de organisatie is die organisatie eigenaar van de hard- en software. De verantwoordelijkheid over en het beheer van die hard- en software, heb je evenwel toebedeeld aan een IT-directeur. Zo kijk ik naar eigenaarspositie van de functionaliteit. Wie is binnen de organisatie verantwoordelijk voor zeg maar een wet of een regeling? En wie voor een applicatiefunctionaliteit? Als je dat kunt vertalen, dan weet je waarover je praat.” Marjolein ten Kroode: “Het is opvallend welke machtsvraagstukken in deze discussie naar boven komen en welke culturele problemen zich manifesteren. Wat ik concludeer is dat IT‘ers een hoog expertgehalte hebben en ook vinden dat een zekere mate van perfectie belangrijk is om de systemen te laten doen wat ze moeten doen. Het gaat daarbij evenwel toch om een machtsdiscussie: wat doe ik en wat doe jij niet? Maar wat ik mis is hoe we er met z’n allen voor gaan zorgen dat die klant echt bediend wordt? Er heeft de afgelopen twintig jaar een grote technologische revolutie plaatsgevonden en het is erg moeilijk al die experts met elkaar te laten samenwerken. De stelling van vanavond vind ik daarom te veel een machtsvraagstuk
www.via-nova-architectura.org
januari 2010
9
worden, waarbij goed opgeleide, verbaal ontwikkelde experts ineens allemaal architect heten.” Daan Rijsenbrij: “Dat is een nieuwe definitie van architect!” Marjolein ten Kroode: “Je hebt behoefte aan maar één architect. Voor de rest zijn het allemaal functioneel of systeemontwerpers.” Richard van Breukelen: “Die machtsvraag is inderdaad niet interessant. Als een business- of proceseigenaar graag het eigenaarschap wil van de IT die voor de business nodig is, dan vind ik dat prachtig. Dat is de beste borging voor systemen die opleveren wat de klant wil.” Marjolein ten Kroode: “We moeten ervoor zorgen dat die machtsvraag voorkomen wordt. Als je dat laat doorzieken in je organisatie, dan voelt geen enkele businessmanager die met z’n klant bezig is, nog enige animo om daar tijd aan te besteden.” Richard van Breukelen: “Als je iets veranderd wilt hebben, dan moet er onderling respect zijn voor de rolverdeling. Als al de randvoorwaarden zijn vervuld, dan hebben we een goede deal. Waar het eigenaarschap precies ligt, is een non-issue.” Henk Bothof: “De machtsvraag wordt vooral gesteld als de afhankelijkheid sterk gevoeld wordt. Niet wanneer je het gevoel hebt dat je samenwerkt aan een doel en dat IT snapt wat ze moeten doen om jou te helpen. Maar zodra IT iets anders wil, wat niet in het belang is van de business en daar invloed op kan uitoefenen, dan begint het eigenaarsvraagstuk. Alleen het feit dat die vraag gesteld wordt is al een signaal dat er iets niet in orde is.” Marjolein ten Kroode: “De expertisemacht van IT is groot en de eigenwijsheid ook. De IT hoeft niet samen te werken, ze weten het allemaal zelf wel. Daar komt bij dat ‘de’ business nogal eens een lager scholingsniveau heeft dan ‘de’ IT. Het is dus voor een groot deel een cultureel vraagstuk.” Michel Bouten: “Ik wil de vraag iets scherper krijgen. Wat als de business vragen stelt waar ze geen of een ander antwoord op krijgen? In de hele keten van keuzes maken en realisatie krijgt de business in veel gevallen iets heel anders dan er gevraagd is. Daar moeten we het over hebben, omdat we architecten nodig hebben om dat probleem op te lossen.” Daan Rijsenbrij: “Zoals ik reeds eerder zei is de architect de regisseur van het beeldvormingsproces. Je hebt als business iets in je hoofd, maar je kunt het alleen nog niet echt goed verwoorden.” Michel Bouten: “Toch heb je mensen die het helemaal niet begrijpen en echt hulp nodig hebben.” Marjolein ten Kroode: “Hulp om hun eigen vraag duidelijker te maken, bij iemand die niet weet hoe zijn wens gestalte moet krijgen.” Daan Rijsenbrij: “Nogmaals: hij weet wel wat hij wil, maar kan het gewoon niet goed formuleren.” Marjolein ten Kroode: “Als ik met een architect aan tafel zit en ik begrijp niet wat die bedoelt, zeg ik: ‘Ga heen en kom terug!’ Ik als opdrachtgever weet wat ik wil en ik kan bepalen met wie ik werk.” “Ik ben gecharmeerd van de parallel met stedenbouwkunde en het bestemmingsplan. Zorg dat de globale lijnen er zijn, zodat je daarin als bedrijf je visie gerealiseerd kunt zien. Vervolgens verwacht ik dat alle experts die daarvoor nodig zijn – en dan haal ik stuk-voor-stuk hun etiketjes eraf – er binnen de multidisciplinaire samenwerking ook naar gaan leven. Natuurlijk krijg je bij grote bedrijven dan laag op laag op laag. De kunst is om daar een organisch geheel van te maken.” Henk Bothof: “Architectuur representeert de visie op de flexibiliteit die je naar de toekomst toe nodig hebt. Op het moment dat we een project doen of iets realiseren, wordt er iets inflexibels gecreëerd. De architect moet vooral aangeven waar we die flexibiliteit in de toekomst nodig hebben.” Paul Laagland: “Ik merk dat er ergens in dit gesprek een shift is ontstaan. In het begin hadden we het over de vertaling van wat de opdrachtgever wil naar de bouwers toe. Nu gaat het over een applicatie waarvan men wil dat die toekomstvast is en dat ik voorkom dat ik
www.via-nova-architectura.org
januari 2010
10
legacy opbouw. Het is een hele andere rol, die nu in het gesprek is ingebracht.” Piet de Kam: “Op bestemmingsplanniveau spreek je over een ruimer verband. Ook daar vind ik trouwens dat de bedrijfsvisie waarmee je met de organisatie naartoe wilt, dominant is boven de architectenvisie. Als je binnen het bestemmingsplanniveau vervolgens een individueel gebouw gaat ontwerpen, of een individueel proces of dienstverlening, dan kom je op een tweede niveau en dan kijk ik ook op een ander niveau naar de inzet van een architect. Als je goed weet te onderscheiden op welk niveau het ontwerpvraagstuk ligt, dan kom je er wel uit.” “Bij de vertaling van de totale eisen als opdrachtgever – en bij een uitvoeringsorganisatie zijn dat de proceskant, de gegevenskant en de regelkant – is het gewenst de samenhang modelmatig op het niveau van het bestemmingsplan te krijgen: wat is de samenhang met de wetgeving en andere aspecten? Bij de vertaling naar een specifieke regeling of naar specifieke processen kunnen vervolgens de procesmodellen en de regelmodellen worden ontworpen. Het totaal van business requirements wil de opdrachtgever professioneel en in samenhang vanuit de businesskant klaarzetten, waarna je in staat bent om eventueel met je engineers in contact te komen over het hoe en in welke volgorde je het ontwerp implementeert. In die zin pas je ook je ontwikkelmethodiek aan. Je praat niet langer over een functioneel ontwerp dat de business moet beoordelen, maar stelt als business zelf je eisen in bedrijfskundige modellen vast. De essentie is: hoe krijg je die verschillende expertisevelden bij elkaar. Want iedereen heeft zijn eigen belangen en zijn eigen views. Die wil je als opdrachtgever samenbrengen.” Marjolein ten Kroode: “Samenwerking is wat ik zoek, niet een architect die denkt dat hij alles weet. Iemand die bij mij aan tafel komt met een hoog apostolisch gehalte zit bij mij verkeerd.” Henk Bothof: “Bij architecten kom je dat geloof veelvuldig tegen.” Marjolein ten Kroode: “Het zijn ook vaak zwaarmoedige gesprekken met een hoog ‘ik heb toch gelijk, waarom krijg ik het niet’ gehalte.” Michel Bouten: “Ik wil ook nog een knuppel in het hoenderhok gooien. Binnen de overheid zijn er ontzettend weinig goede opdrachtgevers. Ik ken veel businesseigenaren die hun eigen business niet eens begrijpen en toch opdrachten geven. Ze kiezen voor SAP en vervolgens worden er megalomane verandertrajecten ingezet. Dat zijn ook problemen die we zullen moeten oplossen.” Daan Rijsenbrij: “Ik vind de problematiek rond SAP zeer interessant. Er zit een intrinsieke architectuur in dat pakket die je cadeau krijgt. Die intrinsieke architectuur moet je confronteren met je eigen architectuur en dan kijk je of er eventuele problemen zijn dan wel kunnen komen. Dat geldt trouwens ook voor Oracle en voor een back office van een externe provider.” Adriaan Blankenstein: “Bij visie en leiderschap zijn er veel dingen die je je laat aanmeten. Door technici, door aanbod van de markt, door het geloof of door wie of wat dan ook. Neem die moeders met bakfietsen en al die kinderen erin op die bochtige straatjes en bruggetjes in de stad. Het is bijna mode om met de verkeerde fiets op pad te gaan en hetzelfde doen wij in de techniek. Een architect hoort te zeggen: dit is een aardige fiets als je boodschappen gaat doen op het platteland, met veel rechte wegen, maar hij is niet handig voor de stad. De architect hoort je te behoeden voor verkeerde keuzes.” “Het gaat er bovendien om dat je als opdrachtgever weet waar je naartoe wilt en wat je daarvoor nodig hebt. Dan ben je volgens mij per definitie geschikt om dat te vertellen aan adviseurs of architecten of technici die je gaan helpen.” Richard van Breukelen: “Maar hebben we goede opdrachtgevers? Velen zeggen van niet, maar dat ligt volgens mij ook aan de opdrachtnemer. Mijn stelling is namelijk dat je daar invloed op hebt. Als je alles maar accepteert, dan is het garbage in en garbage out.” Daan Rijsenbrij: “Ik heb kortgeleden een opdrachtgever – waar het softwarehuis echt onprofessioneel uurtjes aan het verstoken was, zonder een duidelijk resultaat – geadviseerd dat softwarehuis voor de rechtbank te slepen, ondanks dat de opdracht niet helemaal waterdicht was. Dat softwarehuis had het respect moeten tonen om de klant de ruimte te geven eerst zijn opdracht te laten uitkristalliseren. Maar nee, dat softwarehuis was alleen maar
www.via-nova-architectura.org
januari 2010
11
geïnteresseerd in het wegzetten van mannetjes. Omdat veel opdrachtgevers ten onrechte denken dat zij ook boter op hun hoofd hebben, durven zij de gang naar de rechter niet aan. De rechter zou gewoon hebben geoordeeld dat het softwarehuis als sterkere partij had moeten waarschuwen dat het gevraagde niet verantwoord was.”
STELLING 3: NORA (Nederlandse Overheid Referentie Architectuur) is een absolute must voor de gehele overheid. NORA moet met hoge prioriteit op het juiste niveau worden gebracht. Toelichting Daan Rijsenbrij: “Bij de eerste stelling werd het steeds onduidelijker wat een architect eigenlijk is. Bij de tweede stelling bleek het onduidelijk te zijn wie nu precies de eigenaar is van de architectuur en wat het eigendom vervolgens inhoudt. In dit licht is het natuurlijk bijzonder interessant om eens te beginnen over de NORA. Persoonlijk heb ik wat positieve kritieken op de NORA geuit. NORA 1.0 en 2.0 waren aardige werkjes, maar nogal inconsistent. De grote verdienste van die eerste NORA-versies vind ik trouwens dat NORA op de kaart is gezet. Inmiddels zijn we beland bij NORA 3.0, waarvan we alleen nog maar een strategisch katern hebben gezien.” “Zoiets als NORA is echt nodig om de automatisering van de overheid op effectieve en efficiënte wijze uit te voeren. Interoperabiliteit, de grondtoon in NORA 3.0, is een eerste vereiste. Ik bemerk echter niet dat bij de eigenaar van de NORA enige sense of urgency aanwezig is om deze cruciale referentiearchitectuur in snel tempo op niveau te krijgen.” Hans Blokpoel: “Je kunt de stelling op twee manieren bekijken. Moeten er meer modellen komen? Of moeten er een aantal dingen gerealiseerd worden die al lang nodig waren om de NORA 1.0 of 2.0 in te vullen? Het is heel erg nodig om aansluiting te houden, om een aantal gemeenschappelijke voorzieningen te realiseren: voorzieningen voor gemeenschappelijke machtigingen, DigiD voor bedrijven, alle zaken die we al jaren geleden hebben afgesproken. Zo lang dat er niet is, is dit een non-discussie. NORA is dus prima, maar de vraag is of wij het nu hebben over een nieuwe papieren versie of over concrete, door ons allemaal te gebruiken gemeenschappelijke producten en diensten, waarmee we invulling kunnen gaan geven aan het huidige concept?” Daan Rijsenbrij: “Op dit moment heb je wellicht meer behoefte aan een aantal bouwblokken die in de hele publieke sector zouden kunnen worden gebruikt, dan aan een theoretische discussie over architectuurprincipes.” “In enkele ondernemingen zie ik dat ze hun architectuurontwikkeling hebben verdeeld over een aantal fasen. Fase nul, de bodemarchitectuur, bevat dan gemeenschappelijke bouwblokken. Deze fase borgt de continuïteit, de robuustheid en de security van de informatievoorziening, waarbij de interoperabiliteit zorgt dat de organisatieoverschrijdende ketens netjes aan elkaar gekoppeld kunnen worden.” Hans Blokpoel: “Alle basisregisters en gemeenschappelijke identificatie voor personen en bedrijven zijn van die heel concrete dingen. Ik denk dat alle energie daarop gericht zou moeten zijn.” Paul Laagland: “Heb jij enig idee waarom dit niet gerealiseerd is?” Hans Blokpoel: “Er worden geweldige discussies gevoerd over financiering, over invloed en over wie het waar voor het zeggen heeft. We zijn met z’n allen heel hard bezig om dat vlot proberen te trekken. Maar laten we nou niet doorgaan met nog weer nieuwere modellen, terwijl deze dingen al zoveel moeite kosten.” Piet de Kam: “Let wel, het is een referentie, niet meer dan dat. Ik ben het ermee eens dat we over interoperabiliteit afspraken moeten maken. En dat over instanties heen. Hoe koppel ik systemen? Hoe werk ik samen? Dat mag best in een versie-3.0 naar voren komen. Maar doe dat parallel met het ontwikkelen van gemeenschappelijke voorzieningen. Het lastige daarbij is de financiering. Wie legt hiervoor het geld op tafel?”
www.via-nova-architectura.org
januari 2010
12
Hans Blokpoel: “Er zijn sowieso een aantal gemeenschappelijke voorzieningen nodig, maar de basis hebben we of is in ontwikkeling. De vragen hoe te werken en hoe dingen te koppelen zijn eigenlijk de belangrijkste. Wie is de eigenaar van die gemeenschappelijke voorziening? Daar begint het en dat is het punt waar we het vaak niet over eens zijn. Binnen de overheid kunnen we ons die functionaliteit vaak niet eens voorstellen. Als we eerst discussies moeten voeren over ‘wie financiert dat en wie ontwikkelt dat‘, dan ben je lang bezig. Vandaar dat ik zeg dat je een tweesporenbeleid moet voeren: NORA 3.0 plus gemeenschappelijke voorzieningen.” Michel Bouten: “NORA is bedoeld om context te geven aan een ontzettend grote hoeveelheid standaarden. Er is daarbij gekozen voor standaarden waar al consenus over was en dat heeft een behoorlijke vlucht genomen. Er bestond bij de overheid een behoefte aan richting en duidelijkheid. NORA voorzag hierin. We zijn daarbij heel lang bezig geweest met de NORA voor bestuurders. Maar je moet juist een NORA maken voor de mensen om die bestuurders heen. Die moet je op dezelfde golflengte brengen. Overigens wil ik nog wel de vraag stellen wat wordt verstaan onder ‘op niveau brengen‘? Bedoelen we daarmee nou een hoger abstractieniveau?” Daan Rijsenbrij: “Nee, concreter juist.” Michel Bouten: “Concreter betekent dat je ook keuzes moet maken en als je in een discussie zit – neem alleen de discussie over basisregistraties – dan heeft dat meestal enorme consequenties. Je komt er dus niet zo makkelijk uit. We moeten volgens mij de discussie goed met elkaar aangaan; wat willen we nou en hoe snel willen we het?” Daan Rijsenbrij: “Zeker omdat je na en naast de NORA ook onderliggende referentiearchitecturen krijgt, die ook allemaal op snelheid beginnen te komen. Bijvoorbeeld de GEMMA op gemeenteniveau.” Michel Bouten: “Zo maken we momenteel gemeenschappelijke afspraken over beveiliging, omdat veel informatie door ketens gaat en er niet altijd een wederzijds vertrouwen is. Hier zitten momenteel architecten over te praten en die maken er een mooi verhaal van. Vervolgens zeggen bijvoorbeeld de gemeentes, die een onderdeel zijn van vrijwel alle ketens, dat het allemaal zo niet kan. Hoe ga je om met dat soort vraagstukken?” Daan Rijsenbrij: “Bij de overheid is elke gemeente baas in eigen huis.” Piet de Kam: “Begripsdefinities die door de keten heen gaan zijn zeer belangrijk voor de samenleving. Je moet het op wetgevingsniveaus zien te krijgen.” Marjolein ten Kroode: “Als je kijkt wat er binnen de wetgeving aan loonbegrippen, persoonsgegevens en adresgegevens voor komt, dan zit er steeds meer voortgang in die begripsafstemming. Dus dat is ook toegevoegde waarde. Je moet niet alleen in termen van ITarchitectuur redeneren. De optie die Piet noemt is vruchtbaar.” Paul Laagland: “Je zal dus dat domein bij NORA moeten betrekken. Het gaat erom dat je binnen de overheid bestaande begrippen hergebruikt in plaats van dat je nieuwe gaat verzinnen.” Marjolein ten Kroode: “We hebben juridische architecten nodig, aan de voorkant dus.” Lenny van Beek: “We hebben binnen het ministerie van Landbouw, Natuur en Voedselkwaliteit (LNV) wetgevingen, die bij wijze van spreken 40 soorten varkens kennen. Er is afgesproken dat er geen enkel varken meer mag bijkomen. Maar het heeft nogal wat voeten in de aarde om van die 40 naar één te komen.” Marjolein ten Kroode: “ Neem bijvoorbeeld het begrip ‘kind‘, dat is ook geëxplodeerd. Diverse overheidsorganisaties brengen het begrip ‘kind’ op verschillende plaatsen onder. Je denkt dat je maar één kind-begrip hebt, maar hoeveel type kinderen zijn er nu wel niet?” Adriaan Blankenstein: “Ik heb bij de NS het begrip ‘kind‘ met en zonder kinderbijslag gezien. Dat zal dus wel een belangrijk onderscheid worden.” Marjolein ten Kroode: “Dit is de prijs die wij betalen voor een geciviliseerde maatschappij.”
www.via-nova-architectura.org
januari 2010
13
Daan Rijsenbrij: “Is dat niet het poldermodel?” Marjolein ten Kroode: “Nee, dat is bureaucratie. Daar hoort dit soort effecten gewoon bij en het is de kunst om erop te organiseren, zonder het kind met het badwater weg te gooien.” Piet de Kam: “Ik vind XBRL wel een mooie benadering, de fiscale standaardisatie van de jaarrekening. Dat betekent dat je in je informatievoorziening vanuit de financiële administraties van bedrijven zowel de banken als de overheid volgens dezelfde standaarden kunt gaan bedienen. Wat in Nederland via een zachte methode wordt ingevoerd, schrijft België overigens gewoon standaard voor. Een overheid die wat wil bereiken, zou bepaalde zaken zo nu en dan dus verplicht kunnen opleggen.”
STELLING 4: Een Digitale Rijksbouwmeester voor de gehele overheid is vereist om de architectuur consistent te krijgen over de verschillen gremia in de overheid. De overall architectuurgovernance dient ook onder zijn/haar bevoegdheid te vallen. Toelichting Daan Rijsenbrij: “De overheid in haar totaliteit is informatietechnisch zeer vervlochten. Hoewel elke bestuurslaag in zekere zin baas in eigen huis is (het subsidiariteitsbeginsel) wordt er veel informatie uitgewisseld en intensief samengewerkt in de organisatieoverschrijdende ketens. Om te borgen dat voor de burger en het bedrijf de overheid als één geheel overkomt, is er een opperarchitect nodig om die integraliteit van de overheid te ontwerpen en te bewaken. Ons welbekende poldermodel werkt daarbij soms contraproductief.” Richard van Breukelen: “Als die Rijksbouwmeester zich weet te houden aan de principes en de consequenties daarvan bespreekt, dan wel.” Daan Rijsenbrij: “Ik denk dat de Digitale Rijksbouwmeester, net als elke volwassen architect, doet wat redelijk is en niet wat theoretisch mogelijk is. Gewoon een praktische man of vrouw.” Henk Bothof: “Met oog voor het detail en liefde voor het geheel.” Daan Rijsenbrij: “De Digitale Rijksbouwmeester zorgt voor de onderlinge positionering van de gemeentes, de Belastingdienst, het UWV, noem maar op. Natuurlijk is daarbinnen iedereen nog wel baas in eigen huis, zo lang je maar zorgt dat de keten probleemloos doorloopt, de stekkertjes goed zijn, er semantische discussies worden gevoerd et cetera.” Piet de Kam: “Bij de Digitale Rijksbouwmeester gaat het in essentie om hoe de wetgeving en de daaruit vloeiende taaktoewijzingen op elkaar zijn afgestemd.” Marjolein Ten Kroode: “Nogmaals: er moet een juridische architect komen.” Paul Laagland: “Als we de analogie doortrekken zoals die in de stelling wordt gebruikt, dan is in mijn ogen Justitie de bewaker van een consistente business. De architect moet dit na een vertaalslag waarmaken.” Marjolein Ten Kroode: “Hoe kun je een departement zien als een business?” Piet de Kam: “Ze claimen in ieder geval dat er een wetgeving wordt gemaakt die consistent is.” Marjolein Ten Kroode: “Een departement dat claimt dat zij de business is, dat is wel een heel rare.” Richard van Breukelen: “Stel dat het ooit zo ver komt dat we een consistente wetgeving en consistente begrippen hebben, en dat je daarnaast iemand hebt die verantwoordelijk is voor interoperabiliteit en voor voorzieningen waarvan we met elkaar hebben vastgesteld dat het inderdaad zinvolle gemeenschappelijke voorzieningen zijn. Dan moet je daarbij een goverancestructuur bedenken die een onderscheid maakt tussen de business van kerndepartementen en de business van uitvoeringsorganisaties. Dat zijn namelijk twee heel verschillende bedrijfstypologieën, die ook heel verschillende generieke voorzieningen vereisen. Die governancestructuur kun je niet opleggen, maar moet je met elkaar op basis van het type generieke voorzieningen vaststellen. De Rijksbouwmeester moet daarbij zijn ideeën bij wijze
www.via-nova-architectura.org
januari 2010
14
van advies voorleggen.” Piet de Kam: “Vanuit de burger geredeneerd is er een gemeenschappelijke verantwoordelijkheid om uitvoering, dienstverlening en handhaving op elkaar af te stemmen. Dat betekent dat de diverse organisaties dit zelf ook via een netwerkconstructie zouden moeten kunnen regelen en terug kunnen naar hun wetgeving als de begrippen onjuist zijn. Voor een deel kunnen de facilitaire taken gemeenschappelijk zijn gefaciliteerd, door een ministerie als BZK bijvoorbeeld. Degenen die binnen het stelsel de verantwoordelijkheid toebedeeld hebben gekregen, zitten dan aan het stuurwiel en kunnen een beroep doen op de Digitale Rijksbouwmeester.” Henk Bothof: “Als iets faciliterend is, dan moet er ergens een vragende partij zijn. Die vragende partij moet zich afvragen waar die keten begint: bij de burger. Hoe heeft die zich georganiseerd? Dat is voor mij het kernprobleem: van wie is die keten?” Marjolein ten Kroode: “Als er een ding is waar wij in deze poldernatie goed in zijn, dan is dat toch wel ketensamenwerking. Tot het moment dat we de machtsvraag gaan stellen: wie is de eigenaar en wie is de verantwoordelijke? Benadruk dus het ‘wij‘ in plaats van het ‘mij‘ of ‘jou‘.” Michel Bouten: “De business moet zich realiseren dat ze niet zonder die uitvoering kunnen.” Richard van Breukelen: “De business ís de uitvoering.” Michel Bouten: “Dat moeten we dan aan de politiek gaan uitleggen.” Richard van Breukelen: “Nee, we moeten aan de kerndepartementen uitleggen dat de business de uitvoerder is. De perceptie bij het kerndepartement is nogal eens dat zij bepalen hoe de uitvoering gebeurt. Dus niet alleen het ‘wat’, maar ook het ‘hoe’.” Lenny van Beek: “Het gaat nu wel een heel vreemde kant op. We hebben bij LNV drie grote uitvoeringsorganisaties en een enterprise-architectuur. Onze ketenpartners willen dat wel, want het helpt hen hun werk goed te doen en hun werk te verdelen, de applicaties goedkoop te houden en dingen op dezelfde manier te doen. Het kan dus juist wel goed werken en de boel goedkoper maken.” Michel Bouten: “Wat voor LNV geldt, geldt ook voor Defensie. Dat zijn typische uitvoeringsdepartementen. Binnen Financiën, waar uitvoering en beleid een geheel afzonderlijke inrichting kennen en vereisen, kijk je daar anders tegenaan. Het gaat om het verschil tussen de beleidskant en de uitvoeringskant, die hebben soms een heel afzonderlijke inrichting nodig.” Adriaan Blankestein: “Als uitvoeringsdepartement proberen we nu intensief samen te werken met bijvoorbeeld BZK als het gaat om veiligheid en politie en dat is wennen. We zijn gewend om bij een probleem gewoon te zoeken naar een oplossing. Zo werkt dat niet bij een beleidsdepartement.“ Henk Bothof: “Redenerend vanuit de burger gaat het dus goeddeels over de taakopvatting. Hoe faciliteer je dat? Het gaat om een soort dienstverleningsconcept dat je met elkaar wilt realiseren. Maar als de keten niet wordt gezien als element binnen de dienstverlening naar de burger toe, dan denkt iedereen dat men op zijn eigen terrein kan blijven zitten.” “Als wij een stukje veiligheid gaan proberen te realiseren, dan gaan we kijken of we camera’s nodig hebben, kentekens moeten fotograferen, databases moeten aanleggen. Vervolgens stappen we naar Verkeer en Waterstaat, dat al driekwart heeft van wat we nodig hebben, en vragen we of we daar nog iets aan mogen toevoegen. Dat werkt heel praktisch, totdat er iemand over gaat nadenken. Dan ontmoeten twee culturen elkaar. Ik ben bang dat als wij een Rijksbouwmeester-gedachte zouden hebben, deze culturen te veel met elkaar in overeenstemming moeten worden gebracht, waarna het alleen maar lastiger wordt.” Paul Laagland: “Dat loopt dan parallel met het bedrijfsleven. Als divisies redelijk autonoom functioneren, dan weet je elkaar toch op een aantal aspecten te vinden. Dan kun je iets op het niveau van een governance board organiseren en deze wat bevoegdheden geven om het te gaan coördineren. Ik kan me voorstellen dat je ook als uitvoeringsorganisaties samen zoiets opzet.”
www.via-nova-architectura.org
januari 2010
15
Adriaan Blankenstein: “Het is goed dat er af en toe iets gebeurt.” Marjolein ten Kroode: “In de uitvoering weten de overheidsbedrijven elkaar heel goed te vinden om op die punten waar er echt samenhang is interoperabiliteit en standaardisatie te realiseren, zeker als dit voor de burger iets oplevert. Ondertussen blijven ze op andere punten losjes gekoppeld.” “Vanuit de Manifestgroep is de DigiD de wereld in geholpen, dat beheert BZK nu als infrastructurele voorziening heel goed. Eerlijk gezegd zie ik de innovatiekracht veel meer vanuit die poldergedachte komen; van bedrijven die heel dicht bij de dienstverlening naar burgers staan in plaats van departementen die er veel verder vanaf staan en die in beleidstermen denken.” Richard van Breukelen: “Je moet erkennen dat de kerndepartementen en de uitvoeringsorganisaties echt twee werelden zijn met een volstrekt eigen dynamiek en een eigen verantwoordelijkheid voor het proces. Het zal ongelooflijk helpen als dat onderscheid wordt gemaakt. Je moet dus gaan faciliteren wanneer uitvoeringsorganisaties vanuit hun eigen verantwoordelijkheid op zoek gaan naar concepten die werken, maar je moet het niet gaan regelen of opleggen.” “Bij Rijkswaterstaat hebben we samenwerkingsverbanden met grote gemeentes en provincies, waarbij zij in onze verkeerscentrales graag zelf het verkeersmanagement voor hun wegen afhandelen. Dus zorgen we dat de ‘desks’ op elkaar zijn afgestemd en dergelijke. Dat hebben we allemaal onderling geregeld in convenanten. Wanneer wordt het moeilijk? Als het op het politiek-bestuurlijke niveau wordt gebracht en de machtsvraag op tafel komt. En dat is het leuke van samenwerken: niemand heeft het voor het zeggen!” Henk Bothof: “Het kenmerk van macht is dat je niet hoeft samen te werken.” Richard van Breukelen: “Bovendien speelt op politiek-bestuurlijk niveau de vraag wie ministerieel verantwoordelijk is als het misgaat. Bij een meer pragmatische samenwerking tussen uitvoeringsinstanties is dat minder snel aan de orde.” Piet de Kam: “Het politieke paradigma is op dit moment dat de verschillende functies tussen beleid en uitvoering wel worden onderkend, maar de vraag is hoe de overheid kan helpen in samenhang te sturen en deze verder door te ontwikkelen, dat komt gewoon niet van de grond. Je moet onderkennen dat er nog een behoorlijke politieke grens ligt tussen beleid en uitvoering.” Daan Rijsenbrij: “Ik heb een paar keer horen zeggen dat je alles moet zien vanuit het perspectief van de burger en het bedrijf. Je had dus voor je aan NORA begon een beeld moeten maken hoe mensen en bedrijven onderling communiceren over pakweg drie jaar en over tien jaar. Binnen die plaatjes kun je de rol van de overheid schetsen. Vervolgens maak je daarvoor een architectuur. Met drie jaar bedoel ik aan te geven dat dat de periode is waarin je de eerste significante transformaties kunt hebben doorgevoerd. Het beeld over tien jaar wordt vaak aangeduid met ‘stip op de horizon’, als een soort richtpunt voor je strategische architectuurbeslissingen.” Richard van Breukelen: “Los van de communicatie binnen de overheid moet ik met de andere partijen waarmee ik samenwerk – organisaties, bedrijven en burgers – afspraken maken over interoperabiliteit. NORA kan dus helpen, maar als dat niet gebeurt, dan blijft er naast NORA nog een andere 80 procent over waarmee ik ook afspraken moet maken. En als ik er niet bij word geholpen, dan ga ik dat zelf regelen.” Daan Rijsenbrij: “De afstemmingen zouden dus ook gebeuren als er geen NORA geweest zou zijn.” Richard van Breukelen: “Ja, maar als het gaat over de interoperabiliteit binnen de overheid, dan kan NORA zorgen dat je er minder tijd aan kwijt bent.”
www.via-nova-architectura.org
januari 2010
16
STELLING 5: Heldere, inspirerende architectuurvisualisaties dienen zonder nadere mondelinge toelichting begrijpelijk te zijn voor businessmanagers en topmanagement. Toelichting Daan Rijsenbrij: “Ik zie veel architectuurdocumenten die bestaan uit 100 tot 300 pagina’s. Hoe krijg je dat consistent en wat kun je hier eigenlijk mee? Stel je voor dat je voor een aantrekkelijk nieuw huis een architect laat komen waaraan je je wensen uit. Na twee weken komt hij terug met een stapel van 100 pagina’s vol moeilijke diagrammen. Ben je dan blij of zeg je: ‘Ik wil zien wat ik krijg. Ik wil kunnen meedenken over de beslissingen die jij hebt genomen. Laat mij zien hoe ik van de kamer naar de keuken kom.’ Mensen zijn visueel ingesteld.” “Bij een verkeersprobleem pak je het stratenplan en toon je de verkeersbezetting om 9.00 uur, 12.00 uur en om 17.00 uur. Daarmee kan je de problematiek tonen. Vervolgens stel je voor een aantal fly-overs of wat tunnels aan te leggen. Daar hang je dan wat kosten aan en een migratietraject. De bestuurder begrijpt aan de hand van het plaatje precies wat de problematiek is. En kan zonder verkeerskunde te hebben gestudeerd een verantwoorde beslissing nemen.” “IT‘ers en architecten denken daarentegen nog steeds grote stapels papier heen en weer te moeten schuiven, waarbij zij ervan uitgaan dat degene die de beslissing moet nemen het allemaal maar begrijpt. Ik zou dus zeggen: ‘We hebben meer heldere architectuurvisualisaties nodig. Visualisaties die zonder veel uitleg makkelijk kunnen worden begrepen door de business’.“ Henk Bothof: “Een plaatje aan de hand waarvan je vervolgens een goed gesprek kunt voeren, kan toch wel zinvol zijn.” Paul Laagland: “Welke eisen stel jij aan een plaatje dat een architect jou presenteert?” Henk Bothof: “De essentie van de te maken keuze moeten duidelijk zijn. Het is wel leuk als je kunt kiezen tussen bijvoorbeeld een fly-over en een tunnel. Maar ook de consequenties moeten tot uiting kunnen komen op dat plaatje. Dat betekent in ieder geval dat je met meerdere plaatjes moet komen.” Piet de Kam: “Uiteindelijk moet je met visualisaties kunnen werken. Maar bij de eerste versies ontkom je niet aan uitgebreide documentatie. Vervolgens gaat het over de standaarden en interoperabiliteitsvisie, maar je weet dat er onderliggend afspraken zijn gemaakt over de semantiek en de syntaxis. Die staan allemaal in die boekwerken.” Henk Bothof: “In onderliggende documentatie zitten bepaalde keuzes, indien die keuzes bepaalde consequenties hebben, moet je ze toch weer even naar boven kunnen halen.” Piet de Kam: “Er liggen belangrijke architectuurprincipes ten grondslag aan de visie hoe een organisatie zich moet ontwikkelen. Neem het proces hoe je de klantbehandeling binnen een organisatie moet inrichten. Op basis van een beperkt aantal plaatjes ga je in discussie met de lijnmanagers over wat alles precies betekent. Daarna kom je op de vraag welke uitgangspunten je dan moet kiezen. Lukt dat samen met je lijnmanagers, dan heb je al heel wat bereikt. Als vervolgens de business iets wil, dan moet je de architectuurprincipes op een lager niveau zien vast te stellen. Daar heb je dan een ander type discussie voor nodig, waarbij een zekere mate van visualisatie goed kan werken. Je moet dus weten op welk niveau je praat en met welke principes je werkt.” Richard van Breukelen: “De visualisatie die we gebruiken bij de infrastructuur, doen we op basis van bepaalde inpassingseisen. Daarbij zie je dat er zeer verschillende ontwerpen naar voren komen, die allemaal voldoen aan de topeis, onderliggende basisprincipes voor de architectuur of voor de functionaliteit. Het aardige van visualisaties is dat je heel zichtbaar kunt maken waar de verschillen zitten en wat de keuzevragen zijn die je moet beantwoorden. Maar die visualisaties kun je pas maken als er op basis van de topeisen tot op een redelijk diep niveau een ontwerp ligt. Pas daarna krijg je de toetsing: wat zijn de keuzes bij die verschillende ontwerpen? En wat vinden we van die keuzes?”
www.via-nova-architectura.org
januari 2010
17
Marjolein ten Kroode: “Natuurlijk is visualisatie belangrijk. Het is wel de kunst om nieuwe IT die er is te gebruiken, want onze klanten zijn niet hetzelfde gebleven als tien jaar geleden. Dat betekent dat grote uitvoeringsorganisaties, die met duizenden mensen klantcontacten hebben, goed moeten begrijpen wat dit nu precies betekent. Bij ons is dit in de praktijk gebracht door degenen die echt klantcontact hebben door middel van die visualisaties aan het stuur te zetten. Ze kunnen zelf integraal het proces van dienstverlening herontwerpen.” Richard van Breukelen: “Een aantal keuzes geef je al als randvoorwaarde mee als er meerdere visualisaties zijn. Zo van: ‘als je deze keuze maakt, dan zal dat er zo uit zien.’ Dat geeft inzicht in het effect van de ontwerpkeuzes waar je gaandeweg tegenaan loopt.” Henk Bothof: “Je kunt heel veel in een plaatje vatten, maar het is inderdaad goed om er een aantal statements aan toe te voegen. Zo‘n plaatje bevat namelijk heel wat impliciete keuzes en creëert impliciet een bepaalde flexibiliteit naar de toekomst toe. Het kan laten zien waar het later inflexibel zou kunnen worden; die keuze heeft dat als gevolg. Ook dat is de essentie van een goeie architectuur.” Adriaan Blankenstein: “Ik zie graag een soort houtskoolschets. Toen architecten nog geen CAD hadden, deden ze het precies zo. Dus gewoon met een dik potlood de hoofdlijnen tekenen. Het is een aanpak waarmee je het overzicht kunt detailleren en de dingen met elkaar in relatie kunt brengen.” Daan Rijsenbrij: “Ik laat businessmanagers en directeuren vaak kladblokken meenemen om te schetsen hoe zij hun business zien. Gewoon laten zien! Vervolgens geef ik ze een rood potlood en dan kruisen ze maar aan waar de obstakels en problemen zitten. En een groen potlood voor eventuele mogelijkheden. Dat soort visualisaties maakt in één keer duidelijk waar het over gaat. Na je architectuurvoorstellen bespreek je in eenvoudige termen ook de IT nog even. Je geeft aan wat er gebouwd/herbouwd dient te worden, wat geoutsourced kan worden of waarvoor een pakket aanwezig is.” Paul Laagland: Het antwoord op de vijf stellingen is niet altijd een eenduidig 'ja' of 'nee'. Het vakgebied ‘architectuur’ is nog volop in ontwikkeling. Stevige discussies zoals op deze avond gevoerd verrijken de nog jonge discipline. Het is daarom aan de lezers van dit verslag om hun eigen beeld te vormen op basis van de uitspraken van de deelnemers aan deze conferentie. Ik zou de discussie als volgt willen samenvatten: •
De architect moet niet tussen opdrachtgever en opdrachtnemer gaan staan, maar de opdrachtgever helpen om de architectuur vorm te geven, deze te toetsen aan referentiearchitecturen, adviseren over korte-termijnoplossingen en aangeven wat de risico´s zijn van bepaalde keuzes. Wel is het zo dat er een onderscheid wordt gemaakt tussen deze (business)architect en de IT-architect (ook wel engineer genoemd) die aan de achterkant moet toetsen of de gekozen oplossingen passen binnen de ITinfrastructuur en het applicatielandschap.
•
De business is opdrachtgever en eigenaar van de architectuur, meer concreet van de functionaliteit die onder deze architectuur wordt gerealiseerd. Maar zodra IT vanuit haar expertise iets anders wil dan de business, wordt het een machtsdiscussie die zeer contraproductief werkt. Zorg daarom voor globale kaders waarbinnen de verschillende experts samenwerken om er een organisch geheel van te maken.
•
Op dit moment is er eerder behoefte om NORA 2.0 in te vullen met gemeenschappelijke voorzieningen dan (nog) meer modellen uit te werken en vast te leggen in NORA 3.0. Financiering is hierbij een belangrijk issue, maar als de uitvoeringsorganisaties de handen ineen slaan – zoals is gebeurd bij de ontwikkeling van het DIGID – is dit probleem oplosbaar.
•
De rol van een Digitale Rijksbouwmeester komt niet uit de verf als het niet duidelijk is wie bij de overheid feitelijk over de architectuur gaat: de kerndepartementen of de uitvoeringsorganisaties. De laatsten zien zichzelf als dé business, terwijl de kerndepartementen denken dat zij bepalen hoe de uitvoering moet werken. In de praktijk werkt het veel productiever als uitvoeringsorganisaties elkaar opzoeken en samen oplossingen creëren.
www.via-nova-architectura.org
januari 2010
18
•
Visualisaties, zeker in handen van de mensen die het contact met de klant hebben, kunnen helpen bij het maken van keuzes in de architectuur, maar moeten wel hun fundament krijgen in uitgangspunten die samen met de lijnmanagers worden vastgesteld.
Ten slotte wil ik de deelnemers aan deze rondetafelconferentie bedanken voor hun actieve inbreng in de discussie.
www.via-nova-architectura.org
januari 2010
19
