I have, in the past, worked on a few software products that were years ahead of their time. As it turns out, being years ahead of your time in the world of Information Technology is not necessarily a good thing. You wind of spending a lot of your time convincing prospective customers that they have a need for software like yours, rather than simply convincing them that your software represents the best choice in an already-established market segment.

Therefore I am sure that when I asked, "Why on Earth would anyone need a system just for business rules," it was neither the first nor would it be the last time that the folks at InRule have had to field this question. Indeed, upon visiting the InRule Web site at www.inrule.com, one of the first things that will catch your eye is a quote from the analyst group Gartner validating the importance of the emerging Business Rules Engine industry and placing InRule, in particular, as Visionary in their 2005 Magic Quadrant.

So, let me begin by giving you the same explanation of Business Rules Engines that InRule gave to me. My contention had been that I could code whatever business rules my applications need in their Business Logic objects. As it turns out, this is true, and there isn't necessarily anything wrong with this traditional approach.

Consider the case, however, where the business rules for a system are frequently changing. From my personal experience, I recall the many hours of development I spent at my first job out of college, changing and re-changing my code as the business folks at my company changed and re-changed their minds about our billing practices.

A couple of years into my employment at this company, we switched to a system that allowed the business folks to directly tinker with the business rules supporting billing calculations via a user-friendly graphical interface. This more or less approximated the functionality and value proposition offered by Business Rules Engines like InRule's flagship offering. Encode your rules to operate in InRule's engine and you may just never have to re-encode those rules again - pretty sweet! Figure 1 shows the architecture that makes this possible.

As it turns out, almost all of InRule's competitors are either Java-based or are simple transliterations (I wouldn't even call them translations) of products that are originally built and still maintained primarily on the J2EE platform. The reason InRule's origins in and sole support for .NET benefits you as a developer is that .NET-specific enhancements are available to you in InRule that aren't available in their competitors.

One example of this is the fact that events that occur in InRule are exposed to your consuming code using native .NET Events. Another example would be that groups of objects are grouped as native .NET collections in InRule. Yet is that data passed back and forth in the Engine are passed using native .NET Datasets. For InRule's competitors, all of these concepts are lost among generic objects, thereby losing all of the advantages of the .NET platform!

I had my first rules-based application up and running a little less than an hour after I installed InRule's products. I found their user interface to be extremely intuitive and I was never stuck for more than a few minutes at any point during my initial coding. If you have business rules that you want to allow business (read "nontechnical") users to maintain themselves without having to tie up developers with writing yet more maintenance code, then you really owe it to yourself to check out InRule!

Company Information
InRule Technology
224 N. des Plaines
Suite 603
Chicago, Illinois 60661
Phone: (312) 648-8000
Fax: (312) 873-3851
Sales: info@inrule.com