Adaptieve systemen (deel 2)

Adaptieve applicaties was het onderwerp van mijn vorige column. Vele organisaties zullen er de komende jaren niet aan ontkomen: starre applicaties beperken de bedrijfsvoering te veel. En het is juist die trend die ingezet is: organisaties behoren zich steeds vaker en sneller aan te passen.

De grote vraag wordt dan wel hoe adaptieve applicaties eigenlijk ontwikkeld dienen te worden? In de praktijk blijkt dit allemaal niet zo simpel te zijn. Ongetwijfeld zullen op lange termijn hiervoor (met veel bloed, zweet en tranen) ontwerpregels en richtlijnen boven tafel komen. Maar precies weten doen we het nu nog niet. Dus hier ligt een formidabele uitdaging.

Wat we wel zeker weten is dat een adaptief systeem gebaseerd moet zijn op een bus-structuur, uit lagen moet bestaan en elke laag generiek ontwikkeld moet zijn. We zullen deze regels wat verduidelijken.

Ten eerste moeten alle applicaties met een bus-structuur onderling gekoppeld zijn. In plaats van op zichzelf staande eenheden, moeten applicaties per definitie met de andere applicaties via een bus kunnen communiceren. In vele gevallen zal deze bus gevormd worden door een middleware-laag gebaseerd op message queuing. Deze bus zal uiteindelijk het centrale punt van de gehele IT-infrastructuur worden. Kent u nog de uitspraak ‘het netwerk ís de computer?’ Misschien dat we binnenkort zeggen ‘de bus ís het IT-systeem.’ 

Voor oude applicaties zal het niet altijd evident zijn hoe ze aan de bus gekoppeld moeten worden. Denk hierbij aan oude Cobol of PL/I-applicaties die indexsequentiële bestanden benaderen en nog een terminal-interface bezitten. Uiteraard zijn er leveranciers die adapters uitbrengen waarmee die oude applicaties alsnog gekoppeld kunnen worden, maar dan nog zal de applicatie lichtelijk aangepast moeten worden. Bij het ontwerp van nieuwe applicaties zal direct de koppeling met de bus opgenomen moeten worden. Een ontwerp waar de bus niet in voorkomt, kan direct in de vuilnisbak gegooid worden.

Ten tweede moet elke applicatie gelaagd opgebouwd worden. De presentatielaag (ofwel de user interface) dient gescheiden te zijn van de applicatielogicalaag en deze dient weer van de databaselaag gescheiden te zijn. Elke laag dient voldoende onafhankelijk te zijn zodat ze eenvoudig door een andere vervangen kan worden. Dit betekent bijvoorbeeld dat er in de presentatielaag geen interface-controls gebruikt mogen worden die direct aan databasetabellen gekoppeld zijn. Dit is misschien wel handig voor de programmeur, maar een ramp voor de adaptiviteit.

Elke laag moet ook een expliciete interface bezitten. Deze hoort niet per ongeluk te ontstaan, maar apart ontworpen te worden. De gelaagde structuur en de expliciete interfaces zal het koppelen aan een bus ook vereenvoudigen. In feite is de gelaagdheid een vereiste als een bus-structuur gewenst is.

Ten derde moet alle applicatiecode en elke databasestructuur generiek opgebouwd zijn. Alleen dan kan een applicatie als adaptief bestempeld worden. Dus in plaats van dat de applicatie precies bevat wat gevraagd wordt, moet het over alle faciliteiten beschikken voor mogelijke toekomstige wensen. Hetzelfde geldt voor de databasestructuur. 

Bijvoorbeeld, in een doorsnee databases heten de tabellen Klant, Product en Order. In een volledig generieke database vinden we tabellen als Entiteit, Relatie en Attribuut. De komende jaren zullen databasestructuren generieker worden. In één keer overstappen naar alternatief twee kan nog niet, want de commerciële databaseservers zijn hier niet op ingesteld, maar ook dat zal een kwestie van tijd zijn. 

Uiteraard zijn dit aanbevelingen die ook nog veel vragen opwerpen. De uitdaging is nu om de technische ontwerpregels en richtlijnen te identificeren om systemen te bouwen die leiden tot adaptieve systemen. Veel van onze bestaande ontwerpregels zijn gericht op het bouwen van starre systemen. Systemen die precies doen wat gevraagd wordt. En die periode willen we langzaamaan afsluiten.