Thinking Through Rules in C#

2008 Paula DiTallo — Sat, 08 Mar 2008 02:51:33 GMT

As I continue with writing the manuscript on rules engines, I've isolated my examples to be coincidental with the overall theme of engineering decision support applications. Today, I am taking a close look at the seemingly simple act of identifying and rejecting unattractive alternatives when competing projects are under review to determine whether or not a given project will warrant funding.

Some of the determining factors are well known algorithms in the financial world. Specifically I am thinking about the rate of return on investment (roi), present worth (pw), annual cost (euac), annual benefit (euab), benefit-cost ratio (bc), net present worth (npw). Overall, these calculations can quickly help decide whether the minimum level of economic attractiveness is met by a project. I will elaborate on each of these later. For now, any of the methods may be used independently or collectively to ultimately reject a candidate project.

Before we translate this decision process to a specific rule engine implementation, Let's look at a class stub I wrote to think it through:

using System;
using System.Collections.Generic;
using System.Text;

namespace CapitalExpendProjProp
{
    public class ProjectProposal
    {
        // MARR = minimum attractive rate of return
        public int ProjectReview(string Project, string[] alternative, int MARR)
        {
            int roi, pwb, pwc, euac, euab, bc, npw, rejTally = 0;

            foreach(string alt in alternative)
            {
                roi = rateOfReturn();
                if (roi < MARR)
                { rejTally = rejTally + 1; } // REJECT

pwb = presentWorthBenefits();
pwc = presentWorthCosts();

if (pwb < pwc)
{ rejTally = rejTally + 1; } //REJECT

euac = AnnualCost();
euab = AnnualBenefit();

if (euac > euab)
{ rejTally = rejTally + 1; } //REJECT

bc = BenefitCostRatio();

if (bc < 1)
{ rejTally = rejTally + 1; } //REJECT

                npw = NetPresentWorth();
                if (npw < 0)
                { rejTally = rejTally + 1; } //REJECT
            }

            return rejTally;
        }
    }
}

Mining Stored Procedures to Develop Business Rules

Paula DiTallo — Fri, 04 Jan 2008 02:56:43 GMT

I am currently working on a manuscript about business rule engines; their purpose in large scale enterprise integration projects; their role in SOA architectures--and their untapped capability in enriching data warehouse-based intelligence delivery.

Today, I am outlining the criteria for comparing two divergent products: TIBCO's iProcess Decisions (part of the BPM product suite) and Microsoft's Business Rule Engine (BRE) (installed with BizTalk Server).

For the nuts and bolts of this first comparison, I will be using the same SQL Server 2005 database instance.

From what I've observed, databases have loosely become de facto rule engines for many large organizations. Frequently the only persistent objects within an enterprise, is a growing network of federated databases--rich with evolving triggers,stored procedures, SQL Agents, etc.. After just a few hours of analyzing the types of stored procedures, triggers, etc.--it becomes obvious that many of the business processing rules are firmly embedded with the treatment/manipulation of the data through updates, inserts, and deletes. Aside from valid data-integrity related reasons for triggers and stored-procedures, one will find a myriad of status value changes, aggregates, date comparisons, etc. In essence, the clear application of business rules for business processes, aptly described by TIBCO as an event cloud.

I like TIBCO's descripton of an "event cloud"--because without the clarity of business rules as applied to specific, repeatable processes in an organization, a cloud is just what it is!

BPM/BRE

Thinking Through Rules in C#

Mining Stored Procedures to Develop Business Rules