The Decision Model and Notation (DMN) standard · PDF file• It's not a comparison of DMN to other notations or models - DMN is a ... in traditional flowcharting terminology or ‘gateways’

www.horizonbusinessarchitecture.com © Horizon Business Architecture Ltd 2014-17

The Decision Model and

Notation (DMN) standard

A worked example

May 2014/February 2016

Nick Broom

http://www.horizonbusinessarchitecture.com/

The Decision Model and Notation

(DMN) standard – a worked example

Page 2 of 25 © Horizon Business Architecture Ltd 2014-17

Introduction

This paper provides a worked example of decision modelling using the Decision Model

and Notation (DMN) specification, published officially by the Object Management

Group (OMG) in September 2015 as version 1.0. Version 1.1 is due out in mid-2016.

This paper started off as a blog post by Nick Broom first published in January 2014.

What’s covered?

• This paper gives a taster of DMN - what it looks like, how it fits in with BPMN.

It's based on learning it from the specification (it's a tough read, but the specs

are not designed for 'business' use - they're more aimed at technology vendors).

What's not covered?

• It's not a comparison of DMN to other notations or models - DMN is a

standard and primarily a notation; other approaches provide both a notation and

a method, such as Knowledge Partners International’s (KPI) ‘The Decision Model’

(TDM). For example, DMN will prescribe a format for Decision Tables, but TDM

has principles that underpin how tables should be constructed, normalised etc.

• It's not an in-depth review of the full scope of DMN - DMN's got a lot of

moving parts - predominantly this paper looks at the graphical notation and the

modelling of Decisions using Decision Tables, but, there's more to the scope than

just Decision Tables.

• It’s not a history of DMN or decision modelling in general – it provides a brief

overview of what decision modelling is, but there’s many other sources of

information that can provide a more detailed background to the interested

reader (see Further reading).

• It’s not about tooling for DMN – it’s looking at the notation from an analysis

viewpoint; this paper specifically excludes any discussion on tools that support

DMN, either now or in the future.

Who should read this paper?

Business Rules Subject Matter Experts, Business Analysts, Project Managers, Enterprise

Architects, Testers, IT Developers.

Objective

To provide a view on what DMN is and how it might be used as part of the business

analysis toolkit.

http://omg.org/

http://omg.org/

http://nickpbroom.wordpress.com/2014/01/08/going-dmn-tal/




Decision modelling

Definitions of a decision:

decision /dɪˈsɪʒ(ə)n

Noun

• a conclusion or resolution reached after consideration: “I’ll make the

decision on my own”; “the editor’s decision is final”

• The action or process of deciding something or of resolving a question:

“the information was used as the basis for the decision”

late Middle English: from Latin decision(n-), from decider ‘determine’

(Oxford Dictionaries, n.d.)

• the act of determining an output value (the chosen option), from a

number of input values, using logic defining how the output is determined

from the inputs.

(Object Management Group, 2015)

Decision, or business, logic:

represents the ‘rules of the business’ that operate perhaps thousands of times a

day in service to customers and partners. Yet many … are buried in program code

or in people’s heads. They are an important consideration in implementing

change and delivering enterprise agility.

Even when captured separately … they are managed as a catalog or list of

business rule statements… They are not managed in a common model as data is

managed today.

(von Halle & Goldberg, 2010)

The primary goal of DMN is to:

provide a common notation that is readily understandable by all business users,

from the business analysts needing to create initial decision requirements and

then more detailed decision models, to the technical developers responsible for

automating the decisions in processes, and finally, to the business people who

will manage and monitor those decisions.

DMN creates a standardized bridge for the gap between the business decision

design and decision implementation.




DMN notation is designed to be useable alongside the standard BPMN business

process notation.

(Object Management Group, 2015)

Decision modelling provides a way of packaging rules into discrete, modular, and

manageable pieces. It separates out declarative rules from procedural behaviour,

that is, process models are simplified by removing those things that are not actually

governed by a specific order. Rather than complicated configurations of ‘decision points’

in traditional flowcharting terminology or ‘gateways’ in BPMN terminology, the

conditions that have to be met are governed by their own model, which makes them

infinitely more responsive to change.

Appreciating that the evaluation of conditions are often not governed by a specific

sequence is the first major cultural mind-set shift in adopting decision modelling. There

are times when sequence is hugely important for distinct reasons and that is

demonstrated during the worked example in the body of this paper. However,

understanding how they can be handled as a unique asset really unlocks the power

