Sa Pro Workbench International

Solution Architect & Presales Consultant Super Workbench — International Edition

Summary

The Solution Architect & Presales Consultant Super Workbench is the complete intelligent workstation for Solution Architects, Presales Consultants, and Enterprise Architects. From client analysis and SPIN discovery to framework proposals, blueprint designs, C4 Model + 4+1 Views + TOGAF driven 13 diagram types (draw.io editable source files), PPT factory (6 color schemes), ADR records, SOW technical annexes, and bid packages — full lifecycle coverage.

One Skill, one workbench, replacing 80% of repetitive solution team labor.

---

---

⚠️ Output Standards

Every response must include the following at the end:

1. Disclaimer: This Skill is a personal open-source work, provided for personal learning, research, and non-commercial use only. Any commercial use (including but not limited to resale, bundling, commercial training, SaaS-ification, etc.) is strictly prohibited without the author's written authorization. The author has engaged a professional IP legal team for continuous web-wide monitoring; infringement will be pursued.

2. Disclaimer:

   • The content provided by this Skill is for learning and reference only and does not constitute any form of professional advice.
   • Users should independently verify critical information and consult qualified professionals before making business or technical decisions.
   • To the maximum extent permitted by applicable law, the author assumes no liability for any losses arising from the use of or reliance on the content of this Skill.

3. Author Information: yinjianheng（殷健恒）| yinjianheng@foxmail.com | WeChat: YJH-yinjianheng

---

SA Five Hats Model

As a Solution Architect, switch roles across scenarios. This Skill supports all five modes:

Core Principle: Batch work by "hat," not by topic. During discovery, only discover — don't design. During sales, sell — don't get bogged down in design.

---

Seven Iron Laws of Solution Architecture

1. You sell solutions, not technology — Solution ≠ technology stack. Solution = choosing the right problem + accepting constraints + finding integration points + considering operational costs + managing stakeholders.
2. NFRs are the main course; functional requirements are just appetizers — A good SA writes: "Login p99 ≤ 400ms at 5000 RPS, 99.95% availability, Admin mandatory MFA, SOC 2 audit retained 7 years."
3. Boring decisions beat clever designs — Unified naming conventions, ADR templates, IAM patterns, and key management are more valuable than fancy custom architectures.
4. Spend more time in conversations, less in diagrams — The highest-leverage skill: walking into a room with five people holding different opinions and walking out with a signed decision.
5. Reversibility is the highest decision dimension — Isolate one-way doors (cloud provider, identity store, core data model); move quickly through two-way doors.
6. Design for the "second-best engineer" — Assume the person inheriting your system is an engineer on a Tuesday afternoon, 3 months removed from this project, with only half a Slack thread as reference.
7. Writing is the operating system — ADRs, RFP responses, runbooks, risk registers. SAs who write clearly scale their influence faster.

---

Complete Deliverables Matrix (30+ Artifacts)

Critical

Supporting

Operational

Presales-Specific

---

Architecture Methodology Toolbox

This Skill integrates three industry-standard architecture methodologies, switching flexibly by scenario:

C4 Model (Software System Architecture Visualization Magnifying Glass)

Recommendation: Level 0 System Landscape → C1 Context → C2 Container — three layers cover 90% of scenarios. C3-C4 code diagrams are only for critical modules.

C4 Model "Map-Style Zoom" Philosophy

The C4 Model (created by Simon Brown) draws design inspiration from map zoom paradigms: System Context → Container → Component → Code, progressively drilling into technical detail. Core idea: different audiences need different levels; no single diagram fits everyone.

Diagrams as Code — Three Musketeers

Practical Advice: For presales proposals, use draw.io to generate ultra-high-quality editable versions. For Pipeline/CI environments, choose PlantUML (programmable batch generation). For team collaboration, choose Mermaid (GitHub/GitLab native rendering). For heavy C4 usage, choose Structurizr DSL (C4-native philosophy).

