Justification (shared concept)
Definition
A justification articulates the reason or rationale for an initiative or business response. It connects the proposed action to strategic objectives, performance gaps, stakeholder needs, regulatory pressures, or other motivators. In structured business architecture, it supports traceability between intent and action.
1. JSON Schema Update: Initiative
Add the following to the Initiative schema:
"justification": { "type": "string", "description": "Explanation of why the initiative is required, referencing business drivers, strategic goals, capability gaps, stakeholder needs, or regulatory obligations." }
Suggested location:
Under top-level metadata (e.g., after objectives or alignmentToStrategy if present).
2. JSON Schema Update: StrategicResponseModel
Add the following to the Strategic Response Model schema:
Suggested location:
After triggerId or responseId, depending on schema structure.
3. Optional enhancements
To further standardise justifications across artefacts, you may wish to eventually:
Introduce a Justification artefact or sub-element (for reuse or linking)
Tag justifications with driver types (e.g. regulatory, strategic alignment, cost pressure)
Link justifications to structured benefits or KPIs in the Performance domain
Yes, absolutely — using the Strategic Response Model (SRM) trigger catalogue items as the initial set of driver types for justifications is both practical and conceptually aligned with the Orthogramic Metamodel.
✅ Why this makes sense:
SRM triggers already represent events, pressures, or stimuli that initiate change or adaptation.
Justifications often answer the question “Why are we responding?”, which directly corresponds to the trigger.
This approach ensures semantic consistency across the metamodel and enables automated traceability between justifications, responses, and outcomes.
Implementation suggestion
Step 1: Define a controlled vocabulary
Use your existing SRM trigger catalogue as an enumeration list of driverType values for justifications. For example:
"driverType": { "type": "string", "enum": [ "Regulatory change", "Customer demand shift", "Operational risk", "Technology obsolescence", "Performance shortfall", "Cost pressure", "Workforce change", "Stakeholder expectation", "Market opportunity" ], "description": "High-level driver category that provides the basis for the justification." }
You may also allow multiple driver types per justification using an array if needed.
Step 2: Embed in relevant artefacts
In Initiative schema:
"driverType": { "type": "string", "description": "Primary driver for this initiative, based on the SRM trigger catalogue." }, "justification": { "type": "string", "description": "Narrative explanation referencing this driver and the rationale for the initiative." }
In Strategic Response schema:
"triggerId": { "type": "string", "description": "Reference to the specific trigger prompting this response." }, "driverType": { "type": "string", "description": "Generalised driver category derived from the SRM trigger catalogue." }, "justification": { "type": "string", "description": "Explanation of why this response is necessary in light of the identified trigger." }
Optional enhancements
Create a DriverType reference artefact that maps each driver type to its definition, common use cases, and example triggers.
Enable filters or dashboards across initiatives and responses grouped by driver type.
Later, associate driver types with strategic priorities, enabling traceability from operational activities to enterprise goals.