Jan van Til

Core Components zijn voor gisteren

Core Components zijn voor gisteren

Duurzame interoperabiliteit vraagt om een radicaal andere benadering.

Jan van Til

Met de Core Component Technical Standard (CCTS) wil UN/CEFACT een revolutionaire benadering bieden ter oplossing van het prangende interoperabiliteitsvraagstuk. Uitwisseling van informatie tussen applicaties/databases is eigenlijk al vanaf de introductie van de eerste interface problematisch. En de problematiek is inmiddels uitgegroeid tot een interoperabiliteitsvraagstuk van zo fors formaat dat velen het uit eigen ondervinding kennen.

Vraag is nu of UN/CEFACT met CCTS wèrkelijk iets nieuws te bieden heeft; iets revolutionairs – zoals ze het zelf uitdrukkelijk beschrijft.

In dit artikel maak ik duidelijk dat CCTS – in de huidige opzet – niét kan ontsnappen aan de beperkingen waarmee ook de nu bekende standaarden voor informatie-uitwisseling te kampen hebben. Bedrijven die serieuze oplossing(en) zoeken voor hun interoperabiliteitsvraagstuk(ken), doen er verstandig aan zich diepgaander te oriënteren.

Inleiding

In september 2007 hoorde ik over het bestaan van het UCM project (ontwikkeling van een Unified Context Methodology) en haar nauwe relatie met het CCTS project (de Core Components Technical Standard) (1). Hierbij is het UCM project verantwoordelijk voor nadere invulling van het contextmechanisme waarvoor de grondbeginselen binnen het CCTS project zijn vastgesteld.

CCTS valt – net als UCM – onder de CCWG (de Core Components Working Group), dat op haar beurt weer onderdeel is van de TMG (de Techniques and Methodologies Group). TMG is één van de vijf permanente werkgroepen van UN/CEFACT (Centre for Trade Facilitation and Electronic Business).

Omdat context op mijn bijzondere interesse kan rekenen, verdiepte ik me in CCTS/UCM – kortweg CCTS. Introductie van een standaard als CCTS bij een bedrijf/instelling vraagt de nodige energie. En ook om die reden is het verstandig een stuk verder te kijken dan de spreekwoordelijke neus lang is en antwoord te zoeken op de vraag of CCTS een bedrijf wèrkelijk iets (extra’s) heeft te bieden.

Zijn we er – met andere woorden – voldoende zeker van dat een willekeurig bedrijf met CCTS iets substantieels kàn bereiken? Iets wat zònder CCTS momenteel niet bereikt kan worden? Is het reëel te veronderstellen dat CCTS op de schaal van een beetje bedrijf kan werken? Hoeveel bedrijven werken momenteel al volgens de voorschriften van CCTS? Wat zijn hun bevindingen?

Serieuze vragen, want daar waar invoeringstrajecten fors tijd en geld kosten, worden – en dat is volkomen terecht – substantiële verbeteringen verwacht. Dit artikel geeft serieuze antwoorden op deze vragen, bespreekt de huidige realiteit van CCTS en haar potentieel tot fitness for use.

Wat de laatste twee vragen betreft, meld ik direct dat ik het antwoord erop schuldig moet blijven. Één van de projectgroepleden heeft me weliswaar een lijst verstrekt, maar ‘navraag’ via Google leverde niet veel meer op dan blijken van interesse en schoorvoetende (aanzetten tot) tests.

De standaard CCTS: Highlights

De standaard CCTS is ontstaan als gevolg van sterk gegroeide behoefte aan interoperabiliteit binnen en tussen applicaties/databases van organisaties (2).

CCTS is bedoeld als een Technische Standaard voor uniforme constructie van een verzameling informatie-componenten; de zgn. Core Components – kortweg CC’s.

Dergelijke componenten worden tot één enkelvoudige, coherente en consistente verzameling gebundeld; de zgn. Core Components Library – kortweg CCL. Genoemde library dient vrij toegankelijk te zijn voor gebruik door alle betrokken deelnemers (3).

CCTS is vervolgens ook bedoeld als een Technische Standaard voor ordelijk gebruik van Core Components door heel gevarieerde deelnemers behorend tot één of meer organisaties.

Op basis van Core Components – afkomstig uit de gemeenschappelijke CCL, construeren deelnemers hun specifieke afleidingen; de zgn. Business Information Entities – kortweg BIE’s (4).

Specifieke afleidingen (BIE’s) zijn steeds deelverzamelingen van ermee corresponderende Core Components. Elk informatie-element (eigenschap, attribuut) dat uit een Core Component wordt overgenomen in een BIE betreft een exacte kopie.

Dit “derivation by restriction” principe (5) dient te waarborgen dat deelnemers die dezelfde afleidingen construeren ordelijk met elkaar kunnen communiceren. De betekenis van elk afzonderlijk informatie-element is vóóraf vastgesteld en ligt vast op Core Components niveau – en daarmee ook op (lager) BIE niveau (6).

