Decision model and notation (DMN standard explained. A worked example by Nick Broom

www.visionalysis.co.uk © Visionalysis Ltd 2014

The Decision Model and Notation (DMN) standard A worked example

May 2014

Nick Broom

http://www.visionalysis.co.uk/

The Decision Model and Notation (DMN) standard – a worked example

Page 2 of 25 © Visionalysis Ltd 2014

This paper provides a worked example of decision modelling using the beta spec of the Decision Model and Notation (DMN), approved by the Object Management Group (OMG) in January 2014. This paper started off as a blog post by Nick Broom written in January 2014, which was based on the initial alpha spec.

This paper gives a taster of DMN - what it looks like, how it fits in with the Business Process Model and Notation (BPMN) and how it can be used to analyse real world situations. It is based on learnings from the spec so far - a tough read, but the specs themselves are not necessarily designed for 'business' use.

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.

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/



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, 2014)

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, 2014)

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

Decision modelling ...................................................................................................................... 25

Business process modelling ...................................................................................................... 25

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

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



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.

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.

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.

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'.



‘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.



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, 2014).

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. Reusability is the primary goal for this approach. 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.

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.



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 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/



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. What DMN will need is something akin to the Method & Style approach used by Bruce Silver for BPMN.

However, this is all based on the beta spec – the development between BPMN versions 1 and 2 was huge, so there is a lot of work that will be done over the next few months and years to really bring DMN to fruition.



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, 2014. Decision Model and Notation. [Online] Available at: http://www.omg.org/spec/DMN/1.0/Beta1/PDF/ [Accessed 19 May 2014].

Oxford Dictionaries, n.d. Decision. [Online] Available at: http://www.oxforddictionaries.com/definition/english/decision [Accessed 19 May 2014].

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 [Accessed 19 May 2014].



Decision modelling

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.

Business process modelling

Bruce Silver’s ‘Business Process Watch’ blog – great articles on the latest views on BPMN. Links to training courses using his ‘Method & Style’ approach

BPMN Method & Style – widely recognised as one of the best authorities on how to apply BPMN, this book is also the basis for Bruce’s training. This is the link to the book on amazon.com.

Nick Broom is a Business Analyst of 13 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 Visionalysis Ltd since its inception in 2011. For more information on Nick’s professional portfolio, see his LinkedIn profile.

Visionalysis Ltd is a company registered in England and Wales, providing independent business analysis consultancy 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://www.brsilver.com/

http://www.amazon.com/Method-Style-Edition-Implementers-Guide/dp/0982368119

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

http://www.visionalysis.co.uk/