Don’t Use Executable Decision Models – Part 2

This is the second in my series on why not to use executable decision models. Part 1 discussed the importance of business user engagement and the challenges posed by executable decision models.

Reason #2: Maintenance

Most tools and methodologies focused on executable models are focused on getting to version 1, not on maintenance. This is, of course, why so many consulting firms like executable models: They are getting paid to give you version 1 so they want to do that as quickly as possible – maintaining the model later, and the cost of maintaining it, will be your problem.

Most executable modeling approaches are optimized for the initial creation of logic and not its ongoing change. Add to this the limited scalability and control offered by most modeling tools – modeling tools are not IT infrastructure and so generally lack DevOps tools and related capabilities – and your ability to maintain these executable models is going to be poor.

This focus also means that teams tend to focus on creation of new artifacts and not reuse of existing ones. Executable modeling tools generally make it much easier to create a new decision than to reuse an existing one. They also generally make it much harder to reuse logic from existing IT infrastructure or packaged solutions, which creates additional problems.

For instance, we have seen teams build executable decision models that take output from a package’s decision and treat it like input data. For instance, a manufacturing cost calculation performed by package because a piece of input data for a sales commission calculation. This breaks the connection between the logic in the package that made the decision and the downstream decisions that use the result. This limits the ability to track the impact of changes to decision-making and creates more silos – separating decision-making that should be linked into separate models.

A better approach is to model the decision-making in the package as a decision that can be properly linked into the model and then map the model to the logic in the package. This reuse is especially important in larger, more complex organizations who often have multiple technologies deployed as well as packages that make decisions.

In my third post I’ll discuss the challenges of integrating analytics and AI into your decision models and conclude with some thoughts on virtual decision hubs.