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).