This follows the Nearly All CMS Technologies Suck article, but expands to other Rules engines (BRMS - Business Rule Management Systems).

Top line:

An business wants to work on a certain subset of application logic - “rules” - in suitable editing environment, validate and approve them outside of the go-live cycle for the application binary. The business wants to safely promote rules from one environment to another, including to/from an in-use production.

Redhat’s Drools and IBM’s JRules are the big players. Drools has JSON to store rules, and JRules uses IRL (Ilog Rule Language). Both are textual, and great for source-control. .Net has InRule and others that are quite analogous.

ThoughtWorks’ chief scientist Martin Fowler wrote about Rules Engines six years ago.

Rules-Engines features.

• Rules are encoded as carriage-return delimited text, instead of a binary format.
• Technical users want to edit rules in a purpose built application.
• Audit of changes should be important too, both historically, and for “what is pending?” (incl diffs).
• Rules changes could go live (promotion) as a set, or one by one.
• Quite often there is a desire to trial pending changes in production, or a non-live domain that otherwise uses the same version of the application binary as live.
• Rules could be directly edited in production, and promoted back to a UAT or staging environment.

Some of those scream “Source-Control”, others are (editing tool) are unrelated to storage choice. Therefore I’ll say, Rules Engines should store rules in source control and use it idiomatically. In some cases Rules Engines don’t stipulate a storage technology, leaving it open to you to read/write them to somewhere. I’m suggesting source-control as the choice developers should make, even if involves writing and maintaining code to do it. Obviously, without built-in support for source-control, promotion is going to be a manual command-line activity, but there is still a huge safety and correctness benefit to that.

Integration Servers too!

These have a similar set of needs. More than for rules engines, integration servers are used for partner integrations.

I’ve only recent experience with webMethods, and it uses a relational schema as well as large amounts of native filesystem storage, with no VCS integration. There are other commercial tools: Informatica Integration, Starfish ETL, Talend Data Integration, MuleSoft ESB, Kapow Katalyst, IBM’s InfoSphere, TIBCO Active-Matrix, InaPlex Inaport, Information Builder’ iWay Integration Suite.

Clicking through installation requirements shows that the installs mostly require Oracle or SqlSever. Some of those make no statement about RDBMS use at all. Obviously transaction and log data should be stored in a RDBMS, but not the ETL configuration itself. That, as I maintain, should be in source-control and eminently mergeable because you’d definitely want to use branches to manage promotions. If someone wants to contact me with more detailed information for each of the above, then please do so.

Could/should these tools change?

Yes, both for Rules engines, and Integration Servers.

I think there a significant reduction in the total cost of ownership of by source-control as the canonical backing store, and living the idioms of source-control especially branching. If I’m right the tool-makers would be interested in getting there, especially as that saving is for the client company’s usage of the technology, and not necessarily the purchase price of the software. Consulting fees to setup installations and develop integrations or rules could drop, which may dissuade some vendors that have a lot of revenue from those sources from making changes.

Maybe the open source technologies could get there first: MuleSoft’s bits and pieces for integration, and Drools for rules. Drools is close because of its “Guvnor” extension which speaks WebDAV and JCR already, meaning a “how to” is just a small amount of example code away.