Modeling Business Logic i.e. Business Processes, Rules, Decisions, Data, Workflow…

In running a business, there are many types of logic that need to be modelled and executed. These models are the assets of your organization. Modeling business logic is the art of building executable models that can express business behaviour visually. After all, a picture is worth a thousand words! Especially when these models are executable, your documentation and implementation will live together. The models become the live specification of your business and systems.

Let's now discuss different types of models you can utilise in modeling business logic.

Decision Table

This is the most popular way to model business rules.

In this model, business rules are modeled in rows of one or more tables in which the conditions of rules are organised in columns. A decision table is a standard (DMN – Decision Model and Notation) way of modeling business rule and decision. Many people (Business analysts and domain experts) are familiar with this form of modeling and notation. As this is in a tabular form, you can use Excel to build this type of decision table and then import or use (execute) it in the system. One of the benefits of this model is you can use Spreadsheets (e.g. Excel, google docs, etc.) to model your rules, and then you can either import it to the system or use it (i.e. execute it) as it is, although importing it to our advanced designer has many benefits. When using a decision table, there are some advanced capabilities that you can take advantage of, such as: web editor, conflict and overlap detection and aggregation functions.

Tree and Sub-Tree

This model is very popular with system and application developers. It allows them to model logic (usually business rules) in a nested, hierarchical tree form.

In this form, business rules (or other logic) are constructed in a tree hierarchy, and sub-trees can present different business rules. Sometimes you will find that the tree model is more compact than modeling a set of rules in a decision table with many empty columns. When your rules do not share many conditions and they expand, the Decision Table may get very big horizontally and vertically. Then you might think of a tree form instead. The other benefit of the tree form is that it makes rule reuse (within and across rule models) very simple.

Business friendly Natural Language

When you speak in the context of your business domain, you use the domain terminologies and language to communicate to stakeholders. Then why not write business rules in the same manner using the established terminologies in your domain?

This model allows you to define business rules and logic in a textual format, which is much clearer for communication and therefore makes it a lot easier to understand the intent of the logic. In Natural Language DSL, business rules are less ‘noisy’ (in comparison with XML) and are constructed using your business terminologies. And on top of that our advanced editor also helps you to write it more easily with a point and click technique. It is just a case of choosing the right term, expression or value from a suggested list.

Developer friendly Natural Language

The good thing about Natural Language is that it is natural for everyone! Sometimes it is easier for developers to model complex logic in code-style modeling.

And you can perform mix and match, partially use this style and also partially use other business friendly styles.

Natural Language can be used as a scripting language for developers.

Flow style

When there are multiple decisions (e.g. Decision Table, Tree, NL, etc.), tasks, and actions involved in a scenario, this model allows you to orchestrate the sequence in which each step is executed.

In this form, nodes are connected to each other based on the required, predefined sequence of execution. In a flow, you can reuse all the other models: Decision Requirement Diagram (DRD), Decision Tables, Trees and Natural Language rules, documents, and so on. If you have many logic documents involved in a scenario with complex dependencies, then using a Decision Requirement Diagram might make your life easier.

Decision Requirement Diagram (DRD)

The Decision Requirement Diagram is part of the DMN (Decision Model and Notation) standard.

In the Decision Requirement Diagram (DRD) model, multiple sets of business logic (decision table, tree, NL…) are connected to each other based on their dependencies. In this model, you can use all relevant models, including Decision Table, Tree and Natural Language (NL). You can think of a DRD as a dependency graph between multiple decisions (Decision Table, Tree or NL). It significantly simplifies your understanding of the scenario that the rules are deriving.

Information Requirement Diagram (IRD)

When modeling business logic, decisions and rules are not the only type of logic. There is data logic as well. More often than not, in the whole business process/scenario, data needs to be prepared from multiple sources at some stage, and then passed on to the decisions/rules model for processing. The model that can prepare your data/information is called an Information Requirement Diagram, or IRD.

You can define multiple data sources and pass that through the IRD. In each node, a specific monadic operation will be applied and the end result will be one or more data/information outputs for your business process/scenario, decisions and rules.

Workflow

In a business process, when there are multiple human participants that are required to take specific actions in order to move the process to the next step, the Workflow can model and execute these scenarios.

In modeling business logic, a workflow defines when a task requires an action by an actor (usually human) and you can orchestrate everything around that. Workflow may take a long time to complete and between starting and finishing may assume different states. The workflow manages all complex timing scenarios (i.e. expiration, timeout, etc.).

Fact Concept

Fact Concept is a conceptual model that allows you to define the things that are important for your business.

The Fact Concept shapes the abstraction model of the problem domain and allows you to define the relationship and constraints. Once the Fact Concept is defined, validation and reuse of the model structures become significantly effortless.

Execution and Testing

You can execute, debug and test all of these models, and also you can host it as a service using a centralised business logic server.

Conclusion

Modeling business logic using visualization techniques and tools enables better communication. In the past, modeling business logic visually was really just a way of analyzing and understating the domain problem, and as the system grew and matured, these models became outdated. No one updated them as this was an expensive exercise. The good news is that now you don't need to maintain the models and implementation separately, as these are the same.

You can also validate the models in order to automatically find any issues related to execution. Each model has its own validation logic that checks the details of the model. Business rules (i.e. decision table) validation reveals rule conflicts and overlaps as well. In Flow, the correctness of links and sequencing are validated along with many other details. Validation allows you to ensure that the model is correct in design time.

Once these are validated, they become a single source of truth. Deploy these models as a REST API using FlexRule Server and every application or business process in the organization can communicate with them for managing day-to-day operations.

Last updated July 13th, 2020 at 11:25 am, Published May 18th, 2015 at 11:25 am

Arash Aghlara

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.