Daan, 
 
 
Een paar punten. 
 
Goed dat je, als outsourcing-man, geen outsourcing adviseert. Outsourcing kan geen soelaas bieden als de organisatie die sourcing buiten de deur brengt niet in staat is om strakke regie over haar leverancier te voeren. Niet doen als je het zelf niet zou kunnen doen is het algemene devies, en er zijn maar weinig organisatie die het zelf zouden kunnen. Daarbij is het de vraag of veel organisaties ooit willen (kunnen) outsourcen, zeker als IT zich naar behoren ontwikkeld (wat nog nauwelijks het geval is). 
 
Je spreekt over IT-governance. Dat is feitelijk tactisch niveau management. IT-governance dient te passen binnen een goed corporate governance. De echte sturing op een technologie als IT ligt vanuit het bedrijfsmiddel informatie, en dus buiten de IT. De praktijk laat zien dat de problemen vooral bij de Corporate Governance rond informatie van een organisatie liggen, dus buiten de IT. Dat wil niet zeggen dat de IT wel goed gemanaged wordt, en als ik de verhalen mag geloven is de huidige miser daar gemaakt. Maar IT dient zich bij haar leest te houden. 
 
Je advies om een sterke raad van externen in te stellen lijkt een minder gelukkig advies. De Belastingdienst valt onder het Ministerie van Financiën en ondersteunt mensen binnen de Belastingdienst die doen waar de Belastingdienst voor is: belasting innen. Dat is de vraagkant waar men gebruik maakt van faciliteiten die onder meer door IT geboden worden: de IT-aanbodkant. Zo’n adviesraad zal van (“eigendom”) het Ministerie van Financiën cq de Belastingdienst moeten zijn, dus van de vraagkant. Daar kan je externe specialisten aan toevoegen, maar het eigendom kan alleen bij de vraagkant liggen en niet bij een groep externen. Als de Belastingdienst inderdaad niet in staat is om de goede krachten die zij hebben te richten, dan zullen ze daar zelf voor moeten zorgen. En daar dus ook verantwoordelijk voor moeten zijn, waarbij zij hulp kunnen inschakelen. Je lijkt hier te adviseren om veel van de IT-governance bij externen neer te leggen. Het klinkt als een ander niveau van outsourcing (outsourcing van IT-management over eigen IT-activiteiten???), maar wel een die een onwenselijke situatie zou laten ontstaan. 
 
Je hebt gelijk dat de “grachten en rivieren” van NORA niet goed kunnen werken als leidraad. NORA blijft steken in IT, en, hoe goed sommige dingen ook neergezet zijn, kan niet anders dan tijdelijk zijn.  
 
En dan als laatste: er zal niet zoveel behoefte zijn aan IT specialisten om dit alles te doen en te regelen. Die passen immers aan de IT-aanbodkant. Men heeft aan de vraagkant kracht nodig, en die zal bij de echte informatiekundigen vandaan moeten komen. Dat zijn geen IT-ers, en er zijn voor dat soort mensen dan ook vrijwel geen opleidingen. 
 
 
Steven van ’t Veld 
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it

Daan, 
 
Architectuur en IT governance zijn onverbrekelijk met elkaar verbonden. Architectuur kan niet succesvol zijn wanneer de IT governance niet is geregeld en IT governance gaat nergens over wanneer deze niet is gebaseerd op gedegen en haalbare blauwdrukken van de gewenste informatievoorziening. Ik wil in mijn reactie eerst ingaan op de samenhang tussen IT governance en Architectuur en daarna de relatie leggen met de Belastingdienst. 
 
IT governance is het besluiten over de richting en inrichting van bedrijfsprocessen, informatiesystemen en IT infrastructuur. Hierbij moeten twee gezichtspunten worden onderscheiden. Een business manager is verantwoordelijk voor het operationele proces en wordt afgerekend op de resultaten van dat proces. Dat kunnen resultaten zijn op afdelingsniveau, op het niveau van een business unit of op ondernemingsniveau. In dat laatste geval zijn de resultaten zichtbaar in de jaarrekening en in de waardering van aandeelhouders op de beurs. In een “going concern” situatie werkt een business manager met ingerichte processen, systemen en infrastructuur. Hij zal voortdurend op zoek gaan naar mogelijkheden om de resultaten te verbeteren, bijvoorbeeld door de bedrijfsprocessen te optimaliseren, maar ook door product- en procesinnovatie toe te passen. Dit brengt vaak met zich mee, dat bedrijfsprocessen anders moeten worden ingericht, met consequenties voor de informatiesystemen en de IT infrastructuur. Het managen van deze veranderprocessen vereist andere competenties dan het managen van de reguliere bedrijfsprocessen. Deze managementrol wordt vaak aangeduid als verandermanager, maar termen als inrichtingsmanager, informatiemanager komen ook voor. Beperkt de verandering zich tot de informatiesystemen en de IT infrastructuur dan acteert de IT manager of een van zijn ontwikkelmanagers als verandermanager. Belangrijk is, dat de business manager en de verandermanager samen het veranderproces besturen, ieder vanuit de eigen verantwoordelijkheid en deskundigheid. De business manager stelt het doel van de verandering vast, is verantwoordelijk voor de business case en stelt de (financiële) middelen beschikbaar voor het uitvoeren van het veranderproces. De verandermanager is verantwoordelijk voor het inrichten van het veranderproces en organiseren van de benodigde competenties om dit proces tot een goed einde te brengen.  
 
