Wendbaarheid: zo geregeld?

Regel-gebaseerde architecturen kunnen bijdragen aan wendbaarheid, transparantie en betere dienstverlening, maar een panacee is het niet. De opiniebijdrage ‘De e-overheid binnen handbereik met Regelgestuurde Services’ van Arno Dalhuisen en Bert Lukkien, die op 9 september op deze site verscheen, verdient daarom nuancering. Dat vraagt allereerst om een historische context van de ontwikkeling naar regel-gebaseerde architecturen. We beginnen daarom met een notedop-geschiedenis van het denken over informatiehuishoudingen.

Twintig jaar denken over enterprise architectuur
In de afgelopen twintig jaar heeft het ontwerpmatig denken over informatiehuishoudingen in organisaties beetje bij beetje leentjebuur gespeeld bij de software-ontwerpwereld bewust of onbewust. Aan het eind van de jaren tachtig staat deze ontwikkeling aan het begin. De software-wereld heeft dan een geschiedenis van zo’n twintig jaar in het professioneel toepassen van concepten, methoden en technieken, waarmee informatiesystemen kunnen worden begrepen en ontworpen. Maar die blijven nog binnen de softwarewereld zelf. Bedrijfsprocessen, ook de informatie-intensieve, worden dan nog in andere termen begrepen dan informatiesystemen.

Dan doet, aan het begin van de jaren 1990, business process management zijn intrede. Vooral als al snel het begrip proces versmalt tot procedure, ontstaat er een denk-brug tussen de twee werelden. Immers, de bedrijfskundige heeft het Tayloriaanse denken in zijn bagage en software engineers herkennen hierin wat zijzelf ‘control flow’ plachten te noemen. Dit denken – en daarmee verbonden methoden zoals ‘lean’ en Six Sigma – is daarna vooral gebruikt voor een verhoging van de efficiëntie en klantgerichtheid bij organisaties. Dat control flow echter niet zomaar de spil kan zijn van het inrichten van een toekomstvaste informatiehuishouding was al wel bekend in de software engineering, maar het zou nog even duren totdat dat inzicht doorsijpelde naar de business-wereld.

Een eerste belangrijke nuancering van het proceduredenken komt als service-oriëntatie (of dienstgerichtheid) populair wordt. In het begin worden services vooral gepositioneerd op de technische laag, ondergeschikt aan procedures. Maar gaandeweg wordt duidelijk dat er niet alleen software-services moeten zijn, maar ook business-services. Het end-to-end gedrag van processen (de dienst, de functie) – ofwel hun toegevoegde waarde – is immers belangrijker dan het stappenplan waarmee je dat invult. Dit komt grotendeels overeen met het functiebegrip uit de software engineering. Deze ontwikkeling liep parallel met de inzet van veel overheden (ook de Nederlandse) op verbetering van de dienstverlening aan burger en bedrijf. Het is daarom niet toevallig dat bijvoorbeeld de NORA ook inzet op service-oriëntatie.

Vervolgens komen gebeurtenissen (events) om de hoek kijken. In de softwarewereld bestaat al de nodige ervaring met het gebruiken van events voor het losjes koppelen van informatiesystemen (typisch via een publish/subscribe-mechanisme). Waar het procesdenken ooit gestart was om verticale verzuiling tegen te gaan, leiden lange procedureslierten ondertussen tot horizontale vertunneling: starre procedurele processen die niet passen bij de veel beweeglijkere werkelijkheid van de praktijk en van het menselijk handelen. In de businesswereld blijken gebeurtenissen een goede manier om die starre procedures op te hakken in flexibel samen te stellen kleinere stukjes, die elkaar aanvuren. Bovendien krijgt men met gebeurtenissen een ingang geboden in de leefwereld van de klant. Levensgebeurtenissen markeren immers de momenten waarop, én de redenen waarom klanten de diensten van één of meerdere organisaties willen aanspreken.

Bijzonder genoeg zijn in deze ontwikkelingen informatiemodellen altijd ondergeschikt gebleven aan de ‘business’. Zij werden (en worden) gezien als een onderdeel van de ‘informatievoorziening’, niet van de ‘processen’. Dat is bijzonder omdat de betekenis van processen en services met handen en voeten vastzit aan de betekenis van informatie. Een activiteit met de naam ‘stel beschikking op’ betekent niets zonder een model van een beschikking; een service met de naam ‘verwerk verhuizing’ betekent niets zonder een model van een verblijfsadres.