Specifieke afleidingen (BIE’s) ontstaan door de toepassing van het CCTS contextmechanisme (7) op Core Components. Om de constructie van specifieke afleidingen te sturen, definieert en hanteert CCTS een beperkt aantal op voorhand bepaalde contextcategorieën. Een specifieke context ontstaat vervolgens door het toekennen van waarden aan vooraf bepaalde eigenschappen (‘stuurvariabelen’) van één of meer contextcategorieën. Toepassing van die context stuurt tenslotte het ontstaan van Business Information Entities uit Core Components.

Funderend principe

CCTS werkt, zoals zojuist aangegeven, op basis van het principe van “derivation by restriction”. Wie dit principe accepteert, erkent tegelijkertijd ook dat de CCL ‘werkt’ als de ruimst mogelijke context voor alle deelnemers. Dat betekent dat binnen de CCL alles te vinden moet zijn wat voor alle (potentiële) deelnemers, zowel individueel als onderling, aan betekenis van belang is en van belang wordt.

De CCTS projectgroep betitelt de CCL als een ‘superset’ en niet als ‘ruimst mogelijke context’ (8). De reden hiervoor is – vermoedelijk – dat CCTS de CC’s en de CCL als contextvrij bestempelt. Verderop in dit artikel wordt duidelijk dat dit als een achterhaalde zienswijze van de hand moet worden gewezen.

Volgens CCTS start een deelnemer met bepaalde, vanuit de CCL beschikbaar gestelde, Core Components en leidt daaruit restrictief de informatie-elementen af die in zijn specifieke situatie (context) van toepassing zijn. Samen met de informatie-elementen raken tegelijk ook de bijbehorende betekenissen van toepassing.

Wie dat allemaal niet zo nauw neemt, weigert feitelijk het “derivation by restriction” principe en daarmee CCTS zelf. Deelnemers dienen helder voor ogen te houden dat dit principe door de CCTS projectgroep opzettelijk en met nadruk is gekozen om daarmee voor èlke afzonderlijke deelnemer te waarborgen dat èlk informatie-element àltijd dezelfde betekenis heeft – ònafhankelijk van het bericht waarin het voorkomt en ònafhankelijk van de deelnemer/organisatie die het gebruikt (9).

Specialisaties

Deelnemers die toch afwijken van dit basisprincipe, plaatsen zichzelf, zoals gezegd, buiten de kaders die CCTS aanreikt en daarmee buiten CCTS zelf. Dergelijke afwijkingen worden specialisaties genoemd en hebben betrekking op specifieke betekenis die niet binnen de CCL werd aangetroffen en toch van belang is voor één of meer deelnemers.

De deelnemer die door middel van specialisaties afwijkt van wat CCTS aan betekenis biedt, loopt het risico in een situatie terecht te komen waarin hij niet (goed) meer kan communiceren met andere deelnemers en/of ketenpartners – dat wil zeggen: niet op basis van CCTS.

Wie ordelijk gebruik van CCTS een warm hart toedraagt en uit wil gaan van Core Components zoals aanwezig in de CCL… en tegelijk ook inziet dat specialisaties een Fact Of (Business) Life zijn, krijgt serieuze belangstelling voor governance!

Governance

Die krijgt serieuze belangstelling voor vragen als: Hoe krijgen belanghebbenden hun specialisaties genormaliseerd? Hoe gaat CCTS om met specialisaties die noodzakelijk zijn voor belanghebbenden maar strijdig met de inhoud van de gemeenschappelijke CCL? Hoe helder is governance van de CCL (al) ingevuld? Hoe zit het met de onderlinge relaties/verhoudingen tussen de normaliserende instantie enerzijds en belanghebbenden anderzijds? Welke partij gaat normalisatie ter hand nemen? Kàn CCTS (voor mij) werken?

Daar waar afwijkingen (specialisaties) optreden, is het voor betrokken deelnemers van belang hiervoor voldoende steun te verwerven zodat deze kunnen worden genormaliseerd en vervolgens in de gemeenschappelijke Core Components Library (CCL) opgenomen.

Opname in de CCL levert – logischerwijs – problemen op als de nieuwe specialisaties strijdig zijn met één of meer bestaande Core Components.

Dergelijke strijdigheden kunnen niet door het contextmechanisme van CCTS worden opgelost omdat dat mechanisme een coherente verzameling Core Components vóóronderstelt. En dat is eigenlijk heel merkwaardig, want context is nu juist middel bij uitstek om eventuele strijdigheden in betekenis op te heffen – zoals verderop in dit artikel zal blijken.

Naarmate meer partijen/organisaties van CCTS gebruik gaan maken, ontstaan er ook meer specialisaties waarvan de onderscheiden belanghebbenden opname in de CCL verlangen. Want – heel praktisch: ‘het’ moet voor alle (individuele) belanghebbenden natuurlijk wel werken!

Samen met toenemende aantallen specialisaties nemen ook de strijdigheden met de CCL toe. Het governance-proces raakt verstopt/vertraagd en/of frustreert belanghebbenden: de normalisatie van hun specialisaties laat (te) lang op zich wachten of komt in het geheel niet af.