Besluitvorming over de inrichting van bedrijfsprocessen, informatiesystemen en IT infrastructuur vindt plaats op verschillende niveaus in een organisatie. De generieke driedeling strategisch, tactisch en operationeel niveau is bruikbaar, mits toegesneden op de betreffende organisatie. Op het strategische niveau beslissen de algemeen directeur en de CIO over de te stellen doelen en de richtlijnen waarbinnen de verandering van bedrijfsprocessen, informatiesystemen en IT infrastructuur moet worden uitgevoerd. Op tactisch niveau beslissen business managers, samen met het verandermanagement, over het verwerven en inzetten van de middelen die nodig zijn om de veranderprocessen uit te voeren. En op het operationele niveau worden de veranderprocessen daadwerkelijk uitgevoerd, waarbij de uitvoering vaak in handen wordt gelegd van een projectmanager. Maar deze projectmanager wordt weer aangestuurd door de meest betrokken business manager (senior user) en een manager uit de veranderorganisatie (senior supplier). 
 
Op alle drie de niveaus moet de besluitvorming worden voorbereid door professionals die zicht hebben op de complexiteit en samenhang van bedrijfsprocessen, informatiesystemen en IT infrastructuur. Omdat er al van oudsher een parallel wordt getrokken met de wereld van de fysiek gebouwde omgeving noemen we deze professionals architecten, of – om het onderscheid met die fysieke wereld duidelijk te maken – digitale architecten. Op het strategische niveau stelt de digitale architect een bestemmingsplan op. Een belangrijk onderdeel daarvan is het afbakenen van business domeinen met daarin samenhangende clusters van bedrijfsprocessen en informatiesystemen, en technologiedomeinen met daarin samenhangende clusters van (gemeenschappelijk te gebruiken) informatiesystemen en IT infrastructuren. Op basis van het bestemmingsplan wordt voor ieder domein een business manager aangewezen die, samen met een verandermanager, verantwoordelijk is voor het managen van de bedrijfsprocessen, informatiesystemen en IT infrastructuren binnen dat domein, en dus ook voor de vernieuwingen of noodzakelijke aanpassingen (IT governance op het tactische niveau). Om op dit niveau de koers uit te stippelen en prioriteiten te stellen zal aan een digitale architect (in dit geval een domein architect) worden gevraagd een meer gedetailleerd plan op te stellen. Op basis van dit plan kan worden besloten projecten op te starten en de besturing daarvan in handen te leggen van een project stuurgroep.  
 
Tot nu toe heb ik de begrippen bedrijfsproces, informatiesysteem en IT infrastructuur steeds in samenhang gebruikt. Je kunt hierin een tweedeling aanbrengen. Aan de ene kant zijn er dan de bedrijfsprocessen en de informatiesystemen die op maat zijn gemaakt om die bedrijfsprocessen te ondersteunen. Aan de andere kant is er de IT infrastructuur en de informatiesystemen die verschillende bedrijfsprocessen – in verschillende business domeinen – ondersteunen. Deze tweedeling weerspiegelt het gezonde spanningsveld dat er binnen iedere organisatie moet bestaan tussen enerzijds effectiviteit van de bedrijfsprocessen en anderzijds de doelmatigheid van de daarbij in te zetten technologie. Dit spanningsveld kan alleen goed gemanaged worden door IT governance in te richten op het strategische niveau.En omdat de pendule in de loop van de tijd heen en weer slingert tussen effectiviteit (business management beslist) en doelmatigheid (vanuit de top wordt druk gezet op IT om de kosten te verminderen) is het belangrijk een lange termijn visie te laten ontwikkelen door digitale architecten. 
 
Bij de Belastingdienst zijn er (ten minste) twee organisaties die een verantwoordelijkheid hebben bij de inrichting van bedrijfsprocessen, informatiesystemen en IT infrastructuur. Dat zijn CP P - het Centrum voor proces- en productontwikkeling, en CICT - het Centrum voor informatie- en communicatietechnologie. Dit is een klassieke opdeling van taken die ook in het bedrijfsleven niet ongebruikelijk is. Vanuit een integrale benadering van het veranderproces is deze situatie echter ongewenst. Het verandermanagement zal moeten liggen binnen CPP, maar veel besluiten die een verandermanager - samen met een business manager - moet nemen in het kader van de IT governance raken de hele keten, dus niet alleen de bedrijfsprocessen, maar ook de informatiesystemen en IT infrastructuur. De architecten binnen CP P die de verandermanager moeten adviseren zijn bedrijfsarchitecten en kunnen de samenhang met informatiesystemen en ICT infrastructuur niet overzien. CICT voert omvangrijke IT projecten uit en beschikt daartoe over een groot aantal professionals, waaronder ICT architecten. Het management van CICT heeft een groot belang bij het laten slagen van deze projecten en zal daarom een belangrijke rol in het verandermanagement claimen. In theorie kan horizontaal en collegiaal bestuur werken, in de praktijk gaat er niets boven het stellen van duidelijke verantwoordelijkheden en bevoegdheden. Vanuit deze optiek onderschrijf ik dan ook het voornemen van Jan Kees de Jager om een “ICT regie en architectuur” organisatie in te richten. Deze organisatie moet dan verantwoordelijk worden gesteld voor het (integrale) verandermanagement en worden ondersteund door digitale architecten. Voor de bemensing van deze organisatie zal ongetwijfeld geput worden uit het management en de professionals van zowel CP P als CICT. Maar voorkomen moet worden dat er binnen “ICT regie en architectuur” twee bloedgroepen ontstaan. Dat kan bijvoorbeeld door tijdelijk een aantal professionals vanuit het bedrijfsleven mee te laten werken, door de organisatie een duidelijk charter mee te geven en door bijzonder veel aandacht te besteden aan het integratieproces. Er moet een enthousiast team worden geformeerd dat met visie en daadkracht de complexiteitsreductie daadwerkelijk gestalte geeft. 
 
