Het laatste paradigma
Met andere woorden: waarheen leidt de reis van gestructureerd programmeren via objectoriëntatie en component-based development naar service-oriëntatie en events? En wanneer komen we aan? In de verschillende kaders beschrijf ik een paar lijnen die licht werpen op deze vragen. Hier alvast een aantal conclusies.
De IT-gemeenschap is een collectief met maar een beperkte capaciteit om zich nieuwe inzichten eigen te maken, laat staan ze goed toe te passen.
Zo vindt het IT-collectief het top-down – met stapsgewijze commando’s – besturen van lokale simpele eenheden gemakkelijker dan het instrueren en faciliteren van een verzameling decentrale, autonome experts die al samenwerkend een probleem oplossen.
Toch is dat laatste ons voorland in de IT: over een jaar of dertig, wanneer persoonlijke agenten of e-butlers namens ons informatie verzamelen, communiceren, afspraken maken, onderhandelen en zelfs vergaderen. Dan zal het belachelijk lijken dat ooit instituties als de overheid, bedrijven en spammers ons direct, via de telefoon, per e-mail of sms konden benaderen. Onze trouwe e-butler schermt dat, op basis van onze voorkeuren, zoveel mogelijk af. En omdat we met hem hebben afgesproken dat we ’s morgens voor het ontbijt maar tien minuten de tijd voor hem hebben, zal hij erg zijn best doen om die tien minuten zo goed mogelijk te gebruiken.
Maar ook op een fundamenteler niveau zijn we veroordeeld tot het vormen van de IT naar ons evenbeeld: autonome en verantwoordelijke wezens. Naarmate we computersystemen meer in onderdelen opsplitsen en steeds meer hergebruiken, nemen de complexiteit van het beheer van deze onderdelen en hun onderlinge afhankelijkheden
toe. En dan is er een grens aan wat we nog met repositories en configuratiedatabases aankunnen.
Waarom niet de onderdelen zelf een grotere verantwoordelijkheid geven? Waarom niet een component zelf laten uitzoeken waar op het netwerk de beste (goedkoopste?) resources beschikbaar zijn die hij nodig heeft?
Waarom niet, op elk willekeurig moment binnen het systeem rondvragen, wie en wat er allemaal actief is en of er problemen te verwachten zijn als ik een bepaalde component of service door een nieuwe vervang? Dan moeten ze mij en elkaar natuurlijk wel begrijpen. Dus de taal waarin ik die vraag stel en waarin zij hun antwoord geven moet rijker en betekenisvoller zijn dan het elkaar toeschreeuwen van ongenuanceerde bevelen zoals nu.
Daarom wordt over een paar jaar het huidige Web 2.0 van mash-ups en social platforms opgevolgd door Web 3.0 van het semantische web. Door de inhoud van de informatie op het web meer en beter te duiden in nieuwe talen als RDF en OWL, overbruggen we stap voor stap de semantische kloof die ons en de digitale werkelijkheid scheidt. Een langdurig proces, want betekenis hangt niet alleen af van de woorden die we gebruiken, maar ook van welk gedrag ze teweegbrengen.
Als we de componenten ook nog in bepaalde dingen laten geloven (beliefs), bijvoorbeeld dat het milieu belangrijk is, ze verlangens geven (desires), bijvoorbeeld het verlangen om, daar waar het past, groene producten te kiezen, en ze op basis van die verlangens doelen laten nastreven (intensions), bijvoorbeeld om minstens 20 procent van ons geld aan groene producten uit te geven, dan leven we in de wereld van Web 4.0, van de personal agents of e-butlers. Vergezocht? Misschien niet. Weten we bijvoorbeeld wel zeker dat er achter alle rondlopende figuren in Second Life een mens zit en geen programmaatje?
We bereiken dan langzaamaan het einddoel van de reis der paradigma’s: het creëren van autonome, slimme componenten die zoals wij en namens ons zoeken, communiceren en afspraken maken. Maar die op de achtergrond ook coöperatief problemen oplossen door, elk met hun eigen belangen en capaciteiten, razendsnel te onderhandelen. Natuurlijk niet met onze menselijke diepgang (begrip, gevoel en creativiteit) maar misschien goed genoeg om nuttig te zijn en om bij ons het Tamagotchi-effect op te roepen waarnaar we zo gemakkelijk neigen. Maar dat laatste hangt natuurlijk ook van de vormgeving af.
Dit allemaal op basis van strenge omgangsregels omdat we anders echte autonomen creëren die al of niet namens ons bedriegen, bedreigen en aanslagen plegen op andere e-butlers. En dat honderdduizend keer zoveel en zo snel als nu gebeurt. Misschien goed opletten waar de stekker zit.
Drs. ing. Cor Baars (cor.baars@dnv.com) werkt voor DNV-CIBIT en is inhoudelijk verantwoordelijk voor de Master of Science-opleiding IT Architecture, die in samenwerking met Middlesex University wordt aangeboden. Hij werkt als adviseur op het gebied van Enterprise Architectuur en doet onderzoek naar de toepassingsmogelijkheden van Multi-Agent-systemen.
Werkwoord of zelfstandig naamwoord?
In den beginne van het computertijdperk commandeerden we computers met statements als Run, Execute en Calculate. Het hoofdprogramma bestuurde de stappen en het echte inhoudelijke werk werd door de subroutines uitgevoerd. Door deze scheiding werden de subroutines onafhankelijker van hun context en daarmee herbruikbaarder. De gegevens speelden toen de tweede viool.
Met de opkomst van objectoriëntatie legden we de nadruk op het zelfstandig naamwoord. De werkwoorden als muteren en berekenen kwamen op het tweede plan. Bevelen werd vragen aan het object en het object kreeg de mogelijkheid om nee te zeggen, bijvoorbeeld om de eigen gegevens te beschermen. De autonomie nam een klein stapje toe.
Dirigent of choreograaf?
Een orkest heeft een dirigent nodig. Dansers niet. Zij hebben de muziek als leidraad. De choreograaf boetseert de dans door de dansers te instrueren en als ze, samen op het podium, op elkaar reageren, ontstaat de dans vanzelf. Dansers zijn autonomer dan musici. Componenten in een choreografie zijn autonomer dan die in een orkestratie.
Reageren op elkaar en op gebeurtenissen van buiten wordt belangrijker naarmate meer kennis- en minder productiewerkers met computers werken of wanneer de omgeving onzeker is. Kenniswerkers laten zich niet voorschrijven wat ze stap voor stap moeten doen. Kenniswerkers geef je een gereedschapskist waarmee zij naar eigen inzicht en stijl iets maken. Systemen moeten daarom de vrijheid aan de gebruiker laten en hoogstens opmerken wanneer grenzen worden overschreden of wanneer de ingevoerde gegevens niet compleet genoeg zijn voor een volgende stap.
Centraal of gedistribueerd?
Vroeger deden we alles zelf en maakten we alles zelf. Nu niet meer. Nu zijn we vooral geïnteresseerd in wat anderen voor ons kunnen betekenen. Daarom is het belangrijk geworden de diensten van andere afdelingen, maar ook die van bedrijfspartners, naadloos in onze systemen te integreren.
SOA helpt daarbij. Tijdens de ontwikkeling neemt de autonomie toe want ik hoef als programmeur niet van tevoren te weten waar ik een geschikte service precies kan vinden en ik hoef ook de interface niet op voorhand te kennen. In het beheer neemt de autonomie af want ik ben voor beschikbaarheid en beveiliging ineens veel afhankelijker geworden van anderen.
Automaat of autonoom?
Componenten zijn autonomer dan objecten, services zijn autonomer dan componenten en systemen die als zender of ontvanger op een eventkanaal zijn aangesloten (event-driven architecture of EDA), zijn het autonoomst van allemaal. Althans qua vorm.
Maar ze zijn nog wel een beetje dom en daarmee nog steeds erg afhankelijk van ons. Als we ze in de komende jaren rijker laten communiceren en wat slimmer maken, dan hoeven we ze niet meer autocratisch te commanderen en aan de buitenkant bij te houden wat ze doen en mogen. Dat kunnen ze dan zelf wel af. En dan worden het misschien veel betere assistenten dan de applicaties en wizards van nu.
Bevelend of beschrijvend?
We kunnen computers programmeren door ze stap voor stap op te dragen wat te doen. We kunnen computers ook een aantal regels geven waarmee ze al redenerend ingewikkelde taken kunnen uitvoeren of complexe afwegingen kunnen maken. Bijvoorbeeld voor het accepteren van nieuwe hypotheekklanten of het stellen van een diagnose.
Het voordeel van regels in plaats van code is dat ze veel leesbaarder zijn, althans als je geen Java-programmeur bent. En dat heeft weer het voordeel dat het moment waarop je als digibeet compleet afhankelijk wordt van een programmeur weer iets naar voren opschuift. De afhankelijkheid van de materiedeskundige neemt wat af.
Tussenstation of eindstation?
Op dit moment kan het IT-collectief programmeren met bevelen aan componenten die zelf verantwoordelijk zijn voor hun werking en gegevens. Daarbij worden (door SOAP) de diensten van verschillende componenten binnen en buiten de organisatie, in een vaste structuur (orkestratie) gecombineerd.
Door event-driven architectuur leren we ook op basis van regels, toestanden en gebeurtenissen besturen en programmeren en dat lijkt al veel meer op de manier waarop wij samenwerken en redeneren.
Als we over een jaar of tien nieuwe talen ontwikkelen om componenten rijker met elkaar en met ons te laten communiceren en we geven ze na nog eens tien jaar het vermogen om, weliswaar beperkt, te redeneren en doelen na te streven, dan komen we dicht bij het eind van onze reis.
Een maatschappij van menselijke en digitale autonomen die samenleven en samenwerken op basis van afspraken en normen. Alles wat we daarna nog verzinnen, valt buiten ons menselijk referentiekader en is dus pure fantasie.