Pieter Wisse
Standaardisatie, is dat niet simpelweg 'iets' waaraan (potentieel) betrokken partijen zich houden? Zijn standaards en componenten zelfs niet precies hetzelfde?
Concrete standaards zijn bestuurlijk eigenlijk niet of nauwelijks interessant. Standaards zijn middelen. Wat bestuurders primair helder moeten stellen zijn doelen. Zij moeten vervolgens van voorgestelde middelen (laten) toetsen of ze optimaal bijdragen aan realisatie van de vooròpgestelde doelen. Daarbij geldt dat doelen kunnen wijzigen. Standaards moeten dus zonodig variabel inzetbaar zijn òf betrekkelijk eenvoudig vervangbaar. Een standaard is vrijwel nooit triviaal. En het verband tussen standaards en componenten is redelijk complex.
Indien elke standaard zo nadrukkelijk als middel opgevat moet zijn, wat is dan het doel van wie zo'n middel gebruikt? Algemeen gesteld, dient een standaard vooral verbetering van doelmatigheid. Het klassieke voorbeeld is dat van spoorbreedte. Ooit koos elke spoorwegmaatschappij daarvoor een maat die haar eigen bedrijfsvoering paste.
Een probleem met afwijkende spoorbreedtes doet zich voor wanneer een reis trajecten van verschillende maatschappijen overbrugt. Dat is met variëteit in maten zeker niet ònmogelijk. De passagier kan immers overstappen en de lading kan worden verladen. Of de wagon wordt op een ander onderstel geplaatst (waardoor passagiers en lading kunnen blijven 'zitten'). Of de as is variabel in breedte. En ongetwijfeld zijn er nog andere oplossingen om doeltreffendheid te verzekeren.
Een trein, met alles erop en eraan, kan echter gewoon doorrijden wanneer de spoorbreedte overal gelijk is. Het is dan zelfs mogelijk met hetzelfde rollend materieel een reis te ondernemen over een onverwachte configuratie van trajecten. Behalve doelmatigheid, bevordert zo'n standaard daarom ook flexibiliteit.
Er zijn doorgaans ook nadelen verbonden aan uniformering onder de noemer van standaardisatie. Grofweg zijn dat tijdelijke en duurzame verschijnselen.
Tijdelijke nadelen betreffen de kosten en overige inspanningen voor (a) aanpassingen en (b) waarborg van continuïteit tijdens het veranderingsproces ad a. Om bij het klassieke voorbeeld te blijven, wie een omvangrijk spoorwegnet van nieuw, 'standaard'spoor moet voorzien, ondervindt uiteraard zowel ad a als ad b serieuze nadelen.
Duurzaam zijn nadelen van een standaard, indien daardoor kwaliteit, doelmatigheid en dergelijke juist afnemen. Wellicht is de gestandaardiseerde spoorbreedte minder geschikt, of zelfs òngeschikt, voor een specifiek traject. De praktijk toont dat de beslissing om de standaard òf door te zetten òf ervan af te zien ten gunste van een uitzondering vaak in het politieke kader valt.
In rationele zin is de behoefte áán danwel de noodzaak vàn een standaard afhankelijk van het volume aan grensoverschrijdingen. Zonder enig verkeer tussen, zeg maar, verzorgingsgebieden is er geen enkele reden1 voor interterritoriale standaardisatie.
Het andere uiterste bestaat wanneer van gescheiden verzorgingsgebieden eigenlijk geen sprake (meer) is. Blijkbaar is er dan geen verschil in verkeersintensiteit op intra- en interterritoriale trajecten. Stel dat het om allerlei andere redenen voordelig is en blijft afzonderlijke organisaties per verzorgingsgebied te handhaven, is toepassing van standaards voor optimale afwikkeling van het uitwisselingsverkeer toch evident.
De praktijk van standaardisatie is zo ingewikkeld, omdat het wèrkelijke volume van grensoverschrijdend verkeer ergens tussen de geschetse extremen ligt. Er kan al verwarring ontstaan over de plaatsbepaling langs dat spectrum. Dan komt daar dynamiek bij; de gerede verwachting luidt meestal dat de mógelijkheid van doelmatiger verkeer het daadwerkelijke volume doet groeien. Dat kàn als bedreiging worden opgevat. Wie dat zo ziet, handhaaft afwijkingen als (al dan niet vermeende) waarborg voor autonomie.
Standaardisatie is dus bij uitstek een strategisch onderwerp. Als een beleidsmaker zich daarvan bewust is, stelt zij/hij zich op naar gelang de openheid danwel geslotenheid die zij/hij voor haar/zijn organisatie nastreeft. Van de organisatiestrategie zijn dan zo consequent mogelijk de omgangsvormen met technische standaards afgeleid.
De praktijk laat echter nog regelmatig zien dat omgang met techniek niet expliciet ingekaderd is. Wanneer in- en vooral externe 'technici' zonder beleidskader hun 'eigen' middelen bepalen, is het risico navenant groter dat voorzieningen voor uitwisseling met andere organisaties nauwelijks of geen proactieve aandacht krijgen.
De technicus die verantwoordelijk handelt, probeert uiteraard rekening met contingenties te houden. Van technische voorzieningen die op zo'n manier door de 'achterdeur' binnenkomen, moet dan later nog maar blijken of zij standaards weerspiegelen in de zin van doelmatigheid van grensoverschrijdend verkeer. Zo niet, dan is met die zgn lokale aanpassing zelfs een extra drempel gevormd voor èchte standaards.
Ter verdediging van bedoelde technici geldt dat beleidsmakers en bestuurders meestal (nog) onvoldoende het belang beseffen van — of zich om redenen van politieke bewegingsruimte juist bewust ervan afzijdig houden — het verband tussen organisatiestrategie en technische standaards. Voor het interne verkeer, dwz binnen het eigen verzorgingsgebied, moet er tòch iets gebeuren. Het gevolg van de passiviteit van de aangewezen bestuurder is dat er wel degelijk 'beleid' voor technische standaardisatie gemaakt wordt, en beslissingen worden genomen, maar met een beperkter perspectief door technici zèlf. Natuurlijk moeten technici een zware stem kunnen inbrengen. Maar, nogmaals, toegepaste techniek is altijd middel. Dat vergt oriëntatie vanuit een doel van een andere orde. Dat is de organisatorische strategie.
Ter bevordering van de aantrekkelijkheid van spoorvervoer hebben betrokken organisaties ooit uit welbegrepen eigenbelang de spoorbreedte gestandaardiseerd. Is dit historisch overigens correct? Het is thans een feit dat er een standaardmaat voor spoorbreedte bestaat èn wordt gehanteerd. Die is wellicht tot stand gekomen onder druk van de overheden voor wat het hun eigen territoria betrof. Vervolgens kan intergouvernementele samenwerking tot de interterritoriale standaard voor spoorbreedte geleid hebben. De bemoeienis van overheid dient dan het zgn maatschappelijk belang.
De Nederlandse overheid kent een vergaand decentrale cultuur, dwz dat elke overheidsinstelling vergaand autonoom is. Het is dus vergaand aan zulke autonome organisaties zèlf overgelaten om hun samenwerking onderling te regelen. Zelden wordt er in Nederland een coördinerend orgaan direct in de lijn geplaatst bóven de organisaties om hun samenwerking hiërarchisch te verzekeren.
De reële autonomie onderstreept dat de beleidsmaker(s) voor elke organisatie zich expliciet met standaardisatie moet(en) bezighouden. Er is immers geen hogere organisatie die standaards dwingend vóórschrijft. Dat houdt echter in dat beleidsmakers de reële behoefte aan c.q. noodzaak van coördinatie op eigen initiatief moeten erkennen. Daarbij geldt dat onttrekking aan standaardisatie tevens de mogelijkheden voor coördinatie door andere betrokken organisaties vermindert. Voor optimale coördinatie is daarom consensus nodig, met standaards als praktische neerslag. Hoe langer consensus uitblijft, des te meer druk komt er vanuit de instelling die algemener maatschappelijk belang (lees ook: grensoverstijgende ketenprocessen) vertegenwoordigt. De paradox van het polderbestuur luidt dat juist wie initiatief tot coördinatie neemt en daarvoor praktische maatregelen voorzieningen à la standaards treft, per saldo haar/zijn autonomie het meest waarborgt.
Tot dusver kwamen componenten in dit [opstel] niet ter sprake. Dat verandert hier nadrukkelijk, maar aanvankelijk zonder enig verband met standaardisatie. Het gaat in eerste aanleg om afzonderlijke nuancering van modularisatie. Pas verderop volgt de samenhang tussen standaardisatie en componenten.
Zoals standaardisatie in absolute zin nooit goed of slecht is, omdat de waarde immers van omstandigheden afhangt, is het a priori verstandig, of juist niet, om voorzieningen als configuraties van componenten te treffen.
Een component is synoniem met een module. De eigenschap die er hier het meest toe doet is dat een component/module een, zeg maar, veranderdeel in een totale constructie is. Dat is extra vergeleken met een apart bouwsegment. Wie componenten louter als segmenten opvat, kan ze tijdens constructie immers ook onlosmakelijk samenvoegen. Het resultaat is dan waarschijnlijk verhoudingsgewijs goedkoop, simpel en dergelijke tot stand gekomen. Maar eventueel onderhoud, verdere ontwikkeling enzovoort zijn net zo problematisch als ware dat resultaat oorspronkelijk 'uit één stuk' opgetrokken.
Het kan ook voor een unieke voorziening, bijvoorbeeld een bepaald gebouw, aanbeveling verdienen vergaande modularisatie toe te passen. (Terzijde: de mogelijke winst uit standaardisatie is dan per definitie nihil.) Als er iets kapot gaat, kan herstel gericht beperkt blijven tot de module(n) met schade.
Van een andere orde is het indien de eisen veranderen waaraan het gebouw moet voldoen. Maar zoals voor schade geldt, blijven de inspanningen voor aanpassing verhoudingsgewijs beperkt wanneer slechts één of enkele modulen gewijzigd behoeven te worden. Of misschien kan daarvoor een module worden verwijderd, of toegevoegd.
Ook voor modularisatie tellen voor- èn nadelen. Wanneer elke component/module geheel nieuw ontwikkeld moet worden, lijkt het aannemelijk dat de aanvankelijke bouwkosten hoger uitvallen. Het systeem voor de componenten moet immers ook uitgewerkt worden. Die extra kosten/inspanningen worden terugverdiend, bijvoorbeeld indien beperkte schade een onvermijdelijk, vaak terugkerend verschijnsel is. Modularisatie loont eveneens indien veranderingen worden verwacht. Mits het systeem erop berekend is, blijven inspanningen wederom redelijk beperkt.
Het is dus zeker niet rationeel om een voorziening te modulariseren waarvoor een onderhoudsvrij bestaan in het verschiet ligt, terwijl ook geen noodzaak voor enige aanpassing verwacht wordt.
Aan de andere kant is het uiterst rationeel om een voorziening vergaand uit modules samen te stellen, indien onderhoud onontkoombaar is en/of aanpassingen moeten worden aangebracht.
Hoewel standaardisatie hier nog niet expliciet aan de orde is, is het opvallend hoe gelijkvormig het onderwerp componenten/modularisatie zich laat ontleden. Daarom volstaat een korte samenvatting. Dus, de praktijk van modularisatie is ingewikkeld want het is een relatief concept. En het onderwerp verdient strategische aandacht.
De verhouding tussen voor- en nadelen van componenten verandert. Dat komt omdat vele modules niet geheel nieuw ontwikkeld behoeven te worden. Waar het aanbod van leveranciers2 reeds het karakter van componenten/modules heeft, dalen de kosten en overige inspanningen die modularisatie vergen.
Een module is enerzijds een lòs deel. Anderzijds is het een ònderdeel, dwz dat hij verband constitueert. Als onderdeel moet de module daarom passen. Hij is per definitie gekoppeld (danwel potentieel koppelbaar) aan één of meer andere modules.
Het binnenwerk van de ene module is onafhankelijk van dat van een andere module dankzij hun gemeenschappelijke koppelvlak (Engels: interface). In omgekeerde richting gedacht, bepaalt de (on)mogelijkheid om zgn binnenwerk onafhankelijk te laten functioneren de ontwerpruimte voor modules/componenten. Hoever modularisatie binnen mogelijkheden ervoor daadwerkelijk doorgezet wordt, moet weer afgeleid zijn van de afweging tussen voor- en nadelen.
Een koppelvlak volgens de compontenstijl voor informatievoorziening is overigens méér dan een eigenschap waardoor de ene component louter statisch past bij een andere component. Dankzij hun koppelvlakken stemmen zij hun dynamiek af. Ofwel, het gedrag van de ene is afgestemd op dat van een andere component, omdat via hun koppelvlakken daarvoor minimaal benodigde informatie uitwisselbaar is.
Het is voor een module een essentiële eigenschap dat hij via (een) koppelvlak(ken) qua dynamiek past bij andere module(n). Om het paradoxaal te verwoorden, die passende buitenkant moet als het ware ten diepste ingebakken zijn. Dan geldt dat een module blijft passen zolang hij voldoet aan de eisen van de koppelvlakken waarop hij moet verschijnen.
Het binnenwerk van een module kan dus onafhankelijk wijzigen, of de ene module kan door een andere vervangen worden, mits het koppelvlak òngewijzigd kan blijven. Zodra echter een koppelvlak verandering moet ondergaan, treft zo'n wijziging uiteraard alle modulen die erop verschijnen.
Het is bijna zover om de samenhang van standaardisatie en componentenstijl te schetsen. Maar omdat er vergeleken met de applicatiestijl iets wezenlijks verandert, is inzicht erbij gebaat hier allereerst die traditionele standaardisatie te vermelden.
Zoals bij ontwikkeling van de ene module er principieel mee gerekend wordt dat hij moet passen bij (een) andere module(n), geldt voor verschillende applicaties dat zij slechts lòs staan en géén ònderdeel vormen. Het zelfvoorzienende karakter van elke applicatie betekent echter duplicatie van binnenwerk. Dit betreft alle aspecten, van autorisatieprogrammatuur tot en met de informatie zèlf. Hoe vaak staat een 'inwoner' niet geregistreerd met het adres waarvoor de informatie erover in de Gemeentelijke Basisadministratie als maatgevend geldt?
Ondanks zulk isolement in de informatievoorziening verdwijnt echter allerminst de behoefte aan uitwisseling. Integendeel, duplicatie roept de behoefte op aan afstemming.
Stel dat twee deelverzamelingen informatie met elkaar vergeleken moeten worden, bijvoorbeeld om wat in de ene ontbreekt daaraan toe te voegen. Dat lukt slechts indien de technieken volgens welke de respectievelijke applicaties 'werken' voldoende overeenstemmen. Zeg maar, achteraf is uitwisseling mogelijk door voldoende gelijkenis van het binnenwerk. Daarom betreffen voorschriften voor standaards in de applicatiestijl vooral opmaak van opgeslagen informatie (Engels: format). En omdat er zelfs voor hetzelfde type — bijvoorbeeld relationeel gestructureerde informatie, of tekstverwerking — lastige drempels kunnen bestaan, strekt standaardisatie zich tot concrete merken uit.
De redenering luidt dan als volgt. Indien iedereen voor informatieopslag het database managementsysteem van, zeg, type X en merk Y gebruikt, is de mógelijkheid tot uitwisseling gewaarborgd.
Juist wanneer het om gestructureerde informatie gaat, is dat trouwens nog volstrekt onvoldoende waarborg. Uitwisseling moet zinvol zijn en daarvoor is behoefte aan vergelijkbare informatie nodig. Wat heeft het voor nut om iemand die een adres zoekt, een kenteken mee te delen? En dan moet die informatie vooral ook vergelijkbaar gestructureerd zijn. Deze conceptuele dimensie van standaardisatie is weliswaar ruim bekend, maar er wordt nauwelijks concreet naar gehandeld. De applicatiestijl is daaraan belangrijk debet vanwege de nadruk op zelfvoorziening.
Dat standaardisatie in de applicatiestijl in de Nederlandse bestuurscultuur gedoemd is te mislukken is vanzelfsprekend. Er spreekt immers bemoeienis met binnenwerk uit. Dat staat op gespannen voet met vergaande autonomie. De behoefte aan autonomie weegt het zwaarst.
Maar is verbetering van informatie-uitwisseling dan eigenlijk wel mogelijk? Elk voorstel daarvoor moet tenminste beginnen met erkenning van de bestuurlijke verhoudingen. Daar horen de grenzen voor eventuele veranderingen bij, want compleet stabiel hoeven die verhoudingen ook weer niet te zijn.
Het karakteristieke onderscheid tussen de applicatie- en de componentenstijl is dat een applicatie in beginsel zelfvoorzienend is en een component niet. De samenhang van een bepaalde component met andere componenten vormt de aanleiding voor de indeling naar zijn binnenwerk, respectievelijk koppelvlak. Extreem gesteld is binnenwerk géén aandachtspunt voor standaardisatie. Autonome organisaties blijven volkomen vrij dat binnenwerk van componenten naar eigen keuze in te richten.3
De heroriëntatie behelst dat standaardisatie uitsluitend voor koppelvlakken geldt, waarbij koppelvlakken dus inherent aan de componentenstijl zijn. Dat is het enige onderwerp, en dat is al moeilijk genoeg, waarover (potentiële) ketenpartners het eens moeten zijn. Deze eis is echter allesbehalve nieuw. Dat geldt allang voor informatie-uitwisseling via niet-digitale technologie. Tot het koppelvlak voor mondelinge communicatie, bijvoorbeeld, behoren (ook al) de taal, het begrippenkader en dergelijke.4
De beperking tot koppelvlakken bevordert coördinatie. Een koppelvlak is immers onomstreden voor wat betrokken organisaties minimaal gemeenschappelijk moeten regelen. Wie dat minimum niet aanvaardt, onttrekt zich feitelijk aan samenwerking. Indien daardoor risico's voor het maatschappelijk verkeer ontstaan, volgt als maatregel (tijdelijke) beperking van autonomie zodat het benodigde koppelvlak via (tijdelijke) coördinatiedwang alsnog gevestigd wordt. Dat is niets anders dan het bestuurlijke spel.
noten
1. Het is natuurlijk iets ingewikkelder. Verschillende domeinen kunnen door dezelfde leverancier bediend worden. Het is dan de leverancier die omwille van zijn eigen doelmatigheid eventueel standaardiseert. Zo kan zonder opzettelijke bedoeling van klanten een gelijke infrastructuur ontstaan.
2. Zie ook noot 1. Wat de kosten echter weer doet groeien, is dat vooral leveranciers van digitale techniek (hard- en software) snel opeenvolgende generaties modulen aanbieden. Dat is tevens in het belang van klanten, wanneer — invoering van — elke nieuwe generatie desondanks meer voor- dan nadelen heeft.
3. Juist door dit uitgangspunt zo extreem decentraal te positioneren blijkt dat er niet uit volgt dat er helemaal géén standaards voor binnenwerk gelden. Zo doet een autonome organisatie er verstandig aan voor haar 'eigen ' componenten het binnenwerk, waar mogelijk, op dezelfde leest te schoeien. En/of de ene organisatie past — aspecten van — binnenwerk van een andere organisatie toe. De crux is de bestuurlijke keuzevrijheid. In de Nederlandse bestuurscultuur is het effect van afwijzing van coördinerende dwang als regel dat méér standaardisatie — nota bene, op vrijwillige basis, dus zowel doeltreffender als doelmatiger — resulteert.
4. Afspraken over koppelvlakken voor interne informatievoorziening zijn verhoudingsgewijs 'vanzelfsprekend.' Van interne procestrajecten valt immers direct op wanneer ondersteuning stokt. Het is juist kenmerkend voor autonomie dat een organisatie ook zonder informatierelaties met haar omgeving nog enige tijd verder kan functioneren, althans de schijn ervan kan ophouden.
2000, webeditie 2005 © Pieter Wisse
(Ook) eerder verschenen in Stijlbreuk in bestuur (Information Dynamics, 2001)