Paul Laagland ( This e-mail address is being protected from spam bots, you need JavaScript enabled to view it ) 
Organisatieadviseur

Wat is er nu eigenlijk precies aan de hand? 
Zit het bestuurlijk gezien mis? 
Laat ‘de’ ICT te wensen over? 
Is ‘de’ cultuur disfunctioneel geworden? 
Missen we iets ‘anders’? Missen we ‘het’ punt wellicht? 
 
Spelen maatschappelijke ontwikkelingen ons parten? 
Is het de als maar verder doordringende informatiemaatschappij? 
Bestaat de overheid daar eigenlijk (nog) wel? En ‘haar’ onderdanen? 
 
En… zitten vele andere (overheids)organisaties niet in zo’n zelfde schuitje? Zo vraagt Daan zich min of meer af. 
 
Heeft iemand qua diagnose al eens – een flink stuk – verder gekeken dan traditionele neuzen lang zijn? 
 
De trein moet weer op de rails – stelt Daan. Oké… maarre… Welke trein? Welke rails? Wie figureren in zo’n nieuwe situatie als verkeersdeelnemers? Als deelnemers aan robuust informatieverkeer? Zijn dat de nu onderling afhankelijke overheidsinstanties, bedrijven en individuen? Of denken (en werken) we nog steeds traditioneel – oud en vertrouwd? 
 