Met andere woorden: het verwerven van voldoende steun voor een specialisatie is – ook als er van strijdigheden geen sprake is – maar al te vaak een tijdrovend proces. Gebrek aan voortgang in het normalisatieproces neemt met hedendaagse dynamiek in informatieverkeer al snel de vorm aan van een roadblock. Veel ‘business opportunities’ komen vandaag de dag vrij plotseling op en vragen vaak op korte termijn om invulling (wie het eerst komt, die…). Trage invulling brengt doorgaans verlies van waarde van de opportunity met zich mee.

Waar belanghebbenden ook rekening mee dienen te houden, is de mogelijkheid dat hun specialisaties in het geheel niet worden opgenomen in de CCL. Dit omdat ze strijdig zijn of omdat de normaliserende instantie van mening is dat de gewenste specialisatie al wordt afgedekt door (andere) Core Components.

Daar waar een belanghebbende zich niet kan vinden in het oordeel van de normaliserende instantie, is de grens van de betekenisruimte van de CCL voor hem bereikt.

Belangrijke vraag in dit verband is hoeveel ruimte CCTS – via de structuur van Core Components – biedt voor betekenisvariatie. Fixaties als vóóraf vastgestelde betekenis en een gelimiteerd aantal contextcategorieën (en stuurvariabelen) wijzen in de richting van een nauw, te nauw afgebakende betekenisruimte – met vele, vele specialisaties als gevolg.

CCTS lijkt sterk naar één CCL te streven met bijpassende governance. UN/CEFACT lijkt zelf te willen voorzien in één – namelijk haar eigen – CCL. En voor die ene CCL zal het beheer door UN/CEFACT ter hand worden genomen. In de geraadpleegde CCTS documenten (10) wordt dat echter (nog) nergens onomwonden vermeld en helder uitgewerkt. Merkwaardig; het betreft hier immers grondslagen – en over grondslagen behoort vooraf… grondig te zijn nagedacht.

CCTS zou governance überhaupt niet moeten richten op één CCL, maar op meerdere onderling afhankelijke CCL’s. Op die manier is governance van één CCL ‘slechts’ één van de mogelijkheden en is er – ingebouwd – ruimte voor gecoördineerde invulling van nadere bijzonderheden in dynamische en/of kleinere (keten)verbanden.

Via een omweg…

In dergelijke coördinatie voorziet CCTS echter niet. Wie uniforme constructie en ordelijk gebruik van Core Components hoog in het vaandel heeft staan en zich tegelijk niet langer kan conformeren aan die ene CCL…, die zegt eigenlijk dat hij betékenis die voor hem van essentieel belang is niet kan vinden in die CCL. Die CCL biedt hem te weinig bewegingsvrijheid, te weinig betekenisruimte.

Er zijn dan – theoretisch! – twee mogelijkheden: (a) de deelnemer past zijn business aan zodat e.e.a. wèl past binnen de betekenisruimte van die ene CCL, of (b) de deelnemer begint voor zichzelf… met een ‘eigen’ CCL. Een CCL waarmee hijzelf (intern) en mogelijk ook samen met partners in één of meer ketens (extern) uit de voeten kan.

Wie het failliet van één grote gemeenschappelijke CCL (betekenisruimte) inziet en start met een eigen CCL, realiseert zich dat hij – eventueel samen met een aantal andere belanghebbenden – begonnen is aan een nieuwe, wellicht ook verbeterde, ‘versie’ van bestaande standaarden als bijvoorbeeld EDIG@S, EDIFACT etc. De enige ‘winst’ die op deze manier kan worden geboekt, is dat het ditmaal standaarden betreft die op CCTS leest zijn geschoeid.

En, ja – een beetje organisatie krijgt op die manier gemakkelijk te maken met meerdere CCL’s. CCL’s die onderling overlap vertonen en qua betekenis kunnen (zullen) conflicteren. Want in coördinatie tussen CCL’s wordt, zoals gezegd, vanuit CCTS niet voorzien. Via een omweg komt de deelnemer weer terug bij af (maar nu volgens CCTS stramien).

Herhaling van zetten

Op deze manier ontstaat echter opnieuw – zeg maar even – verzuiling. Een verzuiling per CCL en haar deelnemers. Als deelnemers tellen nu bijvoorbeeld de ketenpartners die – voor zover en voor zolang ze ketenpartner zijn – dezelfde betekenissen hanteren (want dezelfde CCL gebruiken).

Wie al wat langer meeloopt, herkent een patroon. Want iets dergelijks deed zich al eerder voor. Voorheen vormden applicaties de ‘zuilen’ waarbinnen betekenis op orde werd gehouden – totdat integratie (behoefte aan interoperabiliteit; ontzuiling) haar intrede deed. Vanaf dat moment begonnen – zonder dat men er aanvankelijk erg in had – betekenissen door elkaar te lopen, hetgeen de deelnemers uiteindelijk tot her-ordening ervan aanzette.

Zo ontstonden standaarden (herzuiling) als EDIG@S, EDIFACT etc. waarbinnen de deelnemers opnieuw gemeenschappelijke betekenis creëerden en deelden. Maar ook dergelijke standaarden bevredigen uiteindelijk niet omdat ze onderling slecht uitwisselbaar zijn. Er is onvoldoende overeenstemming in betekenis (lees ook: onvoldoende interoperabiliteit) en spraakverwarring steekt steeds weer opnieuw de kop op.