to make those rules clearer and more responsive to an ever-increasing rate of

change in modern industry.




Contents

Introduction ...................................................................................................................... 2

What’s covered? ................................................................................................................ 2

What's not covered? .......................................................................................................... 2

Who should read this paper? ............................................................................................. 2

Decision modelling ............................................................................................................ 3

Worked example context ................................................................................................... 6

The business process...................................................................................................... 6

DMN - Decision Requirements .......................................................................................... 7

DMN - Decision Logic ........................................................................................................ 9

First Decision – ‘Applicant Demographic Suitability’ ................................................... 10

‘Applicant Demographic Suitability’ Decision Model ................................................. 11

‘Applicant Years of Age Calculation/Applicant is Existing Customer’ Decision Model

.................................................................................................................................. 13

‘Applicant Private/Student Credit Card Demographic Suitability’ Decision Model ... 14

Second Decision – ‘Applicant Credit Card Eligibility’ ................................................... 15

‘Applicant Credit Card Eligibility’ Decision Model .................................................... 16

‘Applicant Balance Transfer Credit Card Eligibility’ Decision Model ........................ 17

‘Applicant Credit Score’ Decision Model ................................................................... 18

Expressing Decision Logic without invoking a Business Knowledge Model ................. 19

Worked example conclusion ............................................................................................ 21

Business glossary, and data modelling ............................................................................ 22

Final observations ........................................................................................................... 23

References ....................................................................................................................... 24

Further reading ............................................................................................................... 25

About the author ............................................................................................................. 25

Disclaimer .................................................................................................................... 25




Worked example context

The example is something relatively straightforward - a credit card application. It's not

dissimilar to the concepts used in part of the worked example in the Section 10 of the

spec.

The example is based on some of the information from the public website of one of the

UK's banks. Other information has been assumed, for example, credit scoring because

it's highly complex and not readily available. A BPMN 2.0 Process Model has been

drafted to provide the context (it's a stub - the process in practice would only be

considered successfully complete when a card was issued) – see Figure 1.

The business process

Process brief

An Applicant submits an Application for a credit card, which is received by a member of

the Credit Card Processing Team. The information is recorded and basic information

about the Applicant assessed to determine whether it is worth requesting their Credit File

from an external Credit Reference Agency. If it is, then the Credit File is requested and

the Applicant is assessed based on specific criteria for the card for which they've applied.

The process ends successfully when the eligibility for the card has been determined and

the Applicant informed of the result.




Figure 1: BPMN process model showing the receipt and assessment of a Credit Card Application,

with two key Decisions

The Business Rule Tasks (small table marker in top-left corner of the activity) denote

that Decisions are required at those points.

DMN - Decision Requirements

From an analysis perspective, DMN's got two main bits: Requirements and Logic.

The Decisions required in a given 'domain' are represented in a Decision Requirements

Graph (DRG). That could get quite big. So the DRG itself can be made up of one or

more Decision Requirements Diagrams (DRDs).

As mentioned above, the process in the real world would probably continue until the

card is actually issued. There are also other elements associated with the credit card

once it is issued: statements; interest charges; defaults; closure etc. All of the Decisions

across those processes would represent the entire domain and thus a DRG.

However, the scope of this paper looks at the requirements for ‘Credit Card Eligibility’

and thus the DRD for that process scope. There are two key Decisions from the initial

process analysis:




• 'Applicant Demographic Suitability' and

• 'Applicant Credit Card Eligibility'.

The analysis starts at that point and begins to define the Decision requirements. In

summary, it looks at the key bits of information that need to be evaluated by talking to

the project stakeholders and establishing how they might be packaged to make those

Decisions more manageable, resulting in the DRD shown in Figure 2.

Figure 2: Shows the DRD for decisions required in assessing a credit card application

In practice, the diagram was developed iteratively along with the logic and the process,

but that evolution is not in the scope of this paper.

Figure 2 shows that:

• the two main Decisions require other Decisions as their inputs, along with

other Input Data;

• the logic for those Decisions are contained in the Business Knowledge Models that

they invoke. Those Business Knowledge Models may be governed/owned by

Knowledge Sources.

There’s some relatively ‘techy’-sounding terminology there, so in an attempt to simplify:

The Decision provides the output information, the thing that’s of interest, but it has to




ask a Business Knowledge Model to work it out (usually, but see Expressing decision

logic without invoking a Business Knowledge Model). Put another way, the Business