Neem ook eens – vrijblijvend natuurlijk! – een kijkje op: Leuker kunnen we het wèl maken! (http://www.emovere.nl/?doc=53) en sta uzelf toe (of niet; u kiest) weer een stapje verder los te komen uit het oude en vertrouwde. 
 
Jan van Til 
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it

@ Paul 
 
 
Je hebt het hier vooral over IT-architectuur (ook wel Enterprise Architectuur of enterprise IT Architectuur). Die zijn inderdaad sterk verbonden met IT-governance en met wat jij hier informatiesysteem architectuur en IT-infrastructuur architectuur noemt.  
 
In je betoog mis je echter een groot stuk aan de vraagkant, namelijk het beeld dat je en de kennis die je moet hebben van de informatie waar een organisatie behoefte aan heeft. Daar ligt het probleem op dit moment in vrijwel elke organisatie omdat er nog nauwelijks iets mee wordt gedaan. Daarmee wordt “smart buyership” cq. “smart exploitatie” t.a.v. IT haast onmogelijk omdat je zonder onderbouwing geen echte regie over de inzet en exploitatie van IT kunt voeren. Dat is juist ook de architectuur die mist, en die in de door Jan-Kees aangekondigde “afdeling” “ICT-regie en Architectuur” bedoeld moet zijn.  
Daarmee sluit ik niet uit dat er problemen in de IT-architectuur zitten, en ook in de buiten de IT-wereld horende architectuur die je bedrijfsproces architectuur noemt. Maar die zijn van een kompleet andere orde, zoals het betoog van Hans hier ook laat zien. 
 
 
Steven van ’t Veld  
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it

‘Ik houd wel van uitdagingen’ aldus Jan Kees de Jager in een interview met Douwe Douwes in de Volkskrant van 1 maart 2008 op pagina 17. Hoewel de Volkskrant simpelweg stelt dat de Belastingdienst blunderde, weet Jan Kees dat te relativeren tot ‘dingen hadden anders gemoeten’. Ach ja, de Fransen zouden zeggen: ‘het is de toon, die de muziek maakt’. 
 
Hoogst opmerkelijk vind ik de opmerking van Jan Kees: ‘Toen ik ‘ja’ zei (tegen de functie van staatssecretaris, belast met de Belastingdienst) wist ik nog niet dat een week voor mijn aantreden Gerrit Zalm had gezegd dat er grote ict-problemen waren bij de Belastingdienst.’ Als ITer begrijp ik dat niet. Ik zeg nooit in het wilde weg ‘ja’. Ik wil eerst weten wat de scope is van de betreffende uitdaging. Maar wellicht is dat de reden dat ik niet in de politiek zit. 
Maar ik mag toch wel aannemen dat Jan Kees bij de start van zijn ambtstermijn wel wist dat er grote problemen waren. Waarom heeft hij toen niet als allereerste daad een legertje externe IT-auditors ingehuurd om de hele erfenis eens grondig door te lichten of een zeer expliciete opdracht aan de Rekenkamer verstrekt? Afijn, na een half jaar werd het Nederlandse bedrijfsleven verrast met de eerste grote IT-misser in het JanKees-tijdperk: de subWalvis affaire. Van de zelfde soort trouwens als de huidige misser. Ging er na dat eerste halfjaar bij Jan Kees geen belletje rinkelen om alsnog dat legertje externe IT-auditors door de Belastingdienst heen te jagen? Zal er nu, na een jaar ambtstermijn wel eindelijk dat legertje externe IT-auditors aan het werk worden gezet of gaan we weer zitten wachten op het volgende IT-drama bij de Belastingdienst? Ik vind dat nu de douane aan de beurt is. 
 
Op de slimme vraag van de Volkskant journalist of Jan Kees het ‘horizontaal-collegiaal’ sturen nu gaat afschaffen, geeft Jan Kees als antwoord dat hij de processen en de systemen wil gaan verbeteren. Ik zou zeggen dat dat ‘horizontaal-collegiaal’ sturen dan maar moet als men dat gezellig vindt, maar in de IT-Governance moet de hiërarchie als de donder weer worden hersteld. Het lijkt mij immers wel zo praktisch om de kraan dicht te draaien alvorens je begint met dweilen. 
 
Vervolgens probeert de Volkskrant journalist met een briljante vraag Jan Kees uit zijn tent te lokken: ‘Managementregel één is dat je de rotzooi in een organisatie niet kunt opruimen met de mensen die haar hebben veroorzaakt. U laat de leiding van de Belastingdienst wel zitten.’ Daarop antwoordt Jan Kees: ‘Het is moeilijk vast te stellen wie de rotzooi in deze heeft veroorzaakt’. Maar daarvoor heb je toch die externe IT-auditors nodig, zou ik zeggen. Althans, dat lijkt mij logisch. Jan Kees vervolgt: ‘De Kamer was deze week eerlijk. Men trok zelf voor een deel het boetekleed aan, dat heb ik ook gedaan namens het kabinet. De politiek in brede zin draagt verantwoordelijkheid voor een dienst die dingen te snel over zich heen kreeg.’ Dit antwoord komt mij wat al te simpel over en heeft niets maar dan ook helemaal niets te maken met het probleem van afgelopen week. Of heet dit een politiek correct statement te zijn? Maar in het geval van vernieuwingen/projecten zou mijn eenvoudige vraag luiden: wie is de uiteindelijke opdrachtgever? Wellicht de staatssecretaris zelf of de DG of een andere hoge ambtenaar bij DG/Bel. Wie is de echte opdrachtnemer? De IT-directeur, lijkt mij. Dus wellicht de hoogste functionaris bij B/CICT?. Laat de opdrachtgever en de opdrachtnemer elkaar eens recht in de ogen kijken, eerlijk opbiechten wat er aan de hand is en vervolgens met behulp van bekwame externe experts de trein weer op de rails proberen te zetten. 
 
Als laatste poging om toch nog enig licht te krijgen in deze diepe duisternis, stelt de journalist van de Volkskrant: ‘Het management heeft nooit gezegd: Dit wordt ons te veel.’ Jan Kees reageert op deze ultieme vraag met de opmerking dat op dat moment iedereen ervan overtuigd was dat het kon. Hoe kan iedereen daarvan overtuigd zijn, terwijl een half jaar tevoren we dezelfde soort ramp hadden. Jan Kees vervolgt met te stellen dat de dienst draaide als een geoliede machine. Wist/weet hij nu werkelijk niet hoe de vlag er voor stond/staat? 
 
Ik vind het trouwens vreemd dat Jan Kees in dit interview niet de nadruk legt op de behoefte aan goede, nuchtere, zakelijke architecten. Zijn collega Guusje ter Horst heeft dat immers op 25 februari 2008 laten weten aan de Tweede Kamer: http://www.minbzk.nl/actueel/110815/brief-aan-de-tweede_0. En met bruikbare architectuur bedoel ik echte architectuurprincipes en veel visualisaties waarmee eenvoudige managers weer inzicht krijgen in de problematiek.

Daan, 
 
Bij deze mijn zienswijze... 
 
Enterprise architecten: professionaliseer de opdrachtgevers  
van te ontwikkelen informatiesystemen bij de Belastingdienst  
in het stellen van kwaliteitseisen. En maak daarbij eens visualisaties! 
 
 
1. De huidige situatie 
De Belastingdienst verricht taken op de volgende gebieden (zie bedrijfsplan van de Belastingdienst): 
- heffing, controle en inning van rijksbelastingen; 
- toezicht op de in-, uit- en doorvoer van goederen; 
- toezicht op de naleving van wetgeving op economisch 
-, gezondheids-, milieu- en veiligheidsterrein, economische ordening en financiële integriteit; 
- heffing en inning van premies volksverzekeringen en werknemersverzekeringen; 
- toekenning van en controle op inkomensafhankelijke toeslagen; 
- opsporing op al de hierboven genoemde terreinen. 
 
In deze taken is zoals ik het zie maar één grote variabele: de jaarlijks veranderende wet- en regelgeving. Bij het uitvoeren van deze taken moet iedereen daar wel voldoende rekening mee houden. Bij deze taken staat overigens niets over het zelf ontwikkelen van software!  
Alle taken bij de Belastingdienst worden ondersteund met geautomatiseerde informatiesystemen. Iedereen, (politiek, bestuur, directie, management, werknemers en de belastingbetaler) zou hoge eisen moeten stellen aan deze informatiesystemen, omdat anders het uitvoeren van de taken in gevaar kan komen. We weten allemaal (ook niet IT-ers) dat het continu doorontwikkelen van een informatiesysteem door een leverancier complexiteitsverhogend en kwaliteitsverlagend werkt als we als afnemer niet streng toezien op de ontwikkeling.  
 
Volgens mij is er dan ook maar één hoofdprobleem bij de Belastingdienst.  
 
De mensen die werken bij de Belastingdienst zijn zeer kundig in het uitvoeren de primaire taken van de Belastingdienst. Het zelf plannen, ontwikkelen en beheren van de ondersteunende IT-middelen, een ondersteunende taak van de Belastingdienst, verloopt redelijk, maar niet goed genoeg. De informatiesystemen die men er maakt zijn redelijk van kwaliteit, alleen gunt men zichzelf onvoldoende de tijd kinderziektes eruit te halen, en worden ze veel te vroeg voor productie gebruikt. De kwaliteit van informatiesystemen bij de Belastingdienst blijk in de praktijk uitmuntend te moeten zijn, in plaats van redelijk. 
 
 
2. Het hoofdprobleem 
Het hoofdprobleem bij de Belastingdienst zou men als volgt kunnen omschrijven: 
De politiek, het bestuur, de directie, het bedrijfsmanagement van de Belastingdienst en de belastingbetaler stellen onvoldoende hoge functionele en technische kwaliteitseisen aan de ondersteunende IT-middelen (met name de informatiesystemen) die door B/CICT worden ontwikkeld. Deze oorzaak zorgt er voor dat de informatiesystemen worden ontwikkeld tegen in de praktijk gebleken te lage functionele en technische kwaliteitseisen (het directe gevolg). De informatiesystemen worden conform de functionele en technische kwaliteitseisen getest en in productie genomen.  
Nu de belastingbetalers in Nederland ook de problemen ondervinden van de te lage kwaliteit van de informatiesystemen (het indirecte gevolg), is er momentum voor de enterprise architecten en opdrachtgevers van de informatiesystemen om orde op zaken te stellen.  
 
 
3. Voorbeelden van te stellen eisen 
Een voorbeeld van tien eisen die de politiek, het bestuur, de directie en het bedrijfsmanagement van de Belastingdienst volgens mij zouden moeten gaan stellen aan het ontwikkelen van informatiesystemen voor de Belastingdienst, zijn: 
1. De informatiesystemen bij de Belastingdienst moeten van een hogere kwaliteit zijn (beter uitontwikkeld, en meer doorgetest) dan de standaard eindgebruikersoftware voor kantoorautomatisering en boekhouden die in de winkel te koop is. De informatiesystemen moeten bijvoorbeeld zeer stabiel zijn, nooit gegevens kwijt raken, gebruikers wijzen op onbedoeld verkeerd gebruik, ongeoefende gebruikers beschermen tegen zichzelf, zich netjes gedragen op de IT-omgeving, op basis van standaarden communiceren met andere informatiesystemen, uitgebreid configureerbaar zijn en zijn voorzien van voldoende helpinformatie en opleidingen. De informatiesystemen moeten veel beter beveiligd zijn tegen virussen en bugs dan gewone standaardkantoorautomatisering. 
2. Een goed opgeleide functioneel beheerder moet in staat zijn veranderde wet- en regelgeving te kunnen invoeren of aanpassen in een informatiesysteem. Hij moet ook in staat zijn in basis de functionele en technische werking van het informatiesysteem te begrijpen. Hij moet betrokken zijn bij de ontwikkeling van het informatiesysteem. 
3. De nieuwe instellingen (regels van wetgeving) in een informatiesysteem moeten kunnen worden getest, los van de productie. 
4. Een informatiesysteem moet altijd zijn opgebouwd uit ‘losse’ vervangbare en herbruikbare modulen om de complexiteit van een informatiesysteem zo laag als kan en beheersbaar te houden. Een informatiesysteem mag niet meer informatiefuncties hebben dan die door het management kunnen worden overzien. Per module moeten we streven naar één, twee of drie informatiefuncties. 
5. Een informatiesysteem moet altijd zijn opgebouwd uit modulen en submodulen die door meer dan één softwareleverancier worden gebouwd en geleverd.  
6. Een informatiesysteem mag bij de Belastingdienst alleen worden samengesteld uit elders gebouwde modulen. Immers softwareontwikkeling is geen primaire taak van de Belastingdienst. Het testen en beheren van modulen kan wel door de Belastingdienst worden gedaan. Maar het is en wordt geen primaire taak van de Belastingdienst. 
7. Een nieuw informatiesysteem mag pas in productie worden genomen als het zich gedurende één jaar in één provincie van Nederland goed heeft proefgedraaid.  
8. Voor nieuwe modulen in een bestaand informatiesysteem geldt een termijn van drie maanden. 
9. Alle dienstverleningsketens over informatiesystemen moeten altijd een eigen besturing hebben. Een informatiesysteem moet aan een digitale verkeerstoren (een centraal bewakingsysteem) inzichtelijk maken waar het aan werkt en welke onderdeel het vormt van een dienstverleningsketen. 
10. Een informatiesysteem en de modulen van het informatiesysteem moeten altijd een eigenaar hebben, een beheerder en onder controle staan van een bewakingsysteem. 
 
 
4. Impliciete behoefte en ontbrekende wetgeving 
De hier genoemde eisen zijn eisen die onder andere terugslaan op de behoefte van gebruikers. Alleen vergt het wel veel ervaring om deze behoefte duidelijk te maken bij de gebruikers zelf. De rationale (achterliggende reden of onderbouwing) is meestal in eerste instantie niet duidelijk voor de gebruikers. Een eis moet eenvoudig door een functioneel beheerder te snappen zijn. Woorden zoals product, proces, principe, concept, klant, model, regel, architectuur en view zijn in deze verboden woorden voor de formulering van eisen. Als je ze toch gebruikt in eisen, zullen ze als containerbegrip dienst doen. 
 
Als het aan mij ligt worden dergelijke geschetste voorbeeldeisen tot wettelijke eisen verheven. Het ontwerpen en bouwen van een auto, vliegtuig of een huis moet immers ook volgens wettelijke eisen en regels. Het ontwerpen en bouwen van een informatiesysteem niet. In ieder geval niet in die mate! 
Een probleem met de hier bedoelde kwaliteitseisen is vaak: wie gaat dat betalen? Als we wettelijke eisen hebben, is die vraag eenvoudig te beantwoorden, of sterker nog: de vraag wordt niet meer gesteld! 
 
 
5. Het stappenplan 
Er is vanaf morgen voor de komende maand maar één taak voor de enterprise architecten bij de Belastingdienst: 
 
1. Het professionaliseren van de opdrachtgevers voor te ontwikkelen informatiesystemen 
a. Welke functionele kwaliteitseisen zou men kunnen en moeten stellen 
b. Welke technische kwaliteitseisen zou men kunnen en moeten stellen 
c. Welke eisen zouden wettelijke eisen kunnen en moeten worden 
 
Om dit professionaliseren te kunnen doen, dient de enterprise architect te beschikken over het vermogen om de taal van de gebruikers en de opdrachtgever te spreken. Maar vooral hun wereld te kunnen visualiseren: Het maken van architectuurvisualisaties zoals structuurvisies, blauwdrukken, artist impressions en situatieschetsen. De enterprise architect moet immers naar niet-inhoudelijk deskundigen met beelden afgestemd op hun begripsniveau duidelijk kunnen maken wat de impact is van het stellen van onvoldoende hoge kwaliteitseisen. Bijvoorbeeld elk van bovenstaande voorbeeldeisen in begrijpelijke visualisaties omzetten. Iets wat men nu vaak doet en wat juist averechts werkt is het maken van documenten die meer dan honderd pagina’s dik zijn en door geen enkele functioneel beheer worden begrepen. De visualisaties in deze documenten zijn vaak technische krabbels die pas na een informatica studie duidelijk worden. 
 
Helaas is hier dus nog een hele weg te gaan. In de praktijk zijn de meeste enterprise architecten nog geen serieuze gesprekspartner voor politici, bestuurders, directie en management en daarnaast zijn de meeste enterprise architecturen ongeoefende tekenaars. 
 
Mijn boodschap is dus: 
1) Enterprise architecten: professionaliseer de opdrachtgevers van te ontwikkelen informatiesystemen bij de Belastingdienst in het stellen van kwaliteitseisen! 
2) Enterprise architecten: ga eerst eens oefenen in het visualiseren van de toekomstige behoefte van een gebruiker en de te stellen eisen aan een informatiesysteem door een opdrachtgever! 
3) Opdrachtgevers: vraag om begrijpelijke architectuurvisualisaties van enterprise architecten, en geef ze als voorbeeld een informatiemap mee van een woonwijk die onder architectuur is gebouwd! 
 
 
 
