What is our primary use case?
Objective: The primary use case is being able to expose business logic to
non-technical users. This logic is traditionally hidden within code. ODM
exposes the logic out to the business users for them to be able to
manage it over time without IT involvement.
Before ODM, all the rules were configured on legacy
systems we're transforming all this into a new set of technologies such
as REST microservices, cassandra and with IBM ODM so that Business Users will be able to easily change the rules.
Deployment is done on the client-side only. Business User can update rules through UI
I have used it for few projects in which number of business logic rules varied from the 70 to about 1,800 rules.
How has it helped my organization?
There is an increase in productivity, agility and responsiveness because after it is configured once in the environment, Business User can deploy the rules and configuring the rules and making the changes by themselves. Deployment failures have happened very few times. (So far, twice only). Only then do we get a call: "We are experiencing issues." So productivity, being on the developer side has improved because once I have configured the rules, I don't have to worry about them. I have time to work on other things. The Business User is able to keep changing the rules and it is very easy for them. The client is very happy.The
result is a step toward creating a more modern infrastructure, to evolving business
Apart from the cost savings, efficiency has also increased. I never thought we would be able to develop that amount of change, it is now near real-time; being from the It used to be a very time-consuming process.
Now, As soon as Business User deploys a rule, well... it gets deployed.
There's more, they can even use an Excel sheet for input for updating the rules.
What is most valuable?
The most valuable feature is the deployment part because it is very easy to deploy.
After being developed and configured once on server, even any one from a non-technical background can easily deploy it and the rules will work.
The testing part for the rules is also very easy to use.
Doesn't matter if you coding experience or not it is very user-friendly.
What needs improvement?
Configuring it on the Tomcat site and on the client's cloud environment, we faced a lot of issues. After configuring it on the Tomcat side, getting it on the Unix server was an issue.
There are two issues that I am facing right now. The first is that the errors I get from time to time are not easy to debug or easy to understand. They are very vague because if a XOM file is missing or there is a deserialization problem, on the client's side I only get a 500 Internal Server Error. To learn where the problem is, I have to go on the Rule Execution Server and test it myself. The deserialization issue is very vague. The error messages should be more straightforward and easy to understand.
I would also like to see the installation part on a single disk only, instead of on three disks. In our local environment we are installing it on Windows, and for the client side we are installing it on a Linux server. For a new user or a new developer or a fresher, it was tricky to understand which disk should be installed first, even if they're labeled Disk 1, Disk 2, Disk 3. Configuration is kind of tricky for a new person. Right now we have to use Installation Manager. It should be like installing any other software.
Finally, it should also start supporting the NoSQL DB. Currently, It does not support NoSQL. I don't know if the newer version supports it, but as far as I know it doesn't. It would make the job easier. Right now the client had to buy a MySQL license, so they are maintaining a separate database for ODM. It should be kept on a single system. NoSQL DBs are better and it can be done.
For how long have I used the solution?
We've been using it over two years.
What do I think about the stability of the solution?
In terms of stability, from time to time I get runtime errors for the deserialization issue for the XOM file. I get an error on the Rule Execution Server saying, "This XOM class cannot be deserialized. Please check if it is configured properly." I have to redeploy that part from my Rule Designer. That has happened twice over the course of the project. I think someone might have changed the XOM. Otherwise, it shouldn't have occurred. On the IBM site there is not too much written about the error.
UPDATE: Changed in configurations : Issue was later resolved. Stability is great.
What do I think about the scalability of the solution?
We have complete control over how the system is configured, managed, and run.We are using about eight server systems. In terms of scalability, it's more like a plug-and-play. We can just keep on adding however many servers we would like to add.
How are customer service and technical support?
There was a dedicated IBM guy and we contacted him about the XOM issue but we have yet to get a substantive response. He said that it is not in his domain to fix that error. He is from the installation part only. This issue was later resolved.
Which solution did I use previously and why did I switch?
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.
How was the initial setup?
While ODM is an excellent business rules engine that solves a wide variety of business needs, the installation,configuration and deployment configuratiosn can be more complex than it appears on the surface. And if your business rules are incorrectly configured, you can put yourself at a major disadvantage.
I think this process can be improved.
Which other solutions did I evaluate?
Which deployment model are you using for this solution?
Which version of this solution are you currently using?