tag:blogger.com,1999:blog-7119233.post112723205450488902..comments2021-09-14T01:47:02.709-07:00Comments on BizKnowledge: BizTalk Rules engine scalibilityEnsinghttp://www.blogger.com/profile/01098367831623180604noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-7119233.post-5374631990547296552013-10-21T09:08:57.484-07:002013-10-21T09:08:57.484-07:00I am looking for places where I can find informati...I am looking for places where I can find information on a <a href="http://www.decisions.com" rel="nofollow">business rules engine</a> and this was perfect. Thanks so much for posting this. You helped me out a bunch.Anonymoushttps://www.blogger.com/profile/07619638933115322455noreply@blogger.comtag:blogger.com,1999:blog-7119233.post-7871182504182021742013-08-09T12:45:05.406-07:002013-08-09T12:45:05.406-07:00How does the business rules engine work? I'm s...How does the <a href="http://www.decisions.com" rel="nofollow">business rules engine</a> work? I'm still confused how it's applied and integrated into the company. I love reading this though, you did a great job of explaining the product.Anonymoushttps://www.blogger.com/profile/07619638933115322455noreply@blogger.comtag:blogger.com,1999:blog-7119233.post-1161723846079353542006-10-24T14:04:00.000-07:002006-10-24T14:04:00.000-07:00Marco,Since a decision tree has many paths, I like...Marco,<BR/><BR/>Since a decision tree has many paths, I like to include each one in the rule count. <BR/><BR/>Re "Take down the mirrors and smoke screens on business rules, and you will see it is all not that different."<BR/><BR/>Well, you're right, it's just a little different from the status quo procedural programming.<BR/><BR/>But I think you'll agree that that slight difference results in lots of benefits (time to market, agility, externalizing rules, etc.)<BR/><BR/>See <A HREF="http://www.bizrules.info/blog/2006/08/whats-big-deal-with-business-rules.html" REL="nofollow">What's the big deal with the business rules approach?</A><BR/><BR/>As you said, "The power of business rules are in the declarative nature."Rolando Hernandezhttps://www.blogger.com/profile/07236576683590137065noreply@blogger.comtag:blogger.com,1999:blog-7119233.post-1137277614097741112006-01-14T14:26:00.000-08:002006-01-14T14:26:00.000-08:00James, thanks for the responds. I feel obligated t...James, thanks for the responds. I feel obligated to further classify my statement after reading your post. There are probably two misinterpretations:<BR/><BR/>First of all: I’m <B>not</B> stating that a company does not have thousands of business rules. They often do. However these rules are grouped together in functional modules. <BR/><BR/>Within Microsoft Biztalk such a group of rules are referred to as a Rule Policy. CA’s Aion refers to a group of rules as a Ruleset. And probably ILog and Blaze are also using the term Ruleset.<BR/><BR/>There can be rule policies (rulesets) for Eligibility, Product pricing, Marketing Campaigns etc. <BR/><BR/>And within a subcategory of ‘Eligibility’, it can be further divided in ‘General Eligibility rules’, and ‘A product specific eligibility rules’, or ‘A region specific eligibility rules’ etc.<BR/><BR/>Interestingly enough Domain Driven Design Patterns (Eric Evans) can assist in identifying proper modules (a.k.a. policies, a.k.a rulesets)<BR/><BR/><I><BR/>Everyone uses modules, but few treat them as a full-fledged part of the model. Code gets broken down into all sorts of categories, from aspects of the technical architecture to developers' work assignments. Even developers who refactor a lot tend to content themselves with modules conceived early in the project.<BR/>It is a truism that there should be low coupling between modules and high cohesion within them. Explanations of coupling and cohesion tend to make them sound like technical metrics, to be judged mechanically based on the distributions of associations and interactions. Yet it isn't just code being divided into modules, but concepts. There is a limit to how many things a person can think about at once (hence low coupling). Incoherent fragments of ideas are as hard to understand as an undifferentiated soup of ideas (hence high cohesion). <BR/> <BR/>Therefore, <BR/>Choose modules that tell the story of the system and contain a cohesive set of concepts. This often yields low coupling between modules, but if it doesn't look for a way to change the model to disentangle the concepts, or an overlooked concept that might be the basis of a module that would bring the elements together in a meaningful way. Seek low coupling in the sense of concepts that can be understood and reasoned about independently of each other. Refine the model until it partitions according to high-level domain concepts and the corresponding code is decoupled as well. <BR/>Give the modules names that become part of the ubiquitous language. modules and their names should reflect insight into the domain.<BR/></I><BR/><BR/>Secondly we might have a different interpretation of how we count rules. I consider decision table as well as decision trees as a single atomic rule. And I only consider rules that are actually executed by an inference engine. <BR/><BR/><BR/>Putting all this in the analogy of software design; yes over time we have created software programs with millions lines of code. But the divide and conquer strategy of component based development has lead to maintainable and understandable code. Take down the mirrors and smoke screens on business rules, and you will see it is all not that different. <BR/><BR/>The power of business rules are in the declarative nature.Ensinghttps://www.blogger.com/profile/01098367831623180604noreply@blogger.com