Knowledge Model could be seen as the script writer for the Decision speaker. The

speaker tells people what they need to know (hopefully) but he's called upon his script

writer to evaluate the necessary information (Input Data) and present it in a format

where that output can be communicated as required to his audience.

Referring back to Figure 1, the diagram shows that the Data Items associated with the

User and Service Tasks match the Input Data in the DRD.

DMN - Decision Logic

The next step is to get into the detail of the logic that sits behind the Decisions:

• DMN has created a standard for Decision Tables;

• a Decision Table is a Business Knowledge Model, but not all Business Knowledge

Models are Decision Tables.

What that means is that a TDM Rule Family View could be used as a Business Knowledge

Model (von Halle & Goldberg, 2013). Other examples include the use of an analytics

model or a natural language expression.

DMN has also created a standard language for expressing Decision Logic called FEEL

(Friendly Enough Expression Language), although that depends on who you are as to

whether it's friendly enough for you! As many of the following examples as possible are

expressed using FEEL but it can be hard going using the spec alone. This paper does not

go into a great deal of detail on FEEL.




First Decision – ‘Applicant Demographic Suitability’

Figure 3: portion of the process model highlighting the first Decision

Figure 4: The portion of the DRD showing that Decision




From the process, there are two main outcomes defined by each gate following the task:

‘Suitable’ and ‘Unsuitable’.

To arrive at that conclusion, the partial view of the DRD in Figure 4 shows that it

depends on:

• two other Decisions;

• two lots of Input Data and;

• a number of Business Knowledge Models.

The reason that this is a separate Decision rather than just forming an overall input to

the eligibility assessment is because there are basic criteria that need to be met for a

given credit card product before putting a footprint on a credit report. This talks back to

the point made at the start of the document where sequence does become important for

distinct business reasons.

‘Applicant Demographic Suitability’ Decision Model

Figure 5: A Decision with an invoked Business Knowledge Model in the form of a Decision Table

Figure 5 shows both the Decision itself and the Decision Table invoked by it. The details

of the structure are broken down below but, in summary, the Decision Logic is

encapsulated in Boxed Expressions.

The type of Boxed Expression for the Decision is a Boxed Invocation - it's the speaker

asking his script writer to do what he does. It passes the required Input Data into the

Business Knowledge Model.




The red numbers against Figure 5 show a number of components associated with the

model:

1. Applicant Demographic Suitability - the Decision itself.

2. Applicant Demographic Suitability Table - the Business Knowledge Model that

the Decision 'invokes'; in this case, a Decision Table.

3. Boxed Expression - this whole structure at the top of the diagram represents a

Boxed Invocation (a type of Boxed Expression).

4. Applicant Years of Age Calculation – another invoked Business Knowledge

Model that will return the required outcome into this model.

5. Applicant is Existing Customer Rules – as ‘Applicant Years of Age Calculation’.

6. Existing Customer Products Held with Lender - for the invoked Business

Knowledge Model 'Applicant is Existing Customer Rules', this defines the Input

Data that represents the logical input expression 'Existing Customer Products

Held with Lender' to that model.

7. Decision Table - this is a Single-Hit Decision Table with Hit Policy of First (the

'F'), meaning that the output returned will be the first rule hit. These can be hard

to validate manually because it is so dependent on the order of the rows. A

Decision Table is also a type of Boxed Expression. The 'C' following 'F' says that

the table is complete1, that is, all rules have been included in order to reach an

outcome.

8. Input Data values – value under test provided where appropriate to the rule; a

dash means that the input value is irrelevant to a particular rule.

9. Input Expression domain values - an optional section used to show the valid

domain values where appropriate.

10. Output Data values – can be an absolute value, or the value can come from the

output of another decision. In this example, rows 3 and 4 are provided by

‘Applicant Private Credit Card Demographic Suitability’ and ‘Applicant Student

Credit Card Demographic Suitability’.

1 There is some justification for stating that completion should only be handled by an

appropriate tool, rather than allowing the analyst to judge when the table is complete (Feldman, 2014)

Example

Applicant is 19, applying for a Student card but is not an existing customer. Row 2 would

be triggered, giving an 'Unsuitable' outcome.




‘Applicant Years of Age Calculation/Applicant is Existing Customer’ Decision Model

Figure 6: The two other Business Knowledge Models invoked by the Decision, providing input data

to the Decision Table

The Decision Table takes two of its inputs from two other Business Knowledge Models.