Dan komt CCTS: CCTS als zuil der zuilen – één centrale CCL, waarin elke deelnemer alles (alle betekenis) van zijn gading vindt en waaruit hij dus altijd kan afleiden wat hij aan betekenis voor zijn business nodig heeft en gaat hebben. Maar helaas, ook deze poging tot ontzuiling creëert haar eigen nieuwe vormen van verzuiling die interoperabiliteit – de ontstaansgrond van CCTS – opnieuw in de weg staan.

Toch… en toch kan een organisatie de oprechte hoop koesteren dat ze haar CCL (of wellicht: haar verzameling CCL’s) op termijn zal kunnen harmoniseren tot een groter geheel – wellicht zelfs tot die ene CCL die door UN/CEFACT operationeel wordt gehouden.

Harmoniseren

Vanuit UN/CEFACT (11) wordt op een aantal plaatsen gesuggereerd dat mogelijkheden tot harmoniseren van CCL’s reëel zijn. Daarbij spelen uniforme constructieprincipes/structuur van Core Components een belangrijke rol.

Alleen… die constructieprincipes/structuur bestonden ook al op het moment dat de verschillende deelnemers met hun eigen CCL begonnen. En de directe aanleiding voor het opzetten van een eigen CCL werd gevormd door verschillen in betékenis! Verschillen in betekenis die tóen niet in die structuur konden worden ondergebracht. En er zijn geen redenen om aan te nemen dat diezelfde verschillen in betekenis nu wèl in diezelfde structuur passen.

Harmonisatie achteraf is niet alleen heel verleidelijk maar ook een verraderlijke illusie! De afzonderlijke CCL’s zijn juist ontstaan als gevolg van een schrijnend gebrek aan ruimte voor betekenisverschillen in de structuur van die ene gemeenschappelijke CCL. En dat is op haar beurt weer het gevolg van een CCTS ontwerpbeslissing (betekenis vóóraf fixeren). Daarmee telt dat gebrek aan betekenisruimte (lees ook: gebrek aan interoperabiliteit) als in CCTS ‘ingebouwd’. Charles Perrow zou ‘ongelukken’ als gevolg van het gebruik van CCTS vermoedelijk als ‘Normal Accidents’ bestempelen (12).

Het harmoniseren van bestaande CCL’s gaat per definitie gepaard met het over-en-weer inleveren van verschillen in betekenis. Verschillen die juist maakten dat aparte CCL’s ontstonden. Wie essentiële verschillen in betekenis ‘harmoniseert’ en daarmee dus loslaat (!), neemt zichzelf niet serieus en doet zichzelf tekort.

Daar waar verschillen in betekenis reëel zijn, mislukt harmonisatie geheid. Wie gelooft in harmonisatie achteraf houdt zichzelf – en mogelijk ook anderen voor de gek. Ja, mogelijk ook anderen want een vraagstuk dat zich hierbij voordoet is wie zo’n ‘harmonisatie-proces’ (eigenlijk) dient te sturen. Als dat wordt overgelaten aan ICT… gaat ‘harmonisatie’ vanuit (beperkt) ICT perspectief lukken, maar vanuit (ruimer) business perspectief tot ernstige ongelukken leiden. Waarom? Omdat het hier eerst en vooral gaat om betekenis van informatie (dus: wáárde voor de business). Het gaat hier niét om definitie van data (in een ICT database). En het is nu juist betékenis die bij ‘harmonisatie’ verloren gaat.

Achterhaald: contextvrije CCL

Wie wat verder nadenkt over specialisaties, realiseert zich dat specialisaties altijd ontstaan binnen een specifieke context van een bepaalde deelnemer. Het is vanuit die specifieke situatie (en belang) dat specialisaties door belanghebbenden ter normalisatie en opname in de CCL worden aangeboden.

Core Components zijn – volgens de CCTS specificatie – contextvrij (13). Als dat al een juiste vooronderstelling is, is dergelijk contextvrij zijn al vanaf de eerste promotie van een specialisatie tot Core Component/informatie-element in de CCL niet meer te handhaven. Nee, veel aannemelijker is het te veronderstellen dat Core Components al op voorhand contextgebonden zijn, en wel aan een soort van – zeg maar ‘supercontext’: de ruimst mogelijke context voor alle deelnemers aan één CCL.

Wie uitgaat van contextgebonden Core Components (en CCL) heeft in ieder geval een heel plausibele verklaring voor het feit dat aanvullingen in de vorm van specialisaties strijdigheden met de CCL kunnen vertonen. Dat dergelijke strijdigheid in het geval van werkelijk contextvrije Core Components (en CCL) eenvoudigweg niet kàn ontstaan, ontgaat de projectgroep die zich met de ontwikkeling van CCTS bezighoudt. Zoals gezegd erkent CCTS zoiets als een ‘supercontext’ niet en stelt domweg dat Core Components (en CCL) contextvrij zijn (14). Specialisaties die (dan toch) strijdig met de CCL blijken te zijn, komen voort uit een context die zich niet verdraagt met de wel degelijk bestaande, maar impliciet gehouden tot en met volledig ontkende (ambigue) context waarin de CCL bestaat: ‘business’.

