Business Rules Come First

onlangs spraken collega ‘ s en ik met de chief software developer van een grote klantorganisatie over de vooruitgang bij een grote re-engineering inspanning daar. Onze zorg was of de leden van het projectteam een deadline van ongeveer negen maanden konden halen voor het leveren van een grootschalig prototype. We hadden net een aantal intensieve maanden besteed aan het ontwikkelen van een uitgebreid businessmodel, en ze hadden nog enkele maanden systeemontwerp te voltooien.

deze hoofdontwikkelaar is zeer scherp—niet iemand om lichtvaardig aan een antwoord te committen. Lange tijd zei hij niets, in gedachten verzonken. Tot slot, kijkend naar de gedetailleerde zakelijke diagrammen gepleisterd op de muren rondom, zei hij: “als we al waren begonnen met coderen, zou ik zeggen dat we helemaal geen kans hadden. Maar aangezien we nog niet begonnen zijn met programmeren, denk ik dat de kans vrij groot is.”

ik moest dat meerdere malen in mijn gedachten herhalen voordat ik zijn betekenis begreep. “Als we al begonnen waren met programmeren, zou ik zeggen dat we helemaal geen kans hadden.”

ik wist dat hij dacht dat de applicatie-codering zelf vrij moeilijk zou zijn. Het zou gaan om het gebruik van een rules engine, een wereldwijd distributienetwerk, grafische gebruikersinterfaces en een aantal belangrijke middleware.

hij zei dat als ze alle zakelijke problemen moesten oplossen tijdens het coderen, ze het nooit op tijd zouden doen—of waarschijnlijk nooit. Echter, omdat het projectteam was het aanpakken van de moeilijke zakelijke kwesties van tevoren (met inbegrip van het specificeren van de bedrijfsregels), hij dacht dat ze een vrij goede kans op het invullen van de code door de streefdatum.

in grote mate gaat het bij de business rule benadering simpelweg om het stellen van de juiste vragen van de juiste mensen. Er is maar één manier om eerlijk te voldoen aan een deadline—en dat is om het zakelijke probleem eerst op te lossen.

Business-Driven IT

In de begindagen van het bouwen van bedrijfssystemen, kon de zakelijke kant in wezen achterover leunen en ze gewoon laten gebeuren. De voordelen van automatiseren waren zo overtuigend dat je vrijwel niets verkeerd kon doen. Nu, voor alle praktische doeleinden, het bedrijfsleven en het werken onlosmakelijk. Bij het uitvoeren van projecten zou de logische stap dan zijn om naadloze business/IT-projectteams samen te stellen en hen een business-georiënteerde aanpak te laten volgen om vereisten te ontwikkelen. Toch zijn veel bedrijven nog lang niet zover dat te doen.

maar al te vaak, de zakelijke kant produceert nog steeds fuzzy, slecht-gerichte “eisen,” en de IT-kant blijft doen “eisen” slechts een inkeping of twee boven de programmering. Hoe kan deze kloof tussen business professionals en IT-professionals bij het ontwikkelen van eisen worden gedicht?

het antwoord is relatief eenvoudig. Het bedrijf heeft behoefte aan een georganiseerde aanpak die zakelijke professionals in staat stelt om de ontwikkeling van de eisen te stimuleren. Deze aanpak moet zorgen voor een routekaart die laat zien hoe je op de juiste momenten de juiste vragen kunt stellen over de juiste dingen. Wat nodig is, is een business-driven aanpak.

bij traditionele ontwikkelingsbenaderingen gaat er meestal veel verloren in de vertaling van de vereisten vooraf naar het eigenlijke draaiende systeem. Maar het schrijven van een set van duidelijke zakelijke regels verbetert de communicatie tussen de zakelijke kant en IT, en biedt een brug tussen business analyse en systeemontwerp. De business rule aanpak helpt om de vereisten kloof tussen de zakelijke kant en de IT-kant te dichten.

Wat is een zakelijke regel? Vanuit zakelijk oogpunt is het een richtlijn bedoeld om gedrag te beïnvloeden of te sturen. Business rules zijn letterlijk de gecodeerde kennis van uw bedrijfspraktijken. Vanuit een IT-oogpunt, een business rule is een atomaire stuk van herbruikbare business logica.

op een bepaalde manier weet iedereen wat bedrijfsregels zijn—zij zijn de leidraad voor uw bedrijf bij het uitvoeren van de dagelijkse activiteiten. Zonder zakelijke regels, je zou altijd om beslissingen te nemen op de vlieg, kiezen tussen alternatieven op een case-by-case basis. Dingen op die manier doen zou erg langzaam zijn.

regels zijn ons allemaal bekend in het echte leven. We spelen volgens regels, we leven onder een rechtssysteem gebaseerd op regels, en we stellen regels voor onze kinderen. Maar het idee van regels in bedrijfssystemen is ironisch vreemd aan de meeste IT-professionals. Zeg “regels” en veel IT-professionals denken vaag van expert systemen of kunstmatige intelligentie. Er is weinig erkenning van hoe centrale regels eigenlijk zijn voor de basis, dag-tot-dag operaties van het bedrijf.

niet toevallig zijn veel werknemers en managers in het bedrijfsleven zo goed geïndoctrineerd in de procedurele opvattingen voor het ontwikkelen van eisen dat het denken in termen van regels vreemd of abstract kan lijken. Vrijwel elke methodologie is schuldig in dit opzicht, of het nu gaat om business process re-engineering, systeemontwikkeling of software-ontwerp.