Mark Paauwe ( This e-mail address is being protected from spam bots, you need JavaScript enabled to view it ) 
 
Promovendus bij Daan Rijsenbrij en Erik Proper op het gebied van architectuurvisualisaties, architectuurprincipes en enterprise architectuurmethoden

De belastingdienst op weg naar ‘Basisregistratie’ status? 
 
Bijna alles is al gezegd in de discussie rond de IT (en besturing) problemen van de belastingdienst. Ik wil nog één facet aan de discussie toevoegen.  
 
Het lijkt erop dat de inrichting van de belastingdienst een ‘intern’ feestje is met zelfsturende teams, gericht op realisatie van overheidsregelgeving en interne probleemoplossing, maar niet op klantsatisfactie. Een externe prikkel (hoe tevreden wordt de burger? Het bedrijf?) lijkt helaas niet meer de drijfveer voor bedrijfsstrategie, inrichting en automatisering van de dienst te zijn.  
Laat de belastingdienst weer maatschappij gerichte ambities formuleren en deze als verantwoordelijk ‘ondernemer’ gaan realiseren. Dit geeft een betere dynamiek en leidt vaak tot volwassener oplossingen. 
De overheid zelf geeft hiervoor een leuk handvat. 
 
Basisregistraties. 
 
Strategisch wordt binnen de overheid gewerkt aan het opzetten van basisregistraties waarmee alle overheidsdiensten (en ook burgers en bedrijfsleven) bediend worden t.a.v. relevante informatie en informatiegerichte processen. De Belastingdienst staat gepositioneerd om op termijn beheerder van één van die basisadministraties te worden.  
 