Voor de duidelijkheid, we doelen niet op gegevensschema’s, die bedoeld zijn voor het ordenen van de opslag en uitwisseling van gegevens. We hebben het over semantische (of conceptuele) modellen die de betekenisrelaties tussen termen en typen beschrijven. Welke vorm zulke modellen aannemen – ontologieën, conceptuele schema’s, kennismodellen, object-event-modellen, … – laten we hier in het midden. Hoe dan ook: dit soort modellen moet uiteindelijk de betekenis vatten en verbinden van zowel gegevens alsook procedures, diensten en gebeurtenissen, anders gezegd: van de business.

Anno 2009 hebben we dus te maken met verschillende soorten ‘ontwerpartefacten’ en hun bijbehorende scholen, methoden en technieken: processen, diensten, gebeurtenissen en informatie. Wie maakt daar nog chocola van? De recente ontwikkeling naar regel-gebaseerd denken zou wel eens een welkome reddingsboei kunnen zijn, om twee redenen. Allereerst brengt de notie van een regel op een nette manier al die voornoemde concepten bij elkaar. Daarnaast versterkt regel-gebaseerd denken de rol van informatiemodellen en vooral van de betekenis (semantiek) van al die ontwerpartefacten. Daarmee krijgt informatie de prominente plek die het moet hebben, óók in het denken over de ‘business’.

Vanuit dit perspectief willen we de volgende kanttekeningen plaatsen bij de bijdrage van Arno Dalhuisen en Bert Lukkien.

Synthese of meer verwarring?
Om te beginnen, in het denken over regel-gebaseerde architecturen – zoals in SBVR – heeft de notie van regel een veel bredere betekenis dan in het genoemde artikel. De beperkte betekenis die er in dat artikel aan wordt gehecht komt overeen met wat vaak rekenregels en/of beslisregels worden genoemd. Er worden echter ook andere soorten regels onderscheiden, zoals informatieregels en ook procesregels, die (deels) de rol van oude proceduremodellen kunnen overnemen. Het artikel doet dat niet en maakt daarmee geen gebruik van de hiervoor genoemde bindende kracht van een breder regel-begrip. Daarmee wordt een kans op synthese gemist en dreigt verwarring over welke aspecten van de ‘business’ nu op welke plaats moeten worden gemodelleerd: in informatiemodellen, in procesregels, in servicespecificaties, in beslisregels, of …?

De keten uit zicht?
Het beschreven concept richt zich vrijwel geheel op individuele organisaties. Alleen in de eerste figuur is ruimte voor ketenpartners en basisregistraties, en dan alleen via het klantdossier. Organisaties in ketens delen echter veel meer met elkaar dan dossiergegevens. Zij delen (mogelijkerwijs) ook levensgebeurtenissen, ook dialogen, ook diensten en óók regels. Niet eenvoudig – omdat hierover dus afspraken moeten worden gemaakt – maar evengoed een fact-of-life.

Wat gebeurt er?
In het beschreven concept lijken gebeurtenissen alleen door burger en bedrijf te kunnen worden ‘aangedragen’. Ook gegevens kunnen echter een sleutelrol vervullen in het ontdekken van gebeurtenissen. Daarmee kan zelfs proactieve dienstverlening worden ingericht. Denk aan een burger die 65 gaat worden: de Sociale Verzekeringsbank – verantwoordelijk voor de uitvoering van de AOW – kan dat zelf zien aankomen en proactief zijn dienstverlening starten in de aanloop naar die gebeurtenis. Dit is een voorbeeld van de grotere rol van informatie (ten opzichte van procedures) in regel-gebaseerde architecturen.

Uiteindelijk kunnen levensgebeurtenissen en klantgegevens nauwelijks modelmatig (semantisch) worden gescheiden. Als het goed is komt elke relevante levensgebeurtenis, vooraf of achteraf, overeen met een veranderde status van betrokken subjecten.

Daarnaast: is een binnengemeentelijke verhuizing een andere gebeurtenis dan een tussengemeentelijke? Of spreken we over één verhuisgebeurtenis en hoort informatie over de betrokken gemeente(n) in de gegevens thuis? Wat betékent eigenlijk een verhuizing? Levensgebeurtenissen horen heel dicht bij het informatiemodel, niet ervan gescheiden.

Dat gaat nog verder. Bij veel levensgebeurtenissen horen meerdere betrokkenen, elk in hun eigen rol. Het meest pregnant is dat bij overlijden. Daar is immers de overledene niet in staat zelf nog diensten af te nemen. Maar dat geldt wel voor nabestaanden, erfgenamen en mogelijk andere betrokkenen. Hoe kunnen dergelijke cruciale relaties anders in beeld gebracht worden dan in een goed (semantisch) informatiemodel?

