Decision Modeling & Notation. Jan Vanthienen KU Leuven

Transcription

1 Decision Modeling & Notation Jan Vanthienen KU Leuven

2 Processes contain decisions When to accept/refuse a claim? Depends on: Customer history Format requirements Timing constraints Type of contract (c) Jan Vanthienen Decision Modeling & Notation 2

3 Modeling the decision Rules should be organised and stored separately from processes/systems (The Business Rules Manifesto) Rules change more often than processes, or at least at different points in time Decisions (WHAT) can be modeled separately from processes (HOW) Decisions can be invoked from decision services (SOA) Decision Modeling & Notation (DMN) (c) Jan Vanthienen Decision Modeling & Notation 3

4 New BPMN 2.0 Activity Types applicant type rules High risk process high risk applicant determine applicant ty pe medium risk process mediumrisk applicant (c) Jan Vanthienen Decision Modeling & Notation low risk process low risk 4

5 DMN Motivation 1. Decisions are important for Business 2. Modeling decisions using BPMN is not ideal (i.e. hardcoding) 3. Decisions/rules are not only in (automated) processes, also in vocabulary, and manual processes 4. Relationships between Decisions, Business Rules, Rule Sets are often obscured 5. Distinction between Business Rule Management Systems (BRMS), Notation Methods, Modeling tools, Rule engines (BREs) 6. Tabular methods are increasingly being used in BRMS, BREs + impact on OMG Case Management, BMM, BPMN2.X (c) Jan Vanthienen Decision Modeling & Notation 5

6 DMN Objectives 1. Standardise at least one decision model type for business users, independent of IT implementation, e.g. Decision tables 2. Support BPMN 2.0 Business Rule Task in a standardised, supportable way, as well as other types of process e.g. CEP-based declarative processes requiring decisions 3. Provide graphical business decision notations for MDA PIMs 4. Bridge standards such as SBVR and PRR, to help complete the analysis automation / verification gap "This RFP solicits proposals for a Decision Model standard comprising of a graphical notation, metamodel and associated MOF artifacts, to complement business process models (per BPMN in BPMS) and bridge between business rule declarations (per SBVR) and executable decisions (per PRR, RIF, BPEL etc). This will provide a modeling standard for decisions in business analysis and design as well as IT decision analysis and implementation (per BRMS)." (c) Jan Vanthienen Decision Modeling & Notation 6

7 DMN Task Force Team RFP IBM Ilog = Large tool (BPM, BRMS etc) vendor KU Leuven (BE) = Subject Matter Expert TIBCO Software = Medium tool (CEP, BPM) vendor Wells Fargo providing guidance in the Business Modeling & Integration Domain Task Force Submission Team Decision Management Solutions Escape Velocity, FICO, IBM, KU Leuven, Model Systems, Oracle, TIBCO, Visumpoint Teams subsequently merged + KPI feedback from Visumpoint, RuleManagement (c) Jan Vanthienen Decision Modeling & Notation 7

8 OMG and Other Specifications BMM OSM Computation Independent Model S-beaver Business SBVR Business Vocabulary DMN BPDM + BPMN BPEL Platform Independent Model W3C RIF PRR UML OWL RuleML Platform Specific Model Model Driven Architecture (MDA) (c) Jan Vanthienen Decision Modeling & Notation 8

9 Contents of final submission Overall modeling paradigms Comprehensive notation and vocabularies Decision tables Expression language S-FEEL, FEEL Metamodel Definitions, Expression Interchange formats XMI, XSD Conformance levels (c) Jan Vanthienen Decision Modeling & Notation 9

10 ASPECTS OF MODELING (c) Jan Vanthienen Decision Modeling & Notation 10

11 Primary USE Cases Modeling human decision-making Descriptively model the decisions within an organization Natural language used rather than formal expressions Modeling requirements for automated decision-making Descriptively model the decisions within an organization Formal expressions used but may be incompletely specified Some decisions may be delegated to humans Implementing automated decision-making Decision logic must be completely specified (c) Jan Vanthienen Decision Modeling & Notation 11

12 DMN - Third in a BMI trilogy Three standards designed to be complementary BPMN 2.0 (2010) Prescriptive (business) process Included a forward looking business rules task Expression language was nice to have so deferred CMMN 1.0 (2012, currently in FTF) Descriptive (case management) process Expression language was judged should have But to manage v1 scope submission team deferred to DMN DMN (2014) Decision Tables are a core DMN feature Expression language was must have so team stepped up (c) Jan Vanthienen Decision Modeling & Notation 12

13 decision requirements diagram (c) Jan Vanthienen Decision Modeling & Notation 13

14 KNOWLEDGE sources (c) Jan Vanthienen Decision Modeling & Notation 14

