The myth is that adopting Decision Management Suite (DMS) and Business Rules Management System (BRMS) will make non-technical teams less reliant on software development and IT teams. But you have to consider the challenges they have with data connectivity and data integration.
Here is an example I found of how to connect Drools to a database. Other DMS and BRMS solutions, like IBM Operational Decision Manager (ODM), are not very different. Essentially, you have two options:
- Writing code in a programming language they support and do the data integration in code.
- Use other products for an orchestration purpose and then integrate the rules into the orchestration.
This approach either for data integration or orchestration integration requires coding and technical skills. As the project grows, you will need more data inputs, different queries, integrations with different database, files, systems, and so on. It is not going to be a one-off integration that sets you up for good.
This does not mean that coding to integrate data is a bad approach necessary, but it means you that cannot eliminate the need for software development efforts for a simple data connectivity requirement. Also, it is very hard (almost impossible) to predict all possible required data, systems, processes, and so on up front. So, you will always be relying on technical software development skills for data integration.
External Orchestration Layer
The other option is to use an orchestration platform to provide data to your rules for decision execution. In turn, you either must:
- Code the integration for the orchestration platform to integrate rules execution; OR
- Accrue the cost of licensing, training, deployment, etc… requirements for the orchestration platform to cover this gap.
Often, you need both: new platform costs and coding resources for the integration work to make them work together.
Additionally, once that is completed and delivered, the solution is sub-optimal because the platform you have adopted for orchestration to integrate data connectivity was not built specifically for this need. This means less performance, harder scalability, overtime maintenance of integration points, training, deployment constraints, and less effective communication and interoperability between rules execution and the orchestration platform. On top of these, it increases technical debt as IT needs to manage two (or more) solutions for one job/requirement, and a poor user experience of jumping between multiple products to get the job done.
Book a Custom Demo
Why is this happening?
The problem is many solutions out there just disregard the mechanics of a decision. This does not mean the problem goes away, it means it has just become a problem for the customer outside of the vendor's responsibility.
The full decision cycle is based on OODA loop’s four stages: Observe, Orient, Decide, and Act. Most BRMS and DMS vendors only focus on the “Decide” stage, which is about modeling and executing the decisions.
The job to be done is to ensure non-technical teams (operation, domain experts, business, etc…) use DMS or BRMS to take care of the business rules is for:
- Increasing business agility and responsiveness of organization to change
- Becoming less reliant on software development and IT, and to free up more time of highly skilled professionals for more strategic priorities
- Improving time-to-market by responding quicker to changes driven by data, laws, and regulations in a changing environment.
Then, it is critically important to address other stages of the decision cycle (Observe, Orient and Act) inside the decision platform explicitly, and not by external 3rd party integrations or coding approaches for the reason explained above.
Code-driven integration for data connectivity and processing, or using 3rd party integration for orchestration, is a sub-optimal solution for automating business decisions. It contradicts the idea of enabling non-technical teams (e.g., domain experts, operation etc.) to become self-sufficient to develop, modify, and deploy business rules because:
- It requires software development and IT for the integration of data in the decisioning process or, integrating the decision in the orchestration layer.
- The requirements of the data and orchestration changes based on rules, and decisions so cannot be built up as one-off software development projects that rely heavily on IT involvement.
- It will accrue costs for licensing, deployment, and training – all for a very sub-optimal solution.
The myth is busted if you are able to address this across all stages the decision cycle using an End-to-End Decision Management Suite with the availability of various data sources and multiple options to deal with data in a decision graph.
Last updated September 19th, 2023 at 09:12 pm, Published September 18th, 2023 at 09:12 pm
CEO and the founder of FlexRule – He is an expert in architecture, design, and implementation of operational decisions, business rules, and process automation. Created Decision-Centric Approach, a methodology that brings People, Data, Rules, and Processes together to automate operational business decisions.
This approach is recognized by Gartner as the missing link to provide business value to organizations.