Wendbaarheid met business rules?

Paul Oude Luttighuis, Marc Lankhorsten Dick Quartel, donderdag 08 oktober 2009

De laatste tijd is het gebruik van regel-gebaseerde architecturen sterk in opkomst. De belofte is dat deze kunnen bijdragen aan wendbaarheid, transparantie en betere dienstverlening, doordat business- en software-aspecten beter gescheiden worden. Een panacee is deze aanpak echter niet en we moeten oppassen dat dit niet het zoveelste paradigma wordt dat naast de al bestaande aanpakken een volgende laag van complexiteit introduceert.

Twintig jaar denken over enterprise architectuur

Een beschouwing over de rol van regels in architectuur vraagt allereerst om een historische context van de ontwikkeling. We beginnen daarom met een korte geschiedenis van het denken over informatiehuishoudingen. 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.

Processen

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 Taylorisme 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 toekomst.vaste informatiehuishouding was al wel bekend in de software engineering, maar het zou nog even duren totdat dat inzicht doorsijpelde naar de business-wereld.

Services

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.

Events

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 (levens)-gebeurtenisseneen 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.

Informatie

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?

Regels

De recente ontwikkeling naar regel-gebaseerd denken (zie ook [Coenen, 2009]) zou 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’.

Een belangrijke valkuil in regel-gebaseerde architecturen is om regels te introduceren als ontwerpartefact-nummer-zoveel, naast procedures, diensten, gebeurtenissen en gegeven. Daarmee dreigt een spraakverwarring en wordt een kans op betekenisvolle synthese gemist. Een voorbeeld daarvan is te vinden in [Dalhuisen, 2009].

Synthese of meer verwarring?

In het denken over regel-gebaseerde architecturen – zoals in SBVR, [OMG, 2008] – heeft de notie van regeleen zeer brede betekenis. Vaak zien we echter dat er in de praktijk (bijv. [Dalhuisen, 2009]) een veel beperktere betekenis wordt gehanteerd, die overeen komt met wat vaak rekenregels en/of beslisregels worden genoemd. We kunnen echter ook andere soorten regels onderscheiden, zoals informatieregels en ook procesregels, die (deels) de rol van oude proceduremodellen kunnen overnemen.

Zo’n smalle blik op het concept maakt 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 …?

Een ander gevaar is dat regels alleen worden geïnterpreteerd in de context van één individuele organisatie. Organi.saties werken echter samen in ketens en delen daarmee veel meer met elkaar dan alleen dossiergegevens. Zij delen (mogelijker.wijs) ook levensgebeurtenissen, ook dialogen, ook diensten en óók regels. Niet eenvoudig – omdat hierover dus afspraken moeten worden gemaakt – maar evengoed een fact-of-life.

Gebeurtenissen

In een business rules aanpak wordt veelal een bijzondere rol toegekend aan de hierboven beschreven gebeurtenissen, die een organisatie uit haar omgeving opvangt en waarop zij, regel-gestuurd, reageert. Een belangrijke vraag is dan ook hoe we de relatie tussen regels en gebeurtenissen (in het bijzonder ‘life events’) moeten zien en wat een gebeurtenis eigenlijk is. Het blijkt bijzonder moeilijk om zulke levensgebeurtenissen en klantgegevens modelmatig (semantisch) van elkaar te scheiden. Als het goed is komt elke relevante levensgebeurtenis, vooraf of achteraf, overeen met een veranderde status van betrokken subjecten. Gegevens kunnen dan ook 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.

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 regel-gebaseerde architecturen wordt die sturing echter regelmatig (!) verplaatst van procedure naar procesregels, waarin gegevensveranderingen als triggers kunnen optreden.

Tot slot

In de business rules wereld worden worden soms 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. De 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.

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.

En laten we vooral 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.

[PDF]

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Sponsoren

Sessies

15/16-11: Landelijk Architectuur Congres meer...

Advertenties

Je kunt hier adverteren

© 2018   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden