A couple of weeks ago I got an update from the folks at InRule. InRule was founded in 2002 in Chicago and has 100+ customers. Their focus, like most business rules vendors, is on dynamic decisioning and process agility. They estimate that nearly half their prospective customers are also doing BPM not just rules. InRule is exclusively focused on .NET . While its customers initially cane from financial services and Insurance, their customers now span most industries. They are, as you would expect, an active Microsoft partner and a member of the Microsoft Business Process Alliance (one of several rules vendors).
InRule has three products – the flagship one, InRule for BizTalk Server and InRule for Workflow Foundation. In each case they provide authoring, catalog (repository), SDK, and execution server components. Neither of the rules engines Microsoft has embedded in Biztalk and Workflow Foundation are designed for business users to maintain rules. Adding this capability and extending the base Microsoft platform are where InRule adds value.
Their value proposition is a pretty standard business rules one, focused on quick time to value and the right tools for different users. Microsoft tends to be very focused on developers but InRule adds a focus on business users/analysts and process owners. They have made their product easily embeddable and have garnered lots of ISV interest. They also have some multi-platform customers who have bought another vendor’s Java offering but have chosen InRule over the established vendor’s .Net product.
InRule is focused on decision points in business processes and on delivering dynamic decisioning at this point. For instance, in a Basel II process a company initially had scorecards in Excel, this was replaced by a web application but the business users liked the control they had with Excel and IT’s web application was too hard to change – they rapidly got a backlog – so they adopted rules. Other companies are moving to SOA and have multiple systems with redundant logic and use a decision service to get the shared logic.
The flagship product has a catalog similar to SourceSafe/TeamServer, authoring and verification, an SDK and potential customer authoring. Rules can be stored in the catalog and pushed to the run time engine. Decision tables, constrained rule editing, value lists and easy to build custom applications are supported. The catalog has versioning, check-in/check-out, permissions, promotion, labeling etc
InRule for BizTalk Server is built on the flagship product (includes all its capabilities) and includes a BizTalk adaptor and has static classes added to Biztalk to call the InRule engine. Biztalk’s rule engine has rete-based inferencing and a repository but lacks IF THEN ELSE logic, which makes authoring and maintaining complex logic very difficult, as nested IF statements must be used. The BizTalk rule engine has a very weak user interface for rule editing (Rules Composer).
InRule for WindowsWorkflow Foundation uses the WF rule engine, adding authoring and management capabilities; the product uses their own editing controls and runs as win components. The rule engine in the Workflow Foundation is ruleset-based, compiled into code and handles sequential and some forward chaining. InRule provides verification tools and irDeveloper – a very thin version of their SDK as the Workflow Foundation rue engine only runs against object graphs- no database or XSD support. The catalog is the same as the main InRule product. InRule extends the Workflow Foundation rule engine to handle notifications, complex functions etc – typically those at the Excel/VBA intersection. There is no support for patterns or the XML/SQL stuff from the main engine. It should be noted that all InRule products can be called from WF workflows (or any BPM tool).
Comments on this entry are closed.
I’ve looked at InRule in the past and some of the things they say are blantantly wrong and misguided. For example, from their “rete or not” article, they make the following statement.
“Rete is not always adept at handling complex or procedural logic, such as looping or nested if statements.”
Rete rule engines are perfectly capable of handling looping and nested statements. They’re right, when they say RETE has a steep learning curve. Their comparison of RETE to their own inference engine is disingenuous. The main reason for using RETE is writing rules in a declarative manner.
I would argue the rule engine doesn’t really matter from an authoring perspective. As long as the authoring tools make it easy for the end user, the underlying engine could be anything assuming the number of rules does not require high performance and scalability to thousands of rules.
The statistics quoted by InRule do not represent the spectrum of business rules. From my own experience, many situations call for a powerful rule engine.
When it comes to the world of BRE’s, people spend way too much time worrying about pattern matching algorithms; AKA RETE, etc. At the end of the day, only three things really matter when buying a Business Rules System: 1. Easy-to-use, 2. Reliable, and 3. Fast. InRule is all three of these and more; the technology is great and so are the people. If you’re considering a BRE for .NET, you’ll want to look at them.