What is our primary use case?
This was primarily to enable rules. I used it before, when I worked with Walmart, so not with my current employer, but the previous company that I worked for, Walmart Humana. The classic use case for Walmart was during Thanksgiving. Thanksgiving is a time when Walmart has huge sales and, at the same time, the most returns the next day. The rules should be competent enough so that business can apply those rules runtime, dynamically, without much involvement from IT. So IT just creates rules to apply discounts, initial discounts, and business has the ability to apply those discounts, change those discounts, dynamically. So that's one of the use cases.
The second use case that we did at Walmart was returns. So, you buy some stuff during Thanksgiving in one store, then you go to the next state and return it in the next state. So the tax rules change a lot. All those rules have been built in ODM. That was a classic example that we did in ODM. That's my first experience working with ODM as well.
The second one was with Humana. Humana is premium Medicare claims processing. There, we implemented ODM on mainframes, AS400. That's the first time I did work on AS400 and implemented ODM on them. There is a huge claims adjudication process that goes on within Humana. Most of the claims processing rules were done in ODM.
How has it helped my organization?
Hard coding was always a problem, because developers come and go, the teams come and go, the maintenance is always a challenge. You had to document those rules somewhere. If you work as a part of a specific solution, you have to document and maintain those changes every time you do.
But with ODM as a centralized rules engine, it's easy to track. You can version the rules in the ODM engine itself. It's always better to decentralize the rules. If your organization doesn't have an option to go with ODM, I would still do modular coding, keep those rules separate, and then plug them into a future ODM implementation, or any other rules engine.
In terms of the effects of allowing business users to update business rules instead of IT, the name indicates business rules are "business rules." So business should own those rules. IT should should simply enable deploying the initial set of rules, and then let business maintain those rules, unless the core datasets change. That would involve IT in the business rules. But once we set the platform for the basic rules, the business should be able to apply their changes periodically.
IBM ODM has definitely reduced the backlog for IT in our case.
In terms of the solution influencing time spent on compliance and reporting, the work I did was mostly internal, we were not reaching out to any external. All the rules, the state tax calculations, they're all internal. So I didn't have an issue with regulations and compliance issues with ODM as such.
We've used Decision Server Insights within IBM ODM, and it's context-based. Every rule has its own business use case, so you know what context it really comes from. When you build a rule, you should know it's lifecycle, how you harvest the rules. You have business requirements, you come up with the rule harvest backlog, so you know each context. That is your driver to start building the context for each of those rules.
What is most valuable?
It's easy to build, easy to adopt for the business. Business can change those rules. I think IBM has done a good job in re-architecting the product with Decision Center as its centralized view, where the business can make changes to the rules dynamically. That's what I like most.
What needs improvement?
The initial set of features that I'd like to see are, for an IT guy like me to start building a rule, we end up using a lot of IT tools. But I think there should be more involvement by business. Business should be able to create those rules from scratch. I think Blueworks does it great. I think there should be a facility for business to really create rules from scratch. The only part for IT should be to make sure the platform is stable, the technology platform, but everything else, the business should be able to create those rules.
It is business-user friendly, but it still needs to be from scratch, from ODM.
What do I think about the stability of the solution?
The stability is good, because it's built based out of IBM WAS, WebSphere Application Server, which is a solid J2 platform that IBM has had forever. The platform is good. Its footprint is a little heavy. Other than that, the product works great.
What do I think about the scalability of the solution?
It's scalable. More and more geographic regions were added to the requirements for what we did for Walmart.
We expanded both horizontally and vertically. So we can add more clusters onto the WAS, and you can still scale it up.
How is customer service and technical support?
I have not been in touch with technical support in recent times. But I used to work with IBM vendors all along, throughout my career. Honest opinion, I think in the last few years, five or six years, I've seen a little bit of lag in the support. It's not as good as what we used to get in the past. I think IBM should improve in that area.
What other advice do I have?
With my current organization, because we have so many repeatable processes, repeatable requirements, I strongly feel we need to have a centralized ODM solution. We have had discussions with my leads and my higher-ups. ODM is in line, it is first in line. Obviously this is my preferred ODM solution. And I would recommend it to my colleagues as well, definitely.