De Clou van Interface

In zijn column De eeuwige interface (15 maart 2013) deelt François van Heurn zijn ongerustheid m.b.t. moderne gegevensuitwisseling: omslachtig, foutgevoelig, kostbaar, lange time-to-market en onbevredigend. “En dat”, zo stelt Van Heurn, “terwijl de techniek de afgelopen jaren juist op het gebied van integratie grote sprongen voorwaarts heeft gemaakt.” Even verder in zijn column vraagt Van Heurn zich dan ook af “waarom bouw en beheer van interfaces dan toch nog steeds zo moeizaam gaat” en geeft aansluitend een korte, praktische, analyse.

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.

Copyright (c) 2013 Emovere/Jan van Til - All rights reserved.

Alle publicaties op deze site zijn gebaseerd op mijn eigen opvattingen. Ze vertegenwoordigen niet noodzakelijkerwijs de standpunten en het beleid van mijn werkgever(s).

Federatieve Informatie

Met De Federatieve App levert Ron Tolido opnieuw een mooie bijdrage aan een discussie die altijd weer op mijn warme belangstelling kan rekenen. Tolido laat in zijn column helder zien dat niemand het in z’n eentje (nog) redt: we zijn tot-en-met onderling afhankelijk. En dat weten we ook wel. Tegelijkertijd hechten we ook enorm aan onze autonomie: eigen meester; niemands knecht! Ook dat weten we – als geen ander.

De vraag is dan ook: hoe opereren we samen/apart zo relaxed mogelijk in dit boeiende spanningsveld van autonomie en onderlinge afhankelijkheid? Hoe laten we iedere participant zoveel als mogelijk zelf ‘de boel’ autonoom regelen, terwijl we – met z’n allen – tegelijkertijd ook altijd robuust en betrouwbaar willen kunnen terugvallen op één of andere gemeenschappelijke basis. Een basis waar we allemaal en zonder mankeren onze mosterd kunnen halen (en brengen)?

Tolido signaleert naar mijn idee terecht dat “[m]obiele apps een ander soort levenscyclus [hebben]”. Tolido samenvattend: het zijn (vaak) een soort Kleenex-applicaties die overal vandaan komen, die snel bedacht, gemaakt en ingezet worden, hun waarde bewijzen en na enige tijd weer vervangen worden door nieuwe varianten. Dynamiek! Tempo!

Zoiets gaat natuurlijk alleen maar werken als er één of ander gemeenschappelijk fundament aan ten grondslag ligt. Robuust en betrouwbaar. Een fundament waar iedereen zijn/haar mosterd kan halen (en brengen). Tolido: “De centrale IT-afdeling zou zich veel meer moeten richten op het aanbieden van een platform dat ervoor zorgt, dat die mobiele apps snel kunnen worden ontwikkeld, getest en beheerd, dat de juiste datasets en enterprise services worden gebruikt, dat identiteit en beveiliging van tevoren al zijn ingebouwd.” Precies! Een applicatie moet weer een zuivere toepassing worden – zònder al die (time-to-market frustrerende) rompslomp.

Daar waar Tolido zich (nog) hoofdzakelijk richt op Techniek (die, zeker, noodzakelijk is), richt ik me eerst en vooral op de Informatie: op dat ‘goedje’ waar het iedereen in de kern om begonnen is! Zo’n gemeenschappelijk fundament – Informatie èn Techniek – is infrastructureel van aard: één pakket aan (im)materiële voorzieningen waarmee tal van gebruikers via hun veelheid aan wisselende apps heel gevarieerd en op hun persoonlijke maat worden bediend.

En dat lukt alleen maar wanneer we er in slagen onze informatie… probleem-ònafhankelijk (!) modelleren. Dat is Nieuw! Want het zit ons in de genen om probleemspecifiek te modelleren en aansluitend dus ook probleemspecifiek te bouwen (met alle gevolgen van dien).

We hebben een nieuwe, stelselmatige, manier van informatiemodellering nodig [1]. Dat levert ons federatieve informatieverzamelingen, waaromheen een federatief pakket aan (im)materiële voorzieningen wordt gebouwd. En dan… dan hebben we dat “platform” [2] waarover Tolido in zijn column spreekt – dat platform waarop apps als zuivere informatietoepassingen soepel en gevarieerd kunnen ‘inprikken’.

Copyright (c) 2013 Emovere/Jan van Til - All rights reserved.
Alle publicaties op deze site zijn gebaseerd op mijn eigen opvattingen. Ze vertegenwoordigen niet noodzakelijkerwijs de standpunten en het beleid van mijn werkgever(s).

[Noten]
1. Voor meer informatie aangaande deze nieuwe vorm van informatiemodellering, zie bijvoorbeeld Systematic Organization of Information (2011). Een uitstekende methode voor bedoelde nieuwe informatiemodellering is Metapattern. Metapattern gaat bovendien vergezeld van een operationeel platform: Knitbits [3].
2. Zie, voor een impressie/verbeelding bijvoorbeeld de presentatie infOrmation Orchestration (2010).
3. Het Nieuwe Modelleren– of, beter uitgedrukt: stelselmatige informatiemodellering vereist ten opzichte van de traditionele (en probleemspecifieke) modellering een geheel andere denk-, kijk- en werkwijze van de informatiekundig ontwerper. Het gaat immers om het ontwerp van enkelvoudige voorzieningen t.b.v. veelvuldig, gevarieerd en variërend gebruik door een veelheid aan ddor de tijd heen wisselende mensen en groepen. Er is, met andere woorden, geen sprake (meer) van een specifiek probleem dat door de ontwerper moet worden opgelost. Nee, de uiteindelijke toepassingen dienen nadrukkelijk op een infrastructurele leest te worden geschoeid. En dat is kwalitatief ànders.