| name | sa-pro-workbench-international |
| version | 1.2.0-intl |
| language | en-US |
| description | 【Solution Architect & Presales Consultant Super Workbench — International Edition】 — Full-stack automation for Solution Architects, Presales Consultants, and Enterprise Architects worldwide. One Skill, replacing 80% of repetitive solution team labor. |
| author | yinjianheng（殷健恒） |
| contact | email: yinjianheng@foxmail.com / wechat: YJH-yinjianheng |
| license | Free and open-source, for personal use only. See Copyright Notice section for full terms. |
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:
-
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.
-
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.
-
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:
| Hat | Mode | Time Scale | Core Outputs |
|---|
| Discoverer | Curious, listening, slow | Days | Interview notes, context map, problem statement |
| Designer | Deep, abstract, system-level | Days-Weeks | Architecture outline, C4 diagrams, ADR records |
| Negotiator | Diplomatic, fast, decisive | Hours-Days | Decision log, stakeholder alignment, scope clarification |
| Salesperson | Confident, narrative, value-driven | Days-Weeks | Solution PPT, RFP response, executive briefing |
| Operator | Pragmatic, hands-on | Ongoing | Runbook, governance gates, delivery escalation |
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
- You sell solutions, not technology — Solution ≠ technology stack. Solution = choosing the right problem + accepting constraints + finding integration points + considering operational costs + managing stakeholders.
- 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."
- Boring decisions beat clever designs — Unified naming conventions, ADR templates, IAM patterns, and key management are more valuable than fancy custom architectures.
- 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.
- Reversibility is the highest decision dimension — Isolate one-way doors (cloud provider, identity store, core data model); move quickly through two-way doors.
- 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.
- 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
| Deliverable | Purpose | Phase | Update Cadence |
|---|
| Discovery Brief / Problem Statement | Align goals, constraints, success criteria | Discovery | On scope change |
| High-Level Architecture Design (HLD) | Define architecture, core components, major trade-offs | Solution | Per milestone |
| Detailed Architecture Design (LLD) | Detailed component behavior, interfaces, configuration | Delivery | On change request |
| Architecture Decision Record (ADR) | Record decisions, options, rationale, consequences | Solution/Delivery | Per key decision |
| Threat Model | Identify attack surface, mitigations | Solution | On major change |
| Solution Documentation | Complete solution narrative | Solution | Milestone updates |
Supporting
| Deliverable | Purpose |
|---|
| Stakeholder Map + RACI Matrix | Identify decision-makers, approvers, contributors |
| Requirements Document (Functional + NFR) | Capture mandatory behaviors and NFR targets |
| Current-State Architecture / Context Diagram | Document baseline systems, integration points, pain points |
| Target-State Vision / Roadmap | Describe end-state architecture and migration path |
| Data Model (Conceptual / Logical) | Define entities, relationships, ownership, retention |
| API Contract / Interface Specification | Lock down integration contracts |
| Capacity Estimation + Scaling Strategy | Validate workload assumptions |
| Cost Estimation / TCO Model | Provide forecast cost drivers |
Operational
| Deliverable | Purpose |
|---|
| SLI/SLO Definitions | Set measurable reliability targets |
| Runbook / Operations Manual | Steps for common operational scenarios |
| Incident Response Plan | Define severity levels, escalation paths |
| DR/BCP Plan | Define RTO/RPO, failover procedures |
| Observability Plan | Logs/Metrics/Tracing dashboards |
| Handover/Knowledge Transfer Package | Empower operations and support teams |
Presales-Specific
| Deliverable | Key Content |
|---|
| Solution Plan | Client background, opportunity context, challenges & goals, solution summary, risk mitigation, architecture design, value timeline, resource plan |
| RFP/RFI Response | Scoring index, business/technical clause line-by-line response, original document preparation |
| PoC Proposal | Success criteria, test scope, validation objectives |
| Bid Package | Commercial bid, technical bid, pricing list |
Architecture Methodology Toolbox
This Skill integrates three industry-standard architecture methodologies, switching flexibly by scenario:
C4 Model (Software System Architecture Visualization Magnifying Glass)
| Level | Name | Answers the Question | Audience |
|---|
| C1 | System Context Diagram | What is the system? Who uses it? What external systems does it connect to? | Everyone (including non-technical) |
| C2 | Container Diagram | What technical services/apps/databases compose the system? | Dev, Ops, Architects |
| C3 | Component Diagram | What modules exist inside each container? | Internal developers |
| C4 | Code Diagram (optional) | How are classes and interfaces organized? | Code review, refactoring |
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.
| Level | Audience | Question | Zoom Analogy |
|---|
| C1 System Context | Everyone (including non-technical) | What is the system? What external systems connect? | Country view |
| C2 Container | Dev, Ops, Architects | What technical services/apps/databases compose the system? | City view |
| C3 Component | Internal developers | What modules exist inside each container? | Street view |
| C4 Code | Code review, refactoring | How are classes and interfaces organized? | Building view |
Diagrams as Code — Three Musketeers
| Tool | Language | Positioning | Recommended Scenario |
|---|
| Structurizr DSL | Proprietary DSL | C4 Model native tool | Full C4 series, CI Pipeline integration |
| PlantUML | Natural-language-like | General UML/C4 drawing | Sequence/Activity/C4 mixed use |
| Mermaid | Markdown-embedded | Lightweight documentation diagrams | README/doc embedding, GitHub/GitLab native rendering |
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)
| View | Purpose | Recommended Diagrams |
|---|
| Logical View | Functional decomposition, component relationships | Functional Architecture Diagram, Class Diagram, Component Diagram |
| Development View | Source modules, build organization | Package Diagram, Module Diagram |
| Process View | Runtime behavior, concurrency, communication | Sequence Diagram, Activity Diagram |
| Physical View | Deployment to hardware/cloud | Deployment Architecture Diagram, Network Topology |
| +1 Scenarios | Use cases connecting all views | Business Process Diagram, User Story Map |
TOGAF Enterprise Architecture (4A Architecture Layers)
Business Architecture → Application Architecture → Data Architecture → Technology Architecture
(Strategy-driven, top-down decomposition)
Methodology Combination Recommendations
| Scenario | Recommended Combination |
|---|
| Executive Briefing / Presales Proposal | TOGAF Capability Map + C4 C1 Context Diagram |
| Solution Design Document | 4+1 Logical+Physical Views + C4 C2 Container Diagram |
| Developer Handover | C4 C2+C3 Component Diagram + Sequence Diagram |
| Iteration Planning | C4 C3 Component Diagram + Lightweight ADR |
| Enterprise-Level IT Planning | TOGAF 4A Full Stack + C4 Level 0 System Landscape |
---## 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
| Phase | Core Deliverables | Key Stakeholders |
|---|
| Preliminary | Architecture principles, team formation, TOGAF framework tailoring, governance model | CIO, Chief Architect |
| Phase A | Architecture vision, scope statement, stakeholder map, business scenarios | CIO, CTO, Business VP |
| Phase B | Business architecture (capability map, value streams, business process models) | Business VP, Process Owner |
| Phase C | Application architecture + Data architecture (application portfolio, data models, interface specs) | CTO, Data Owner |
| Phase D | Technology architecture (platform selection, infrastructure, deployment model) | CTO, Infrastructure Lead |
| Phase E | Solution portfolio, ROI analysis, gap analysis | CIO, PMO |
| Phase F | Migration roadmap, work package breakdown, resource plan | PMO, Implementation Team |
| Phase G | Compliance review, architecture contracts, implementation monitoring | Architecture Board |
| Phase H | Change request assessment, architecture update, governance adjustment | Architecture Board |
Architecture Governance Three-Stage Model
Develop ──► Implement ──► Deploy
(Architecture (Implementation (Deployment
Development) Supervision) Verification)
│ │ │
▼ ▼ ▼
Architecture Architecture Architecture
Contract Compliance Conformance
| Governance Stage | Core Activities | Responsible Role | Key Deliverables |
|---|
| Develop | Architecture development, review, approval | Chief Architect | Architecture Definition Document, ADR |
| Implement | Implementation supervision, change handling, compliance review | Architecture Board | Architecture Compliance Report, Change Assessment |
| Deploy | Deployment verification, migration confirmation, go-live approval | PMO + Board | Deployment Confirmation, Go-Live Approval |
Governance Role Matrix
| Role | Core Responsibilities | Decision Authority | Meeting Frequency |
|---|
| CIO | IT strategy alignment, investment prioritization, resource allocation | Approve architecture principles and major investments | Quarterly |
| CTO | Technology strategy, platform selection, tech debt management | Approve technology standards and selection | Monthly |
| Chief Architect | Architecture integrity, architecture governance, standards development | Approve architecture decisions and contracts | Weekly |
| Architecture Board | Compliance review, change assessment, standards maintenance | Approve exception requests | Bi-weekly |
| Solution Architect | Specific solution architecture design, ADR authoring | Approve component-level decisions | Weekly |
| Domain Architect | Domain architecture (data/application/security) | Approve domain standards | As needed |
ADM Three Iteration Levels
| Iteration Level | Scope | Object | Typical Cycle |
|---|
| Full-Cycle Iteration | Re-execute entire ADM cycle | Major architecture transformation | 1-3 years |
| Inter-Phase Iteration | Feedback loops between phases | Incremental architecture delivery | 3-6 months |
| Intra-Phase Iteration | Multiple refinements within a single phase | Architecture detail refinement | 1-4 weeks |
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:
| Framework | Origin | Latest Version | Core Focus | Governance Model | Best For |
|---|
| TOGAF | The Open Group (UK) | TOGAF 10 (2022) | ADM process + Architecture Content Framework | Architecture Board + Contracts | Large enterprises, government, defense |
| Zachman Framework | John Zachman (USA) | V3.0 | Taxonomy/ontology — "what, how, where, who, when, why" | Lightweight, ontology-driven | Enterprise ontology, classification |
| FEAF | US Federal Government | FEAF v2 | Consolidated Reference Model (CRM) — 6 sub-models | Federal CIO Council | US federal agencies |
| DoDAF | US Department of Defense | DoDAF 2.02 | 8 viewpoints, 52 models — operational, systems, services | DoD Architecture Framework | Defense, aerospace, military |
| Gartner EA | Gartner (USA) | Continuous | Business-outcome-driven, "EA as a discipline not a deliverable" | Lightweight, business-aligned | Commercial enterprises, agile orgs |
| ArchiMate 3.2 | The Open Group | 3.2 (2022) | Visual modeling language — 6 layers, 14+ viewpoints | Complements TOGAF | Enterprise architecture visualization |
| SAFe EA | Scaled Agile (USA) | SAFe 6.0 | Lean-Agile EA — "architectural runway," agile release trains | Lean governance, decentralized | Large-scale agile enterprises |
Global EA Maturity by Region
| Region | EA Maturity | Dominant Framework(s) | Key Characteristics |
|---|
| North America | High | TOGAF, Gartner EA, SAFe EA | Business-outcome-driven, agile-aligned, strong federal/DoD frameworks |
| Western Europe | High | TOGAF, ArchiMate | Process-heavy, compliance-driven, strong public sector adoption |
| UK & Ireland | High | TOGAF (originated here), ITIL | Mature public sector EA, strong governance culture |
| Nordics | Very High | TOGAF, ArchiMate | Digital government leaders, strong interoperability standards |
| APAC (Japan, Korea, Singapore) | Medium-High | TOGAF, local adaptations | Government-led digital transformation, smart city focus |
| China | Medium-High | TOGAF, China-specific frameworks | Government-driven, Xinchuang ecosystem, classified protection (MLPS 2.0) |
| Middle East | Medium | TOGAF, Gartner EA | Smart city mega-projects, digital government initiatives |
| India | Medium | TOGAF, open-source | IT services-driven, cost-sensitive, rapid digitalization |
| LATAM | Low-Medium | TOGAF (emerging) | Growing adoption, cloud-first strategies, digital inclusion |
| Africa | Low-Medium | TOGAF (emerging) | Leapfrog digitalization, mobile-first, infrastructure gaps |
International Solution Architect Certifications
| Certification | Issuing Body | Level | Focus Area | Global Recognition | Typical Salary Premium |
|---|
| TOGAF 9/10 Certified | The Open Group | Foundation + Certified | Enterprise Architecture | Global gold standard | +15-25% |
| ArchiMate 3 Certified | The Open Group | Foundation + Practitioner | EA Modeling & Visualization | Strong in Europe/APAC | +10-15% |
| AWS Solutions Architect Professional | Amazon Web Services | Professional | AWS cloud architecture | Global, cloud-dominant | +20-30% |
| Azure Solutions Architect Expert | Microsoft | Expert (AZ-305) | Azure cloud architecture | Strong in enterprise/MS shops | +20-30% |
| Google Cloud Professional Architect | Google Cloud | Professional | GCP cloud architecture | Strong in data/AI/ML shops | +20-30% |
| CISSP-ISSAP | (ISC)² | Advanced | Security architecture | Global, security-focused | +25-35% |
| Salesforce Certified Technical Architect | Salesforce | Architect | Salesforce ecosystem | Salesforce partner ecosystem | +30-40% |
| ITIL 4 Master | Axelos | Master | IT service management | Global, ITSM roles | +10-20% |
| PMI-PBA | PMI | Professional | Business analysis | Global, BA roles | +10-15% |
| SAFe Architect | Scaled Agile | Architect | Lean-Agile architecture | Growing in agile enterprises | +15-20% |
Global SA Salary Benchmarks by Region (2025-2026)
| Region | Junior SA (0-3yr) | Mid SA (3-7yr) | Senior SA (7-12yr) | Principal/Chief SA (12+yr) | Currency |
|---|
| United States | $100K-$140K | $140K-$190K | $190K-$250K | $250K-$330K+ | USD |
| United Kingdom | £55K-£75K | £75K-£105K | £105K-£145K | £145K-£190K+ | GBP |
| Germany | €58K-€80K | €80K-€110K | €110K-€145K | €145K-€180K+ | EUR |
| Netherlands | €55K-€75K | €75K-€105K | €105K-€140K | €140K-€175K+ | EUR |
| Switzerland | CHF 105K-140K | CHF 140K-185K | CHF 185K-235K | CHF 235K-290K+ | CHF |
| Australia | AUD $105K-$140K | AUD $140K-$185K | AUD $185K-$235K | AUD $235K-$290K+ | AUD |
| Singapore | SGD $75K-$110K | SGD $110K-$155K | SGD $155K-$210K | SGD $210K-$280K+ | SGD |
| Japan | ¥6.5M-¥10M | ¥10M-¥14.5M | ¥14.5M-¥20M | ¥20M-¥28M+ | JPY |
| UAE / Dubai | AED 260K-400K | AED 400K-600K | AED 600K-860K | AED 860K-1.2M+ | AED |
| India | ₹10L-₹18L | ₹18L-₹35L | ₹35L-₹60L | ₹60L-₹100L+ | INR |
| Brazil | R$135K-R$200K | R$200K-R$320K | R$320K-R$480K | R$480K-R$680K+ | BRL |
| China | ¥220K-¥380K | ¥380K-¥600K | ¥600K-¥880K | ¥880K-¥1.35M+ | CNY |
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
| ADM Phase | Primary ArchiMate Layer | Secondary Layer | Key ArchiMate Elements |
|---|
| Preliminary | Motivation | — | Drivers, Goals, Constraints, Principles |
| Phase A | Motivation, Strategy | Business | Stakeholders, Goals, Capabilities, Course of Action |
| Phase B | Business | Motivation | Business Roles, Business Processes, Business Services |
| Phase C | Application | Business | Application Components, Application Services, Data Objects |
| Phase D | Technology | — | Nodes, Devices, System Software, Technology Services |
| Phase E | Strategy, Implementation | — | Work Packages, Gaps, Plateaus |
| Phase F | Implementation | — | Work Packages, Deliverables, Plateaus |
| Phase G | Implementation | Motivation | Deliverables, Assessments, Constraints |
| Phase H | Motivation, Strategy | — | Drivers, Goals, Assessments |
ArchiMate vs C4 Model Complementary Use
| Dimension | ArchiMate | C4 Model |
|---|
| Coverage | Strategy → Business → Application → Technology full stack | Software system architecture (Context → Code) |
| Abstraction Level | Enterprise/architecture-level macro view | System/module-level micro view |
| Strength | Cross-layer relationship modeling, motivation analysis | Developer perspective, deployment clarity |
| Weakness | Weak expression for code-level detail | Lacks strategy and motivation layers |
| Best Scenario | Enterprise architecture planning, TCO analysis, capability planning | Solution design, technology selection, developer handoff |
| Combination Strategy | ArchiMate for "Why + What" | C4 for "How + Where" |
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
| Stage | Characteristics | Competitive Dimension | Practical Implication | Decision Recommendation |
|---|
| Genesis | Brand new, poorly understood, extremely scarce | Exploration & validation | Market does not yet exist | Self-build or partner with academia |
| Custom | Market forming, immature products | Differentiation & customization | Expensive, requires specialist skills | Custom development or procure leading products |
| Product | Productized, mature market | Features & price | Multiple vendors available | Procure commercial products |
| Commodity | Standardized, pay-per-use | Efficiency & scale | Utility/on-demand services | Use cloud services/SaaS |
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
| Context Type | Characteristics | Causality | Decision Method | Architecture Example |
|---|
| Clear | Known best practices | Obvious | Sense → Categorize → Respond | Relational database selection |
| Complicated | Requires expert analysis | Can be analyzed | Sense → Analyze → Respond | Microservice decomposition strategy |
| Complex | Unpredictable | Only explainable in retrospect | Probe → Sense → Respond | AI model selection / technology trends |
| Chaotic | Highly turbulent | Cannot be sensed | Act → Sense → Respond | P0 incident / supply chain attack |
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:
| SPIN Dimension | Meaning | Analysis Questions |
|---|
| Situation | Client current state | Current business processes? Systems in use? Organizational structure? |
| Problem | Existing difficulties | Efficiency bottlenecks? Data silos? Redundant work? |
| Implication | Consequences of inaction | Cost losses? Compliance risks? Competitiveness decline? |
| Need-Payoff | Value after resolution | Cost reduction? Efficiency gain? New business opportunities? |
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:
| Dimension | Example Question | Response Key Points | Supporting Material | NG Behavior |
|---|
| Technical | "How do you compare to Competitor X?" | Differentiated advantages + scenario fit | Competitive comparison table | Belittling competitors |
| Commercial | "What if the budget is insufficient?" | Phased construction + ROI analysis | TCO model | Easily agreeing to price cuts |
| Security | "What about data security?" | Encryption + access control + audit | Security whitepaper | Over-promising |
| Implementation | "How long until go-live?" | Phased delivery + dependency explanation | Milestone plan | Compressing timeline |
| Service | "What about operations?" | Service levels + response mechanisms | SLA template | Promising unachievable metrics |
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 Diagram)
2.2 Core Business Process Diagrams × N (L2-L3 Swimlane Diagrams, including normal + exception flows)
2.3 Business Rule Definitions (Decision Tables / Rule Engine inputs)
2.4 Role & Permission Matrix (including Function-Role mapping table)
Chapter 3 Functional Design
3.1 Functional Architecture Overview (Functional Architecture Diagram)
3.2 Level-1 Module Detailed Design (per module: function list + page/operation flow)
3.3 Level-2 Function Detailed Design (function interaction diagram + input/output definitions)
3.4 Non-Functional Features (internationalization, multi-language, multi-tenancy, messaging notifications, etc.)
Chapter 4 Data Design
4.1 Data Domain Partitioning (aligned with business domains)
4.2 Core Data Entities (Conceptual Data Model / ER Diagram)
4.3 Data Flow Design (Data Flow Diagram Level 0-2 multi-level)
4.4 Data Storage Strategy (OLTP/OLAP/Cache/Search Engine/Data Lake selection)
4.5 Data Governance Standards (metadata management, data quality, data standards, data security classification)
Chapter 5 Integration Design
5.1 Integration Landscape (System Integration Diagram, marking all integration points and methods)
5.2 Interface Inventory (list: interface name, method, direction, data format, frequency, SLA)
5.3 Key Interface Design (interface protocol, request/response examples, exception handling, retry strategy)
5.4 Integration Strategy Summary (real-time/near-real-time/batch; API/SDK/MQ/ETL/FTP/File)
Chapter 6 Technical Implementation Design
6.1 Technology Selection Overview (including ADR per selection: options, rationale, consequences)
6.2 Key Technical Solution Details (e.g., distributed transactions, search engine, real-time computing)
6.3 Non-Functional Requirements Implementation Plan
- Performance (P95/P99 latency targets, QPS/TPS, stress testing plan)
- Security (authentication, authorization, encryption, audit, vulnerability management)
- Availability (SLA targets, redundancy, failover, SLO/SLI)
- Scalability (horizontal/vertical, sharding strategy)
6.4 AI/Intelligent Module Design (model selection, prompt engineering strategy, RAG architecture)
Chapter 7 Deployment Architecture Design
7.1 Deployment Topology Detail (including CIDR, security groups, instance specifications)
7.2 Environment Planning (dev/test/staging/production environment configuration difference table)
7.3 Network Planning (VPC/subnet/firewall policies)
7.4 Disaster Recovery Plan (RTO/RPO, active-standby/multi-active, backup strategy)
Chapter 8 Implementation Plan
8.1 Implementation Phase Breakdown (per phase: inputs, outputs, acceptance criteria, duration, resources)
8.2 Milestones & Deliverables List
8.3 Resource Planning (personnel/equipment/environment)
8.4 Quality Assurance Plan (testing strategy, review mechanisms)
Chapter 9 Operations Design
9.1 Operations System
9.2 Monitoring & Alerting
9.3 Logging Standards
9.4 Emergency Response Plan
Chapter 10 Appendix
10.1 ADR Complete Records
10.2 Change Log
10.3 Items To Be Confirmed List
---## Phase 5: Diagram Factory (13 Types of Professional Diagrams)
This is the signature capability of this Skill — precision generation of various professional diagrams for solutions.
5.0 General Diagram Standards (Apply to ALL Diagrams)
Tool Selection & Installation Check
Default Tool: draw.io (diagrams.net) — free, open-source, cross-platform, industrial-grade, rich ecosystem.
⚠️ Must Execute Before First Use:
- Check if user has draw.io desktop installed (
draw.io --version or check /Applications/draw.io.app)
- If not installed → guide installation:
- If not installing → inform impact: no offline editing, no CLI batch export, inconvenient collaboration, potential formatting issues in proposal diagrams
- If user insists on not installing → recommend VS Code extension
hediet.vscode-drawio (in-IDE editing, lightweight solution)
General Delivery Standards
- Dual-file delivery:
.drawio source file + .png preview, same name, same path
- Independent storage: All diagrams in
project_folder/diagrams/ directory
- Naming convention:
[Diagram Type]-[Topic]-V[Version].drawio
- Proposal references: Only reference .png in documents, do not embed .drawio
Professional Diagramming Principles (from Draw.io Style Guide Best Practices)
| Principle | Description |
|---|
| Shape Vocabulary | Use consistent shapes for same element types: rectangle = service/database, hexagon = gateway, circle = user/external entity |
| Color Semantics | Establish color coding system for different layers/domains/states, maintain global consistency |
| Line Type Semantics | Solid = primary data flow, dashed = secondary/async, thick = critical path, dotted = management flow |
| Arrow Directionality | Solid arrowhead = data flow, hollow arrowhead = dependency, no arrowhead = bidirectional sync |
| Minimal Palette | Core colors ≤ 5, black/white/grey as base, color only for highlighting key elements |
| Unified Font | Sans-serif font throughout (Arial/Helvetica), 12-14px main, 18-20px titles |
| Grid Alignment | Enable Snap to Grid, coordinates at multiples of 10 |
| Version Tracking | Place version number + date label inside diagram, filename includes version number |
draw.io XML File Structure Template
Generated .drawio files must include complete XML structure:
<mxfile host="Claude" modified="YYYY-MM-DD" agent="Claude Code" version="24.0.0">
<diagram name="Page-1" id="Page-1">
<mxGraphModel dx="1600" dy="1200" grid="1" gridSize="10" guides="1" tooltips="1"
connect="1" arrows="1" fold="1" page="1" pageScale="1"
pageWidth="1600" pageHeight="1200" math="0" shadow="0">
<root>
<mxCell id="0" />
<mxCell id="1" parent="0" />
<!-- All graphic elements -->
</root>
</mxGraphModel>
</diagram>
</mxfile>
Diagram Generation Workflow
- User describes requirements → Confirm diagram type and content scope
- Output ASCII sketch → For user to confirm layout, hierarchy, main elements
- After user confirmation → Generate complete draw.io XML, write to
.drawio file
- Attempt PNG export → Auto-export if draw.io CLI available; otherwise inform user of manual export method
- Inform path → Remind that it can be opened in draw.io for fine-tuning
5.1 System Context Diagram (C4 Level 1)
═ Most Frequently Used Presales Diagram, Core of C4 Model ═
Applicable Scenario: Proposal first-page overview, executive briefing, system landscape display.
Element Standards:
- Core System: Blue large rounded rectangle centered
fillColor=#1E88E5;fontColor=#FFFFFF;fontStyle=1;fontSize=16
- User Roles: Light blue person icon
shape=actor;fillColor=#E3F2FD
- External Systems: Grey rounded rectangle
fillColor=#ECEFF1;strokeColor=#90A4AE
- Interactions: Solid arrow + protocol label (REST/gRPC/MQ/File)
Layout: Core system centered, users left or above, external systems right or below, connections labeled with interaction purpose.
5.2 Container Diagram (C4 Level 2)
Applicable Scenario: Architecture design, technical solution detail.
Element Standards:
- Mobile App / SPA:
fillColor=#42A5F5 (Blue)
- Web App / Backend Service:
fillColor=#66BB6A (Green)
- Database:
shape=cylinder3;fillColor=#AB47BC (Purple)
- Message Queue / Cache:
fillColor=#FFA726 (Orange)
- File System / Object Storage:
fillColor=#78909C (Grey)
- System Boundary Box:
dashed=1;fillColor=none;strokeColor=#333333
5.3 Technical Architecture Diagram
Applicable Scenario: Layered display of the technical landscape from infrastructure to frontend applications.
Internet Layered Architecture Five-Layer Model Reference
The standard layered architecture for modern enterprise systems, also the foundational reference model for technical architecture diagrams in presales proposals:
| Layer | Responsibility | Typical Technology Selection | Key NFR |
|---|
| Client Layer | User interaction, device adaptation | React/Vue/Flutter, Electron, Mini Programs | First screen load <3s, multi-device consistency |
| Access Layer | Traffic ingress, security protection | Nginx/Kong/APISIX, CDN, WAF | 99.99% availability, TLS 1.3 |
| Application Layer | Business logic, process orchestration | Spring Boot/Go/Node.js, K8s | P99<500ms, graceful degradation |
| Service Layer | Shared services, platform capabilities | Microservices/Service Mesh, gRPC/Dubbo | Service discovery <1s, circuit breaker RTO<60s |
| Data Layer | Data persistence, caching | MySQL/PostgreSQL, Redis, ES, Kafka | RPO<5min, RTO<30min |
Standard Layering (top to bottom):
┌─────────────────────────────────────────────────┐
│ Access Layer │ Web / Mobile / H5 / OpenAPI / Gateway │ #E3F2FD
├─────────────────────────────────────────────────┤
│ Application Layer │ Microservice Cluster / Business Modules / Job Scheduler │ #E8F5E9
├─────────────────────────────────────────────────┤
│ Platform Layer │ Middleware / AI / Messaging / Search / Process Engine │ #FFF3E0
├─────────────────────────────────────────────────┤
│ Data Layer │ OLTP / OLAP / Cache / Search Engine / Data Lake │ #F3E5F5
├─────────────────────────────────────────────────┤
│ Infrastructure Layer │ Cloud / K8s / Network / Storage / Security Groups │ #ECEFF1
└─────────────────────────────────────────────────┘
← Security System (vertical penetration) → ← Operations System (vertical penetration) →
Key Rules:
- Use horizontal swimlanes or large containers for each layer
- Layer-internal components use rounded rectangles, grouped arrangement
- Security and operations systems use vertical lines/color bars penetrating from top to bottom
- Each layer container fill color has 30-40% color difference from internal component fill colors
- External systems/third-party services placed in the rightmost column as independent area
5.4 Business Process Diagram
Applicable Scenario: End-to-end business processes, approval flows, decision branches, exception handling.
Swimlane Standards:
- Horizontal swimlanes: each row represents a role/department/system
- Swimlane title width 30px (
startSize=30)
- Role background colors: human roles light warm, system roles light cool
BPMN Elements Mapped to draw.io:
| BPMN Element | draw.io Shape | Style |
|---|
| Start Event | Thin ring | ellipse;fillColor=#C8E6C9;strokeColor=#388E3C |
| End Event | Thick ring | ellipse;fillColor=#FFCDD2;strokeColor=#D32F2F;strokeWidth=3 |
| Task/Activity | Rounded rectangle | rounded=1;fillColor=#FFFFFF;strokeColor=#333333 |
| Gateway (Exclusive) | Diamond | rhombus;fillColor=#FFF9C4, label "X" inside |
| Gateway (Parallel) | Diamond | rhombus;fillColor=#FFF9C4, label "+" inside |
| Data Object | Top-right folded rectangle | shape=document |
| Annotation | Left-folded rectangle | Dashed border, light yellow fill |
Connection Rules:
- Normal flow: Solid line
strokeColor=#333333;endArrow=classic
- Message flow: Dashed
dashed=1;dashPattern=8 8
- Exception/compensation flow: Red dashed
strokeColor=#D32F2F;dashed=1
5.5 Data Flow Diagram (DFD — Level 0-2 Multi-Level)
Applicable Scenario: How data flows, processes, and stores between system modules.
DFD Level Strategy:
| Level | Name | Content | Audience |
|---|
| Level 0 | Context Diagram | System as single process + external entities | Everyone |
| Level 1 | Major Sub-Processes | 3-7 main processes + data stores | Technical+Business |
| Level 2 | Detailed Decomposition | Internal detailed data flow of each Level 1 process | Dev, Architects |
| Level 3 | Atomic | Rarely used, only for extremely complex systems | Deep technical |
DFD Four Elements (Standard Notation):
| Element | Shape | draw.io Implementation |
|---|
| External Entity | Rectangle (double border or bold) | strokeWidth=2;fillColor=#E3F2FD |
| Process | Circle or rounded rectangle | ellipse or rounded=1 (number inside) |
| Data Store | Open rectangle or cylinder | shape=cylinder3;fillColor=#F3E5F5 |
| Data Flow | Arrow line | strokeWidth=2;endArrow=classic, label data content |
Recommended Method: Use draw.io's multi-page diagram feature — one DFD level per page, higher-level shapes link to lower-level detail pages, achieving natural drill-down navigation.
5.6 Functional Architecture Diagram
Applicable Scenario: System functional module partitioning and hierarchical relationships.
Three-Level Tree Layout:
┌──────────────────────────────────────────────────────┐
│ Platform / Product Name │ ← Top title bar
├────────────┬────────────┬────────────┬────────────────┤
│ Module A │ Module B │ Module C │ Module D │ ← Level-1 Modules
│ #1E88E5 │ #43A047 │ #FB8C00 │ #8E24AA │
├──┬──┬─────┤──┬──┬─────┤──┬──┬─────┤──┬──┬──────────┤
│A1│A2│A3 │B1│B2│B3 │C1│C2│C3 │D1│D2│D3 │ ← Level-2 Functions
└──┴──┴─────┘──┴──┴─────┘──┴──┴─────┘──┴──┴──────────┘
Rules:
- Level-1 modules: 4-8, each using independent color scheme (blue/green/orange/purple/cyan/pink, hue spacing ≥45°)
- Level-2 functions: 3-6 per module
- Module separation: 5-10px spacing or light grey dashed lines
- For more levels, use expand/collapse (multi-page links)
5.7 System Integration Diagram
Applicable Scenario: Core system and external/peripheral system integration landscape.
Layout: Core system centered (160×120px, dark blue fill + white text), external systems arranged around.
Integration Method Visual Encoding:
| Integration Method | Line Type | Color | Label |
|---|
| API/HTTPS (Sync Real-Time) | Solid strokeWidth=2 | #1E88E5 Blue | REST/SOAP/GraphQL |
| Message Queue (Async) | Dotted dashed=1;dashPattern=1 4 | #FB8C00 Orange | MQ/Kafka/RabbitMQ |
| Batch/ETL (Batch Processing) | Long dash dashed=1;dashPattern=8 8 | #43A047 Green | FTP/File/Scheduled Task |
| Database Direct Connection | Double solid | #D32F2F Red | JDBC/ODBC |
| SDK/Embedded | Thick single strokeWidth=3 | #8E24AA Purple | SDK/Library |
Required Legend: Bottom-right corner legend explaining each line type/color meaning.
5.8 Deployment Architecture Diagram
Applicable Scenario: Cloud/data center physical deployment topology.
Key Annotations (Professional Standard):
- Availability Zone/Region boundary box:
strokeColor=#FF9800;strokeWidth=2;dashed=1
- VPC/Subnet: Light grey container + CIDR annotation (e.g.,
10.0.1.0/24)
- Security Groups/Firewall: Annotate rule direction (inbound/outbound)
- Instance specification annotation:
4C8G × 3 or t3.large × 2
- Load Balancer/Reverse Proxy:
shape=triangle;rotation=-90
- Network connection annotation with protocol and port (e.g.,
HTTPS:443)
- High availability annotation: "Primary," "Standby," "Multi-Active" badges
5.9 Data Architecture Diagram
Five-Layer Standard Structure:
Data Source Layer → Business DB / Tracking / IoT / External Data / Files
Data Integration Layer → CDC / Kafka / ETL / Flink
Data Storage Layer → ODS → DW/DM → Data Lake → Feature Store
Data Service Layer → API / Metrics Platform / Tag Platform / AI Features
Data Application Layer → BI Reports / Dashboards / Data Products / Intelligent Decision
Data Governance (Metadata → Data Quality → Data Security → Data Standards) vertical penetration
5.10 Business Architecture Diagram (Capability Map)
Applicable Scenario: Enterprise-level business capability landscape, value stream mapping.
Structure:
- Top: Business value streams (L1 end-to-end processes)
- Middle: Core business capability domains + enabling capability domains (arranged by value chain)
- Bottom: Supporting platforms (Technology/Data/Collaboration)
- Color by "Strategic-Core-Supporting" three tiers
5.11 Network Topology Diagram
Professional Drawing Standards:
- Hub-Spoke structure clearly differentiated
- All network segments annotated with CIDR addresses
- NSG (Network Security Groups) and UDR (Route Tables) markers
- Internal/external network DMZ zones clearly demarcated
- Use color for health status: Green=Normal, Yellow=Warning, Red=Fault (operations view)
5.12 Implementation Roadmap / Gantt Chart
Structure: Horizontal axis = time (weeks/months/quarters), vertical axis = workstreams/phases/modules.
- Time blocks use different colors for phases
- Key milestones marked (diamond/flag)
- Dependencies connected with arrows
- Each phase's deliverables annotated
5.13 AI/Intelligent Solution Diagram
Structure:
AI Application Layer → Assistant / Process Automation / Insights / Decision / Agent Orchestration Entry
Multi-Agent Orchestration → Orchestrator-Worker / Supervisor patterns; task decomposition, role assignment, collaboration & fallback
AI Service Platform Layer → LLM Gateway / AI Gateway / RAG 2.0 Engine / Agent Framework / Model Serving / LLMOps
MCP Tool Integration Layer → MCP Server/Client; standardized tool access to external systems/APIs/data/actions (successor to Function Calling)
AI Model Layer → Tiered Routing: small (classification/extraction) / mid (dialogue/RAG) / large (reasoning/planning) / reasoning (o1/R1-class)
Data & Feedback Layer → Knowledge Base / Vector DB / Labeled Data / Human-in-the-loop Feedback
← Guardrails (Prompt Injection / Jailbreak Defense / Red Teaming) + AI Cost Governance (token/inference accounting) + Observability (vertical) →
2026 upgrade: The structure above extends the original four layers into an "AI-Native Architecture", adding MCP tool-integration layer, multi-agent orchestration, RAG 2.0, LLMOps/AI gateway, model tiered routing, AI evaluation & guardrails, AI cost governance, and vector database selection. The original four layers (Application/Platform/Model/Data) are fully retained.
RAG 2.0 essentials (replaces naive "vector search + prompt stuffing"):
- Hybrid Retrieval: dense (vectors) + sparse (BM25/full-text) fused reranking, improves long-tail/proper-noun recall
- GraphRAG: graph-structured entity relations for multi-hop reasoning and global summarization (Microsoft open-source paradigm, 2024+)
- Re-ranking: Cross-Encoder / rerank models rerank candidates for precision
- Context Compression: query rewrite, context pruning, redundancy removal to cut token cost and hallucination
- Knowledge Governance: chunking strategy, versioning, citation/source tracing, freshness labeling
Vector DB Selection (2025–2026):
| Vector DB | Positioning | Best For |
|---|
| Milvus | Distributed, large-scale, production-grade | Billion-scale vectors, high-QPS retrieval |
| PGVector | PostgreSQL extension | Existing PG stack, mid-scale, ACID + vector in one |
| Qdrant | Rust, strong filtering | Semantic search with payload filtering, cloud-native |
| Chroma | Lightweight, embedded, dev-friendly | Prototypes/POC, embedded RAG |
| (also Weaviate / Pinecone / Redis Stack) | | |
Model Tiered Routing: route by task complexity & cost — simple classification/extraction to small models (low latency, near-zero cost); complex reasoning/planning to large or reasoning models; balance quality, latency, and token cost via a routing policy.
AI Evaluation & Guardrails:
- Prompt Injection / Jailbreak Defense: input sanitization, least privilege, confirmation for sensitive actions
- Red Teaming: adversarial samples, jailbreak attempts, data-leak testing as pre-launch evaluation
- Evaluation: RAGAS / objective metrics (faithfulness, answer relevancy) + business metrics + human sampling
AI Cost Governance:
- Account costs per token / inference call; build "cost per answer / cost per task" dashboards
- Caching hits, small-model offload, context compression, batching to lower unit cost
- Budget alerts & anomaly detection (extend FinOps three-phase cycle to AI spend)
LLMOps / AI Gateway: model versioning, canary release, traffic routing, rate-limiting/circuit-breaking, audit logs, eval regression, prompt versioning — consolidated at the AI gateway.
Companion template: New templates/ai-adr-template.md (AI Selection ADR template) standardizes high-risk decisions such as "adopt Agent or not / which model / vector DB & RAG strategy / guardrails & cost red lines".
Diagram Generation Summary
| # | Diagram Type | Corresponding Methodology | Layout Pattern | Typical Complexity |
|---|
| 1 | System Context Diagram C1 | C4 Model | Center+Periphery | ★★ |
| 2 | Container Diagram C2 | C4 Model | Layered+Grouped | ★★★ |
| 3 | Technical Architecture Diagram | Industry Standard | Horizontal Layers | ★★★ |
| 4 | Business Process Diagram | BPMN Lightweight | Swimlane | ★★★ |
| 5 | Data Flow Diagram Level 0-2 | DFD Standard | Left-to-Right | ★★★ |
| 6 | Functional Architecture Diagram | Industry Standard | Three-Level Tree | ★★ |
| 7 | System Integration Diagram | Industry Standard | Hub-Spoke | ★★ |
| 8 | Deployment Architecture Diagram | 4+1 Physical View | Zone Grouping | ★★★ |
| 9 | Data Architecture Diagram | TOGAF Data Domain | Five-Layer Flow | ★★★ |
| 10 | Business Architecture Diagram | TOGAF Business Domain | Capability Layering | ★★ |
| 11 | Network Topology Diagram | Network Engineering Standard | Hub-Spoke | ★★★ |
| 12 | Implementation Roadmap | Project Management Standard | Timeline | ★ |
| 13 | AI Solution Diagram | Emerging Standard | Layered+Embedded | ★★★ |
---## Phase 6: PPT Factory / Presentation Factory
PPT Type Matrix
| PPT Type | Slides | Audience | Style | Key Requirements |
|---|
| Executive Briefing | 5-8 slides | C-level/VP | Premium Dark/Minimalist | One point per slide, heavy on charts |
| Solution Presentation | 12-18 slides | Technical decision-makers | Corporate Navy | Architecture diagrams ≥30% |
| Technical Deep-Dive | 15-25 slides | Dev/Architects | Tech Modern | Include code snippets/interface examples |
| Bid Defense Presentation | 15-20 slides | Bid evaluators | Professional Standard | Strictly organized by scoring criteria |
| PoC Report | 8-12 slides | Project Sponsor | Fresh Clean | Emphasize validation results and data |
Solution Presentation PPT Standard Structure (13 Slides)
P1 Cover (Project Name + Team + Date)
P2 Table of Contents
P3 Project Background & Objectives (1 slide, Why Now?)
P4 Client Pain Points & Challenges (1 slide, Pain Points, data-driven)
P5 Solution Overall Architecture (1 slide, full-page architecture diagram, most critical slide)
P6 Business Design Highlights (1 slide, core business scenarios)
P7 Technical Architecture Highlights (1 slide, key technical innovations)
P8 Functional Design Overview (1 slide, functional map)
P9 AI/Intelligent Capabilities (1 slide, if applicable)
P10 Implementation Roadmap (1 slide, milestones + timeline)
P11 Project Organization & Assurance (1 slide, simplified RACI)
P12 Solution Advantage Summary (1 slide, Why Us?)
P13 Summary & Next Steps (1 slide, Call to Action)
PPT Design System
Color Schemes
| Scheme | Primary | Secondary | Accent | Best For |
|---|
| Corporate Navy | #1E2761 Deep Blue | #F5F7FA White | #C9A84C Gold | State-owned enterprises / Finance / Manufacturing |
| Tech Dark Blue | #0A1628 Midnight Blue | #1A3A5C Medium Blue | #00D4FF Cyan | Internet / Technology |
| Professional Blue-Grey | #2C3E50 Graphite Blue | #ECF0F1 Light Grey | #3498DB Blue | Consulting / Professional Services |
| Premium Dark | #111111 Black | #1A1A2E Deep Purple-Black | #D4AF37 Gold | C-level Briefing |
| Fresh Business | #FFFFFF White | #2C5F2D Forest Green | #FF6B35 Orange | SMEs / Startups |
| Tech Purple | #1A0033 Dark Purple | #F8F9FA White | #7B2FBE Purple | AI / Innovation Topics |
Typography Standards
| Element | Specification |
|---|
| Slide Title | 36-44pt Bold |
| Section Title | 24-28pt Bold |
| Body Text | 14-16pt Regular |
| Diagram Labels | 10-12pt |
| Margins | ≥ 0.5" / 1.27cm |
| Content Spacing | 0.3-0.5" |
Design Discipline
- Sandwich Structure: Dark cover+ending, light content slides (or all-dark for premium unified look)
- Every slide must have visual elements: Diagrams/large numbers/icons/photos, no pure text slides
- Left-aligned body text, centered titles only
- No title underlines (hallmark of AI-generated feel)
- No mixed spacing: Uniform 0.3" or 0.5", pick one
- No default blue: Color scheme reflects topic and industry
- No same layout three slides in a row: Vary columns, cards, callouts
PPT QA Process (Must Execute)
- Slide-by-slide check: text overflow, element overlap, uneven spacing
- Check diagram sources: PNGs referenced from
diagrams/ must be high-res (≥ 1920×1080)
- Check contrast: text/icons on dark backgrounds must be clearly visible
- Check content completeness: key slides not missing, key numbers not lost
- Final check: look for AI traces (title underlines, cookie-cutter layouts)
Phase 7: Contract & SOW Support
SOW Standard Structure (8 Chapters)
1. Project Overview — Background, objectives, scope (including system boundary diagram)
2. Scope of Work — Detailed work scope, deliverables list, explicit exclusions
3. Technical Solution Summary — Overall technical approach, key technical descriptions, technical constraints & assumptions
4. Implementation Plan — Phase breakdown, milestones, resource investment (person-days/equipment)
5. Acceptance Criteria — Acceptance methods, acceptance criteria checklist (functional/performance/security/documentation), acceptance process
6. Organization & Responsibilities — Project organization structure, bilateral responsibility matrix (RACI)
7. Assumptions & Constraints — Key assumptions (change mechanism), constraints, risk notes
8. Commercial Terms Reference — Pricing model, payment milestones, warranty period
RFP/RFI Response Support
- Organize response structure by scoring index
- Commercial clause line-by-line response (Comply/Deviate/Alternative)
- Technical clause line-by-line response + solution corroboration
- Proactively showcase bonus items
Global Public Procurement Market & RFP Best Practices
Global Public Procurement Market Size
| Region | Annual Procurement Market | Key Characteristics | Primary Platforms |
|---|
| United States | ~$700B (federal) + $2T+ (state/local) | FAR-based, GSA Schedules, GWACs, set-aside programs | SAM.gov, GSA eBuy, FedBizOpps |
| European Union | ~€2T (all member states) | EU Procurement Directives, TED, OJEU, MEAT criteria | TED (Tenders Electronic Daily), national portals |
| United Kingdom | ~£300B | PCR 2015 / Procurement Act 2023, CCS frameworks, G-Cloud/DOS | Find a Tender, Contracts Finder, CCS Digital Marketplace |
| APAC | ~$2T+ (combined) | GeBIZ (Singapore), AusTender (Australia), e-GP (Japan) | GeBIZ, AusTender, JETRO, KONEPS (Korea) |
| Middle East | ~$200B+ | Vision 2030/2071 mega-projects, sovereign procurement | Etimad (Saudi), Dubai eSupply, government portals |
| China | ~¥3T+ | Government Procurement Law, centralized procurement, Xinchuang requirements | China Government Procurement Network (ccgp.gov.cn), provincial portals |
| LATAM | ~$300B+ | Mercosur procurement protocol, national public procurement laws | ComprasNet (Brazil), ChileCompra, Mercado Publico |
| Africa | ~$200B+ | AfDB/World Bank procurement, emerging e-GP systems | Country-specific e-GP portals, AfDB, World Bank |
International RFP Response Framework
When responding to RFPs across different jurisdictions, adapt your approach to local expectations:
| Dimension | US | EU/UK | APAC | Middle East | China |
|---------------|-------|------|-------------|-------|
| Evaluation Model | Best Value / LPTA (Lowest Price Technically Acceptable) | MEAT (Most Economically Advantageous Tender) | Quality + Price weighting; often 70:30 or 80:20 | Technical compliance first, then price negotiation | Comprehensive scoring; technical + commercial + price |
| Page Limits | Often strict; follow exactly | Typically flexible within reason | Varies by country; Japan often strict | Often no strict limits; quality over brevity | Strict; must follow tender document exactly |
| Language | English (Spanish for some state/local) | Local language + English summary sometimes | Local language + English (Singapore, Philippines use English) | Arabic + English (UAE), Arabic (Saudi) | Chinese (Simplified) |
| Compliance | FAR/DFARS (US), Section 508 accessibility | EU directives, GDPR, NIS2, DORA | Local procurement acts, data residency | Local content requirements (In-Country Value/ICV) | Government Procurement Law, MLPS (Multi-Level Protection Scheme), Xinchuang |
| Key Differentiator | Past performance, small business participation | Sustainability, social value, innovation | Relationship, local presence, knowledge transfer | Wasta (relationships), local partnerships, ICV | Localization, domestic IPR, Xinchuang compatibility |
| Bid Bond | Often required (5-20%) | Varies by country | Common (5-10%) | Often required (1-5%) | Often required (bid bond, typically ≤2%) |
| Negotiation Style | Transparent, rule-based | Structured, consensus-driven | Relationship-first, harmony | Relationship-driven, hierarchical | Formal, hierarchical, guanxi matters |
RFP Response Quality Checklist (International)
---## Phase 8: Cloud Financial Management (FinOps)
FinOps is the IT financial management practice for the cloud era, achieving cloud cost visibility, control, and optimization through cross-functional (Technology + Finance + Business) collaboration. Adding a FinOps perspective to presales proposals shows clients "not just how to do it, but how much it costs and how to save" — the complete picture.
FinOps Three-Phase Cycle
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Inform │────►│ Optimize │────►│ Operate │
│ Visibility│ │ Optimize │ │ Operate │
│ (Inform) │◄────│ (Optimize)│◄────│ (Operate)│
└──────────┘ └──────────┘ └──────────┘
- Inform (Visibility): Establish cost allocation tagging system (department/project/environment/application), real-time cost dashboards and budget tracking, Showback→Chargeback maturity path
- Optimize (Optimization): On-demand instances → Reserved Instances/Savings Plans (save 50-70%), Spot instances for non-critical workloads, storage tiering, idle resource identification and release
- Operate (Operations): Automated cost governance policies, budget alerts and anomaly detection, regular review meetings, cost optimization culture building
Key Industry Data
| Metric | Data | Source |
|---|
| Enterprises citing cloud cost management as top challenge | 84% | Flexera 2025/2026 |
| Enterprises with cloud costs exceeding budget | 67% | Flexera 2025/2026 |
| Enterprises with at least 10% cloud spend waste | 82% | Flexera 2025/2026 |
| Average savings achievable through FinOps | 20-30% | FinOps Foundation |
| Dedicated FinOps teams (up from 51% in 2024) | 59% | Flexera 2025 |
| FinOps actual adoption (as of 2026) | >60% of mid-to-large enterprises have established FinOps teams/functions | Flexera 2025/FinOps Foundation |
| Original Gartner forecast "70% of enterprises adopt FinOps by 2026" | Actual adoption ~60%+, met but below 2022 forecast | Flexera 2025/FinOps Foundation |
10 FinOps Best Practices
| # | Best Practice | Description | Implementation Difficulty |
|---|
| 1 | Business Alignment | Cost attribution to specific business/product/project | ★★★ |
| 2 | Cross-Functional Teams | Finance + Technology + Business tripartite collaboration, breaking information silos | ★★★★ |
| 3 | Real-Time Visibility | Cost data latency ≤24 hours, ideally real-time | ★★ |
| 4 | Showback→Chargeback | First show departmental costs, then gradually establish cost recovery mechanisms | ★★★ |
| 5 | Automation | Auto-tag resources, auto-generate reports, auto-execute optimization policies | ★★★★ |
| 6 | Budget & Alerts | Set departmental/project budgets, auto-alert on over-budget | ★★ |
| 7 | Reserved Instances/Savings Plans | Purchase reserved instances for long-term stable workloads, can save 50-70% | ★★ |
| 8 | Regular Audits | Monthly review of cost anomalies and optimization opportunities | ★★ |
| 9 | Cultural Education | Engineers understand cloud costs, cultivate "every penny has an owner" culture | ★★★★★ |
| 10 | Continuous Improvement | Establish PDCA cycle, set year-over-year optimization KPIs | ★★★ |
FinOps Application in Presales Scenarios
| Scenario | FinOps Perspective | Talking Point |
|---|
| Cloud Solution Selection | Compare 5-year TCO across different cloud solutions | "We select based on optimal business value, not just the coolest technology" |
| Capacity Planning | Provide on-demand/reserved/spot hybrid strategy | "Initial on-demand for rapid launch, reserved after stabilization saves 50%+" |
| Architecture Design | Serverless and containerization significantly reduce idle costs | "This architecture natively supports the FinOps three-phase cycle" |
| Implementation Plan | Embed FinOps training in implementation plan | "Build cloud cost awareness during construction, immediately controllable in operations" |
Global Cloud Market Landscape
Global Cloud Market Share & Trends
| Cloud Provider | Global Market Share (2024) | YoY Growth | Key Strengths | Regional Dominance |
|---|
| AWS | ~31% | +17% | Broadest services, global reach, startup ecosystem | North America, LATAM, India |
| Microsoft Azure | ~24% | +21% | Enterprise integration, Microsoft 365 ecosystem, AI/OpenAI | Enterprise, government, Europe |
| Google Cloud | ~11% | +26% | Data/AI/ML, Kubernetes, analytics | Data-heavy, AI/ML shops |
| Alibaba Cloud | ~4% (global), ~35% (China) | +5% | China market, APAC, e-commerce | China, Southeast Asia |
| Oracle Cloud | ~3% | +25% | Database, enterprise applications, OCI | Enterprise database workloads |
| IBM Cloud | ~2% | +3% | Hybrid cloud, mainframe, regulated industries | Financial services, regulated |
| Salesforce | ~3% | +10% | SaaS CRM, platform ecosystem | CRM, enterprise SaaS |
| Others | ~22% | — | Regional players (Huawei Cloud, Tencent Cloud, Naver Cloud, etc.) | Regional markets |
Source: Synergy Research Group Q4 2024, Gartner Cloud Market Share 2024. Total cloud market (IaaS+PaaS+SaaS) ~$680B in 2024.
2025–2026 Cloud Market Dynamics Correction (as of Full Year 2025, Synergy/Canalys)
As of full-year 2025 (Synergy/Canalys), the cloud market share landscape shows significant AI-driven revision:
| Provider | 2024 Share | 2025 Q3-Q4 Share | Key Driver |
|---|
| AWS | ~31% | ~29% | Growth slowed to ~17%, pressured by Azure/GCP on AI workloads |
| Microsoft Azure | ~24% | ~20% | AI (OpenAI/Copilot) drives enterprise demand, but share eroded by GCP |
| Google Cloud | ~11% | ~13% | Fastest-growing hyperscaler (+26% YoY), benefiting from AI/data-analytics differentiation |
| Alibaba Cloud | ~4% | ~4% | Stable, leading share in the China market |
| Others | ~22% | ~34% | Intensified competition in niche markets |
Key changes:
- Q3 2025 global cloud infrastructure spend exceeded $106.9B/quarter for the first time (28% YoY); full-year 2025 projected > $400B
- AI workloads (GPU-as-a-Service >200% YoY growth) became the largest growth driver
- Google Cloud rose from 11% to 13%, Azure fell from 24% to 20%, AWS from 31% to 29% — AI differentiation significantly reshaped the competitive landscape
- Presales implication: Proposals should emphasize a multi-vendor/multi-cloud strategy over single-vendor lock-in; AI/GPU compute planning becomes standard in cloud proposals
Global Cloud Adoption Trends by Region
| Region | Cloud Maturity | Dominant Providers | Key Trends | Regulatory Landscape |
|---|
| North America | Very High | AWS, Azure, GCP | AI/ML platforms, serverless, multi-cloud, FinOps | SOC 2, HIPAA, FedRAMP, CCPA |
| Western Europe | High | AWS, Azure, GCP | Sovereign cloud, GAIA-X, sustainability | GDPR, EU AI Act, NIS2, DORA |
| UK | High | AWS, Azure, GCP | Post-Brexit data regime, fintech cloud | UK GDPR, FCA cloud guidance, NCSC |
| Nordics | Very High | AWS, Azure, GCP | Green cloud, data center sustainability | GDPR, national data protection laws |
| Japan | High | AWS, Azure, GCP | Digital transformation (DX), legacy migration | APPI, FISC (financial), ISMAP |
| South Korea | High | AWS, Azure, Naver Cloud, KT Cloud | AI/5G convergence, smart factory | PIPA, K-ISMS, CSP safety assessment |
| Singapore | Very High | AWS, Azure, GCP | Smart Nation, digital government cloud | PDPA, MAS TRM, MTCS |
| China | High | Alibaba Cloud, Huawei Cloud, Tencent Cloud, AWS China, Azure China | Xinchuang, domestic substitution, industrial internet | China classified protection (MLPS 2.0), CSL, DSL, cross-border data transfer |
| India | Medium-High | AWS, Azure, GCP | Digital India, UPI-scale infrastructure, startup ecosystem | DPDP Act 2023, RBI cloud guidelines, MeitY |
| Middle East | Medium-High | AWS, Azure, GCP, Oracle Cloud | Smart city, sovereign cloud, AI hubs | National data protection laws, sovereign cloud mandates |