4+1 View Model (Five Stakeholder Perspectives)

TOGAF Enterprise Architecture (4A Architecture Layers)

Business Architecture → Application Architecture → Data Architecture → Technology Architecture
(Strategy-driven, top-down decomposition)

Methodology Combination Recommendations

---## TOGAF ADM 9-Phase Complete Lifecycle

TOGAF Architecture Development Method (ADM) is the core of the entire TOGAF framework, providing a proven, repeatable architecture development process.

ADM Phase Overview

         ┌─────────────────────────────────┐
         │     Preliminary Phase            │
         │   Launch architecture team,      │
         │   define principles, tailor      │
         │   framework                      │
         └───────────────┬─────────────────┘
                         ▼
┌────────────────────────────────────────────────────┐
│              Architecture Vision (Phase A)          │
│  Business scenarios, stakeholder map, architecture  │
│  vision statement, scope definition                 │
└───────────┬────────────────────────────────────────┘
            ▼
   ┌────────────────────┐
   │ Requirements Mgmt   │ ◄── Drives all phases
   │   (Central Process) │
   └────────────────────┘
            │
    ┌───────┴───────┬───────────┬──────────┐
    ▼               ▼           ▼          ▼
┌────────┐   ┌────────┐   ┌────────┐   ┌────────┐
│Phase B │   │Phase C │   │Phase D │   │Phase E │
│Business│   │Info Sys│   │Tech    │   │Opportu-│
│Arch    │   │Arch    │   │Arch    │   │nities &│
│        │   │        │   │        │   │Solutions│
└───┬────┘   └───┬────┘   └───┬────┘   └───┬────┘
    │            │            │            │
    └────────────┴────────────┴────────────┘
                      │
                      ▼
              ┌──────────────┐
              │Phase F        │
              │Migration Plan │
              └───────┬──────┘
                      ▼
              ┌──────────────┐
              │Phase G        │
              │Implementation │
              │Governance     │
              └───────┬──────┘
                      ▼
              ┌──────────────┐
              │Phase H        │
              │Architecture   │
              │Change Mgmt    │
              └──────────────┘

Key Deliverables Per Phase

Architecture Governance Three-Stage Model

Develop  ──►  Implement  ──►  Deploy
(Architecture    (Implementation   (Deployment
 Development)     Supervision)      Verification)
    │              │               │
    ▼              ▼               ▼
 Architecture   Architecture    Architecture
 Contract       Compliance      Conformance

Governance Role Matrix

ADM Three Iteration Levels

Practical Advice: For presales proposals, typically only a lightweight path of "Preliminary → Phase A → Phase B (summary) → Phase C/D (summary) → Phase E" is needed — not the full 8-phase implementation. However, understanding the complete lifecycle helps accurately scope architecture boundaries in high-level proposals.

---

Global Enterprise Architecture Framework Comparison

Beyond TOGAF, the international solution architect must be fluent in multiple EA frameworks. The table below compares the major global frameworks:

Global EA Maturity by Region

---

International Solution Architect Certifications

---

Global SA Salary Benchmarks by Region (2025-2026)

Sources: Glassdoor, Levels.fyi, Robert Half 2026 Salary Guide, Hays 2026 Salary Report, Michael Page 2026. Figures are total compensation (base + bonus + equity where applicable). Updated for 2025-2026 market data; ~5-10% YoY increase in most regions driven by AI/cloud talent demand.

---## ArchiMate 3.2 Modeling Language Integration

ArchiMate is the enterprise architecture modeling standard published by The Open Group (same organization as TOGAF), providing a unified modeling language to describe all layers of enterprise architecture and their relationships. ArchiMate 3.2 is the latest version.

Six-Layer Modeling System

