As a consultant, I have seen customers using many different solutions.  There are only a few products out there on the market that actually allow business users to manage business rules.  Most of the other products that compete with ODM are too IT-centric.  By far, our most successful customers use ODM for managing business logic.

Customers switch to ODM for two primary reasons.  They want their business users to own the business rules and/or they need super-fast performance. 

Keep your rules in Excel format and they will be much easier to use and configure. A rule priority or sequence should be kept in mind: Which rule should be executed first. This should be clear for both the person who is developing the rules and the businesspeople who are going to be using them.

We used a Java-based approach for the customization of business rules earlier. It was time-consuming for development. Later, we switched to ODM as it is robust and scalable.

At the time, we were trying to use an IBM solution for testing, but it wasn't as easy as it could have been. Really, our rule authors, as we call them, we needed them to be able to just get them out on the fly. Set up a project and make it work just like we would our actual application, and then have it run those rules. That's how we needed it to be.

My top criteria for selecting a vendor start with, do people like it? There's got to be some reviews on these vendors, and there has to be some kind of reliability with them. And with the software they're bringing out, how is their testing going with hit? Do you know what their testing methods are? That's one of my favorite things to say. They say, "Oh yeah, we tried this out. Let us show you it working." But I don't want to see it in some perfect scenario. When they say, "Let us let you use it for a bit," I love that. I like getting my hands on things.

No. However, I have used other rules engines.

The decision to purchase ODM was made before I was hired on with my current company.

We have a homegrown solution. We are switching because it is not scalable nor performing as well as we would like it to.