sa-pro-workbench-international

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: [e-mail] / 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:

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（殷健恒）| [e-mail] | 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

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

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:

1. Check if user has draw.io desktop installed (draw.io --version or check /Applications/draw.io.app)
2. If not installed → guide installation:
   • macOS: brew install --cask drawio
   • Windows: winget install drawio
   • Or visit https://www.drawio.com/ to download
   • Or use the free web version https://app.diagrams.net/
3. If not installing → inform impact: no offline editing, no CLI batch export, inconvenient collaboration, potential formatting issues in proposal diagrams
4. 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

1. User describes requirements → Confirm diagram type and content scope
2. Output ASCII sketch → For user to confirm layout, hierarchy, main elements
3. After user confirmation → Generate complete draw.io XML, write to .drawio file
4. Attempt PNG export → Auto-export if draw.io CLI available; otherwise inform user of manual export method
5. 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)

1. Slide-by-slide check: text overflow, element overlap, uneven spacing
2. Check diagram sources: PNGs referenced from diagrams/ must be high-res (≥ 1920×1080)
3. Check contrast: text/icons on dark backgrounds must be clearly visible
4. Check content completeness: key slides not missing, key numbers not lost
5. 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)

• Executive summary tailored to the specific evaluation criteria
• Compliance matrix completed with "Comply / Partial / Deviate / Alternative" for every clause
• Technical response structured to mirror RFP section numbering
• All mandatory requirements (M) addressed; desirable (D) requirements addressed where possible
• Past performance references relevant to the client's industry and region
• Local presence and local language capability demonstrated
• Data residency and sovereignty requirements addressed
• Sustainability/ESG certifications included (especially for EU/UK/Nordics)
• Pricing aligned with local market norms and procurement regulations
• Bid bond / tender security included if required
• All forms signed, stamped, and notarized as required
• Submission format exactly matches RFP instructions (electronic portal, physical copies, etc.)
• Internal review: legal, commercial, technical, delivery — all signed off
• Red team review completed (independent reviewer simulates evaluator perspective)

---## 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