Decision Model

Definition

A decision model is a business architecture artifact that captures a decision as a discrete, reusable object — separate from the process that triggers it and the system that may eventually execute it. Each entry in a decision model typically identifies the decision itself (e.g., "determine credit risk tier"), the business questions it answers, the inputs required to make it, the rules or logic applied, the output produced, and the role or capability accountable for the outcome. In business architecture, decision models are cross-mapped against capabilities, value streams, and information concepts, giving leadership a clear line of sight into where judgment is exercised across the enterprise. Decision models are deliberately technology- and implementation-agnostic. They do not prescribe whether a decision is made by a human underwriter, a rules engine, or a machine learning model — they describe the decision logic and governance independent of how it gets executed. This distinguishes a decision model from a decision tree, a business rules catalog, or a workflow diagram, all of which are downstream artifacts that may implement a decision once it has been architected. A decision model also has boundaries. It is not a data model, though it references data as decision inputs and outputs. It is not a process model, though decisions are typically triggered by and embedded in process steps or value stream stages. And it is not a governance charter, though it frequently feeds one by clarifying decision ownership and escalation paths.

Origin & Context

The concept has two intertwined roots. The Business Architecture Guild's BIZBOK Guide formalized decisions as a core business architecture building block, cross-mapped to capabilities and value streams to expose where and how judgment is exercised in delivering value. Separately, the Object Management Group published Decision Model and Notation (DMN) in 2015 as a companion standard to BPMN, giving practitioners a formal notation for decision tables and requirement diagrams used in rules automation and decisioning platforms.

Why It Matters

Business architects use decision models to expose inconsistent or duplicated decision logic scattered across business units — a common source of regulatory exposure in financial services and healthcare. CIOs and automation leads rely on decision models to identify which decisions are candidates for rules engines or AI-driven decisioning, and which require human judgment and escalation paths. Compliance and risk officers depend on decision models as an auditable record of how and why a business arrived at a determination, which is often required evidence in regulatory examinations. Getting decision modeling right shortens the path from strategy to automation and reduces the risk of inconsistent outcomes for similar customers or cases.

Common Misconceptions

Myth: A decision model is just a configuration of a business rules engine.

Reality: A decision model is a technology-agnostic architectural artifact created before any automation decision is made. It documents the business logic, ownership, and inputs/outputs of a decision independent of whether it will ever be automated. Rules engine configurations are one possible downstream implementation of a decision model, not the model itself.

Myth: Decision models only apply to automated or algorithmic decisions.

Reality: Decision models apply equally to decisions made by people — a loan committee, a clinical reviewer, a claims adjuster. Documenting these judgment-based decisions is often more valuable, since it exposes accountability gaps and inconsistent criteria that pure automation efforts overlook.

Myth: A decision model is the same thing as a decision tree or flowchart.

Reality: A decision tree or table is one notation used to express the logic inside a single decision. A business architecture decision model is broader — it includes a decision inventory across the enterprise, ownership assignments, links to the capabilities and value streams that depend on the decision, and the information required to make it.

Practical Example

A regional insurer's underwriting operations lead flagged inconsistent risk determinations across branch offices. The business architect facilitated a working session with underwriting managers and a data architect to build a decision inventory for the policy issuance value stream. They isolated "determine risk tier" as a distinct decision object, documenting its inputs (applicant history, property data, claims history), the business rules applied, the accountable role, and the capability it supported. Cross-mapping revealed that three regions applied materially different criteria for the same decision, despite using a shared policy system. The architecture team used the decision model to standardize the logic, clarify which parts warranted automation through a rules engine and which required underwriter judgment, and gave compliance a defensible, auditable record of how risk tiers were assigned going forward.

Industry Applications

Financial Services

Decision models document credit approval, fraud escalation, and account opening determinations, giving risk and compliance teams an auditable view of decision logic across lending channels.

Healthcare

Payers and providers use decision models to standardize prior authorization and clinical eligibility determinations, reducing inconsistent coverage decisions across regions and plans.

Insurance

Underwriting and claims decisions are modeled to separate business logic from policy administration systems, enabling insurers to modernize core systems without losing decision governance.

Related Terms

• Value Stream Map: Decisions are embedded as stages or triggers within value stream flows