Prioriteiten
30 september 2009
door: Tim Berkelaar
Informatiseerders ouder dan 40 kennen hem vaak wel: Gert Nielen. Hij was van 1970 tot 1995 hoogleraar Informatiemanagement (dat heette toen nog anders) in Tilburg. Zonder meer de meest inspirerende hoogleraar die ik meegemaakt heb. Hij is nu 83, maar af en toe spreekt hij nog en op LinkedIn publiceert Eksbit (de vereniging van afgestudeerde Tilburgse informatiekundigen) een column van zijn hand (om deze columns te lezen moet u lid worden van de Eksbit groep op LinkedIn).
Ik citeer een (typisch Nieliaans) stukje: “Informatiesystemen hebben een hele reeks eigenschappen, zoals daar zijn: reactietijd, bedrijfskosten, gebruiksvriendelijkheid, betrouwbaarheid, levensduur, flexibiliteit, etc., etc. Bij het inrichten van een informatiesysteem kiezen we voor elke eigenschap een waarde; zo komt de kwaliteit van het systeem tot stand. Dat kiezen kan niet in volledige vrijheid. De keuze voor eigenschap A bepaalt soms mede de waarde van eigenschap B. Neem als voorbeeld veiligheid (security als u wilt) en toegankelijkheid (oftewel gebruiksgemak). Een hoge veiligheid vereist beperkingen in de toegankelijkheid; de waarden voor dit paar moeten dus tegelijk worden gekozen. Het systeem is bovendien nooit maximaal veilig plus maximaal toegankelijk. Bij een tienerdisco zal de toegankelijkheid groot zijn (anders komt er geen tiener) en dus zal de beveiliging het nodige te wensen over laten. Bij verkeersvliegtuigen domineert de veiligheid, en nemen we de beperking aan gemakkelijke toegang voor lief.”
Dit is natuurlijk niet nieuw of buitengewoon verrassend, maar wel fundamenteel.
Laten we met deze notie in het achterhoofd nog eens naar de tien basisprincipes in de NORA (de Nederlandse OverheidsReferentieArchitectuur) kijken. Een NORA-principe is een kenmerk waaraan een dienst geacht wordt te voldoen, om de interoperabiliteit van die dienst te vergroten (zegt het strategisch katern van de NORA).
Een van de basisprincipes stelt de eis dat ‘afnemers niet worden geconfronteerd met overbodige vragen’. Bij dit principe wordt verwezen naar de ‘eenmalige gegevensverstrekking’. Een ander principe stelt de eis dat ‘afnemers erop kunnen vertrouwen dat informatie niet wordt misbruikt’. De dienstverlener moet kunnen garanderen dat informatie alleen toegankelijk is voor bevoegde personen en alleen wordt gebruikt voor het doel waarvoor zij is verzameld. Mooie principes, waar je niet tegen kunt zijn, toch?
Maar, let op, hier worden eisen geformuleerd waartussen de spanning waar Nielen op wijst, bestaat. Je kunt niet maximaal voldoen aan de eis dat gegevens maar één keer aan een willekeurige overheidsorganisatie worden verstrekt en dan overal worden hergebruikt en tevens maximaal voldoen aan de eis dat het niet kan voorkomen dat onbevoegde personen er toegang toe krijgen.
Die spanning is interessant want hij kan leiden tot forse verschillen van inzicht rond concrete te nemen beslissingen met betrekking tot de inrichting van de overheidsinformatiehuishouding. Neem bijvoorbeeld de invoering van het BSN. Dat BSN is natuurlijk heel belangrijk om het mogelijk te maken gegevens die op dezelfde persoon betrekking hebben, uit te kunnen wisselen. Maar door overal hetzelfde persoonsnummer te gebruiken wordt de kans dat er een eigenlijk niet toegelaten koppeling van gegevens plaatsvindt een stuk groter. Of je het BSN een goed idee vindt, hangt af van de vraag wat je het zwaarste laat wegen, hoe groot je de kans op ongelukken acht en hoeveel geloof je in compenserende maatregelen hebt. Rond de invoering van het BSN hebben we in de beleidsvoorbereiding dan ook stevige discussies tussen verschillende betrokkenen gezien. En dat is prima. Nielen leert ons dat echt fundamentele ontwerpbeslissingen altijd beslissingen zijn om een bepaalde eigenschap belangrijker te vinden dan een andere. Je offert iets op. Dat kan maar beter weloverwogen gebeuren en met een besef van wát er is opgeofferd. Even terzijde: het is wel van belang de volledige oplossingsruimte te verkennen. In Oostenrijk bijvoorbeeld worden verschillende persoonsnummers in verschillende overheidssectoren gebruikt. Die zijn echter te koppelen door degene die de geheime sleutel kent waarmee die verschillende persoonsnummers in elkaar zijn te vertalen. Dit maakt uitwisselen van gegevens mogelijk, maar vermindert het risico op een ongeoorloofde koppeling drastisch. Maar deze oplossing scoort waarschijnlijk veel slechter op het criterium ‘implementeerbaarheid’. Dat hebben de Oostenrijkers dan weer op de koop toe genomen.
Het is jammer dat het strategisch katern van de NORA er niet expliciet op wijst dat er spanning kan bestaan tussen de verschillende principes. In zekere zin zijn de 10 basisprincipes een wensenlijstje. Je zult moeten afwegen hoe relevant ze zijn in een concrete situatie. Terecht wordt er in het strategisch katern op gewezen dat NORA geen blauwdruk is die één op één over kan worden genomen. En waar er spanning tussen de principes bestaat zal ook beslist moeten worden welk principe voorrang krijgt. Overal maximaal aan willen voldoen is waarschijnlijk niet zo’n goed idee. Daarbij komt dat er niet alleen spanning bestaat tussen de 10 principes die de NORA formuleert, maar vooral ook tussen die principes en andere ontwerpcriteria. Zoals de vraag hoe lang je wilt doen over het realiseren van een dienst, wat het inrichten ervan mag kosten, of hoe complex je een dienst wilt maken. Een project dat een systeem probeert op te leveren dat maximaal wil scoren op alle NORA principes loopt het risico onbeheersbaar te zijn. De Algemene Rekenkamer waarschuwde een tijdje terug nog voor het willen maken van systemen die aan alle mogelijke wensen voldoen.
Dat is overigens slecht nieuws voor luie informatiemanagers. Het is volstrekte nonsens om in het programma van eisen van een aan te besteden systeem op te schrijven dat het op te leveren product ‘NORA conform’ moet zijn. De NORA is géén set toetsbare standaarden. Je kunt wel toetsen of in het proces om tot een eisenpakket te komen de NORA principes systematisch zijn overwogen. Maar dat proces zit bij degene die de aanbesteding voorbereidt en niet bij de leverancier. De NORA kiest niet, dat zult u zelf moeten doen.
Ook voor de sturing van de realisatie van de gemeenschappelijke informatie-infrastructuur van de overheid levert de NORA geen kader. De NORA zegt niets over de principiële keuzes die daarin moeten worden gemaakt (voor de aard daarvan: zie het BSN voorbeeld), laat staan dat er prioriteiten uit af te leiden zijn. Aan zo’n kader lijkt wel behoefte en eigenlijk zou je van een architectuur mogen verwachten dat het in die behoefte voorziet. Bij een uitwerking in die richting krijgt de NORA een agenderende functie: zij draagt kwesties aan waar bestuurlijk knopen over doorgehakt moeten worden. Dan wordt het echt interessant.