Pieter Wisse
In het bijzonder de opstellen Schakelpunten voor operationele integratie en Schets van technische infrastructuur zijn [als hoofdstukken van het boek Stijlbreuk in bestuur] bedoeld om bestuurders in zo kort mogelijk bestek een algemeen referentiekader voor een specifiek thema te verschaffen. Dat thema betreft technische middelen voor informatievoorziening, maar hun perspectief moet uiteraard bestuurlijk zijn en blijven. Wat bestuurders dus overeind moeten houden, is besef van het secundaire belang van techniek. Anders is de horizon te smal, terwijl de blikrichting ook weleens verkeerd kan zijn. Hoe belangrijk zij ook voor praktische resultaten is, de redenering mag niet met techniek beginnen.
Stel dat een bestuurder overlegt, onderhandelt, enzovoort met een leverancier van informatiediensten en/of -producten. Dat kan een onderdeel uit de eigen organisatie zijn. Of een àndere organisatie. In beide gevallen gaat het toch om een leverancier. In het eerste geval is het een interne, anders een externe.
Wat zowel interne als externe leveranciers vaak delen, is dat zij primair op techniek gericht zijn. Als dat zo is, moet zo'n leverancier hoognodig veranderen. Elke leverancier moet duidelijk kunnen verklaren welke rol met toegevoegde waarde hij voor de informatievoorziening van zijn klant wil èn kan spelen. Als het dus om informatievoorziening voor bijvoorbeeld openbare orde en veiligheid gaat, moet de bestuurder verlangen dat de leverancier inzicht heeft in organisatorische en proceskarakteristieken van …, precies, de openbare orde en veiligheid. Voor de leverancier is dat uiteraard geen doel op zichzelf. Maar voldoende inzicht is nodig als middel voor adequate bijdragen. Voor de openbare orde en veiligheid komt erbij dat diverse klanten en leveranciers afgestemde relaties moeten onderhouden (zie ook Integrale componentenstructuur, § 2). Wat de klanten verenigt zijn de zgn ketenprocessen waaraan ze deelnemen (zie Hoofdlijnen van keteninformatisering). Daar komen dan leveranciers bij, bijvoorbeeld stafafdelingen van de gebruikersorganisaties zèlf, commerciële leveranciers, aparte instellingen voor zgn basisregisters en dergelijke.
De pluriformiteit, keteninformatisering dus, betekent dat twee techniekoriëntaties zinvol zijn. Het is het eenvoudigst ze extern, respectievelijk intern te noemen.
Er is allereerst techniek met zoiets als een externe oriëntatie. Juist de componentenstijl waarborgt (zoveel mogelijk) dat externe techniek beperkt is en blijft tot zgn koppelvlakken. Wat in het algemeen een koppelvlak is, staat in Het verband tussen standaards en componenten (§ 7) toegelicht.
Essentieel voor het nut van een koppelvlak is het conceptuele aspect. Is de uitgewisselde informatie aan weerszijden zinvol? Daar is passende, zeg maar, uitwisselingstechniek voor nodig. Als internettechnologie zijn standaards daarvoor sterk in ontwikkeling. De stand van 2001 is dat consensus groeit over XML als beschrijvingstaal voor informatie. Gestandaardiseerde mogelijkheden voor structurering van, zeg maar, informatie zèlf is echter nog onvoldoende om succesvolle uitwisseling te waarborgen. Daarvoor moet de uitwisseling als proces eveneens standaards kennen. Dergelijke standaards lijken zich uit te kristalliseren onder de noemer van, alweer een afkorting, SOAP. Een grove analogie luidt dat de boodschap met XML vorm krijgt. Dankzij SOAP neemt zo'n boodschap vervolgens de gedaante aan die bezorging via erkend briefverkeer regelt.
De aanduiding XML staat voor eXtensible Markup Language. De toevoeging "eXtensible" is trouwens enigszins misleidend. Als taal voor vormbeschrijving (zgn markup) betekent XML inderdaad een uitbreiding vergeleken met een eerdere internettechnologie. Dat is HTML, of HyperText Markup Language. Onder noemers zoals documentuitwisseling en hergebruik heeft markup echter lang voordat het Internet — of, nauwkeuriger gezegd, het World Wide Web — bestond intensief aandacht gekregen. Dat heeft ooit tot een internationale standaard geleid, de Standard Generalized Markup Language (SGML). HTML is geïnspireerd door SGML. Als internettechnologie is het daarbij sterk vereenvoudigd. En ook XML heeft in diverse opzichten nog niet de uitdrukkingskracht die het oorspronkelijke SGML voor vormbeschrijvingen biedt.
Het acroniem SOAP is ontleend aan Simple Object Access Protocol. Of is het andersom? Leek de afkorting interessant, en is vervolgens een min of meer betekenisvolle naam erbij verzonnen? Hier is relevant dat de 'O' uit het acroniem ook als de 'c' van component kan worden opgevat. Indien hun koppelvlakken op SOAP ingesteld zijn, kunnen componenten 'brieven' uitwisselen. Dankzij een gemeenschappelijke instelling op XML schrijft de afzendende component de boodschap in een vorm die de ontvangende component kan lezen. Of laatstbedoelde component de boodschap ook 'begrijpt,' is weer iets anders. Daarvoor bestaan geen standaards. Dit onderstreept dus opnieuw het belang van conceptuele informatiemodellering.
Nogmaals, de keuze voor XML en SOAP — of voor wat dan ook om koppelvlakken voor de eerstkomende jaren adequaat in te richten — staat niet op zichzèlf. Voorop staat de behoefte danwel noodzaak om informatie uit te wisselen.1 Hoe beperkter de technische standaards (kunnen) zijn, nota bene, nodig voor implementatie van conceptuele standaards, des te groter is de kans dat ze daadwerkelijk door het pluriforme oov-veld geaccepteerd worden. Het omgekeerde werkt trouwens ook. Slanke technische standaards bevorderen conceptuele afstemming.
Let wel dat externe techniek in de Nederlandse verhoudingen, zoals ze onder meer voor openbare orde en veiligheid tot uitdrukking komen, niet eenzijdig door welke partij dan ook vastgesteld wordt. Dat is altijd uitkomst van polderpraat, ofwel onder alle betrokken partijen groeit consensus. De machtigste partijen trekken uiteraard aan het langste eind. Als het goed is, moet dat een 'gevecht' tussen de klanten zijn. De leveranciers doen er juist wijs aan zich bemiddelend op te stellen, dwz gericht op háálbare afspraken. Dat geeft ze constructieve invloed.
Tot zover de externe techniekoriëntatie. Dan is er techniek met wat hier gemakshalve een interne oriëntatie heet. Zoals Het verband tussen standaards en componenten benadrukt, beslist elke organisatie hierover in beginsel zelfstandig. Juist met het oog op eigen voordeel blijkt dan vaak een simpele vuistregel. Die luidt om de externe technische oriëntatie — die immers afgeleid is van primaire karakteristieken van het veld waarop de organisatie, ihb de leverancier, in kwestie opereert — onverdund als uitgangspunt voor de interne technische oriëntatie te kiezen. Dat is wel zo eenvoudig. Wie zo kiest, vermijdt daarmee elke vertaalslag in techniek.
De externe oriëntatie is volgens de componentenstijl per definitie tot koppelvlakken beperkt. Een zgn — interne of externe — leverancier construeert echter ook binnenwerk van componenten. Daarvoor is dus aanvullend die interne technische oriëntatie nodig. Wat daarvoor de meest toekomstvaste aanbevelingen zijn, is veel minder duidelijk dan ze thans voor de koppelvlakken zijn. Het criterium moet daaraan aangepast zijn. Wat bij grote onzekerheid vooral telt, is de vervangbaarheid van technische middelen. Een bepaalde keuze mag nooit zo uitpakken, dat gewijzigd inzicht niet — betrekkelijk eenvoudig — tot noodzakelijke koerswijziging leidt.
Bestuurders moeten zich niet (willen) bemoeien met de keuze vóór of tègen concrete technische middelen. Zij moeten hun bestuurlijke perspectief zonodig verhelderen. En zij moeten erop aandringen dat technische voorstellen is dat perspectief worden toegelicht. Zeker als het om bijdragen van externe leveranciers gaat, behoren bestuurders het accent op (bestuurlijke) doelenrealisatie te plaatsen. Het (technisch) middelengebruik is ondergeschikt.
Bij een interne leverancier is een bestuurder natuurlijk sterker betrokken. Stel dat na de wezenlijke bestuurlijke toets bepaalde middelen volgens de interne technische oriëntatie gekozen zijn. Het gewicht van praktisch succes of mislukking moet vervolgens op de eigen medewerkers van de interne leverancier rusten. Daarvoor zijn het professionals. Wat vaak ontbreekt, is de beslissing voor vernieuwing en de aanzet voor technische consequenties. Voor zo'n beslissing zijn bedoelde professionals niet verantwoordelijk, wat in hun geval nogal eens inhoudt dat ze een afwachtende houding innemen. Daardoor loopt technische achterstand gauw op. Bestuurders moeten dat met strategie doorbreken. Dat lukt samen met medewerkers optimaal door ruimte voor experimenten. Want wat voor specialisten vaak óók essentieel is, is betrokkenheid bij besluitvorming. Hun motivatie daalt, terecht, als zij aan het werk moeten nádat het definitieve besluit over interne techniek genomen is. Een experimenten — het woord zegt het al — moet daarentegen juist dienen ter vóórbereiding van zo'n beslissing. Kortom, de allereerste beslissingen over techniek behelzen optimaal de start van experimenten. Dat is meestal voor vele betrokkenen, bestuurders zelfs nadrukkelijk inbegrepen, avontuurlijk genoeg.
noot
1. Inmiddels geldt ‘dienst’ als algemenere noemer voor gecoördineerde bijdragen door diverse actoren annex componenten. De engelstalige aanduiding voor het referentiekader luidt: service oriented architecture. Zie bijvoorbeeld Enterprise Service Bus (O’Reilly, 2004) door D.A. Chappell. (Ook) door zo’n boektitel dreigt overigens de misvatting dat het slechts om gecoördineerde informatievoorziening binnen één enkele onderneming gaat, dus overwegend intern gericht, terwijl het wezenlijke belang van bedoelde (informatie)diensten juist bestaat uit — de mogelijkheid van eenvoudiger — informatiebetrekkingen tussen allerlei actoren. Kortom, overeenkomstig de maatschappelijke, wezenlijk extern gerichte schaal van het Internet. Dit laatste behelst de reden waarom dienstgerichte infrastructuur, zachtjes uitgedrukt, sterk bevorderlijk is voor het informatieverkeer in het publiek domein (met momenteel de zgn elektronische overheid als aanzet).
2001, webeditie 2005 © Pieter Wisse
(Ook) eerder verschenen in Stijlbreuk in bestuur (Information Dynamics, 2001)