Wie de Core Components Technical Standard doorneemt (in het bijzonder de hoofdstukken 3, 4, 5 en 9), vindt een spoor. Woorden als ‘circumstances’, ‘situation’ en ‘context’ zijn in verreweg de meeste gevallen synoniem met resp. business circumstances, business situation en business context. Daarmee vernauwt CCTS haar gezichtsveld tot zoiets als business. Hand in hand daarmee vormt zich een ‘supercontext’ – en wel zònder dat de CCTS projectgroep dat inziet!

Bijkomend punt van kritiek is dat wat ‘business’ constitueert – vandaag, morgen enzovoort – verre van stabiel en continue in beweging is. Als standaard behoort CCTS zo algemeen geldig mogelijk te zijn: ‘business toepassing van informatie’ is niet meer dan een deelverzameling van ‘toepassing van informatie in het algemeen’. En van de verzameling ‘toepassing van informatie in het algemeen’ vormen allerhande wezenlijke (belangen)groepen – bijvoorbeeld klanten (!) – op hun beurt weer een deelverzameling. Het is van groot belang dat business – het gaat immers om interoperabiliteit nu, morgen, volgend jaar enzovoort – bréder en vèrder kijkt dat CCTS haar suggereert te doen.

Elk bedrijf dat ‘klaar wil zijn voor de toekomst’, denkt maar beter diép na, kijkt vèrder dan ‘business’ en steekt heel bewust in op het ‘enablen’ van informatieverkeer tussen èlke willekeurige X en èlke willekeurige Y. Waarom? Omdat alleen zo’n Ruimte-tot-Communicatie duurzaam voldoende Ruimte herbergt van waaruit met vertrouwen niet alleen B2B, B2C, B2enzovoort kan worden ‘gedaan’, maar ook – en daar gaat het om – óók: X2Y. Wie een dergelijke visie heeft, ziet dat B2B en B2C slechts (belangrijke) deelverzamelingen zijn van X2Y. Wie een dergelijke visie heeft en vanuit dit Ruime perspectief contextualisering tot ordelijke betekenisgeving ter hand neemt, komt goed beslagen ten ijs en is uitstekend voorbereid op een verrassend concurrerende toekomst: interoperabiliteit tussen willekeurige X en willekeurige Y is immers goed geregeld. Want wie het eerst komt, die….

Hoe is het toch mogelijk dat de CCTS (en ook UCM) projectgroepen zo weinig doen met de wetenschap dat er niéts is dat ‘an sich’ – dat wil zeggen zònder context – bestaat? Àlles wat bestaat, bestaat àltijd in relátie tot iets ànders, tot de omgeving (de context) waarìn het bestaat. Dat geldt óók voor een CCL; óók voor Core Components onderling bínnen een CCL.

De namen en de betekenissen die door mensen aan een object worden toegekend, worden er aan toegekend vanuit datgene wat zo’n object kan betekenen in relatie tot de verschillende situaties, omstandigheden enzovoort waarin dat object zich kan manifesteren, tot aanzijn kan komen, tot teken en betekenis kan komen.

De vooronderstelling dat (onderdelen van) de CCL contextvrij zouden zijn, is niét vol te houden. Dat lukt alleen tegen beter weten in.

Wat mag een bedrijf operationeel verwachten van CCTS als CCTS conceptueel niet deugt? Alleen middels een reëel contextbegrip kunnen strijdigheden in betekenis oplossen. Want betekenisverlies en strijdigheden in betekenis ontstaan juist dáár waar niet wordt begrepen dat context en betekenis innig, innig zijn verbonden. Nogmaals: alleen een reëel contextbegrip houdt betekenissen ordelijk uit elkaar en conflicten buiten de deur.

Achterhaald: betekenis komt vóór context

Één van de basisassumpties van CCTS is echter dat betekenis aan context voorafgaat en ook los van context valt toe te wijzen. In de CCL is betekenis binnen de Core Components immers al vastgelegd – onafhankelijk van een specifieke context (15). En daarmee raakt betekenisgeving absoluut.

Deze denkwijze en de eruit voortvloeiende handelswijze staan haaks op wat in de sociale psychologie al decennia lang bekend is: Wat iets betékent voor een mens (actor) wordt heel fijnmazig gestuurd door de context waarin dat iets aan die mens (actor) verschijnt. Andere context? Andere betekenis! Punt uit.

Zolang contexten door de tijd heen maar marginaal veranderen – zoals bij aanvang van het ICT tijdperk het geval was, ondervindt niemand hinder van een gemis aan dergelijk inzicht. Dat wordt anders in een wereld waarin verandering aan de orde van de dag is. Die toename in dynamiek en veranderlijkheid is één van de gevolgen van de hoge vlucht die ICT heeft genomen en de grondige veranderingen die dat in maatschappij en bedrijfsleven heeft teweeggebracht. In een wereld waarin alles – dat wil eigenlijk zeggen: betekenis – continue in ‘beweging’ is, wordt het van eminent belang de (o.a.) door de sociale psychologie verschafte inzichten alle ruimte te geven in ons denken, in onze informatiebetrekkingen en ons informatieverkeer