Pas nadat (levens)gebeurtenissen en de daarbij betrokken rollen in semantische termen zijn gedefinieerd, komt de vraag aan de orde hoe betrokkenen zouden moeten of kunnen handelen in reactie op de gebeurtenis. Dat kan gedefinieerd worden met procesregels. Zo kan dus ook een verandering in gegevens een proces aanvuren, in plaats van een aparte ‘proceslaag’. In het stuk is dus weliswaar sprake van dat ‘het proces bepaalt wat er moet gebeuren’, dat wil zeggen, dat het proces het gedrag van de applicatiecomponenten bepaalt, maar in regel-gebaseerde architecturen wordt die sturing regelmatig (!) verplaatst van procedure naar procesregels, waarin gegevensveranderingen als triggers kunnen optreden.

Centraal beheerde opslag?
In het stuk wordt gesproken over ‘centraal beheerde opslag’ van alle gegevens over burger en bedrijf. Centralisatie van beheer (van hetzelfde gegeven) is belangrijker dan centralisatie van opslag van alle gegevens. Zonder over de wenselijkheid daarvan te willen spreken: grootschalige centralisatie van opslag zal vaak niet mogelijk zijn en is ook niet nodig om de genoemde voordelen te realiseren.

Een dergelijke opmerking kan ook geplaatst worden bij de genoemde ‘centraal beheerde opslag’ van regels. Een organisatie die geraakt wordt door een zekere regel, is nog niet de eigenaar daarvan. Wel is het belangrijk dat regels (bijvoorbeeld uit wetgeving) die op meerdere organisaties (apart of in een keten) van toepassing zijn, door hen op dezelfde manier worden geïnterpreteerd en toegepast. Afstemming hierover is dus wel gewenst.

Business in vieren?
In het stuk is sprake van vier ‘generieke business services’. Het lijkt dat hier vier platformen bedoeld zijn (zoals een rule engine, een database, een applicatieserver, een webserver, et cetera), die elk met de voor hen bedoelde modellen worden gevoed. Als dit juist is, zijn die ‘generieke services’ zeker geen business services, maar juist (kale) platformservices. Het zijn juist de (regel)modellen die de business vertegenwoordigen. Kort gezegd: platform service + regels = business services. De business is nu eenmaal niet in vier generieke services te vatten. Dat zal ook nooit kunnen.

Juist deze ontkoppeling tussen enerzijds de modellen (die de business uitdrukken) en anderzijds de onderliggende generieke machines zorgt ervoor dat de business aan het stuur komt te zitten. Die hoeft zich immers alleen met de modellen bezig te houden; de machines zijn vervolgens de trouwe werkpaarden die de modellen uitvoeren. Overigens moeten deze modellen wel zo scherp zijn dat de machine ze ook begrijpt. Vertegenwoordigers van de business zijn vaak niet gewend zulke precieze modellen te maken.

Tot slot
In het artikel worden beloftes gedaan die in de hierboven beschreven twintig jaar geschiedenis al herhaaldelijk zijn gemaakt: wendbaarheid, transparantie en betere dienstverlening. Regel-gebaseerde architectuur kan inderdaad een belangrijke bijdrage aan deze doelen leveren. Maar laten we ook bescheiden blijven. Eerdere zilveren kogels hebben het toch ook net niet helemaal gebracht. Er is geen enkele methode of standaard die het allemaal voor ons gaat regelen. Gezamenlijk vakmanschap, van business én van ontwerpers, blijft een noodzakelijk ingrediënt.

Regel-gebaseerde architecturen kunnen helpen de historische scheefgroei in het ontwerpen van ‘bedrijfsprocessen’ te corrigeren en zo procedures, diensten, gebeurtenissen en informatie in balans en vooral in betekenisvolle samenhang te ontwerpen. Het herstellen van de rol van informatiemodellen, en vooral van semantiek, is daarbij cruciaal. Dat versterkt bovendien de relatie met het ontwerpen van software, zodat we een stukje afknabbelen van de – deels kunstmatige – afstand tussen business-ontwerp en software-ontwerp. Zo kan het gezamenlijk vakmanschap tussen de twee werelden eindelijk vorm krijgen.

Paul Oude Luttighuis is principal researcher en consultant bij Novay;
Marc Lankhorst is principal researcher en groepsleider bij Novay;
Dick Quartel is senior researcher bij Novay.