Rather than Decision Tables, these use Boxed Contexts. These are good for calculations.

This example highlights that a company will most likely derive the ‘Applicant's Years of

Age’ - applications typically ask for a date of birth instead of years of age.

These models return the required Input Data to the Decision Table from the previous

figure. The numbers in red show:

1. Boxed Context - the structure represents a Boxed Context (another type of Boxed

Expression).

2. Natural language expression - a natural language expression that defines how

the ‘Years of Age’ is calculated.

3. Output - the value returned by the expression. This will then be used as the Input

Expression in the 'Applicant Demographic Suitability' Decision Table.




‘Applicant Private/Student Credit Card Demographic Suitability’ Decision Model

Figure 7: The two Decision Tables required for the logic assessing Student and Private Credit Card

Demographic Suitability

Another couple of Decision Tables for the two Decisions that are 'required' by the main

'Applicant Credit Card Demographic Suitability' Decision (the Boxed Invocations for the

Decision itself have been left off this example).

These are both Single-Hit Decision Tables, the first with Hit Policy of Any. This means

that any rule can be hit during the Decision, but in the event that multiple rules are

hit, they will only return the same conclusion. So if the Customer has both £150k in

annual income AND £350k in outstanding mortgage borrowings, both rules 1 and 2 will

be hit, but will only return "Suitable". The second is Unique, meaning no overlap is

possible and rules are exclusive.

The outputs of these two tables are required as Input Expressions in the 'Applicant

Demographic Suitability' Decision Table.

Example

An Applicant applies for a Private Credit Card, they are an existing customer and they

have mortgage borrowings of £350,000 and a sole annual income of £200,000. Both

rows 1 and 2 will be triggered, where both outputs are 'Suitable'.




Second Decision – ‘Applicant Credit Card Eligibility’

Figure 8: portion of the process model highlighting the second Decision

Figure 9: Partial view of the DRD showing the Applicant Credit Card Eligibility decision and its

requirements

From the process in Figure 8, there are two main outcomes defined by each gate

following the task: ‘Eligible’ and ‘Ineligible’.




The second Decision uses the Credit File obtained from the external Credit Reference

Agency. This information is used in the ‘Applicant Credit Score Table’ Business

Knowledge Model, which is dictated by the Credit Policy of the Lender (shown as a

Knowledge Source).

‘Applicant Credit Card Eligibility’ Decision Model

Figure 10: The Decision and its invoked Decision Table to determine the eligibility of the Applicant

for the Applied Card

1. Single-Hit Decision Table with Hit Policy of Unique - only one rule can be hit

during the execution of the Decision.

2. Limited set of Input Data - some of the criteria were established in the first

Decision; on that basis, the process would never have got to this point without it

the Applicant being a fit for the target demographic. So that Input Data is not

required by this Decision.

Example

Applicant is applying for a Balance Transfer card and they have a credit score of 570

resulting in an outcome of 'Ineligible'.




‘Applicant Balance Transfer Credit Card Eligibility’ Decision Model

Figure 11: The Decision Logic for the Applicant Balance Transfer Credit Card Eligibility decision.

As with the ‘Applicant Years of Age’, application forms usually get applicants to list their

address history, so this requires another expression to return the information. The

associated calculations have not been included here.

1. List of Input Data - application forms typically list address details and range of

dates for each, rather than the number of years being available as a specific item

of input data. Therefore, there needs to be an expression to derive the value

using that data.

Example

Applicant has a sole income of £15,000, hasn't applied for the card at any time in the last

6 months, has 5 years of address history and lives in France. Row 3 would be triggered

with an outcome of 'Ineligible'.




‘Applicant Credit Score’ Decision Model

Figure 12: Credit Scoring Multi-Hit Decision Table that aggregates the outputs together as a sum

Points to note on Figure 12:

1. This table is entirely fictitious - the numbers are arbitrary, as are the Input

Expressions, but the main purpose is to demonstrate the Multi-Hit Decision Table

with a Hit Policy of No Order (that is, the order in which the various values are

output from the table is of no consequence).

2. Ranges of values are shown between brackets - where the type of bracket

defines whether the first and last values shown are included in the range. Square

brackets indicate inclusion of both values.

3. Multi-Hit Decision Tables have an Aggregator - in this instance, Sum, which

means the output values are summed together. It is the summed value that is

used as the Input Expression to the 'Applicant Credit Card Eligibility' Decision

Table.

