Waar draait het bij interfaces eigenlijk om? Wat is, zeg ook maar, de clou? Cruciaal is de uitwisseling van betekenis. Datatransport is secundair. Cruciaal is dus dat data zo is georganiseerd dat bedoelde betekenis gemakkelijk kan worden vastgesteld. Altijd. En bij elke willekeurige uitwisseling ervan.
Daarmee krijgt het derde punt in Van Heurn’s analyse plotseling de hoofdrol toegewezen! En, ja, klopt helemaal, onze huidige “Data definities” vormen wat organisatie annex betekenis betreft een groot en groeiend probleem. Dat is, zo constateert hij: “in de praktijk een crime”.
Wie de clou van interface (in)ziet, ziet ook dat oplossing voor dat probleem zich laat vinden in een nieuwe opvatting m.b.t. organisatie van informatie – van de “Data definities” zo u wilt. Al was het maar om – zoals Van Heurn het uitdrukt “de kosten van interfaces te decimeren!”
We zouden ons, heel productief, kunnen realiseren dat “een factuur [g]een factuur [is]”, dat “een order [g]een order [is]”, dat “een artikel [g]een artikel [is]” enzovoort. Nee, natuurlijk niet! Daar denkt iedereen – in de harde dagelijkse realiteit – nu eenmaal anders over! En daarover verkrijgen we met elkaar in geen 100 jaar consensus! Vergeet het! Zet het uit uw hoofd! Accepteer wezenlijke verschillen en probeer ze niet te standaardiseren, te harmoniseren of anderszins te verdoezelen.
We zouden ons, heel productief, kunnen realiseren dat het uitwisselen en aan elkaar knopen van ongelijkwaardige informatie een malle bezigheid is. Wie verstandig is stopt er dan ook mee – en wel zo snel als mogelijk. Een factuur in de context van partij A is nu eenmaal geen factuur in de context van partij B. En… àls A en B momenteel al met dezelfde facturen werken, kan dat volgend jaar maar zo weer anders liggen. Wie de ogen sluit voor reële dynamiek… wie de ogen sluit voor essentiële verschillen… en ‘de boel’ via “mappings” al polderend aan elkaar blijft plakken, houdt zichzelf voor de gek, is verk(n)ocht aan de eeuwige interface: omslachtig, foutgevoelig, kostbaar, lange time-to-market en onbevredigend.
Zolang “Data definities” feitelijk ongeschikt zijn voor informatie-uitwisseling tussen partijen, blijft het ‘gewoon’ sappelen met dergelijke data in en tussen applicaties – of ze nu gearchitectureerd, SOA, Open, XML, SOAP enzovoort zijn/hebben of niet. De kern van het probleem zit-um niet – herhaal: niet – in de techniek, maar in ons overtuigingen aangaande de manier waarop wij onze “Data definities” in elkaar menen te moeten steken.
Zolang wij in essentie blijven werken volgens het aloude adagium ‘voor elk probleem een apart systeem’… zolang zullen wij “Data definities” blijven produceren die uitermate geschikt zijn voor één bepaalde partij en derhalve minder/niet geschikt zijn voor andere partijen.
Nogmaals: wat m.i. nodig is, is een nieuwe opvatting m.b.t. organisatie van informatie. Een organisatie met het oog op het uitwisselen van betekenis – de clou van interfaces. Wanneer we informatie ànders – lees: niet langer traditioneel, maar stelselmatig – modelleren, kunnen tal van partijen uit vergaand dezelfde informatie-elementen elk hun eigen factuur, order, artikel enzovoort samenstellen. Voor nadere onderbouwing en details verwijs ik u graag door naar Information Modeling for Context Aware Systems.
Alle publicaties op deze site zijn gebaseerd op mijn eigen opvattingen. Ze vertegenwoordigen niet noodzakelijkerwijs de standpunten en het beleid van mijn werkgever(s).
Geen opmerkingen:
Een reactie posten