jw's picture

Reading the latest newsletters and factsheets about business rules management systems (BRMS), I'm struck by the strong emphasis on the ability to model rules in teams. For experienced ARIS users, of course, that isn't exactly new... Right from the start, the ability to have a team designing processes was a key requirement for us. In fact, a database supporting joint modeling and the corresponding access rights was a feature of the very first version of ARIS. I dug around in our archive and made a screenshot of ARIS 2.0 (I only found a German version, unfortunately), which shows that there was a database with access rights as far back as 1993: 

ARIS Toolset

So why is a multi-user environment specifically for rule modeling such hot news? The explanation could lie in the fact that the two ''world'' have different origins. ARIS was intended from the outset as a process modeling tool for non-technical users, while software for rule definition and execution tends to be more IT-oriented. I've been involved in development long enough to remember how things were and I still see the same approach among my colleagues every day. A development environment is essentially about providing support for writing ''correc'' code. That includes functionalities like automatically completing method calls, identifying syntax errors, and providing good debugging options for testing program code on examples. The actual outcome of the programming process is still stored in a file today. It's tested locally and only when everything is functioning properly is it ''checked in'' to a separate version management system, where it can then be accessed by the entire development team. This makes the development process very time-consuming and the recent integration of multi-user support into some products is clearly a major step forward in terms of getting the work done efficiently.

In contrast, team modeling in a multi-user environment with a central repository and access rights is already the norm for ARIS process modelers, although the options for checking the accuracy of models are generally restricted to the familiar reporting functionality. Now, however, users can ''run'' such a process model with sample data at the push of a button—something that was previously only possible in ARIS to a limited extent. ARIS Business Rules Designer combines the best of both worlds, from both a business and a functional viewpoint:

  • Multi-user repository with dedicated user rights for team-based rule modeling
  • Versioning of business rule models and their vocabularies
  • Use of examples to test and debug the rule models created

I have to admit that, as a product manager, I get a kick out of impressing ARIS experts with the sophisticated debugging functionality! Over the past year, some of the major BPM providers have acquired BRMS vendors (IBM – ILOG, SAP – YASU, Oracle – Haley), confirming IDS Scheer's vision that processes and business rules belong together. What's more, the recent evolution of business rules management systems shows that the integrated ARIS Business Rules Designer tool not only combines the best of both worlds from a business perspective, it also brings together functional support features that were previously specific to each of those worlds. That’s what I think, anyway. Whether you agree with me or have a completely different viewpoint, I'd love to hear from you!