dit is om twee redenen jammer:

1. Denken over elke georganiseerde activiteit in termen van regels is eigenlijk heel natuurlijk. Stel je bijvoorbeeld voor dat je een spel zoals schaken, dammen, honkbal of voetbal probeert uit te leggen zonder de regels uit te leggen.

2. Bedrijfswerkers en managers hebben de kennis die nodig is om goede regels te creëren.

Voorbeeldregels

bekijk de voorbeeldregels die volgen en merk op hoe elk aspect van operationele controle in een bedrijfssysteem kan worden aangepakt met regels:

* beperkingen: een klant mag niet meer dan drie spoedorders op zijn kredietrekening plaatsen.

* heuristiek: Een klant met voorkeursstatus moet zijn bestellingen onmiddellijk laten invullen.

• berekeningen: het jaarlijkse ordervolume van een klant moet worden berekend als de totale verkoop die tijdens het boekjaar van de onderneming is gesloten.

• conclusie: een klant moet als voorkeur worden beschouwd als de klant meer dan vijf bestellingen van meer dan $1.000 plaatst.

• Timing: een klant moet worden gearchiveerd als de klant gedurende 36 opeenvolgende maanden geen bestellingen plaatst.

• Triggers: “send advance notice” moet worden uitgevoerd voor een bestelling wanneer de bestelling wordt verzonden.

regels bouwen rechtstreeks op voorwaarden en feiten. Termen—zoals klant, verzending en factuur-moeten een nauwkeurige, ondubbelzinnige definitie hebben in het bedrijf. Bijvoorbeeld, klant kan worden gedefinieerd als: “een organisatie of individuele persoon die ten minste één betaalde bestelling heeft geplaatst in de afgelopen twee jaar.”

feiten worden gegeven door eenvoudige, declaratieve zinnen die de termen verbinden met een werkwoord of werkwoordzin, zoals “klant plaatst bestelling.”

een “fact model” is een reeks fact statements die de resultaten van een bedrijfsactiviteit beschrijven. Een fact model moet dienen als een eerste blauwdruk voor een datamodel, maar het primaire doel is om kennis over het bedrijf vast te leggen in een gestructureerde vorm, gedistilleerd uit de business-side werknemers en managers die het bezitten.

regels voegen in wezen de Betekenis van de woorden must or must not toe aan de termen en feiten, zoals in: “Orders op krediet van meer dan $1.000 moeten niet worden geaccepteerd zonder kredietcontrole.”

regels moeten worden uitgedrukt in duidelijk, ondubbelzinnig, goed gestructureerd Zakelijk Engels, te beginnen met een expliciet onderwerp. Regels moeten geen pluis hebben en geen ontbrekende feiten. Regels kunnen worden gekwalificeerd, zoals in ” een zending moet worden verzekerd als de zending waarde groter is dan $ 500.”En regels kunnen timing criteria omvatten, zoals in” een student moet zijn ingeschreven in ten minste twee cursussen tegen het einde van de registratie.”

Rule Independence

een bedrijf lijkt erg op een menselijk lichaam. De kennis (term en feit) structuur is als het skelet; de processen zijn de krachtige spieren; en de regels zijn het zenuwstelsel dat de andere twee controleert. Alle drie zijn essentieel en met elkaar verbonden. Maar zakelijke regels moeten gescheiden zijn van de andere twee. Een basisprincipe van deze aanpak is dat regels onafhankelijk zijn van processen en procedures. Een bijkomend voordeel van die” regelonafhankelijkheid ” is een enorme vereenvoudiging van de processen.

het resultaat is een “dun proces”, een langdurig doel van veel IT-professionals. Door de regels uit de processen te halen, kunt u processen produceren die relatief eenvoudig zijn en naar behoefte kunnen worden veranderd.

in de National Football League, als een spel niet werkt voor een team, zal het verdwijnen uit het speelboek binnen een paar wedstrijden. De toneelstukken zijn in wezen wegwerpartikelen. Evenzo moeten bedrijven hun eigen procedures zien als wegwerpproducten—goedkoop genoeg om zich te ontdoen en gemakkelijk te vervangen wanneer de procedures niet meer goed werken.

Wegwerpprocedures zijn een must voor het aanpassingsvermogen en de concurrentiekracht van het bedrijf. Dit bedrieglijk eenvoudige idee-mogelijk gemaakt door de business rules aanpak—kan een revolutie in de manier waarop het werk wordt gedaan en systemen worden ontworpen. Reprinted with permission from Principles of the Business Rule Approach, door Ronald G. Ross (Addison-Wesley, 2003). Ross is medeoprichter en principal van Business Rule Solutions LLC en uitvoerend redacteur van de website BRCommunity.com.

Library Fact Model
dit diagram toont een grafisch fact model voor een library. De formulering van de regel is direct gebaseerd op het fact model, dat is een diagram van de basis zakelijke Concepten – een kennisstructuur. Een feitenmodel kan en moet een eerste-cut blauwdruk bieden voor hoe gegevens uiteindelijk in een database zullen worden georganiseerd. REGEL: Een bibliotheekpas mag alleen worden gebruikt om een boek uit te checken als het boek eigendom is van een bibliotheek waarvoor de kaart is geautoriseerd.