Voor dergelijk (inmiddels bekend) inzicht is binnen de opzet en structuur van CCTS echter geen plaats. Betekenis is eerst en raakt vervolgens selectief – via het ruwe CCTS contextmechanisme – van toepassing op een deelnemer.

Ook de vooronderstelling dat betekenis vóór context komt, is niét vol te houden. Dat lukt alleen tegen beter weten in. Deze – ooit voldoende werkbare – denk-/handelswijze is disfunctioneel geworden. Betere inzichten verdienen onze onverdeelde aandacht zodat reële relatie tussen betekenis en context werkelijk vorm kan krijgen – ook in standaarden als CCTS.

Opnieuw dringt zich de vraag op wat een bedrijf operationeel mag verwachten van CCTS als CCTS conceptueel niet deugt? Wie gebruik maakt van sinds jaar en dag voorhanden en geaccepteerde kennis en inziet dat die vandaag toegepast móet worden om informatiebetrekkingen en informatieverkeer (interoperabiliteit) duurzaam te faciliteren, ziet dat CCTS – waar het op iets zo cruciaals als betekenisordening-via-context aankomt – uit de bocht vliegt.

Scherp: context!

De CCTS projectgroep heeft scherp gezien dat context van Groot Belang is voor het creëren van de zo fel begeerde en ook noodzakelijke interoperabiliteit! Tegelijk is het triest te moeten constateren dat de CCTS projectgroep context invult vanuit een paradigma dat het inmiddels zo schrijnende gebrek aan interoperabiliteit als kernprobleem heeft voortgebracht. Zoiets is tot mislukken gedoemd; Einstein wist al dat dergelijke problemen nooit kunnen worden opgelost binnen hetzelfde paradigma waarin ze zijn ontstaan.

Achterhaald paradigma

Het paradigma waarin CCTS rust, is hetzelfde paradigma dat heeft gemaakt dat ICT zo’n enorm hoge vlucht kon nemen en ook heeft genomen. Maar – o, ironie – het is juist dit paradigma dat ICT in het algemeen en CCTS in het bijzonder nu voor de voeten loopt, omdat het zich niet langer verdraagt met de wereld die diezelfde ICT heeft helpen ontstaan. En (vrijwel) niemand heeft dat in de gaten. Wat een tragiek! Om met Eric Hoffer te spreken: “In times of massive change, learners inherit the world, while the learned remain beautifully equipped to deal with a world that no longer exists”.

De wereld die ICT heeft helpen ontstaan, is er één waarin alles op eenvoudige wijze met alles kan worden verbonden: inderdaad – Internet. Zoals bekend wordt daar inmiddels op ongeëvenaard grote schaal gebruik van gemaakt en hebben we te kampen gekregen met een pijnlijk gebrek aan – wat we zijn gaan noemen… interoperabiliteit. Waarom? Omdat interoperabiliteit eenvoudigweg niet is ‘ingebouwd’ in ons ICT-dènken en dus ook niet in ons ICT-dóen. Dàt is het manco dat zich steeds manifester aan ons opdringt – zònder dat we het doorgronden. En nog steeds proberen we dat manco uit alle macht binnen het heersende paradigma op te lossen. We voelen duidelijk dat de schoen wringt, maar hebben (nog) geen idee waar precies en waarom.

Wat een tragiek! Want de interoperabiliteitsproblematiek is niet op te lossen binnen het heersende paradigma. Een kwalitatieve sprong is onontkoombaar en hóógstnoodzakelijk!

Wie grip wil krijgen op interoperabiliteit, wie – met andere woorden – de verwarring over wat iets betékent wil ontwarren, dient het hele idee van absolute betekenisgeving lòs te laten en dient zich grondig af te vragen wat het precies is dat betekenis constitueert. De uitkomst? Context!

Een basisassumptie die aan CCTS en ook aan governance-a-la-CCTS ten grondslag lijkt te liggen, doet sterk denken aan iets als ‘one fits all (forever)’. De eind 2007 beschikbare CCTS documenten (grotendeels ‘under construction’) ademen sterk een sfeer van stabiliteit en helderheid voor alle deelnemers op vóórhand. Hoewel ook hier geldt dat de geraadpleegde CCTS documenten zich niet onomwonden uitspreken over gehanteerde basisassumpties, vooronderstellingen enzovoort, is wèl helder dat CCTS betekenis vóóraf definieert en dat het contextmechanisme daarná in actie komt en het ja/nee relevant zijn van informatie-elementen stuurt.

De CCTS projectgroep hanteert daarmee het principe van – zeg maar – de omgekeerde wereld. Ze hanteert een achterhaald paradigma.

Times of massive change…

