Zelf vind ik dat business rules! Precies om die reden heb ik eigenlijk niet zoveel met business rules. Mogelijk wordt dat veroorzaakt omdat business rules uit de technologie op ons af zijn gekomen. Van origine was er geen onderscheid in rules; later knipte de techniek ‘de boel’ (allemaal technisch dus) op in applicatielogica en andere logica. Die andere logica werd ‘gewoon’ businesslogica genoemd. Weet iemand (nog) waarom? Iets dat niet langer strikt op de applicatie betrekking heeft, is toch nog niet zomaar en automatisch ‘business’? 
 
Oord stelt: “Het oorspronkelijke idee achter business rules, zoals dat al jaren wordt verkondigd door goeroe Ron Ross is goed. Maak een scheiding tussen applicatielogica en businesslogica. Applicatielogica hoort bij de ICT-afdeling, businesslogica hoort bij de Business.” 
 
Is dat waar? Hoort de businesslogica werkelijk bij de business - zoals de naam suggereert? Waarom spreekt het de business dan niet veel meer aan? Zou het misschien zo kunnen zijn dat wat wij (vanuit de techniek dus) business rules noemen... eigenlijk helemaal geen business rules zijn, maar gewoon een zinvolle technische afsplitsing van wat voorheen samen applicatielogica werd genoemd? Dat zou in ieder geval verklaren waarom de business er geen begrip van/voor heeft. Het zijn hun rules/logica immers niet! Mee eens: “Anders waren ze wel ICT’er geworden.”  
 
Zou het zo kunnen zijn dat echte businesslogica - hoewel sterk gerelateerd aan ‘businesslogica’ – toch van een kwalitatief andere orde is dan wat IT-ers ervan verwachten? 
 
Wat mij betreft: “let the business rule”, maar dan wel met haar eigen mensenlogica, met haar eigen business rules. Vooral niet met ‘business rules’ zoals ze uit de techniek zijn voortgekomen. Dat wordt, inderdaad, niks.

Is het niet alles wat we in IT doen gerelateerd aan business? Wat maakt de business rules technologie meer business dan laten we zeggen "Domain-driven design" afgezien van het woordje business ervoor. Gezien het architectuurwerk voornamelijk bestaat uit het begrijpen wat business wenst (of nog beter: nodig heeft) en vervolgens onder andere het kiezen van de juiste patronen en raamwerken, is business rules "technologie" niets meer dan een manier om een IT oplossing vorm te geven. Het feit dat business (ofwel niet-technici) niets met business rules technologie doen, is eigenlijk logisch. Het is voor ITers en door ITers gemaakt om business beter te bedienen.

Beheren van bedrijfsregels via een eenvoudige spreadsheet zoals bij OpenRules is een methode die ook wordt gebruikt bij TripleForms eFormulieren (in gebruik bij veel gemeenten). Blijkbaar vormt dit nu een goede middenweg waarbij, lekker laagdrempelig, toch een deel van de businessrules beloften kan worden waargemaakt.