Niets wijst erop dat de dienst zich daarop aan het voorbereiden is. Zou zij dat wel doen, dan helpt hen dat in de professionalisering van zowel de eigen business als IT. De registratie heeft namelijk een extern maatschappelijk doel (lastenbeperking en ‘makkelijker maken’ van de (elektronische) overheid processen.) 
 
Rond de basisadministraties zijn inmiddels zeer goede en helder geformuleerde spelregels opgesteld. Deze kennen en implementeren zou voor de Belastingdienst een hulp kunnen zijn bij het uitgroeien boven het paniekvoetbal spelend fout op fout stapelend overheidsorgaan dat de dienst nu lijkt te zijn.  
 
Ter adstructie het volgende: 
 
De overheid heeft om te beginnen zes basisregistraties (authentieke registraties) aangewezen en daarvoor de nodige wet en regelgeving geschreven. Het gaat over het gebruik van gegevens en informatie binnen de overheid en de standaardisatie van de communicatie tussen organisaties van die overheid onderling, en met de burger en het bedrijfsleven.  
 
De eerste zes basisregistratie die binnen het stelsel zijn of worden gerealiseerd zijn: 
1. Gemeentelijke Basis Administratie voor Persoonsgegevens (GBA)  
2. Basisregistratie Ondernemingen & Andere Organisaties (KvK) 
3. Basis Gebouwen Registratie (BGR) 
4. Basisregistratie Kadaster (Kadaster) 
5. Basisregistratie Topografie (Kadaster) 
6. Basis Registratie Adressen (BRA) 
 
Op termijn worden andere informatie gebieden aangewezen om als basisregistratie te gaan werken. Nu al werden onderkend: 
1.de kentekenregistratie van de RDW  
2.de polisadministratie door UWV (uitvoeringsinstituut werknemers verzekeringen)  
3.de inkomens- en vermogensregistratie bij de Belastingdienst  
4.de registratie van niet-ingezetenen  
5.de Grootschalige Basiskaart Nederland  
6.Data en Informatie Nederlandse ondergrond (DINO) 
 
(Wellicht komen daar later nog andere informatiegebieden bij zoals: 
1.Medische dossiers 
2.Persoonlijke financiële situatie 
3.Persoonlijke identificatie (DNA, vingerafdruk, oogbal, RFID…) 
Maar dat wordt wellicht te privé en zal de toets der privacybewakers wel niet doorstaan… Hoewel: een landelijk elektronisch patiëntendossier wordt al heel lang gewenst…) 
 
De overheid heeft voor basisregistraties, de uitvoerende organisaties en het gebruik van die informatie goede regelgeving gecreëerd. In tegenstelling tot de NORA zijn deze regels praktisch, verhelderend en zeer goed toepasbaar bij het realiseren van oplossingen. In die wetgeving staat o.a.: 
 
1) De registratie is bij wet geregeld. (en iedereen hoort de wet te kennen…) 
2) De afnemers hebben een terugmeldplicht. 
3) De authentieke registratie wordt verplicht gebruikt door de hele overheid en de als authentiek aangewezen gegevens kunnen in de werkprocessen zonder nader onderzoek gebruikt worden. 
4) Er is duidelijkheid over de aansprakelijkheid. 
5) De realisatie en exploitatie geschieden tegen redelijke kosten en er is eenduidigheid over de verdeling ervan. 
6) Er Is duidelijkheid over inhoud en bereik van de registratie. 
7) Er zijn sluitende afspraken en procedures tussen de houder enerzijds en de leveranciers van gegevens en de afnemers anderzijds. 
8) Er zijn duidelijke procedures met betrekking tot de toegankelijkheid van de authentieke registratie. 
9) Er is een stringent regime van kwaliteitsborging. 
10) Er is vastgelegd dat en hoe afnemers van gegevens op een niet vrijblijvende wijze betrokken worden bij de besluitvorming betreffende de authentieke registratie. 
11) De positie van de authentieke registratie binnen het stelsel van authentieke registraties is duidelijk gemaakt en de relaties met de basisregistraties zijn beschreven. 
12) De zeggenschap over de authentieke registratie berust bij een bestuursorgaan en er is een minister verantwoordelijk voor het realiseren respectievelijk functioneren van de betreffende authentieke registratie. 
 
