- Is it about sharing actual rules overlapping in geography, product offerings or lines of business?
- Is it about defining a “mold” for business rules applicable to one problem?
Well, I did not realize that some people only viewed deployment as the unit of reuse until I stumbled upon some LinkedIn group updates today. I commented there of course but since you may not be members of the group, I am copying the response here too:
Well, yes and no…
You can see rule reuse in many different ways. Of course, the most intuitive idea conveyed by the notion of “Universal Decision Engine” is that you can access a rules service from many different applications and/or channels. There is nothing new or specific to business rules here since SOA is addressing this very aspect.
I think that rule reuse goes far beyond just the rules service deployment though.
In a large system, it is likely that business rules of the same “flavor” might be affected by local regulations or competitive strategies. This is where rule reuse becomes critical to scale to tens of thousands or even millions of rules. I know more than one project that faced that level of complexity and struggled to organize their rules *right* to ease the maintenance down the road. You can see rule reuse in those cases as:
– the ability to segment and partition business rules for easy maintenance, allowing to construct rules services dynamically picking up the right mix of governing rules – global, regional, local… In some cases, design by “baskets” as The Hartford presented a few years ago at Business Rules Forum might be a solution. Design by local exception is an equally appropriate design pattern. Some products provide such support more or less out-of-the-box. Please do not derive from the example here that I want to cram all the segmentation criterias in the conditions of a gigantic ruleset. That would be madness or more specifically “un-manageable”.
– reuse could be abstracted too. Think about templates. Don’t take me too literally here. I am not necessarily referring to template capabilities of commercial BRMS products. I am talking about the generic concept of templates. If you see the same “pattern” occurring over and over again, you may want to capture it so that you can define business rules quickly that conform to it. For example, it could be an eligibility decision service. Many rules of the same kind will invariably be there, granted with different thresholds; some other rules might sometimes be defined. Having a fast way to construct one new such service can be a time saver as well as a quality assurance factor. It might for you (as a Business User) to cover all typical aspects of an eligibility service. You want it flexible enough though to add new criterias that were not considered before. The type of interaction to construct it could then be anything that makes sense. Think outside the box.
I think we (the industry) have not invested enough in those areas. I encourage you, end users of the technology, to focus on your true needs rather than how the technology has been used so far.
Et voila!
Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager
