Here is the consolidated master guide on how to use the 12-Phase Traceability Matrix covering MDST (Maturity, Discovery, Solution, and Transformation) model to deconstruct and solve any enterprise architecture challenge.
| Phase | Architectural Layer | The Deliverable / Artifact |
|---|---|---|
|
Maturity has vision and scope boundaries
|
||
| 1 | Vision (The 'Why') | Strategic KPI |
| 2 | Pre-Discovery | Process Taxonomy (L1-L3) & Scope Matrix |
|
Vision, and Pre-discovery leads to discovery
|
||
| 3 | Discovery (The 'As-Is') | Pain Point |
| 4 | Business Intent (The 'To-Be') | Future State |
| 5 | Gap Analysis (The Delta) | Identified Gap |
|
Gap analysis drives solution; process, systems, and data
|
||
| 6 | Solutioning (The Concept) | Process Architecture and Configurations |
| 7 | Systems (The Landscape) | Infrastructure |
| 8 | Data (The Info Arch) | Data Model and Development |
|
Solution enables the transformation
|
||
| 9 | Integration (The Connective Tissue) | System Interfaces |
| 10 | Development (The Build) | Technical Specs |
| 11 | UAT | Business Validation Script |
| 12 | Governance (The Guardrails) | Rules & Maintenance |
| RTM Hierarchy (The Architecture View) | Agile/Jira Issue Type (The Delivery View) | Purpose & RLM Example |
|---|---|---|
| L1: Value Stream | Initiative | The massive, end-to-end lifecycle. Example: Quote-to-Cash (QTC). |
| L2: Process Area | Component / Theme | The major buckets within the Value Stream. Used for reporting and filtering in Jira. |
| L3: Specific Process (Process Catalog) | Epic | The actual task to be accomplished. This is the business capability boundary. It groups the commercial threads. |
| L4: The Commercial Thread (Pre-Gap Steering) | User Story | This is the "Transaction-Based" narrative. It defines how the L3 capability is executed across the RLM platform for a specific scenario. |
| L5: Architectural Gap / Risk | Acceptance Criteria (DoD) | The rules that prove the User Story survives the transaction. |
| L6: Technical Build Task | Sub-Task | The specific administrative actions assigned to developers to satisfy the story. |
The true power of this framework is that it forces a chronological sequence. It prevents developers from writing code before the data model is secure, and it prevents business stakeholders from demanding features that do not align with their strategic KPIs.
Stop the scope creep before it starts.
Phase 1: Vision (The 'Why')
The Goal: Define the single Strategic KPI that determines project success.
The Architect's Move: If a requirement does not directly improve this KPI, politely reject it or push it to Phase 2.
Phase 2: Pre-Discovery
The Goal: Establish the Process Taxonomy (Level 1 to Level 3).
The Architect's Move: Use the "Straw Man" approach. Present a predefined list of in-scope processes to the executive steering committee and force them to explicitly agree on the boundaries.
Find the root cause of the business pain.
Phase 3: Discovery (The 'As-Is')
The Goal: Document the current Pain Point.
The Architect's Move: Never trust what a user says; trust what they click. Make the Subject Matter Expert (SME) share their screen and demonstrate the broken process live.
Phase 4: Business Intent (The 'To-Be')
The Goal: Define the Future State in plain English, completely independent of technology.
The Architect's Move: Use "What If" nudges (e.g., "What if the system just did this for you?") to guide the SME toward standard Salesforce capabilities without using technical jargon.
Phase 5: Gap Analysis (The Delta)
The Goal: Break the Identified Gap into Process, System, and Data deficits.
The Architect's Move: This is the pivot point. If you only identify a System Gap but ignore the Process Gap, your technical solution will fail upon user adoption.
Design the Salesforce architecture to bridge the gaps.
Phase 6: Solutioning (The Concept)
The Goal: Define the Process Architecture and Configurations.
The Architect's Move: Determine your architectural pivot. Are you forking the data at the Order object? Are you shifting calculations to an OmniStudio Pricing Procedure?
Phase 7: Systems (The Landscape)
The Goal: Identify the required Infrastructure and managed packages.
The Architect's Move: Call out the specific clouds and licenses required (e.g., Revenue Cloud Advanced, Salesforce Billing, Experience Cloud).
Phase 8: Data (The Info Arch)
The Goal: Map the Data Model and Development.
The Architect's Move: Define the specific custom objects, required standard objects, and the relational mapping (e.g., Master-Detail vs. Lookup) that will support the logic.
Build, test, and protect the investment.
Phase 9: Integration (The Connective Tissue)
The Goal: Define the System Interfaces.
The Architect's Move: Identify inbound and outbound data flows, batch schedules, API types, and error-handling fallbacks for external systems (like an ERP).
Phase 10: Development (The Build)
The Goal: Write the Technical Specs (Declarative vs. Programmatic).
The Architect's Move: Hand the Tech Lead the "What" and the "Why" through perfectly structured Jira tickets (Given/When/Then formats). Ensure declarative tools (Flows, OmniStudio) are prioritized over custom code (Apex).
Phase 11: UAT (User Acceptance Testing)
The Goal: Execute the Business Validation Script.
The Architect's Move: Do not hand the business a blank sandbox. Give them a strict, step-by-step testing script mapped directly to the original Phase 4 Business Intent.
Phase 12: Governance (The Guardrails)
The Goal: Establish Rules & Maintenance to prevent regression.
The Architect's Move: Implement technical locks (like Advanced Approvals or Validation Rules) and process audits (Center of Excellence reviews) to ensure users cannot bypass the new architecture.