I got a chance to catch up with the folks from InRule Technology® recently to discuss the new release of their business rules management system– InRule® v4 (I previously blogged about the product and the InRule 3.2 upgrade). The focus of this release is the authoring interface. Based on a lot of customer feedback, InRule Technology wanted to achieve several things with this release:
- They wanted to make it easier for business and technical users to collaborate on a set of rules
- They wanted make it easier to customize the authoring environment with domain-specific or customer-specific extensions
- They wanted to update the look and feel
- They wanted to simplify rule execution debugging for developers and non-technical users
- And they wanted to improve the navigation around very large rule-bases as their customers develop more sophisticated systems.
The new version is designed to really focus on and enhance a collaborative approach so that users and developers can work on the rules together. This ability of a business rules management system to bring business users and developers together is by far the most valuable aspect of a business rules approach as I have said before. With InRule 4 users can easily configure their environment while developers can extend it as necessary to support specific users’ needs. irAuthor, the InRule authoring environment, has been updated to the Microsoft Office 2010 look and feel– ribbon bar, nice start screen etc. Outlook-like navigation is shown on the left with the ability to focus on different tasks. This helps keep the environment simpler as well while still displaying focused tree views of the catalog. As panes, such as a decision table, are opened the ribbon changes to focus on the specific task being performed.
Developers can easily customize the environment, for example allowing different kinds of users to see a different and appropriate subset of the environment – role-based definitions of what is visible and accessible are now supported. A more user-centric navigation approach is available also with a bookmark capability for users to track their current or regular work items as well as automatic tracking of those items a user edits the most and access to saved searches. The search itself is also more powerful, searching through metadata, expressions, categories, notes or even data. Each search can select the different kinds of data being searched across (allowing a search across just metadata or across notes and expressions for example) and searches can be saved and managed. The upshot of all this is a flexible, navigable, role-based authoring environment with a strong Office-like look and feel.
One of the challenges in any piece of software with a broad array of users is that different users request different features while large customers tend to want very specific features added. Making the environment extensible helps ensure everyone can customize their own environment their own way. The new product has an add-in capability to let customers extend the behavior and user interface of the authoring environment. For instance, while InRule has long allowed customers to extend the metadata stored about a rule, the new extensibility approach allows customers to both add a custom form and define the rules for when different kinds of metadata should be recorded. One could imagine a check that said that any rule that changed certain attributes must have a piece of metadata to link it to an appropriate security policy or similar. One common example is where customers must merge rules with their own product or other data and link them together. Ideally this should be done inside the rule environment rather than external to it, and the new feature would allow the metadata to be defined and then managed using a custom UI.
The extensibility features allow new ribbons, new tabs, new buttons to be added as well as code/rules to be written – one example is a spell checker developed using the extensibility interface. These plugins are written in VisualStudio .Net using the authoring framework as a reference library, very analogous to the way Excel or Word add-ins are developed. InRule itself can be used to develop rules-based plugins to, for instance, check rules for policy violations, check rule metadata for completeness etc. Custom saves (to the cloud say) are another example. These extensions can be shared through InRule’s User Community forum. This ability to make the rule environment a tightly coupled part of a broader environment is a very powerful one.
Not all rules, of course, are maintained using irAuthor and many are edited in web-based rule management applications. With InRule v4 all of the controls visible within the irAuthor environment are also available as Silverlight controls (and through Windows Presentation Foundation) for embedding in custom Silverlight applications. In addition the irAuthor extensions could be architected to keep the core logic of the extension separate and accessible from Silverlight applications as well as from irAuthor. Similarly a Silverlight UI could be developed (for metadata say) and then embedded as an irAuthor plugin.
Many customers will use irAuthor’s out of the box configurability to reduce/focus the UI for analysts and let developers use the full (extended) irAuthor environment. Role-based restrictions for analysts and rule authors will make it easier to use irAuthor while Silverlight-based applications, as a Silverlight webpart in SharePoint, will extend the customized environment to end users. This ability to ensure that these customer-specific UIs and checks are available both in the main editing environment as in Silverlight is well thought out and immensely powerful.
Although this usability was the main focus of v4, traceability and debugging in irVerify has been updated also to take more advantage of the logging engine that has been in the product for a while. irVerify sill brings up a quick interface to allow test data to be typed in (showing the data structure for a rule project with those fields that are calculated grayed out) and the rules executed. This has always been logged and displayed but the mapping of this log to the design environment was complex with larger projects. The new version has the trace results displayed in the authoring environment and as the log is clicked the related design elements are shown– the rule that fired, the decision table that was entered etc. The details of a log item can be viewed also, so that a function or expression for example could be investigated to see the data elements brought in, their values and how the expression was evaluated to get the result. This allows a test transaction to be walked through at a very granular level of detail for testing, QA and debugging problems.
An identical trace can be stored for live transactions too (using an API in the production environment) and the resulting trace can be brought back into irAuthor – the rule trace file can be imported and viewed. And this brings its own version of the rules that were executing at that point in time. This data is also accessible for ongoing statistical analysis so you could, for instance, analyze the history of your decision making to see what you did, and why, when a particular item had a particular value. Although not as unique as the work on the rules editing environment, this too has been nicely implemented.