Het heersende paradigma dat zo’n enorme en ook verstrekkende bijdrage heeft geleverd aan de ontwikkeling van maatschappij en bedrijfsleven is toe aan vervanging. In een wereld waarin, kort gezegd, verandering de enige constante is geworden en waarin informatie steeds intensiever door (ketens van) machines wordt gemedieerd, valt betekenis niet (langer voldoende betrouwbaar) op voorhand te bepalen. Daarvoor is heel expliciet extra informatie noodzakelijk. Dergelijke informatie noemen we… context. Context stuurt betekenisgeving en naarmate meer eisen worden gesteld aan betekenisdifferentiatie (fijnmazigheid, ordening van betekenis), zal ook meer contextinformatie daaraan haar bijdrage moeten leveren. De inrichting/structuur van het contextmechanisme dient steeds voldoende fijnmazig te zijn zodat wisselende behoeften aan betekenisdifferentiatie er – dynamisch – in kunnen worden ondergebracht.

Met open inter-connectie op de schaal van hedendaags Internet – informatieverkeer met en door iedereen, overal en altijd – kan het hele Internet gemakkelijk (ook vruchtbaar!) als één groot informatiesysteem worden beschouwd. De voorheen aparte informatiesystemen constitueren nu als onderling afhankelijke knooppunten het netwerk voor informatieverkeer. En die verandering – van apart naar interoperabel – is kwalitatief van aard. Wat iets ergens in dat veelomvattende informatiesysteem voor een willekeurige deelnemer betékent, kan alleen maar helder worden door er van geval tot geval voldoende – en voor dat moment ook relevante omgevingsinformatie (context) aan te relateren. Wie vanuit zo’n perspectief contextualisering tot ordelijke betekenisgeving ter hand neemt, zal zich niet snel een buil vallen: hij doorziet de ‘massive change’; hij ‘inherits the world’ want bouwt met visie en doortastendheid aan X2Y!

Dat alles staat in schril contrast met wat de standaard CCTS als grondslag biedt. Volgens CCTS wordt de betekenis van informatie-elementen op voorhand bepaald (statisch); geheel los van context. En dat is alleen verantwoord in een heel stabiele omgeving waarin ‘de dingen’ zich gedurende lange(re) tijd vergaand gelijkblijvend manifesteren. Dat past niet bij de (nog steeds toenemende) beweeglijkheid, veranderlijkheid etc. die ieder van ons dagelijks waarneemt.

Al sinds jaar en dag is bekend en geaccepteerd dat betekenis zich niet vóóraf laat opdringen of vastleggen. Nee, het is juist context – ingewikkeld en veranderlijk – die betekenisgeving heel fijnmazig stuurt en duurzame interoperabiliteit duurzaam binnen handbereik brengt. CCTS zit in haar ‘omgekeerde wereld’ op een volkomen verkeerd spoor. Als standaard laat CCTS dimensies als betekenis en context bovendien stollen; dimensies die in onze werkelijkheid juist uiterst vloeibaar zijn. Nee, CCTS kàn voor een beetje bedrijf eenvoudigweg niet werken – ook niet als eerste stap op weg naar interoperabiliteit.

Nieuwe wereld – nieuwe toekomst

Bedrijven hebben vandaag de dag op allerlei niveaus te opereren in tal van ingewikkelde en ook veranderlijke omgevingen/situaties (contexten). Om in een dergelijke omgeving gezond, concurrerend enzovoort te blijven, komt het steeds meer aan op ter zake doende betekenisgeving aan snel wisselende en gevarieerde gebeurtenissen. En daarover dient vervolgens snel en betrouwbaar (lees ook: zinvol en betekenisvol) te kunnen worden gecommuniceerd met/tussen wisselende interne en/of externe (keten)partners (X2Y).

Dàt is ‘de wereld’ waarin ieder zich staande heeft te houden – vanaf vandaag; vanaf morgen. Een wereld waarin interoperabiliteit niet langer een nice to have is, maar een must! Dat besef lijkt bij de CCTS projectgroep (nog) niet in volle omvang doorgebroken (16).

Voor zo’n wereld kàn CCTS geen adequate oplossing aanreiken. Want met CCTS komt een bedrijf – alle mooie beloften over sterk verbeterde interoperabiliteit ten spijt – niet of nauwelijks verder dan met de huidige standaarden voor berichtuitwisseling.

En dat is pijnlijk, want het was juist het gebrek aan interoperabiliteit van dergelijke standaarden die de opmaat vormden tot het ontstaan van een nieuwe standaard als CCTS….

Als standaard schiet CCTS ernstig te kort; de concepten waarop CCTS is gestoeld, verdragen zich niet (meer) met de ons omringende werkelijkheid. Een werkelijkheid die ons steeds duidelijker fundamenteel àndere dingen laat zien: veranderlijkheid als constante, verdergaande vervaging van traditionele (business)grenzen, snel en sterk wisselende en veranderlijke (business)relaties enzovoort. Nogmaals: dat is niet ‘gewoon’ een kwestie van schaal; nee, dat is kwa-li-ta-tief ànders!

Betékenis staat meer dan ooit op losse schroeven. Losse schroeven die pas vanuit een nieuw paradigma hun samenhang (orde) laten zien: context. Want context zorgt voor orde in betekenis. Vanuit zo’n invulling-van-visie kom je goed beslagen ten ijs en ben je uitstekend voorbereid op een verrassend concurrerende toekomst. Wie het eerst ziet, die het eerst komt, die…. En dat ‘zien’ vereist volgens Shoshana Zuboff een “rupture of the world we take for granted; then the old categories of reference are called into question and revised”.