15 (c) Jan Vanthienen Decision Modeling & Notation 15

16 (c) Jan Vanthienen Decision Modeling & Notation 16

17 (c) Jan Vanthienen Decision Modeling & Notation 17

18 DECISION LOGIC Decision 1 Decision Business 1 Knowledge 1 Replace with boxed invocation Parametrized value expression (c) Jan Vanthienen Decision Modeling & Notation 18

19 Decision tables Applicant Risk Rating Hit policy Inputs Outputs Hit policy: - If one rule is required: Unique (if there is only one for every set of inputs) [default] or select the desired one: Any, First, Priority - If all applicable rules are required: results in an output list (operations may be applied, e.g. sum(partialscores)) List order is No order (arbitrary), Rule order, Output order (c) Jan Vanthienen Decision Modeling & Notation 19

20 Example decision logic Strategy Bureau Call Type (U) Pre-bureau risk category Bureau Call Type 1 HIGH, MEDIUM FULL 2 LOW MINI 3 DECLINE NONE table with unique columns - complete Strategy (U) Pre-Bureau Eligibility Bureau Call Type Strategy 1 INELIGIBLE - DECLINE 2 ELIGIBLE FULL, MINI BUREAU 3 NONE CONTINUE table with unique columns - complete Bureau call type Pre-bureau eligibility Pre-Bureau Eligibility P Pre-Bureau risk category Instalment Affordable Age Monthly Income Pre-Bureau Eligibility 1 DECLINE INELIGIBLE 2 - False - - INELIGIBLE < 18 - INELIGIBLE < 100 INELIGIBLE ELIGIBLE table with overlapping columns (priority INELIGIBLE > ELIGIBLE) Pre-Bureau Risk Category Pre-bureau risk category Existing Customer Application Risk Score Pre-Bureau Risk Category True <100 HIGH [ ] MEDIUM > 120 LOW False < 80 DECLINE [80..90] HIGH ( ] MEDIUM > 110 LOW single hit - consistent - complete - non redundant (c) Jan Vanthienen Decision Modeling & Notation 20

21 DMN Types of tables (single hit) DMN identifies different table types, indicated by the first letter: unique hit tables: every input case is included in one rule only. There is no overlap between rules. any hit tables: every input case may be included in more than one rule, but the outcomes are equal. Rules are allowed to overlap. priority hit tables: multiple rules can match, with different outcome values. This policy returns the matching rule with the highest output value priority (e.g. highest discount). first hit tables: multiple (overlapping) rules can match, with different outcome values. The first hit by rule order is returned (and evaluation can halt). This is a common usage, because it resolves inconsistencies by forcing the first hit. It is important to distinguish this type of table from others because the meaning depends on the sequence of the rules. Because of this sequence, the table is hard to validate manually and therefore has to be used with care. (c) Jan Vanthienen Decision Modeling & Notation 21

22 Expressing the Decision Logic FEEL ( Friendly Enough Expression Language) implements the required mechanisms Built-in types, functions and operators Every decision in a DRD can be defined using a formal expression that specifies how the decision s output is determined from its inputs Complete decision models can be defined Formal expressions may also be encapsulated as functions Supports abstraction, composition, and scalability S-FEEL ( Simple FEEL ) is a basic subset of FEEL designed to cover the essential requirements of Decision Table-based DMN models DMN can be extended to use other expression and type definition languages (c) Jan Vanthienen Decision Modeling & Notation 22

23 CONFORMANCE Conformance level 1 Notation, Interchange level 2 Notation, Interchange + S-FEEL level 3 Notation, Interchange + FEEL (c) Jan Vanthienen Decision Modeling & Notation 23

24 Cell Phone Bill Payment Phone Co Finance Admin Manager Accounting Kathy A. Long, "The KISS Approach to Process," Business Rules Journal, Vol. 10, No. 1 (Jan. 2009) (c) Jan Vanthienen Decision Modeling & Notation 24

25 Cell Phone Bill Payment Phone Co Finance Admin Manager Accounting Kathy A. Long, "The KISS Approach to Process," Business Rules Journal, Vol. 10, No. 1 (Jan. 2009) (c) Jan Vanthienen Decision Modeling & Notation 25

26 Decision structure Loan Approval Type of loan? Customer.Type? Creditworthiness? Approve loan Customer.Type Age of Account? Annual Amount? Customer.Type Creditworthiness Age? Income? History? Creditworthiness History Some condition Another condition History (c) Jan Vanthienen Decision Modeling & Notation 26

27 A decision model Decision Result Criteria Type: table, formula, 1..n Criterium Source: User, DB, Decision Decision details Table logic Tree ANN (c) Jan Vanthienen Decision Modeling & Notation 27