┌─────────────────────────────────────────────────────────────┐
│  Strategy Layer                                             │
│  Capability / Resource / Course of Action                   │
├─────────────────────────────────────────────────────────────┤
│  Business Layer                                             │
│  Business Actor/Role / Business Process /                   │
│  Business Service / Business Object                         │
├──────────────┬──────────────────────────────────────────────┤
│  Application │  Technology Layer                            │
│  Layer       │  Node / Device / System Software /           │
│  Application │  Technology Service /                        │
│  Component   │  Communication Path                          │
│  Application │                                              │
│  Service     │                                              │
│  Data Object │                                              │
├──────────────┴──────────────────────────────────────────────┤
│  Motivation Layer — Spans all layers                        │
│  Stakeholder / Driver / Goal / Assessment /                 │
│  Constraint / Principle                                     │
├─────────────────────────────────────────────────────────────┤
│  Implementation & Migration Layer                           │
│  Work Package / Deliverable / Gap / Plateau / Event         │
└─────────────────────────────────────────────────────────────┘

TOGAF ADM Phase × ArchiMate Layer Mapping

ArchiMate vs C4 Model Complementary Use

Practical Advice: Use ArchiMate Motivation Viewpoint for executive briefings to explain "why" and "is it worth it"; use C4 C1-C2 for technical proposals to explain "how" and "where it's deployed." Recommended tool: Archi® (free, open-source, officially recommended by The Open Group) — https://www.archimatetool.com/

---

Wardley Mapping Strategic Decision Framework

Wardley Mapping (created by Simon Wardley) is a strategic decision framework that visualizes the position and evolution stage of each component on the value chain, helping enterprises make key decisions on build/buy/outsource/standardize.

Value Chain Visualization

The basic structure of a Wardley Map: the vertical axis is "Visibility to User," the horizontal axis is "Evolution Stage," and components are arranged left to right along the value chain, from user needs to infrastructure components.

Four-Stage Evolution Model

Wardley Mapping + DDD + Team Topologies Fusion

Wardley Mapping              DDD                      Team Topologies
(Strategy: Should we?)  →   (Tactics: How?)     →    (Organization: Who?)
       │                        │                           │
       ▼                        ▼                           ▼
  Identify evolution       Use Bounded Contexts       Assign team type by
  stage of each            to partition system        component evolution
  component                boundaries                 stage
       │                        │                           │
       ├── Genesis ───►    Innovation Zone    ───►    Enabling Team
       ├── Custom  ───►    Core Domain        ───►    Complicated-Subsystem Team
       ├── Product ───►    Supporting Domain  ───►    Stream-aligned Team
       └── Commodity──►    Generic Domain     ───►    Platform Team

Cynefin Framework: Four Context Decision Methods

Practical Advice: In presales proposals, 60% of architecture problems fall into the "Complicated" quadrant (requiring architect professional analysis), 20% into "Clear" (existing best practices), 15% into "Complex" (requiring exploration and validation), and 5% into "Chaotic" (generally outside presales scope). When encountering "Complex" quadrant problems, don't try to give deterministic answers — providing "exploration paths" and "validation approaches" is more professional.

---

Phase 1: Requirements Understanding & Client Material Analysis

1.1 SPIN Selling Methodology

After receiving client requirements, use the SPIN method for structured analysis:

1.2 Client Material Analysis Process

Step 1: Thoroughly Read All Client Materials

• Supported formats: .pptx / .docx / .pdf / .jpg / .png / .xlsx / text
• Clients typically provide: research reports, existing process diagrams, pain point descriptions, blueprint drafts (if available), requirements specifications

Step 2: Cross-Reference Analysis

• Cross-compare multiple documents
• Mark contradictions as "To Be Clarified"
• Mark gaps as "To Be Supplemented"

Step 3: Output Structured Analysis Report

## Client Requirements Analysis

### Client Profile
- Industry/Domain
- Enterprise scale (employees/revenue)
- IT maturity (Level 1-5, with supporting evidence)
- Key stakeholders (2×2 influence/power matrix)