Verder zijn er initiatieven genomen tot verdere standaardisatie van sleutels en andere relevante informatie en interfaces. Hier valt o.a. onder: 
 
·Invoering Burger Service Nummer en Bedrijvennummer als landelijke sleutels. 
·Standaard berichtendefinities van & naar basisregistraties  
·Standaardisatie inhoudelijke berichten naar Belastingen, CBS en KvK (later volgen meer partijen). Dit laatste gebeurt binnen Het Nederlands Taxonomieproject (XBRL) en moet leiden tot een éénmalige en eenduidige interface van bedrijven naar de overheid. (en nieuwe intermediaire partijen…) Voor meer informatie zie: http://www.xbrl-ntp.nl/ 
·Opzetten Persoonlijke Internet Pagina (PIP) voor iedere burger in Nederland. 
 
Die PIP is nog nauwelijks bekend, maar er wordt al mee geëxperimenteerd. De bedoeling: Iedere burger (en ieder bedrijf) krijgt een persoonlijke internetpagina waarin men zelf de eigen informatie kan bijhouden en ter beschikking stellen aan de overheid. 
Voeding van de pagina geschiedt dan verder door overheidsdiensten, werkgevers (bv. salaris en loonbelasting gegevens) en wellicht op termijn door leveranciers van diensten: accountants, administrateurs, verzekeraars… De belastingdienst kan dan de informatie halen. Dat geeft een andere dynamiek dan de huidige aangifte (breng) plicht. Zie voor meer informatie: http://www.e-overheid.nl/sites/pip/  
 
Zou de Belastingdienst zich inrichten als Basisregistratievoerder en voldoen aan de daarvoor goed te implementeren spelregels, dan heeft dat een zuiverende werking op de realisatie van de interne bedrijfsprocessen en de daarvoor benodigde automatiseringssystemen. Immers, de regelgeving dwingt eenvoudig af aan welke performance eisen de voerder van de administratie moet voldoen en dit werkt kaderend voor de verdeling van de verantwoordelijkheid voor de te verlenen diensten. 
 
Als dit dan gekoppeld wordt aan eenduidige en eenhoofdige eindverantwoordelijkheid voor deze levering per soort service binnen de belastingdienstorganisatie, dan ontstaat een gezondere besturing die wellicht leidt tot een hoger dienstverleningsniveau. 
 
Niels Klinkenberg, adviseur.  
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it

Is Jan Kees de Jager te optimistisch? 
 
Computable heeft op 7 maart 2008 op de pagina’s 4 en 5 een uitgebreide beschouwing gegeven over de overwegingen van Jan Kees de Jager, onder het kopje ‘De Jager houdt rekening met meer fouten’. Toevallig heb ik zelf in de Automatisering Gids ook van 7 maart 2008 en ook op de pagina’s 4 en 5 een nieuwsanalyse gegeven onder het kopje ‘Is de IT van de Belastingdienst nog betrouwbaar?’, met als subkop ‘Opknappen Belastingdienst mag geen vijf tot tien jaar duren’. 
 
Het valt mij op in het verhaal in Computable dat Jan Kees zijn hoop vestigt op SOA, in het bijzonder op de schaalbaarheid die deze ontwerpbenadering zou kunnen borgen. Nu denk ik persoonlijk dat SOA slechts één antwoord is om de adaptiviteit te borgen. En laten we eerlijk zijn, het gaat om ‘adaptiviteit’ en niet slechts om het beperktere concept van ‘schaalbaarheid’. Gezien de omvang en de toestand van het applicatielandschap van de Belastingdienst gaat een volledige soa-implementatie minstens vijf jaar duren. Ik zou trouwens aan de buitenkant beginnen! 
 
De foutjes die gemaakt zijn bij de Belastingdienst bij het laatste IT-drama hebben echter niets te maken met architectuur. Zoals ik in bovenvermeld artikel in de Automatisering Gids heb weergegeven: fout in de backup-procedure en wellicht een integratietest niet goed genoeg uitgevoerd. 
Hoewel ik een fervent voorvechter ben voor bruikbare architectuur, zegt mijn Hollandse nuchterheid mij dat het zakelijk slimmer is om eerst de problemen te verhelpen die het huidige IT-drama en het drama rond de Walvisaffaire hebben veroorzaakt. Dus pak eerst de IT-Governance aan alvorens een nieuw architectuurconcept toe te passen. Immers de winkel moet open blijven tijdens de verbouwing. 
 
Ik vind het overigens onbegrijpelijk dat in het Computable artikel nog eens wordt onderstreept dat Jan Kees het moeilijke transformatietraject zonder noemenswaardige externe assistentie wil doen. Ik zou dat anders aanpakken, vooral ook gezien de culturele obstakels die er liggen. Ik wens Jan Kees veel sterkte toe met deze moeilijke opgave. 
 
Daan Rijsenbrij 
personal IT-coach en architect in de Digitale Wereld