4. Available credit used > 100 - whilst this looks unusual, technically it is possible

for all credit available to have been used and to have exceeded the limit as well.

The input and output values in a DMN Decision Table are specified by FEEL and that has

been included in Figure 12. Ranges of values are of particular interest and FEEL




accommodates all combinations of start and end points being included/excluded in the

expression.

Expressing Decision Logic without invoking a Business Knowledge Model

The spec states that:

In most cases, the logic of a decision is encapsulated into business knowledge

models, and the value expression associated with the decision specifies how the

business knowledge models are invoked, and how the results of their invocations

are combined to compute the output of the decision. The decision’s value

expression may also specify how the output is determined from its input entirely

within itself, without invoking a business knowledge model: in that case, no

business knowledge model is associated with the decision.

(Object Management Group, 2015).

What that means is that it is possible, should you wish to do so, to include a Decision

Table within the Decision itself, rather than in a separate model.

Expressing logic in a separate Business Knowledge Model allows that logic to be reused

in multiple Decisions, potentially with different Input Data. So there could be two

Decisions that use the same Business Knowledge Model, but it might be evaluating the

same logical information using different physical data sources.

However, the use of a Business Knowledge Model is not mandated. Figure 13 shows an

alternative way of expressing the ‘Applicant Credit Score’ Decision.

Example

Example: Applicant has defaulted once in the last 12 months, has not declared

bankruptcy, has 4 years with their bank and has used 67% of their available credit. This

triggers rows 1, 6, 9 and 12, giving individual scores of 100, 250, 250 and 150. This is

aggregated to give an overall score of 750.




Figure 13: Alternative expression of the Decision, showing the Decision Table as part of the Decision.

Note that there is no longer a reference to the table underneath the Decision name.




Worked example conclusion

Imagine now if all of the rules defined in the previous tables had been built as gateways

within the process? Each Input Expression would probably have needed its own gateway

and ensuring coverage for each combination of conditions would have been

exceptionally difficult. As it stands, there are three key points that have been

demonstrated by this example:

• Simplified process – two tasks have taken the place of numerous gateways. This

allows the process model to focus on its primary objective: the flow of activity.

The logic that governs which path should be taken from a gateway is now

encapsulated in the Decision Tables.

• Processes driven by decisions – processes can be architected to focus on

reaching outcomes of key Decisions; the process becomes about how you ensure

those Decisions have the right data at the right time.

• Flexible rule management – additional criteria for evaluation become another

column in a Decision Table. Additional values associated with the Input

Expressions that need to be assessed become new rows. Rules that are not best

managed through a table can take other forms, such as a natural language

expression.




Business glossary, and data modelling

Business terms and glossaries have not been covered in this paper. These are still a

critical aspect of expressing Decisions effectively. However, a lot of the modelling

practices that are part of TDM have been used in this worked example in naming the

Input Expressions (Fact Types in TDM-speak). DMN doesn't mandate a glossary; this is

potentially because there is an expectation that the other OMG spec, 'Semantics of

Business Vocabulary and Business Rules' (SBVR), provides the appropriate model.

Consideration of SVBR is out of scope of this paper.

In order to come up with the meaningful, accurate, names for the Input and Output

Expressions, the following portion of a Concept/Fact model was produced:

Figure 14: The concepts defined to help guide the naming of the input and output expressions

This model helped in defining the in-scope concepts and their relationships between

them in order to properly qualify the terms used.

http://www.omg.org/spec/SBVR/

http://www.omg.org/spec/SBVR/




Final observations

As mentioned at the start, the intention of this paper is to provide a view of DMN, not

critique it. However, a few final observations have been included below:

• Decision domain view - providing a graphical Decision-oriented view of the

domain has a huge benefit. Whilst a lot of Decisions are executed as part of a

process, understanding the full context in which a decision is made is impossible

without reference to that process. By providing a DRG and associated DRDs,

there is now a specific view of Decisions that will speak more appropriately to a

specific demographic of stakeholders.

• Decision Table flexibility - the flexibility of the types of tables is beneficial for

handling different scenarios, particularly in terms of the different Hit Policies for

Single-Hit Tables and the Aggregator for Multi-Hit Tables.

• Potential Decision Table complexity - whilst the flexibility of the Decision

Tables is a plus, it's also a drawback, particularly to business usability, because

the way in which a table is read is down to people spotting the one-character

indicator in the top-left of the table. They've also got to know which of the Hit