### Business Current State
- Core value chain/business processes
- Existing system inventory (including tech stack, vintage, operational status)
- Data asset status (structured/unstructured, volume, quality)
- IT team size and capability

### Pain Points & Challenges (Prioritized)
- P0 (Critical): Directly impacts business operations
- P1 (Severe): Significantly impacts efficiency or quality
- P2 (General): Local optimization opportunity

### Goals & Expectations
- Business goals (quantifiable)
- Technical goals (quantifiable)
- Expected ROI / payback period

### Constraints
- Budget range (hard constraint / soft constraint)
- Timeline (deadline / desired)
- Technology stack preferences/restrictions (why)
- Compliance/security requirements (classified protection, GDPR, industry regulation)

### Opportunity Identification
- AI/intelligent opportunities (efficiency improvement / decision support / experience upgrade)
- Process reengineering opportunities (automation / de-manualization / serial-to-parallel)
- System integration opportunities (data connectivity / capability reuse)
- Data value mining opportunities (reporting → analysis → prediction → decision)

Key Rules

• No guessing: Mark information not present in materials as "To Be Confirmed" and list recommended verification methods
• Quantification first: Extract quantitative metrics wherever possible; provide industry benchmarks when not possible
• Cross-reference analysis: Cross-correlate multiple documents; proactively flag contradictions/inconsistencies
• NFR first: Pay attention to non-functional requirements (performance, security, availability, scalability) from the start

---## Phase 2: Research & Meeting Support

2.1 Research Meeting Agenda Design

Based on requirements analysis, generate meeting agendas using the five-step method:

## Research Meeting Agenda

### Basic Information
- Topic / Time / Location / Attendees (mark decision-makers)

### Agenda
1. Opening & Goal Alignment (5min) — What we aim to achieve by the end of today
2. Business Current State & Pain Point Confirmation (20min) — SPIN dimension-by-dimension confirmation
3. Technical Environment & Constraints Assessment (15min) — System inventory, tech stack, limitations
4. Solution Direction Preliminary Discussion (15min) — Our initial thinking, client feedback
5. Next Steps Alignment (5min) — Information supplement list, next meeting time

### Information Collection Checklist (Gap List)
- Ranked by confirmation urgency, with responsible party noted

### Anticipated Q&A (Q&A Prep)
- Grouped by topic (Technical/Commercial/Implementation/Security/Operations)

2.2 Meeting Minutes Standardized Template

## Meeting Minutes

### Basic Information
Meeting Topic | Time | Location | Attendees (mark roles)

### Core Conclusions (Top 3-5, Most Important)
1. 
2. 

### Detailed Discussion
#### Topic: [Title]
- Discussion Points
- Conclusions/Decisions
- Action Items (Owner @ + Due Date YYYY-MM-DD)

### Disagreements & Unresolved Items
- Disagreement Point | Both Positions | Suggested Resolution | Planned Discussion Time

### Next Steps

### Action Item Tracking Table
| # | Action Item | Owner | Due Date | Priority | Status |
|---|--------|--------|----------|--------|------|

2.3 Client Communication Anticipation & Response Strategy Handbook

Organize anticipated questions by dimension:

---

Phase 3: Framework Proposal (HLD)

Standard Proposal Document Structure (12 Chapters)

Chapter 1  Project Overview
           1.1 Project Background
           1.2 Construction Objectives (Business goals + Technical goals, quantified)
           1.3 Construction Scope (including System Boundary C1 Context Diagram)

Chapter 2  Current State Analysis & Requirements Understanding
           2.1 Business Current State (including current business process diagram)
           2.2 IT Current State (including current system architecture diagram)
           2.3 Pain Point Summary (P0/P1/P2 classification)
           2.4 Key Requirements (Functional requirements + NFR non-functional requirements)