28 Decision table structures From DB, Ask user, Orders Customer.CreditLimit Ok Not Ok Customer.Type - Good Not Good Stock.Quantity Ok Not Ok Ok Not Ok - Execute Order x - x - - Refuse Order x WaitList Order - x - x - Customer.Type? Execute Order.Quantity Order.Distance Discount Transport Bill Type Account.Age (years) Account.Turnover (T) Customer.Type < Road A >=10 and <15 <50 10% Road A >=50 and <100 5% Road A >=100 2% Road A >=15-10% Railway B <1 >=1 <10 Not Good >=10 Good <5 Not Good >=5 Good (c) Jan Vanthienen Decision Modeling & Notation 28

29 Decision goal network naturalization (c) Jan Vanthienen Decision Modeling & Notation 29

30 Decisions and Processes naturalization Start each individual decision activity as soon as all its preconditions are fulfilled Avoid superfluous decision activities (unnecessary work) Group customer contacts (c) Jan Vanthienen Decision Modeling & Notation 30

31 Sometimes the process is a decision Hard-coding the decision process (Bruce Silver) Customer.Type Age of Account? Annual Amount? Customer.Type Loan Approval Type of loan? Customer.Type? Creditworthiness? Approve loan Creditworthiness Age? Income? History? Creditworthiness the decision process the data acquisition process the decision sequence Hist Some ory condition Another condition History (c) Jan Vanthienen Decision Modeling & Notation 31

32 Modeling the decision Naturalization is the acquisition of citizenship by somebody who was not a citizen of that country when born. Not everyone can request naturalization and the decision whether someone can apply for a new nationality is restricted by several requirements. The requirements for the Belgian citizenship are formulated by the following decisions: Is the applicant legal of age? Does the applicant has a legal residence? (What does it mean to have a legal residence?) Has Belgium been the applicant s main country of residence? Can the applicant show that he is socially and culturally integrated? (c) Jan Vanthienen Decision Modeling & Notation 32

33 Decision goal network Decide on the application for naturalization (Z) Asses the legal age (A) Evaluate the appropriateness of the applicants current residence status (B) Check whether Belgium is the main country of residence (C) Asses on the cultural and social integration of the applicant (D) Check the IDcard for foreigners. (B1) Asses the registration in the register of foreigners (B2) Assess the residency conditions (B3) The main decision Z has only one incoming edge, this signals that the decision is dependent on the value of all lower level decisions A, B, C and D. Decision B on the other hand has three incoming edges, this means that it only needs the outcome of one lower level decision. (c) Jan Vanthienen Decision Modeling & Notation 33

34 Serial and parallel designs (c) Jan Vanthienen Decision Modeling & Notation 34

35 Criteria to choose between different models Criteria distinguished by (Reijers,2005) : Customer: This criterium improves the relations and contacts with the customer such that the contacts happen in an efficient way and customer friendly manner. An example: reducing the customer touchpoints, by having all information available upfront. Business process operation: This criterium implements the workflow in an efficient way. An example: eliminating redundant activities. Business process behavior: This criterium optimizes the time aspect of the execution. An example: moving activities to the front that are likely to fail. Organization: This criterium optimizes the organizational structure and the involved resources. An example: assigning the same worker to a case for the whole process. Because the worker has prior knowledge about the case he doesn t need to get accustomed to the case every time. Information: This criterium uses best practices for the usage of information in business processes. An example: minimize information requests by checking incoming and outgoing information. External environment: This criterium improves the collaboration and communication with third parties. An example: using standardized interfaces with customers and criteria. H.A. Reijers, S. Limam Mansar. Best practices in business process redesign: an overview and qualitative evaluation of successful redesign heuristics. Omega, Volume 33(4), pp , (c) Jan Vanthienen Decision Modeling & Notation 35

36 An example process model (c) Jan Vanthienen Decision Modeling & Notation 36

37 Evaluating the model Customer perspective: the applicant must come to the administration twice, for assess the integration of the applicant and check ID card for foreigners. Business process behavioral perspective: starting with a labor-intensive activity as assess the integration of the applicant is not optimal since the application could be easily rejected when Belgium is not the country of residence (simple check in the Register) Organizational perspective: the number of handovers can be halved by letting the check ID card for foreigners succeed the assess the integration of the applicant immediately. Informational perspective: the current activity sequencing imposes a double consultation of the Register of Births in some cases, while all necessary information could be easily at one point in time. External environmental perspective: assessing legal age might require intervention from an embassy. The number of contacts with embassies should be limited. (c) Jan Vanthienen Decision Modeling & Notation 37

38 Another model (c) Jan Vanthienen Decision Modeling & Notation 38

39 Other models (c) Jan Vanthienen Decision Modeling & Notation 39