Grondwerk

CCTS baseert zich op een achterhaald paradigma en moet – om werkelijk succesvol te kunnen worden – eerst grondig op de schop. Een grondig omgewerkt CCTS bevat geen ‘los’ contextmechanisme, maar een contextmechanisme dat er integraal en onlosmakelijk onderdeel van is. Context ‘gebeurt’ niet éénmalig – nádat een object-met-attributen-en-betekenis tot stand is gekomen, maar context ‘gebeurt’ continu en stuurt ordening van betekenis (en daarmee gedrag) van moment tot moment.

In de afgelopen jaren is al veel grondwerk verricht. Er is zelfs een methode (metapatroon (17)) voor contextuele verbijzondering en betekenisdifferentiatie ontwikkeld – inclusief een naadloos daarop aansluitend operationeel platform: Knitbits (18). Metapatroon is een werkelijk innovatieve methode voor conceptuele informatiemodellering die voluit rekening houdt met de dimensies context en tijd. Ten opzichte van CCTS werkt metapatroon op een hoger abstractieniveau en kan dankzij zeer fijnmazige structuur enorme betekenisdifferentiatie aan. CCTS past om die reden geheel binnen de grenzen (ruimte) van metapatroon (19).

Eindnoten

1.	Een beschrijving van CCTS (v3.0; 2nd Public Review) en haar connectie met UCM is beschikbaar via: http://www.unstandards.org:8080/download/attachments/3801818/Specification_CCTS3p0+2nd+Public+Review+16APR2007.pdf?version=1. Sinds 9 december 2007 is ook de ‘implementation verification draft’ van CCTS v3.0 beschikbaar. Zie: http://www.unstandards.org:8080/download/attachments/3801818/Specification+-+CCTS3p0+ODP6WorkingDraft9Dec07.doc. Ten opzichte van 2nd Public Review laat deze versie echter geen enkele wending in grondslagen zien. Aangebrachte veranderingen bevestigen/versterken de denk- en werkrichting van de voorgaande versie. Om die reden baseer ik me in dit artikel op de eerdere 2nd Public Review van 16 april 2007. Daar waar verwezen wordt naar hoofdstukken en regelnummers, wordt steeds verwezen naar dit document (tenzij expliciet anders staat aangegeven).
2.	Zie bijvoorbeeld hoofdstuk 3 (r.347 vv).
3.	Zie bijvoorbeeld hoofdstuk 4 (r.459 vv).
4.	Zie bijvoorbeeld hoofdstuk 5 (r.484 vv; r.606 vv).
5.	Zie bijvoorbeeld hoofdstuk 5 (r.606 vv). In de implementation verification draft van CCTS versie 3.0 wordt genoemd principe herhaald en nog verder aangescherpt. Concreter nog staat dit aangegeven in hoofdstuk 5 (r.102) van een ander document: “UN/CEFACT – Context Methodology Technical Specification (UCM)”, Working Draft, Revision 0p3, 25 October 2007.
6.	Zie bijvoorbeeld hoofdstuk 5 (r.97 vv en r103 vv) in “UN/CEFACT – Context Methodology Technical Specification (UCM)”, Working Draft, Revision 0p3, 25 October 2007.
7.	Zie bijvoorbeeld hoofdstuk 5 (r.484 vv; r.606 vv) en hoofdstuk 9 (r.3643 vv).
8.	Zie bijvoorbeeld hoofdstuk 5 (r.98-100) in “UN/CEFACT – Context Methodology Technical Specification (UCM)”, Working Draft, Revision 0p3, 25 October 2007.
9.	Zie bijvoorbeeld hoofdstuk 5 (r103 vv) in “UN/CEFACT – Context Methodology Technical Specification (UCM)”, Working Draft, Revision 0p3, 25 October 2007.
10.	Zie bijvoorbeeld hoofdstuk 4 (r.459 vv).
11.	Zie bijvoorbeeld de beschikbare (voorlopige) informatie bij de Core Components harmonization Group (TBG17) en de Techniques and Methodologies Group (TMG).
12.	Zie “Normal Accidents: Living with High-Risk Technologies” van Charles Perrow.
13.	Zie bijvoorbeeld hoofdstuk 5 (r.496 vv).
14.	Zie bijvoorbeeld hoofdstuk 5 (r98-100) in “UN/CEFACT – Context Methodology Technical Specification (UCM)”, Working Draft, Revision 0p3, 25 October 2007.
15.	Zie bijvoorbeeld hoofdstuk 5 (r.496 vv).
16.	Zie bijvoorbeeld hoofdstuk 3 (r.351-357).
17.	Metapatroon is ontwikkeld door Pieter Wisse. Zie “The pattern of metapattern: ontological formalization of context and time for open interconnection” voor een inleidende tekst op metapatroon. Genoemde tekst is afgeleid van het boek “Metapattern: Context and Time in Information Models”, Pieter Wisse, Addison Wesley, 2001.
18.	Zie www.knitbits.com.
19.	Zie “How so-called core components are missing the point”, Part I – Context happens, paragraaf ‘Gradual migration’.