1. Specifying collaborative decision-making systems
using BPMN, CMMN & DMN
Alan Fish
Principal Consultant, Decision Solutions, FICO

2. OMG model standards specify:
Pragmatics
OMG model standards specify:
Notation
Syntax
Semantics
These are the basic features of a language.
But they are not enough. To use a language you need pragmatics.

3. What is your worst fault?
Pragmatics
What is your worst fault?
Getting the syntax & semantics of a question but ignoring the pragmatics.
Could you give me an example?
Yes, I could.

4. Pragmatics
Pragmatics gives context to language:

5. Pragmatics gives context to models:
Business concept: what each element represents
Notation
Syntax
Semantics
Business practice: how the model will be used
For an organization to use models successfully, it needs to adopt a standard set of business concepts and business practices.

6. DRAW provides clear business concepts and practice, but...
Pragmatics
DRAW provides clear business concepts and practice, but...
Focusses on decision services
Cannot describe complex user interactions
Encourages simplistic system design
Extending modelling to multiple domains brings flexibility but uncertainty:
Where to model each item
How to deal with overlaps
How to model interactions between domains
Hence xDRAW: a framework for using multiple models to specify decision-making systems

7. Conceptual framework

8. Functional requirements: four domains
Business Process Management
Process workflows
Stateful, sequential & event-based

9. Functional requirements: four domains
Business Process Management
Process workflows
Stateful, sequential & event-based
User Interface Management
User facilities
Stateful, parallel & user-driven

10. Functional requirements: four domains
Business Process Management
Process workflows
Stateful, sequential & event-based
User Interface Management
User facilities
Stateful, parallel & user-driven
Decision Management
Decision services
Stateless, no side effects

11. Functional requirements: four domains
Business Process Management
Process workflows
Stateful, sequential & event-based
User Interface Management
User facilities
Stateful, parallel & user-driven
Decision Management
Decision services
Stateless, no side effects
Data Management
Persistence
Case data, state

12. Modelling functional requirements
Based on formal models
OMG “triple crown”
BPMN: process models
CMMN: case models
DMN: decision models
UML:
object models
state models
use-case models

13. Modelling functional requirements
BPMN process models
Describe sequences of tasks & events to be managed by the system
Implemented as a set of stateful business processes
Interactions:
call external services (Service task)
call decision services (Business rule task)
run cases synchronously (Case task)
send events to cases (Event throw + Event listener)
read / write data (data annotations)

14. Modelling functional requirements
CMMN case models
Describe functions which users can carry out through the system
Implemented as a set of stateful user interface facilities
Interactions:
interactions with user (Task)
call decision services (Decision task)
run processes synchronously (Process task)
send events to processes (Milestone + Event listener)
read / write data (Case file items)

15. Modelling functional requirements
DMN decision models
Describe decisions to be made by the system
Implemented as a set of stateless decision services
Interactions (rare):
call external services
read data
(external BKM?)

16. Modelling functional requirements
Systems strictly decomposed into three domains
No functional overlap between domains
All interactions between domains are constrained to a few types
Domains and their interactions all defined with formal models in open standards

17. A contrived example

18. CMMN: Submit Application stage
Case
Call decision service
Stage
Milestone event
User function
Stage termination
User data
Stage entry
Decision results

19. DMN: Provide Illustration decision service
Service results
Intermediate results
User data

20. CMMN: Process Application stage
Call process
Stage entry
Stage termination
Detect process event
Case termination
Milestone event

21. BPMN: Process Application business process
Detect user event
Send user event
End state
Call external service
Call decision service

22. DMN: Decide Routing decision service
Decision results
External data
User data
Re-use

23. UML: Application state transition model
Starting state
Transition = event
Intermediate state
End state

24. Using the models

25. Using the models
High-level functional models
Detailed requirements and design

26. Using the models
Business process management
Expand process model into detailed process workflows
Fully specify process tasks and events
Configure workflows and tasks in process engine

27. Using the models
User interface management
Design set of UI components to provide modelled functions
Design navigation between components, restricting access as defined by state model and use case diagram
Configure, package and deploy as UI facilities

28. Using the models
Decision management
Define decision logic for each decision & BKM
Configure decisions and BKMs in decision engine
Package as defined services for consumption by business processes and user interface

29. Using the models
Data management
Define universal object model and map/transform for each domain
Implement state management as modelled
Implement persistence, housekeeping etc

30. Case study: a real current project

31. Business process model

32. Decision model

33. Case model

34. Use case diagram

35. State transition model

36. Implementation tools
Environment: FICO ® Decision Management Suite
Process workflows, user interfaces, data management, integration: FICO® Application Studio (FASt)
Decision services: FICO ® Decision Modeler (Blaze)

37. Experience so far It works. Modelling: Implementation:
The “triple crown” plus UML can specify a complete decision-making system
All project participants appreciate the value of graphical models
Having a fixed framework for the use of the models makes everything easier still
CMMN is easier to understand as functions than as tasks
Implementation:
Strict decoupling of functionality allows teams to work in parallel
Implementation flows naturally from the modelled elements in all three domains
UI implementation involves mapping functions to components
Approach adopted by FICO as xDRAW

38. Thank You!
Dr Alan N Fish
(mob), (desk)