Policies the indicator belongs to, although the Aggregator at the bottom of the

table should help that. Tool vendors may make their own decisions as to how

many types of decision table will be supported. In this paper, only Decision

Tables that are rules-as-rows have been considered; it is also possible to have

rules-as-columns as well as Cross-tab.

• Terminology - 'invocation'; 'boxed <insert name here>' may provide a cultural

challenge to adoption, as the terminology may be seen as too ‘techy’.

• Method and style - as described, the example in this paper has been produced

via learning from the spec, but a big part of doing the decomposition of the

decisions was based on applying the principles and practices from TDM. A

standard notation is good, but without guidance on how best to apply that

notation, there are inherent risks to its effective use in industry. For example,

most of the Decision Tables in this paper were created using 3 Input Expressions.

However, it would have been simple to create very large tables in terms of rows

and columns and this will be the most likely first step for the new person

attempting this notation; large tables are inflexible and unmanageable. Books

are starting to appear on the subject as at the start of 2016 and this year should

start to see methods develop as part of those publications.

The likelihood is, people will really start getting interested when this standard hits

2.0 – given the development of BPMN between versions 1 and 2, there will be a lot more

work done to really bring DMN to fruition.




References

Feldman, J., 2014. Another DMN Decision Model (executable!). [Online]

Available at: http://openrules.wordpress.com/2014/01/08/another-dmn-decision-

model-executable/

[Accessed 20 May 2014].

Object Management Group, 2015. Decision Model and Notation. [Online]

Available at: http://www.omg.org/spec/DMN/1.0/PDF

[Accessed 22 February 2016].

Oxford Dictionaries, n.d. Decision. [Online]

Available at: http://www.oxforddictionaries.com/definition/english/decision


von Halle, B. & Goldberg, L., 2010. The Decision Model: A Business Logic Framework

Linking Business and Technology. 1st ed. Boca Raton: Auerbach Publications.

von Halle, B. & Goldberg, L., 2013. The OMG Decision Model and Notation Spec (DMN)

and The Decision Model (TDM). [Online]

Available at:

http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/

articleId/2757/The-OMG-Decision-Model-and-Notation-Spec-DMN-and-The-Decision-

Model-TDM.aspx





Further reading

• DMN LinkedIn forum – many of the early discussions were held on this forum

and it is a great resource for getting in touch with the DMN submitters, and

learning more about the standard.

• The history of modelling decisions using tables – first part in a three-part series

by Professor Jan Vanthienen from the University of Leuven.

• List of publications on Decision Tables, Tabular Decision Models, and Business

Rules, again by Professor Jan Vanthienen.

• Decision Management Systems – ‘a practical guide to using business rules and

predictive analytics’ is a book by James Taylor of Decision Management

Solutions.

• Understanding business data using The Decision Model – a slideshare

presentation by Nick Broom on KPI’s ‘The Decision Model’, showing the different

concepts used in the model and its application in practical scenarios.

About the author

Nick Broom is a Business Analyst of 15 years and has been a freelancer since 2005. He’s

delivered projects in a number of different business and technological environments.

Specialising in Business Process Modelling, and Decision Analysis, he has been the lead

analyst on a number of decision modelling projects with major clients in the UK.

He currently lives in York, UK and has been Director of Horizon Business Architecture

Ltd since its inception in 2011. For more information on Nick’s professional portfolio,

see his LinkedIn profile.

Horizon Business Architecture Ltd is a company registered in England and Wales,

providing independent business architecture and analysis services.

Disclaimer

The author is not a member of the DMN committee or affiliated in any way, and has not

been financially compensated by any party for any of the content found herein. All

referenced works have been cited appropriately.

https://www.linkedin.com/groups?home=&gid=4225568&trk=my_groups-tile-grp

http://www.brcommunity.com/a2012/b637.html

http://www.econ.kuleuven.be/prologa/publications.htm

http://www.amazon.com/Decision-Management-Systems-Practical-Predictive/dp/0132884380/ref=sr_1_1?s=books&ie=UTF8&qid=1400512180&sr=1-1&keywords=decision+management+systems

http://www.slideshare.net/nickpbroom/understanding-business-data-using-the-decision-model

http://uk.linkedin.com/in/nickpbroom/

http://www.horizonbusinessarchitecture.com/

Documents

The Decision Model and Notation (DMN) standard · PDF file• It's not a comparison of DMN to other notations or models - DMN is a ... in traditional flowcharting terminology or ‘gateways’