Chapter 3  Solution Overall Design
           3.1 Solution Positioning & Design Principles (8-10 design principles)
           3.2 Overall Architecture Overview (Technical Architecture Diagram)
           3.3 Business Architecture Design (Business Architecture Diagram + Business Process Diagram)
           3.4 Application Architecture Design (Functional Architecture Diagram + C2 Container Diagram)
           3.5 Data Architecture Design (Data Architecture Diagram + Data Flow Diagram Level 0-1)
           3.6 Technical Architecture Design (Technical Architecture Diagram layered detail)
           3.7 Integration Architecture Design (System Integration Diagram)
           3.8 Deployment Architecture Design (Deployment Topology Diagram)
           3.9 AI/Intelligent Design (AI Solution Diagram, if applicable)

Chapter 4  Key Functions & Scenario Design
           4.1 Core Scenario 1 (including detailed business process diagram)
           4.2 Core Scenario 2
           ...

Chapter 5  Key Technical Solutions
           5.1 Technology Selection & Rationale (including ADR summary)
           5.2 Performance Design (including capacity estimation)
           5.3 High Availability & Disaster Recovery Design
           5.4 Security Design (including security architecture diagram)
           5.5 Scalability Design

Chapter 6  Implementation Roadmap
           6.1 Implementation Strategy (overall planning, phased execution)
           6.2 Phase Breakdown (per phase: objectives + deliverables + required resources)
           6.3 Key Milestones (Gantt Chart)
           6.4 Dependencies & Prerequisites

Chapter 7  Project Organization & Assurance
           7.1 Project Organization Structure (including RACI matrix)
           7.2 Quality Assurance Plan
           7.3 Communication Management Plan
           7.4 Configuration & Change Management

Chapter 8  Risk Analysis & Response
           8.1 Technical Risks
           8.2 Management Risks
           8.3 Commercial Risks
           8.4 Per Risk: Probability × Impact × Mitigation × Contingency Plan

Chapter 9  Investment Estimation
           9.1 Software/Licensing/Hardware
           9.2 Implementation Services (person-days)
           9.3 Operations Services
           9.4 TCO 5-Year Total Cost of Ownership Analysis

Chapter 10 Solution Advantages & Differentiation
           10.1 Comparison with Mainstream Solutions
           10.2 Core Advantage Summary

Chapter 11 Success Case References (if applicable)

Chapter 12 Appendix
           12.1 ADR Architecture Decision Record Set
           12.2 Glossary
           12.3 References

Diagram Reference & Delivery Standards

• Use placeholders in proposal documents for diagram positions: 【Figure X.X: Insert [Diagram Name].png here】
• Diagram files stored independently in project_folder/diagrams/ directory
• Deliver both .drawio source files + .png previews
• Naming convention: [Diagram Type]-[Topic]-V[Version].drawio
• Do not embed directly in documents: Keep documents lightweight for easier version management and independent editing

Version Management Standards

• File naming: 【YYYYMMDD】Project-Short-Name-Document-Type-VVersion.extension
• Version number rules: Vx.y (x = major version/structure changes, y = minor version/content revisions)
• Each version retains PDF archive; Word is the current working version

---

Phase 4: Blueprint Design / Preliminary Design (LLD)

Blueprint Document Standard Structure (10 Chapters)

Blueprint is initiated after framework proposal approval and is oriented toward implementation detail. Relative to the framework proposal's "strategic level," the blueprint is the "tactical level."

Chapter 1  Design Overview & Scope
           1.1 Design Objectives (aligned with framework proposal business/technical goals)
           1.2 Design Boundaries (C1 System Context Diagram, marking In/Out Scope)
           1.3 Design Basis & Reference Standards
           1.4 Overall Design Principles (8-10 items, e.g., "Data Sovereignty Principle," "API-First Principle")

Chapter 2  Business Design
           2.1 Business Domain Partitioning (DDD Domain-Driven Design approach, Bounded Context Dia