Data is one of the most precious resources nowadays. Processes and decisions turning data into value are defining the success of an enterprise. The importance of business process management is widely recognised, whereas decisions are rather seen as part of a process and not as a concern on their own. Hence, they are often buried in applications, code, processes or even in the heads of people, although they are driving performance and are subject to regulatory requirements. This results in unmaintainable and inconsistent decisions imposing unknown risks to enterprises. As a cure for unmanageable decisions the discipline of decision management emerged promising transparency, productivity, accuracy, agility, and consistency of decisions.
DMN - Decision Management and Notation
To fulfil the need of a more consistent decision management the standard Decision Management and Notation (DMN) was introduced in 2015 by the Object Management Group. The decision modelling enables the separation of process logic from decision logic. Instead of using complex structures with many gateways a decision is displayed concisely in a Decision Requirement Diagram (DRD) and decision tables. Thereby, DMN is complementary to BPMN as decision models can be invoked by business rule tasks of process models.
The standard has been adopted by several software vendors for business process management (for instance Signavio and Camunda). DMN is very appealing in this regard since the created models are ready for execution.
Appian’s Decision Management Capabilities
Appian provides a leading platform for low-code, business process management and case management. With the introduction of decision tables in the 17.2 release a step in the direction of decision management was taken. Therefore, it is worthwhile to have a look at the overall capabilities of Appian regarding decision management.
Appian’s DMN-based decision tables are offering the following features:
- Rules are displayed as rows.
- The following three (the DMN standard comes with seven) hit policies can be used defining the decision logic:
- Unique: Only one rule of the decision table can match. The rules must be distinct.
- First: The output of the first rule that matches is returned.
- Rule Order: The output of all matching rules is returned.
- Inputs of a decision must be of a simple type. Inputs can be of the type Boolean, Number (Decimal, Integer) or Text. Furthermore, enumerations of these types can be specified by creating lists or using expressions. Input entry cells cannot be merged.
- Besides simple types also documents, process models, users and groups are available as output and multiple outputs are possible.
- The friendly enough expression language (FEEL) is substituted by Appian’s expression language SAIL.
Appian does not offer the creation of DRDs. Thus, complex decision logic combining several decision tables must be implemented by using expression rules. Also, processes could be used, but this would contradict the notion of a separation between business logic and processes and should therefore be avoided.
As DMN is only a notation and does not cover all relevant aspects of decision management, it is important to have a look at the decision management capabilities of Appian:
- Integration: Appian is built as a platform to unify data and enable processes to work with them. Obviously, the same is true for decisions as they can be made accessible to other systems as a service and vice versa other services can be integrated with Appian. Furthermore, Appian comes with out the box support for Amazon AWS Machine Learning enabling the creation of complex decision logic by leveraging machine learning capabilities.
- Reusability and consistency: All objects (a decision is just another object in Appian) can be reused across all applications. Decision objects can be used and reused in all kinds of aspects including the creation of dynamic process flows, forms or assignments of users or groups.
- Transparency: Dependents of a decision e.g. processes and other expression rules can be viewed. Clearly, this is not as transparent as a decision requirement diagram. All objects in Appian are versioned.
- Agility and adaptability: Changes can be made to decision tables without having a dedicated developer: subject matter experts and business analysts can work on defining the decision logic by using decision tables. As access rights are defined for every object, it is ensured that only relevant objects are accessible to the corresponding person. However, decision tables (as all objects in Appian) can only be edited by one person at the time.
- Accuracy: During the creation of decision tables the soundness is checked. Invalid values, overlapping rules and incomplete value ranges are highlighted during the creation
Appian is not supporting the DMN standard as it stands, but by leveraging the power of its transformation suite and the adaption of DMN-based decision tables many requirements of decision management are met. Overall, as with business process management, Appian is rather on the execution site than on the management site. Since business process modelling using BPMN is not done in Appian, also DMN should be modelled using a dedicated tool and then brought into action in Appian.