Direct Answer: DMN (Decision Model and Notation) is an OMG standard for modeling business decisions, supported natively in Sparx EA. Enterprise architects use DMN to document the decision logic that drives business processes: the rules that determine which path a process takes, which approvals are required, which exceptions apply. DMN complements BPMN and ArchiMate rather than overlapping with them: BPMN documents what the process does step by step, DMN documents the rules that govern the choices within it, and ArchiMate documents the capabilities and systems that execute both. Organizations that model processes without modeling decisions are leaving half the story out of their architecture.
Key Takeaways:
Understanding DMN starts with its core element types. These are the building blocks you will work with in both the Decision Requirements Diagram and Decision Tables.
The Decision is the central element: it represents an outcome to be determined. A Decision has a name (the question being answered, expressed as a noun phrase: “Loan Approval Status”, “Applicable Tax Rate”, “Eligibility Category”) and logic that produces that outcome. The logic is specified either as a Decision Table or as another supported expression type.
Decisions are the primary elements in a DRD. A complex decision is typically decomposed into sub-decisions, each of which contributes to the final determination.
Input Data elements represent the information that feeds into a decision. They are distinct from the decision itself: Input Data is what you know (customer credit score, application amount, document status); the Decision is what you determine from it (loan approval status).
In Sparx EA, Input Data elements have defined types: the type system is important for validating that decision table inputs are consistent with the data available in the process.
A Business Knowledge Model (BKM) is reusable decision logic: a named function or decision sub-table that can be invoked by multiple decisions. Where the same decision rules appear in different contexts, factor them into a BKM rather than duplicating the logic. In Sparx EA, BKMs appear in the DRD and are referenced by the decisions that use them.
A Knowledge Source is the authority or regulation that governs a decision or BKM: the policy document, regulatory requirement, or subject matter expert that the logic derives from. Knowledge Sources in the DRD are documentation elements: they show reviewers where the decision logic came from and who is accountable for it. For compliance-heavy domains, this traceability from rule to authority is architecturally significant.
The DRD is the DMN diagram that shows all of the above elements and the relationships between them: which Input Data feeds which Decisions, which BKMs are invoked by which Decisions, which Knowledge Sources authorize which Decisions or BKMs. The DRD gives reviewers a structural view of the decision landscape before they look at the detailed rules. For complex decisions with many sub-decisions and inputs, the DRD is essential for understanding scope.
The Decision Table is the workhorse of DMN: the tabular specification of decision rules. Each row in a decision table is a rule: given these input conditions, produce this output. Decision tables can cover dozens or hundreds of rules in a compact, reviewable format. They are more rigorous than narrative business rules because they have defined completeness and consistency checking semantics.
Sparx EA’s DMN implementation supports full decision table authoring with all standard hit policies and FEEL expression syntax.
Hit policy defines what happens when more than one rule in a decision table matches the input conditions. This is one of the most consequential decisions in decision table design.
For most business rule tables, Unique hit policy is the right choice: it forces analysts to be explicit about all cases and produces deterministic outcomes. Teams that default to First hit policy often do so to avoid the discipline of making rules non-overlapping, which leads to fragile tables where rule order encodes unstated logic.
FEEL is the expression language used in DMN decision tables. For simple cases: equality comparisons, range checks, string matches: FEEL is readable without specialized training: >= 700 (credit score at least 700), "approved", "pending" (status is approved or pending), [18..65] (age between 18 and 65 inclusive).
For more complex expressions: date arithmetic, list operations, function calls: FEEL has a full expression grammar that requires more familiarity. The name is aspirational: FEEL is friendly enough for simple cases and requires learning for complex ones.
Sparx EA’s decision table editor provides syntax guidance for FEEL expressions. Business analysts authoring simple decision tables do not need to learn FEEL in depth; technical architects defining complex BKMs will need to.
A decision table is complete if, for every possible combination of input values, at least one rule matches. A table with gaps: input combinations that no rule handles: produces undefined output, which in a production system means unpredictable behavior. Sparx EA supports completeness checking for decision tables, flagging gaps in coverage. For compliance-critical decisions, completeness is not optional.
The combination of DMN and BPMN in a single Sparx EA repository is more powerful than either language alone. BPMN without DMN documents process steps but leaves decision logic in narrative: imprecise and ungoverned. DMN without BPMN floats detached from the process context where decisions are invoked.
A BPMN task or gateway invokes a DMN decision. The pattern:
Both elements live in the same Sparx EA repository, cross-referenced. The BPMN diagram communicates to process stakeholders; the DMN decision table communicates to business rules analysts and compliance reviewers. Neither contains what the other needs to contain.
Do not embed decision logic in BPMN gateway labels. A gateway labeled “score > 700 AND employment_verified = TRUE” is cramming DMN content into BPMN notation. It makes the process diagram harder to read and it makes the decision logic ungoverned: no hit policy, no completeness checking, no traceability to the regulatory authority that defines the threshold. Extract that logic into a DMN decision table.
Recommended package structure:
Cross-references between Processes and Decisions at the element level (BPMN task ↔ DMN decision) are the analytical links that enable impact analysis: “Which processes are affected if this regulation changes?”
DMN decision tables have a structural property that makes them particularly AI-friendly: they are already tabular, typed, and rule-based. Unlike narrative text or loosely structured diagrams, decision tables map directly to structured data that AI tools can query and reason about.
Via EA GraphLink’s MCP interface, AI tools querying a Sparx EA repository with governed DMN content can answer:
These are governance and compliance queries that currently require a business analyst to manually navigate the model and compile a response. With EA GraphLink, they become direct queries against the repository.
Organizations in regulated industries: financial services, healthcare, government: use DMN in Sparx EA specifically because decision tables provide auditable documentation of business rules. When a regulator asks “what are your approval rules for this product category and what regulation governs them?”, a DMN DRD with decision tables and linked Knowledge Sources is a precise, complete answer. Narrative documentation is not.
AI-assisted querying of DMN content accelerates the preparation of compliance documentation and audit responses: but only if the DMN models are governed. Inconsistently modeled decisions with undocumented knowledge sources do not enable this capability.
Is DMN included in Sparx EA or does it require an add-on?
DMN is included natively in Sparx EA: no additional MDG profile or add-on is required. Decision Requirements Diagrams and Decision Tables are available as standard diagram types. The FEEL expression language is supported in the decision table editor. Sparx EA’s standard license includes DMN support.
What is the difference between DMN and BPMN?
BPMN (Business Process Model and Notation) models process flow: the sequence of activities, decisions, and events that produce a business outcome. DMN (Decision Model and Notation) models decision logic: the rules that determine the outcome of a specific decision point within a process. BPMN answers “what happens and in what order?”; DMN answers “what rules govern the choice at this point?” They are complementary: use BPMN for process flow, DMN for the decision tables that the process invokes.
What is a Decision Requirements Diagram (DRD)?
A DRD is the DMN diagram that shows the structure of a decision: which Input Data elements feed which Decisions, which Business Knowledge Models are invoked, and which Knowledge Sources authorize the logic. The DRD is the decision architecture map: it provides context before you look at individual decision tables. For complex decisions with multiple sub-decisions and many inputs, the DRD is essential for understanding scope and dependencies.
What hit policies are available in Sparx EA DMN decision tables?
Sparx EA supports all standard DMN hit policies: Unique (U), Any (A), First (F), Priority (P), Rule Order (R), and all Collect (C) variants including sum, min, max, and count aggregations. Hit policy is set at the decision table level and governs how the table handles multiple matching rules. For most business rule tables, Unique hit policy is recommended: it enforces mutually exclusive, collectively exhaustive rule coverage.
Can I validate a DMN decision table for completeness in Sparx EA?
Yes. Sparx EA’s DMN decision table editor supports completeness analysis: it can identify input combinations that are not covered by any rule in the table. For decision tables with a small number of discrete input values, this is a built-in capability. For tables with continuous value ranges, completeness analysis requires careful definition of value domains. Completeness checking is particularly important for compliance-critical decisions where undefined outputs represent regulatory risk.
How do I connect a BPMN task to a DMN decision in Sparx EA?
In Sparx EA, a BPMN task that invokes a DMN decision is linked to the corresponding DMN Decision element via a dependency relationship. The task element in the BPMN diagram and the Decision element in the DMN DRD are separate elements in the repository; the relationship between them is a cross-package link. This link is what enables impact analysis: querying which processes are affected if a decision table changes. The link type convention should be defined in your team’s modeling standards.
What is FEEL and do I need to learn it to use DMN in Sparx EA?
FEEL (Friendly Enough Expression Language) is the expression language used in DMN for specifying input conditions and output values in decision tables. For simple cases: equality tests, range comparisons, string values: FEEL is straightforward and business-analyst accessible. For complex expressions involving date arithmetic, list operations, or function calls, FEEL has a more demanding grammar. Most business analysts can create effective decision tables with basic FEEL literacy. Technical architects defining Business Knowledge Models with complex logic will need deeper FEEL knowledge.
Can EA GraphLink query DMN decision tables?
Yes. DMN decision tables are highly structured data in the Sparx EA repository: typed inputs, defined outputs, explicit rules. EA GraphLink exposes this structure via MCP, enabling AI tools to answer natural language questions about decision logic: what rules govern a specific decision, what inputs a decision requires, which decisions reference a specific regulation. For organizations with governed DMN repositories, this provides compliance documentation and governance query capability that previously required manual model navigation.
DMN is underused in most EA practices: not because it lacks value, but because teams have not integrated it with BPMN and ArchiMate in a way that makes the effort worthwhile. The payoff comes when decision logic is formally modeled, linked to process, and governed as part of the EA practice.
Amplify engages with your EA practice on multiple fronts: including the integration of DMN, BPMN, and ArchiMate into a coherent modeling approach that supports governance, compliance, and AI-ready repository intelligence.
Related framework pages:
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.