A Practitioner’s Review of DMN 1.2

A Practitioner’s Review of DMN 1.2

In April 2016, James Taylor and I summarized our experiences of decision modelling in DMN by publishing two wish lists of the features I’d like to see in the next version of the standard. Specifically, I listed new feature suggestions for the way the standard represents decision requirements and decision logic elements.

Now the new version, DMN 1.2, is near release (the OMG committee are due to ratify the proposed changes on June 21). We look at the major new features that made it into this release, how these impact users of the standard and what we think of these changes.

If you are new to decision modeling find out why it’s important and see our overview of DMN1.1.

DMN 1.2 Update

Over the last month I’ve been modelling the IFRS-17 insurance accounting regulations using the Decision Model and Notation (DMN). I’ve been using the standard to produce a transparent and executable decision service that generates ledger entries that are IFRS-17 compliant. This is complex work which uses most of DMN’s current facilities – so I thought I’d take a look at the new version of the standard, DMN 1.2, announced last week by partners Trisotech, to see what new features might be useful for complex decision models. DMN 1.2 has lots of new features, many of which were on my original April 2016 wish list. Which features will be genuinely useful and which are still missing?

Readers should be aware that this article is based on my understanding (and opinion) of an announcement made ahead of the OMG DMN Task Force’s official release of DMN 1.2. It’s possible that the final release may differ from this. I will keep this article updated.

New Feature: Decision Services Can Be Invoked From DRDs

1. Definition of a Decision Service

DMN 1.1 supported the definition of a Decision Service, a means of specifying an interface for a Decision defined in a model, via which it can be invoked by an external architecture component (e.g., a BPMS or BRMS). An example Decision Service, Discount Service, is shown in Figure 1. It defines a means of calculating a discount for a customer given their faithfulness, volume of orders and special offers.

However, in DMN 1.1, it wasn’t possible to use Decision Services within the model itself. In this version, decisions can reuse an Business Knowledge Models using a knowledge requirement such as that shown in Figure 2. The Determine Discount knowledge model, which could offer the same business logic as the service, is supplied parameters (e.g., customer history, order volume discount and special offer details – not shown in Figures 2 and 3 for brevity) by its two ‘users’ in lieu of input data. It then provides an outcome just like the service.

2. Invocation of a Business Knowledge Model (BKM) by Two Decisions

3. DMN 1.2 Decisions Can Now Invoke Decision Services Directly

DMN 1.2 now allows Decision Services to be invoked inside a model in a similar way. This means that nodes in one Decision Requirement Diagram (DRD) can invoke Decision Services defined in the same DRD, another DRD in the same model or even in a different model. An example invocation is shown in Figure 3. The rounded rectangle is a Decision Service that is being invoked by the decisions Partner Discount and Customer Discount. Just as with the Business Knowledge Model, the invokers provide the necessary parameters (documented as input data nodes outside the service box in the service definition).

Note the expand button on the decision service (the little plus in a box), when selected this toggle ‘expands the service’ giving the ‘internal view’ of the service shown above. This expansion is analogous to the way subprocesses behave in BPMN.


