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.