Met lichte verbazing heb ik bovenstaand artikel gelezen. De rule engines van tegenwoordig, zoals bijvoorbeeld Oracle Policy Automation of Be Informed zijn stukken krachtiger dan in dit artikel is verondersteld. Het probleem ligt niet in de veronderstelling dat de tools niet krachtig genoeg zijn (dit zijn zij zeker wel!) in combinatie met de juiste ondersteuning voor de business user. Één van de problemen is dat de business niet geleerd wordt om te gaan met de regel engines. Zij worden aan hun lot overgelaten door de ICT. Regelgestuurd werken is wel even een hele nieuwe manier van werken. Het zit hem inderdaad in competenties, je moet wel analytisch kunnen denken om met een regel engines om te gaan. En dat is een competentie die gemiddeld genomen nog ontbreekt bij de Business. Het is ook een andere manier van kijken naar jouw eigen kennis. Het is niet dat we daardoor maar weer nagenoeg volledig terug moeten naar de ICT`er (die zijn namelijk ook niet zo heel goed in het scherp krijgen van requirements), de business moet aan de hand worden meegenomen in deze nieuwe wereld! Capacity building noem je dat, van meekijken, naar meedoen, naar zelfdoen. 
 
Het tweede punt waar ik het echt zeer oneens mee ben, is dat het aantal implementaties in de echte wereld zeer gering is. Wat een onzin! Kijk naar publieke organisaties als de IND, SVB en Belastingdienst, allen hebben zij regel engines geimplementeerd, of zijn zij deze aan het implementeren. En bijvoorbeeld de Engelse en Amerikaanse Belastingdienst hebben een heel scala aan regel engines. Dus ik weet niet waar de heer van Oord werkt, maar wellicht is dat niet in de echte wereld ;) (of publieke sector telt niet mee). Daarnaast zie je bij nagenoeg iedere huidige aanbesteding in de publieke sector sowieso regel gestuurd werken als centrale component terugkomen in de architectuur. Waar dan aan vast zit, de wens om een regel engine te implementeren (waarbij soms de vraag gesteld kan worden of dit voor een specifieke organisatie nog niet iets te vroeg is, maar dit is een ander verhaal). 
 
En ik ken OpenRules, dat is nu een perfect voorbeeld van een nog vrij berperkte rule engine als je deze afzet tegen de krachtige regel engines in de markt die wel een centrale rol in een toekomstigbestendige architectuur kunnen spelen. OpenRules kan dit op dit moment zeker niet. 
 
Om op de retorische vraag 'wat is hier nu aan de hand' te reageren: 
 
- Na aanschaf van een regel engine laat de ICT de business aan haar lot over 
- De business heeft veranderingsweerstand 
- Het management van BRM (de M) wordt onvoldoende ingericht, waardoor het beheer van regels in de soep loopt (geen duidelijke taken, rollen en verantwoordelijkheden) 
- ICT kan onvoldoende de juiste BRE/BRMS combinatie samenstellen met en voor de business 
- Er is nog geen enkel pakket op de markt die de complete BRM behoefte afdekt! 
 
Zoals ik het nu zo schrijf lijkt het wel een klaagzang, maar ik ben wel enthousiast over het feit dat Erwin hiermee zijn nek uitsteekt, ga zo door, het scherpt mijn denken ook weer. Erwin, bedankt!

Bjorn, 
 
Ik hoor je nog geen voorbeelden noemen waar business daadwerkelijk zelf met rules engine aan de slag gaat. Een rules engine gebruiken is een, maar gebruiken zoals bedoeld waar iemand vanuit business daadwerkelijk zelf in charge is en invulling geeft, lijkt me iets anders. Het lijkt me interessant om een artikel te lezen over het succesvol toepassen van een rules engine met nadruk op de betrokkenheid van business.

Viktor,  
 
Vanuit mijn eigen werkervaring is het eerste voorbeeld dat mij te binnen schiet nog wel de Nederlandse Douane (circa 5500 medewerkers in totaal). Douaniers werken daar in een regel analistenteam al ruim vier jaar zelfstandig met de bedrijfsregels met en in de regel engine Blaze Advisor van FICO. De regel engine wordt daar ingezet om kennis rondom risico`s in de goederenketen vast te leggen, en risico`s deels geautomatiseerd te kunnen detecteren en goederen(zendingen) te selecteren voor controle. Uiteraard werken ook zij binnen de beperkingen van IT (aanpassingen op het datamodel waarop bedrijfsregels geschreven kunnen worden duren vrij lang) maar zij zijn binnen de kaders van dat datamodel vrij in het opstellen, implementeren en beheren van bedrijfsregels, en doen dat ook zelfstandig. Er zijn veel geleerde lessen en verbeterpunten te noemen in dat project, maar één ding staat als een paal boven water, de business rules! bij de Douane :). 
 
Het is evenwel zeker een heel goed idee om meer te publiceren over bedrijfsregel implementatie waarbij de betrokkenheid van de business groot is, je hebt me meteen getriggerd, ik ga contact zoeken met de Douane! En dat is meteen een oproep aan iedereen die dit leest, laten we de (succes) verhalen verzamelen, zodat mythe van feit gescheiden kan worden.

Bjorn, 
 
Een interessante case. Ik zou zeker meer over willen weten. In je uitleg noem je even een hoop interessante punten waarover ik zeker kritische vragen zou kunnen stellen. Als je die met voors en tegens kan beantwoorden, dan wordt het nog interessanter: 
 
1. Beschouw je de analistenteam de business of IT? In mijn ervaring zijn dat ITers met weliswaar geen zorg over techniek, maar zijn wel door technische (on)mogelijkheden geconditioneerd. Hun hoofdzorg is het business begrijpen en vertalen naar IT. Hun dagelijkse bezigheid is IT-gerelateerd. Voor een echte business mens is IT een bijzaak, ondersteuning. Hun dagelijks werk is het toepassen van een of meer business processen zoals controleren van zendingen in Douane geval. 
 
2. De afhankelijkheden met datamodel en misschien andere technische aspecten kunnen wel killend zijn voor de uiteindelijke doel: snel een rule aan kunnen passen zonder hulp van IT engineers. Komt niet daarmee de toepassing van rules engines ter discussie te staan? Immers, business had net zo goed de regels in Word of Excel kunnen opschrijven. Dan zijn ze nog steeds in charge. 
 
3. Ik zou het onderscheid willen zien in wie in charge is en wie daadwerkelijke implementatie uitvoert. Een rules engine kan nog steeds een goede middel zijn om rules uit te voeren. Als de invoer en het bijhouden hoe dan ook door IT-ers plaatsvindt of sterke betrokkenheid vereist, dan is een rules engine slechts een technische manier om rules af te dwingen, toch? Business is nog steeds in charge, ook al hebben ze niet te maken met daadwerkelijke implementatie. 
 
gr., Viktor

Goedemiddag Viktor, 
 
In reactie op jouw vragen: 
 
1. Het analistenteam zijn pure business mensen met een douanetechnische achtergrond. Daarom zijn zij nog niet altijd in staat gebleken hele complexe situaties goed af te dekken, en ook de regel architectuur laat nog steeds te wensen over (hopelijk schoffeer ik hier niemand mee, in hun verdediging, het is baanbrekend BRM werk geweest). Dit brengt dan beperkingen met zich mee in het dagelijkse 'regel werk', oftewel de creatie, implementatie en het onderhoud van regels. Men is vooral bezig met die ene regel, en in mindere mate met het grotere geheel. Dat maakt het toekomst borgen van (enkele van) de pijlers van BRM, meer flexibiliteit en complexiteit snel kunnen activeren binnen je bedrijfsvoering, lastig vol te houden. 
 
2. Daar heb je deels een punt. Lastige voor de Douane is wel dat zij zich hebben geconformeerd aan een internationale (WCO en EU) datastandaard. Daarbij komt dan ook nog eens dat ieder data onderdeel waar zij op willen selecteren via Brussel gaat. Dus dat is sowieso (buiten de rule engine om) een 'dingetje'. Maar het is voor een 24/7 bedrijfsvoering killing dat men, als men een risico vindt, waarvoor men wel de data in de aangiftesystemen binnenkrijgt, maar nog niet in de dataset aangeboden krijgt binnen de rule engine (ergo, je kunt er geen bedrijfsregels op schrijven), dat je via IT moet om die te kunnen toevoegen (eis van de business was ook, hele dataset), maar IT had de overhand door te zeggen, alleen wat je nu nodig hebt ivm performance, IT claimde snel te kunnen opschakelen, helaas bleek praktijk anders...ik begrijp je redenatie rondom Word en Excel niet, wat ga je daar dan mee doen, als je die regels daarin hebt gevangen? Hoe ga je die handhaven binnen je aangiftesystemen met miljoenen aangiftes, waarvan je maar een promille kunt selecteren? Maar om terug te komen op jouw vraag, belangrijkste rule engine drivers zijn daar wel behaald, centraal toepassen van bedrijfskennis, flexibel kunnen omgaan met de bedrijfslogica (binnen kaders ;)), zelfstandig als business aanpassingen kunnen verrichten in de bedrijfslogica. 
 
3. Dat onderscheid wordt nu juist bij goed ingevoerde BRM vrij klein, en vindt plaats in uiterst nauwe collaboratie. Doordat de regeltalen van de rule engines steeds uniformer worden, en steeds meer op bedrijfstaal (kunnen) lijken, is die scheidslijn kleiner aan het worden. Ik vind het dan ook op z`n zachtst gezegd opmerkelijk dat BRM software vendors (BRMS en BRE) niet veel nauwer samenwerken en integreren dan dat ze nu doen. Maar zoals ik in mijn BRM praktijk zie, er bestaat nog niet één pakket die het volledige BRM concept, of BRM proces met software ondersteunt, dus je hebt deels zeker (nog) een punt. Daar is wellicht ook een mooie rol voor architecten weggelegd ;). Ander punt dat ik nog wil maken, is dat voor het bedrijfsregel denken, het in voorkomende gevallen zelfs beter is een regel niet in de regel engine te plaatsen, maar op andere wijze te implementeren. Er zit dus nog een hele wereld voor (en na) de regel engine. Mensen denken ten onrechte dat BRM = BRE. Maar zo is het niet. Het kan dus wel zo zijn dat IT`ers de implementatie van bedrijfsregels uitvoeren, als de regels nooit (of nagenoeg nooit) wijzigen kun je er wellicht voor kiezen om deze bijvoorbeeld weer in harde code te gieten (wellicht goedkoper?). Een regel engine kan een technische manier zijn om regels te implementeren, maar het is maar net welk smaakje regel engine je aanschaft, en wat voor type medewerkers je hebt (of wilt hebben) die met de regels aan de slag gaan. Oh ja, en hoe je wetten, regelgeving & beleid dat je in regels wilt vangen er uit ziet natuurlijk ;).