We like this new feature. This ability to invoke decisions in one place that are defined in another is a great step towards diagram scalability. Practitioners can now avoid complex, ‘cat’s cradle’ diagrams by separating the definition of decisions from their use. You should consider this separation of decision use and definition whenever:

  • A decision is used in many places
  • A decision is independent of the rest of the DRD (i.e., doesn’t share most of the same knowledge or information dependencies
  • A decision and the model in which it is used are maintained by distinct parts of your organisation.

We can see this feature will be very useful in refactoring our diagrams, especially in the majority of tools that do not fully support the Decision Requirement Graph (DRG) concept.

New Feature: Ellipsis in DRDs – DRD Diagram Layout Now Maintained in Interchange Files

4. Use of Ellipsis in DMN 1.2

In DMN each Decision Requirements Diagram (DRD) shows a subset of the components and dependencies represented in the whole Decision Requirements Graph (DRG). So any given DRD in a model is a visual view of part of the DRG.

In our wishlist we argued that modelers should be able to represent (visually) that a component shown in a DRD (e.g., a decision or knowledge model) is involved in other dependencies that are (for brevity) not shown on this DRD. This is now part of DMN 1.2.

Consider an example of two separate DRDs in Figure 4. DRD ‘A’ represents the entire DRG, whereas DRD ‘B’ is a subset of the DRG and the ellipsis in the bottom decision signifies the elided child nodes.

The need for this notational convenience is clarified by a major extension of DMN 1.2’s interchange file structure (the contents of save files in DMN compliant tools). In DMN 1.1, the XML save file format used to transfer decision models from one tool to another only represented the abstract model DRG (e.g., decisions, input data, knowledge sources and their relationships). Now in 1.2, the file preserves both the concrete syntax of diagram layout (e.g., node size, fonts, node positions, color) and the abstract syntax separately. As a consequence, multiple concrete DRDs may be saved which reference objects in the same abstract model DRG.

As a result one DRD may be a partial (simplified) view of another (see example below), used for a specific purpose or to convey a specific facet of a model’s meaning. Notice how the sub-view (Figure 6) is more effective at representing a specific facet of the model (in this example how it depends on a single input data) than the entire DRD (Figure 5). You can click on these diagrams to zoom in.

6. DMN 1.2 Simplified Facet ‘sub-view’ of the DRD

5. Complex Single DRD with One Facet Highlighted


This use of multiple diagrams to represent multiple perspectives (i.e., different views) of the same underlying graph is frequently pivotal in the development and consensus building of decision models because it allows each perspective to concentrate on clarifying a single business viewpoint (see section 14.3.2 of our book for an explanation of the importance of this). This allows you to customize the model to the audience. This is also a great way of removing the clutter in some diagrams and focusing on the important details – it’s another example of how DMN 1.2 supports scalability in decision modeling.

New Feature: More Powerful Test Expressions in Decision Tables

In our original DMN 1.2 wish list article we called for more powerful conditions to be allowed in decision table cells. We wanted complex logic to be supported without the need to resort to FEEL context entries or boxed expressions. In technical terms, we asked that the unary test restrictions be lifted and that tests not be limited to inequalities and ranges of literal values, as they are in DMN 1.1. We felt that decision table tests should embrace more of FEEL’s expressive power.

We presented a proposal in which any FEEL function could be incorporated into decision table test expressions, providing it yielded a Boolean result (i.e., the success or otherwise of the test). We suggested a reserved symbol could be used to represent the variable being tested within this test expression. The DMN committee have supported this in DMN 1.2 with a facility called generalized unary tests. They have selected the reserved symbol ‘?’. Now, in the input cells of decision tables, it is possible to use FEEL expressions like contains list(?, “NY”), to determine if a list of states includes New York. This extension has interesting consequences for decision tables as the following example shows.

Example 1

Imagine you are modelling the admission rules for a grueling and dangerous mountain-pass walk. You might impose restrictions on the age, number and experience of persons comprising parties attempting the walk. According to their composition, some parties may be allowed to conduct the walk independently, some may require supervision by one of your staff and others may not be admitted at all. In DMN 1.1 such logic often had to resort to boxed contexts such as that in Figure 7 below.

7. Existing Use of Context Entries in Decision Tables

However by allowing support for generalized unary tests in expressions, it’s possible to reduce this to the logic shown in Figure 8:

8. DMN 1.2 Generalized Unary Tests

The use of these generalized unary tests allows input variables holding collections (in this case collections of ages, qualifications and persons) to be tested directly (as in this example) which was not possible in DMN 1.1. This is a nuanced case because although the second example is more compact and has powerful conditions, it contains some repetition in the conditions (usually this is considered poor practice and it could be prevented in this case with context entries). In addition the syntax may unnerve some business users, especially when used in conjunction with filters (as in the persons.experience conditions).

Example 2

A common pattern in decision modeling is to use a list of text enumerations to represent the properties of something, for example the issuers of a financial instrument. Then decisions decide on outcomes (e.g., the credit risk of an instrument) according to the membership of this list. In the DMN 1.1 example of Figure 9, we decide the credit risk of an instrument (as a last resort) by looking at the collection Instrument Classes.

9. Decision Table Using Collection of Enumerated Text

Because context entries are needed to check for each important possible member of the collection (e.g., GOVT EMERGING, AP AGENCY), the decision table requires a lot of work if new Instrument Class needs to be handled. It also gets wider and wider as each new instrument class condition is added. In DMN 1.2, we can use generalized unary tests to redesign this table to the much more readable version shown in Figure 10. This has the added benefit that additional instruments classes can be accommodated without next context entries or condition columns.

10. DMN 1.2 Decision table uses GUT to Check Members of a Collection


In our view the introduction of generalized unary tests in decision tables provides a new level of expressive power and scalability. We can easily recall several engagements in which it would have been useful (see example 2 above). It should be used carefully of course. Practitioners should avoid dense logic at the risk of making the decision tables less easy to understand. Nevertheless this feature offers the prospect of more elegant and powerful decision tables.

New Feature: Annotations in Decision Tables

In our wishlist article we argued (as many others did) that, just as DMN Decision Requirement Diagrams benefit from text comments called annotations to clarify their meaning (e.g., to express assumptions, explain goals, denote use of patterns, etc.), there should be a rule level annotation in decision tables with the same intent.

DMN 1.2 now supports this. Decision Table Annotations are (one or more) additional columns of a Decision Table (to the right of the outputs in a rules as rows table or below them in a ‘rules-as-columns’ table) that act like comments or post-execute explanation.


  • Document the intent, rationale and idiosyncrasies of each rule (as required)
  • Act as a means of supporting after-the-fact behavioral explanations of why specific rules were selected, including the ability to evaluate expressions to assist with diagnostics
  • Optionally link a rule with a specific section of a Knowledge Source that it satisfies

We’ve placed an example in Figure 8, above. The Explanation column is a rule level annotation.


Annotations are an effective means of embedding business justifications and other documentation, making your Decision Tables easier to understand. They can also be used in logging decision model behaviour. What is not clear from the DMN 1.2 proposal is the extent to which annotations can evaluate expressions for logging purposes (as is the case with messages in TDM).

Additional Functions in FEEL

Although FEEL incorporates many useful built-in functions for calculating values, manipulating information and aggregating collections of values, we observed that many of the included functions lack mathematically associated functions. For example:

  • sum() was supported (by DMN 1.1), but not product()
  • mean() was supported, but not median(), mode() or stddev()

It seems the DMN committee were listening! DMN 1.2 incorporates a wealth of new functions, including:

  • product(), median(), stddev() and mode() for both list objects and sequences of arguments
  • split(string, delimiter) to divide a string into fragments
  • abs() to determine the absolute value of a number
  • modulo(n, d) for determining the integer remainder after division of n by d
  • mathematical functions: sqrt(), log(), exp(), odd(), even()
  • Boolean functions: any(), all()


A richer set of the functions reduces the number of functions that modelers have to define themselves, eliminating clutter and repeated work. This is a welcome step. It’s a shame that intersect() is still not supported: we’ve have to add this for about 40% of our decision models for determining what members two (or more) lists have in common. Nevertheless anything that improves the expressive power of FEEL is a welcome development.

Other New Features

The standard included a wealth of other additions which although less impactful are certainly welcome.

Date, Time and Duration Handling

The semantics of addition, subtraction, multiplication and division for dates, times and durations have been clarified after the ambiguities pointed out by Keith Swanson’s blog post last year. In particular the meaning of time zones has been formalized, especially where date calculations feature some dates with a timezone and others without. In addition, the properties of time, date and duration objects have been described in more detail and a new date property, weekday, has been added. This will prove useful for commercial decision models and removes the need for another common user defined function.

String Escapes

New string escape sequences have been added with allow quotes, backslashes, newlines, tabs and Unicode characters to be embedded into strings. These will be useful for text processing and generation.


FEEL iteration statements in DMN 1.2 may iterate over literal ranges instead of just lists. In addition iterations support the reserved word partial which represents a list of the outcome of all previous iterations. Therefore, for example, the following iteration produces the first ten triangular numbers:

For x in 1..10 return if (x=1) then 1 else x+sum(partial)

Although both of these are interesting additions and the use of literal ranges is handy, we haven’t yet come across a use case for partial.

Singleton List Handling

One commonly reoccurring pattern of FEEL expressions is applying a filter to a list which, you know in advance, will yield a single result or in which only the first result is meaningful. Nevertheless, given this list, L, it is still necessary to use the filter L[1] to ‘unwrap’ this single object and use it. For example, if you have a FEEL object student with an attribute dependees representing a list of that student’s financial dependents, you might need the expression…

student.dependees[Relationship Classification(item.relationship) in ("PARTNER", "SPOUSE")][1]

…to yield the student’s (one and only) partner. DMN 1.2 allows such singleton lists (which only have one entry) to be treated, for convenience, as if they were the singleton object itself. So in the example shown we could omit the [1]. In short, for a list with one item, L, it may behave, where relevant, as if it were L[1].

While we like the convenience of this, we feel on balance that it is better to be explicit about the difference between lists and items. Such an implicit filter might hide the author’s intent and serve to make FEEL harder to understand which would be unfortunate considering its audience is business analysts and subject matter experts not developers.

Repudiation of S-FEEL

S-FEEL, the simplified subset of FEEL introduced in the earliest drafts of the standard, has been formally renounced. Although still supported by the standard, the committee no longer recommends its use in DMN 1.2 and the implication is that it may be removed in a later version.

S-FEEL was a strict subset of the FEEL expression language introduced with the idea of allowing business analysts to use simple value expressions without overloading their models with the complexity of FEEL full expressions or boxed expressions. It was also a way for tool vendors to offer an intermediate level of support for FEEL.

In practice however, we (and many others) never encountered a single use case for DMN which required S-FEEL. Models can either avoid using the expression language completely and express all their logic using decision tables (it’s surprising how often this can be achieved) or they need expressions, in which case the small subset provided by S-FEEL is never enough. Because of this, we welcome this development.


We feel the latest release of DMN offers many exciting new features and these will help to make decision modeling even more relevant to corporations that need to improve the transparency of their business decisions. Decision services, generalized unary expressions and the extension of the file interchange format will have the most significant impact in our view. Business stakeholders will benefit from having decision models that can be tailored to represent the facets of business decisions most important to them and decision modelers will appreciate the new flexibility in representing complex business logic.

It’s also good to see that more common functions are being supported (although many vendors had supplied these before DMN 1.2) and that the glitches in datetime arithmetic have been ironed out.

One of the most powerful applications of decision modeling is in the integration of predictive analytics, machine learning and AI into business decision making and we were sorry to see no significant advances in this direction. In addition, the continued lack of any glossary integration (e.g., data source and enumeration management) remains a limitation in DMN that is felt by every corporate adopter.


Our thanks to Denis Gagne at Trisotech for his timely article on DMN 1.2. It’s remarkable that Trisotech’s decision modeling product (DES) already supports DMN 1.2.

Thanks also to Jacob Feldman for sharing the news of DMN 1.2 via the DMCommunity forum.

Picture: How Decision Management Supports GDPR

Picture: How Decision Management Supports GDPR

A client recently asked about how Decision Management and Decision Modeling supports GDPR, “in a nutshell“.

I paused considering my usual answer, perhaps something like:

Decision Management is a means of bringing a company’s business policies and decision-making ‘into the light’, making decisions an explicitly-managed, corporate asset, expressed in a standard, transparent format.


This explicit, transparent medium can be used to capture, analyze and communicate exactly how a company’s operations depend on key data attributes and business knowledge.


This is done so precisely, the result, the decision model, is actually executable.


As a result, it’s much more accurate at supporting a GDPR Information Audit or Privacy Impact Assessment than traditional paper techniques like process/data mapping: the data dependencies of all your business decisions are directly traceable.

Instead I drew the diagram above, illustrating directly how the pillars of GDPR are supported by Decision Management. Sometimes a picture really does say a thousand words. But, if you are more interested in the thousand words, see below.

What is Decision Management

Decision management is a technique and technology stack that provides:

  • Transparency: renders business policy and operational decision logic transparent to business experts and analysts, for rapid improvement, by representing complex logic in standardized, easy to understand formats such as decision tables;
  • Business Orientation: makes operational business policies measurable and accountable to all stakeholders in terms of business performance indicators;
  • Agility: decision models are executable (but not code), supporting rapidly-evolving, model-driven definition of compliance needs;
  • Dependency Management: checks decision integrity and drives out all their data dependencies, confirming that decisions are used consistently and reliably and identifying all required data support;
  • Complexity Management: allows even the most complex decisions to be represented compactly without code.

As a result, it directly empowers any GDPR initiative by:

Understanding and Justifying Current Data Use

The GDPR Data Audit and Privacy Impact Assessment are directly supported by decision management, including ensuring you only process the data you really need and checking that this processing is lawful.

Decision management is a powerful technique for capturing, analysing and communicating, in detail, how a company’s operations depend on key data attributes and business knowledge. It’s much more effective at supporting a GDPR Information Audit or Privacy Impact Assessment than traditional techniques like process/data mapping because it helps you to identify and justify which data is needed, which is superfluous and the justification for both – even when data dependencies are hidden within white-box predicative analytics. Decision management and modeling keeps all stakeholders informed of the outcomes of this analysis.

Decision management also provides a formal background for assessing and labelling the sensitivity, criticality, accuracy, retention period, distribution constraints and timeliness needs for all data inputs as part of a GDPR PIA. It can document data sources and consent traceability.

Unlike paper process/data maps, decision models are executable. So the data dependencies they reveal always reflect what’s actually happening in your business systems.

Remediating Non-Compliance

Decision management is a powerful means of identifying, making and checking the data use changes mandated by GDPR.

Decision management also provides powerful impact analysis, so when non-compliant data use is discovered, or a subject requests restriction, the company can very quickly and accurately assess the scope and impact of the necessary changes to business operations. Because decision models are executable, these changes can also be rapidly deployed.

Servicing Customer (Subject) and Regulator Requests

Decision management and modeling can enpower requests for policy information, erasure or portability.

Decision management facilitates the transparent and open capture, representation and execution of complex logic: decision-making (both general policies and specific case histories), customer profiling logic (including analytics), consent acquisition, retention policies, deletion policies, distribution constraints, production of portable data and expression of EU state-specific rules and variations (e.g., how to treat minors). All of which allows stakeholders, regulators and subjects to have a clear view of the company’s policies and its behaviours with regard to a specific case. The latter is most relevant to article 22.

Testing and Maintaining Compliance

The open articulation of these business policies and the fact that decision management allows their effectiveness to be monitored also supports testing compliance and maintaining privacy. It allows for breach frequencies to be incorporated directly into an on-going measurement of the effectiveness of your approach.

Find out more about GDPR and Decision Modelling. Find out how we can help you with GDPR.

How GDPR Makes the Case for Decision Management

How GDPR Makes the Case for Decision Management

GDPR undoubtedly represents one of the most onerous regulatory mandates of the past decade—the first to explicitly demand an after-the-fact ability to explain your decision-making. So how can decision management help?


The General Data Protection Regulation (GDPR) will revolutionize the way in which most companies with partners or clients resident in the European Union source, verify, secure, use, retain and distribute their data. Further, it gives new rights to EU citizens that are the subjects of this data. The biggest revolution in data handling compliance since the original 1995 Data Protection Act (DPA), GDPR will force medium and large companies to appoint new, independent personnel charged with monitoring data processing, servicing the rights of data subjects and reporting breaches. It also sets record fines if these regulations are not followed. With a target implementation date in May 2018, many companies are concerned about their ability to meet this regulatory standard.

Crucially, GDPR will impose new obligations on companies that will require new levels of transparency in their decision-making, necessitating the increased use of techniques such as decision management and modeling. For example, under some circumstances, GDPR will make companies responsible for explaining their automated decision making when challenged by data subjects who are affected by the outcome. We examine these new obligations and describe how GDPR helps make the case for decision management.

What is GDPR?

GDPR is a new compliance mandate that will impact the majority of companies that store, move or process data from, or involving, a European company or involving subjects domiciled in the EU. A stronger replacement for the Data Protection Act of 1995, GDPR will be enforced from May 2018 and will have a wider territorial scope, more obligations, be better harmonized across Europe and will have the backing of every EU state. Most significantly, it will entail much more punishing fines for non-compliance: 20M Euro or 4% of annual turnover, whichever is the larger—such fines are enough to compromise some companies.

Many make the mistake of assuming GDPR only controls European companies, but this is far from the truth. GDPR has jurisdiction over corporations processing data in the EU. However it also encompasses any company handing the data of EU subjects (persons or companies) or supplying services or goods to the EU regardless of: where it is based, whether or not money changes hands and whether or not the data processing takes place in the EU.

GDPR has the power to ensure that:

  • companies acquire data with appropriate consent;
  • companies do not hold excessive, stale or inaccurate data;
  • they hold data only for lawful reasons;
  • they do not collect or distribute it without active consent of the subject;
  • they have more stringent security, processing and breach control/reporting protocols controlled by documented personnel within the company (the Data Protection Officer and the Information Security Manager); and
  • they uphold key rights of data subjects, including the right to have inaccurate data corrected, to prevent data being used for direct marketing without their active consent and the right to have their data erased (to be forgotten).

Although GDPR will only affect medium and large sized companies (normally those with 250 or more employees), it cannot be evaded by sub-contracting out these responsibilities to subsidiaries or business partners as the DPA could. Its central obligations must be provided in-house after an extensive information audit to assess the company’s information assets, regular privacy impact assessments to ensure data streams are being handled appropriately and a demonstration that the company has the right to hold and process the data it does. Companies will be responsible for checking and documenting the adequacy of data suppliers to meet these needs and ensuring the physical location, security and integrity of the data.

How Does Decision Management Support GDPR?

Decision Management is a means of bringing a company’s business policies and decision-making ‘into the light’, to make decisions an explicitly-managed, corporate asset. Specifically decision management:

  • identifies and prioritizes operational decisions and their impact on the business;
  • makes operational business policies transparent and accountable to all stakeholders by representing complex logic in easy to understand formats such as decision tables;
  • renders business policy and decision logic transparent to business experts and analysts for rapid innovation and improvement;
  • checks decision integrity and drives out all their data dependencies;
  • helps to explain, after the fact, why a decision generated a specific outcome and
  • confirms that they are used consistently and reliably.

Decision Modeling is a vital part of decision management, it gives us a standard means of representing business decisions—The Decision Model and Notation (DMN)—that is much easier to understand than code or ad-hoc spreadsheets, that is a safer representation for business policies than leaving them in the minds of subject matter experts and, most importantly, that is directly executable. This means that decision models can be tested and deployed without the need to develop decision-making code. DMN enables a viable, model-driven approach to decision-making and evolution, allowing you to convert decision models into automated, highly-efficient decision services without needing to go through the error-prone and time-consuming process of translating decisions into programs.

So how does this help with regulatory compliance mandates like GDPR?

Decision Transparency and Article 22

Article 22 of the GDPR demands that subjects (an individual about whom a company holds information) be safeguarded against potentially damaging decisions being made on their behalf, or concerning them, without the possibility of human intervention. Business operations that are fully automated and that have outcomes that could disadvantage a subject or ‘have a significant or legal effect on them’ (e.g., determining if someone is eligible for a mortgage or a credit card) must support the following entitlements:

  • The subject has a right to obtain an explanation of the decision and its consequences
  • The subject has the right to express a view on the decision
  • The subject has the right to challenge the decision and obtain rectification if there are sufficient grounds

These rights are only waived if: the decision was required for entering or remaining in a contract with the data subject (and therefore the decision-making and its consequences are spelled out in the contract); it is authorized by law; or it is based on explicit, active consent by the subject.

Furthermore Article 22 of the GDPR stipulates that in circumstances where it is acceptable to profile a subject (e.g., for the purposes of targeting goods and services, determining the best next action or cross-selling), such profiling must be transparent. Specifically: the profiling logic must be meaningfully described; the subject must be aware of the consequences; companies must be able to demonstrate that appropriate logical, mathematical or statistical approaches have been used and they must prove procedures are in place to spot inaccuracies or mistakes.

Decision modeling offers a powerful means of supporting all these rights because it offers the most effective means of documenting decision-making in a transparent, open-standard format currently available. This standard, DMN, allows even the most convoluted decision-making to be represented transparently using straightforward layouts free from jargon and code. Furthermore, many decision management systems provide an after-the-fact explanation of decision behaviour, giving a blow-by-blow account of how and why an outcome was determined and all the data used. This powerful combination allows data processors to explain their automated decision-making in easy to understand terms, using decision tables and other accessible representations to answer subject queries. It helps them meet their obligations while at the same time giving them a framework to improve their automated decision making. Event when opaque data analytics are used in decision-making, decision modeling can help in making outcomes transparent.

Being Explicit About Data Sources

GDPR insists that companies perform a one-off information audit and regular privacy impact assessments. Both require a thorough understanding of the exact source of all inbound data and why and how it is used to support business decision-making. Companies need to understand how their decisions depend on data—down to the level of individual fields. This helps them to ensure the real need for every field. They also need to know what implications this use has on the GDPR compliance of their operations and the data’s completeness, accuracy, latency and retention time requirements. This knowledge is essential for two reasons. Firstly, the degree of sensitivity of some data fields, currently classified into one of four levels, determines if and how the data may be used for a given application; the use of sensitive attributes is severely restricted. Secondly, the constraints on which data may be used may change with future versions of GDPR or with alterations in the purposes for which the data is used.

Decision modeling explicitly captures and justifies the dependencies that decision-making has on data and business knowledge. Furthermore, it can capture the source of every attribute of data used. Many companies use decision modeling precisely because it enables a quick and thorough audit of what data is required, its origin, how sensitive it is and why (and for how long) it is needed. Furthermore, many decision modeling tools can support queries on how specified fields are used across the enterprise and the big-picture impact of restricting or eliminating the use of specified data fields for compliance purposes.

The strict accountability enforced by a decision management environment is also vital for thorough and transparent information audits and the sensitivity classification of data attributes.

Ability to Support Decision Complexity and Rapid Change

Like any new compliance mandate, GDPR has many geographical and jurisdictional variations and uncertainties. A good example of this are the rights young people have regarding how their sensitive data is used under the regulation. Specifically, how age is used to classify minors and determine the degree to which they can personally give consent, as opposed to their guardians. The age boundaries used depend on the nation of jurisdiction. Also, the mechanics of parental consent in the current version of GDPR is recognized as draft and is likely to change post go-live. These factors mean that any automated support for GDPR must be capable of expressing these variations and accommodating change quickly and safely.

Decision modeling is an ideal means of documenting complex decisions because it scales effectively and it is expressly designed to support jurisdictional and other variations. Decision management technology stacks support the rapid evolution of regulatory logic through the transparency of decision models, provision of a collaborative environment with change impact assessment and the fact that models are directly executable. Further, the regression testing facility that many stacks provide ensures that regulatory updates can be performed quickly and without error. We refer to this combination as safe agility.



Many compliance directives benefit from decision management, but GDPR undoubtedly represents one of the most onerous regulatory mandates of the past decade—the first to explicitly demand an after-the-fact ability to explain your decision-making but certainly not be the last. If your company falls under the scope of GDPR, using decision modeling, deploying a decision technology stack and executing your automated decisions on a highly performant decision execution engine are vital requirements to success.

Overcoming the Challenges of Financial Decisions with DMN

Overcoming the Challenges of Financial Decisions with DMN

Join Lux Magi and business partner, Trisotech, to discover how Decision Management addresses the key risks of regulatory compliance. This webinar outlined the practical difficulties of supporting mandatory regulatory compliance in finance IT systems and described how a key technique of Business Decision Management—Decision Modelling—can overcome these challenges. The benefits of using the Decision Model and Notation (DMN) were also presented. (more…)

Decision Modeling: The Bottom Line

Decision Modeling: The Bottom Line

Why should organizations model their important business decisions as part of digital transformation? We’ve been asked so many times to explain how our clients have benefited from decision modeling that we decided to capture it here. This article covers seven reasons to adopt decision modeling and summarizes the bottom-line benefits decision modeling has brought to companies that use it effectively.