Skip to content

Step 10- Strategic Domain Design (SDD)

Purpose

Produce a Strategic Domain Design (SDD) that integrates all Stage 3 business artifacts into a single, coherent view of how the business operates for a specific initiative.

This step exists to describe the business domain at a strategic level — including departments, functional groups, workflows, roles, artifacts, lifecycles, and strategic business rules — without introducing any technical design or implementation detail.

The SDD is the final business-facing output of Stage 3 and the primary input to Stage 4 (Tactical Domain Design).

When To Run This Step

This step is executed by a person after all prerequisite Stage 3 artifacts are complete and validated.

Run this step when:

  • An approved Project Initiative Package (PIP) exists
  • A Product Requirements Document (PRD) has been completed for the selected Outcome
  • A Business Workflow Specification (BWS) has been completed and validated
  • A Domain Parts List (DPL) has been extracted and approved
  • The business domain is ready to be consolidated into a single strategic view

This step must not run if:

  • Any of the PIP, PRD, BWS, or DPL is missing or incomplete
  • Business workflows or requirements are still changing
  • The team is attempting to design systems, data models, or technical architecture

Inputs (Required)

  • Approved Project Initiative Package (PIP)
  • Approved Product Requirements Document (PRD)
  • Approved Business Workflow Specification (BWS)
  • Approved Domain Parts List (DPL)

Prompt to Run

  • Prompt Name: Strategic Domain Design (SDD) Generator
  • Prompt Version: v1.0
  • Prompt Location: SDD Generator

Instruction: Run the SDD prompt using the PIP, PRD, BWS, and DPL as inputs.

Integrate all business information into the SDD YAML structure. Describe business ownership, workflows, artifacts, lifecycles, and rules only. Do not include technical design or system behavior.

Outputs (Produced)

The step produces a Strategic Domain Design (SDD) YAML specification that documents:

  • Organizational structure (Departments and Functional Groups)
  • Business workflows and their triggers, steps, and outcomes
  • Roles and responsibilities
  • Business artifacts and their lifecycles
  • Case lifecycle stages and transitions
  • Strategic business rules governing operations

The output must strictly follow the SDD YAML template.

Artifact Storage

Store the SDD in the predefined system of record selected during setup.

  • One SDD per initiative
  • One primary storage location only
  • The artifact must be referenceable
  • Ownership must be clear

Validation Rules

The SDD is valid only if:

  • All content is derived from the PIP, PRD, BWS, and DPL
  • The document remains strictly business-facing
  • No technical design, schemas, APIs, or implementation details are included
  • Organizational ownership and responsibilities are explicit
  • Workflows, artifacts, and lifecycles are internally consistent
  • Missing information is explicitly marked as TBD

The SDD is invalid if it:

  • Introduces technical architecture or system behavior
  • Invents new business concepts not present in source artifacts
  • Reinterprets or expands the approved business intent
  • Blends multiple initiatives into a single domain view

Invalid SDDs must be corrected before proceeding.

Decision Gate

Question: Is the business domain fully and coherently defined at a strategic level for this initiative?

Outcomes:

  • Yes: Proceed to Stage 4 — Tactical Domain Design (TDD)
  • No: Resolve gaps or inconsistencies and update the SDD

No other outcomes are allowed.

Failure Modes & Anti-Patterns

  • Treating the SDD as a technical design document
  • Introducing schemas, services, APIs, or system interactions
  • Inconsistent terminology across workflows and artifacts
  • Missing or unclear ownership of business responsibilities
  • Allowing solution or implementation thinking to leak in

If this step is polluted with technical detail, Stage 4 will be compromised.

Traceability

  • Previous: Stage 3 — Domain Parts List (DPL)
  • Next: Stage 4 — Tactical Domain Design (TDD)
  • Consumes: PIP, PRD, BWS, DPL
  • Produces: Strategic Domain Design (SDD)

Status

  • Maturity: Stable
  • Enforced by Tooling: Planned