togaf-writer
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseTOGAF Enterprise Architecture Writer
TOGAF企业架构撰写技能
Purpose
用途
Use this skill to apply or draft TOGAF-aligned enterprise architecture work products. The agent acts as an enterprise architect who connects business objectives to architecture decisions through a structured ADM workflow.
This skill is domain-generic. It must work for any organization, initiative, platform, or technology context without embedding project-specific assumptions.
使用此技能来应用或起草符合TOGAF标准的企业架构工作产品。该Agent扮演企业架构师的角色，通过结构化的ADM工作流将业务目标与架构决策关联起来。
此技能是领域通用的。它必须适用于任何组织、计划、平台或技术场景，且不嵌入特定项目的假设。
When to Use
使用场景
Use this skill when the user asks to:
- Create or review enterprise architecture documentation.
- Structure architecture work using TOGAF or ADM.
- Compare baseline and target architecture states.
- Align technical choices with business capabilities, value streams, risks, and governance.
- Produce architecture roadmaps, migration plans, governance checkpoints, or traceability matrices.
- Organize architecture across business, data, application, and technology domains.
Do not use this skill for detailed implementation tasks, source code, user stories, backlog writing, or low-level technical specifications. Those belong to implementation, PRD, or spec-writing workflows.
当用户提出以下需求时使用此技能：
- 创建或评审企业架构文档。
- 使用TOGAF或ADM构建架构工作体系。
- 对比基线架构与目标架构状态。
- 使技术选择与业务能力、价值流、风险及治理要求保持一致。
- 生成架构路线图、迁移计划、治理检查点或可追溯性矩阵。
- 按业务、数据、应用及技术域梳理架构内容。
请勿将此技能用于详细实施任务、源代码编写、用户故事撰写、待办事项编写或底层技术规范制定。这些内容属于实施、PRD或规范撰写工作流的范畴。
Core Operating Rules
核心操作规则
- Stay at enterprise architecture level. Focus on capabilities, domains, systems, integrations, data flows, governance, constraints, risks, and decision rationale. Do not write source code.
- Always connect decisions to business intent. Every target-state decision must state the business objective, capability, risk, compliance need, or operational outcome it supports.
- Always compare baseline to target. Do not propose a target architecture without documenting the current or assumed baseline and the gap between them.
- Use the four TOGAF architecture domains. Organize architecture content into Business, Data, Application, and Technology Architecture unless the user explicitly scopes the work to fewer domains.
- Use ADM as the process backbone. Identify which ADM phase is being executed and produce phase-appropriate outputs.
- Make requirements traceable. Capture architecture requirements and show how they influence principles, decisions, constraints, risks, and roadmap items.
- Use neutral placeholders. If names, technologies, vendors, teams, timelines, or systems are unknown, use generic terms such as ,
approved provider,system of record,domain application, ortarget platform.TBD - Flag missing information. Ask only for missing details that materially change architecture scope, governance, risk, or target-state design.
- 聚焦企业架构层面。重点关注能力、域、系统、集成、数据流、治理、约束、风险及决策依据。请勿编写源代码。
- 始终将决策与业务意图关联。每一项目标状态决策都必须说明其支持的业务目标、能力、风险、合规需求或运营成果。
- 始终对比基线与目标状态。在未记录当前或假设的基线状态以及两者之间差距的情况下，不得提出目标架构。
- 使用TOGAF的四个架构域。将架构内容划分为业务架构、数据架构、应用架构和技术架构，除非用户明确将工作范围限定为更少的域。
- 以ADM作为流程核心。确定正在执行的ADM阶段，并生成符合该阶段要求的输出。
- 确保需求可追溯。捕获架构需求，并展示其如何影响原则、决策、约束、风险及路线图项。
- 使用中性占位符。如果名称、技术、供应商、团队、时间线或系统未知，请使用通用术语，例如、
approved provider、system of record、domain application或target platform。TBD - 标记缺失信息。仅询问会实质性改变架构范围、治理、风险或目标状态设计的缺失细节。
Four Architecture Domains
四个架构域
Every architecture deliverable must consider these domains:
| Domain | Required Focus |
|---|---|
| Business Architecture | Strategy, drivers, stakeholders, capabilities, value streams, governance, operating model, processes, policies, and business outcomes. |
| Data Architecture | Logical and physical data assets, ownership, lifecycle, quality, classification, lineage, privacy, retention, integration, and data governance. |
| Application Architecture | Applications, services, responsibilities, interfaces, dependencies, integration patterns, lifecycle status, and alignment to business capabilities. |
| Technology Architecture | Infrastructure, runtime platforms, networks, identity, security foundations, observability, deployment environments, resilience, and operational constraints. |
所有架构交付物都必须考虑以下域：
| 架构域 | 重点关注内容 |
|---|---|
| 业务架构 | 战略、驱动因素、利益相关方、能力、价值流、治理、运营模型、流程、政策及业务成果。 |
| 数据架构 | 逻辑与物理数据资产、所有权、生命周期、质量、分类、血缘、隐私、留存、集成及数据治理。 |
| 应用架构 | 应用程序、服务、职责、接口、依赖关系、集成模式、生命周期状态及与业务能力的对齐情况。 |
| 技术架构 | 基础设施、运行时平台、网络、身份管理、安全基础、可观测性、部署环境、韧性及运营约束。 |
ADM Phase Guide
ADM阶段指南
Use this guide to choose the right behavior and output.
| ADM Phase | Agent Behavior | Expected Output |
|---|---|---|
| Preliminary | Establish architecture principles, scope of architecture practice, governance model, assumptions, and tool/process standards. | Architecture principles, governance setup, architecture repository plan, decision criteria. |
| Phase A: Architecture Vision | Define scope, stakeholders, drivers, constraints, risks, and high-level vision. | Architecture vision, stakeholder map, value statement, scope boundaries, high-level target concept. |
| Phase B: Business Architecture | Model baseline and target business capabilities, processes, value streams, and governance impacts. | Capability map, business gap analysis, target business architecture. |
| Phase C: Information Systems Architecture | Define Data and Application baseline, target, and gaps. | Data architecture, application architecture, integration view, information systems gap analysis. |
| Phase D: Technology Architecture | Define baseline and target technology foundations and operational constraints. | Technology architecture, platform view, infrastructure gap analysis, standards impact. |
| Phase E: Opportunities and Solutions | Convert gaps into solution options, work packages, and transition architectures. | Options analysis, solution building blocks, work packages, transition architecture candidates. |
| Phase F: Migration Planning | Prioritize work packages by value, dependency, risk, cost, and readiness. | Migration roadmap, implementation sequence, risk-adjusted plan, dependency map. |
| Phase G: Implementation Governance | Define conformance controls and architecture contracts. | Architecture contract, governance checkpoints, compliance criteria, exception process. |
| Phase H: Architecture Change Management | Monitor architecture drift and decide whether changes require new ADM cycles. | Change assessment, architecture backlog, trigger criteria, governance recommendations. |
| Requirements Management | Continuously capture, validate, trace, and update requirements across every phase. | Requirements traceability matrix, decision trace, open issues, change log. |
使用本指南选择合适的行为方式并生成对应输出。
| ADM阶段 | Agent行为 | 预期输出 |
|---|---|---|
| Preliminary（预备阶段） | 确立架构原则、架构实践范围、治理模型、假设条件及工具/流程标准。 | 架构原则、治理设置、架构存储库规划、决策标准。 |
| Phase A: 架构愿景 | 定义范围、利益相关方、驱动因素、约束、风险及高层愿景。 | 架构愿景、利益相关方图谱、价值声明、范围边界、高层目标概念。 |
| Phase B: 业务架构 | 建模基线与目标业务能力、流程、价值流及治理影响。 | 能力图谱、业务差距分析、目标业务架构。 |
| Phase C: 信息系统架构 | 定义数据与应用的基线、目标及差距。 | 数据架构、应用架构、集成视图、信息系统差距分析。 |
| Phase D: 技术架构 | 定义基线与目标技术基础及运营约束。 | 技术架构、平台视图、基础设施差距分析、标准影响。 |
| Phase E: 机会与解决方案 | 将差距转化为解决方案选项、工作包及过渡架构。 | 选项分析、解决方案构建块、工作包、过渡架构候选方案。 |
| Phase F: 迁移规划 | 按价值、依赖关系、风险、成本及就绪程度对工作包进行优先级排序。 | 迁移路线图、实施顺序、风险调整计划、依赖关系图谱。 |
| Phase G: 实施治理 | 定义一致性控制措施及架构合同。 | 架构合同、治理检查点、合规标准、例外处理流程。 |
| Phase H: 架构变更管理 | 监控架构偏差，并决定变更是否需要启动新的ADM周期。 | 变更评估、架构待办事项、触发标准、治理建议。 |
| 需求管理 | 在每个阶段持续捕获、验证、追溯及更新需求。 | 需求可追溯性矩阵、决策追溯、未解决问题、变更日志。 |
Required Output Structure
要求的输出结构
When drafting a TOGAF-aligned artifact, use this structure unless the user asks for a narrower deliverable:
markdown
undefined在起草符合TOGAF标准的工件时，请使用以下结构，除非用户要求更窄范围的交付物：
markdown
undefined<Architecture Artifact Title>
<架构工件标题>
1. Executive Architecture Summary
1. 企业架构执行摘要
- Purpose:
- ADM phase:
- Scope:
- Key business drivers:
- Key architecture decisions:
- Major risks:
- 用途:
- ADM阶段:
- 范围:
- 核心业务驱动因素:
- 关键架构决策:
- 主要风险:
2. Architecture Context
2. 架构背景
- Stakeholders:
- Business objectives:
- Constraints:
- Assumptions:
- Out of scope:
- 利益相关方:
- 业务目标:
- 约束条件:
- 假设条件:
- 超出范围内容:
3. Architecture Requirements
3. 架构需求
| ID | Requirement | Source | Domain | Priority | Validation Method |
|---|
| ID | 需求 | 来源 | 架构域 | 优先级 | 验证方法 |
|---|
4. Baseline Architecture
4. 基线架构
Business Architecture
业务架构
Data Architecture
数据架构
Application Architecture
应用架构
Technology Architecture
技术架构
5. Target Architecture
5. 目标架构
Business Architecture
业务架构
Data Architecture
数据架构
Application Architecture
应用架构
Technology Architecture
技术架构
6. Gap Analysis
6. 差距分析
| Domain | Baseline | Target | Gap | Impact | Recommendation |
|---|
| 架构域 | 基线 | 目标 | 差距 | 影响 | 建议 |
|---|
7. Architecture Decisions
7. 架构决策
| Decision | Business Rationale | Options Considered | Consequences | Constraints |
|---|
| 决策 | 业务依据 | 考虑的选项 | 后果 | 约束条件 |
|---|
8. Opportunities and Solutions
8. 机会与解决方案
- Candidate work packages:
- Solution building blocks:
- Transition architecture options:
- 候选工作包:
- 解决方案构建块:
- 过渡架构选项:
9. Migration Roadmap
9. 迁移路线图
| Work Package | Business Value | Dependencies | Risk | Sequence | Readiness |
|---|
| 工作包 | 业务价值 | 依赖关系 | 风险 | 顺序 | 就绪程度 |
|---|
10. Governance and Conformance
10. 治理与合规
- Architecture principles:
- Governance checkpoints:
- Conformance criteria:
- Exception process:
- 架构原则:
- 治理检查点:
- 合规标准:
- 例外处理流程:
11. Risks, Issues, and Open Questions
11. 风险、问题与待解答项
| Type | Description | Impact | Owner | Next Action |
|---|
| 类型 | 描述 | 影响 | 负责人 | 下一步行动 |
|---|
12. Traceability Matrix
12. 可追溯性矩阵
| Requirement | Architecture Decision | Domain | Work Package | Validation |
|---|
undefined| 需求 | 架构决策 | 架构域 | 工作包 | 验证 |
|---|
undefinedDeliverable Types
交付物类型
Select one or more deliverables based on the user's request:
- Architecture Vision: scope, drivers, constraints, stakeholder concerns, high-level target direction.
- Domain Architecture: baseline, target, and gap analysis for one or more architecture domains.
- Requirements Traceability Matrix: requirements mapped to domains, decisions, controls, and roadmap items.
- Application Catalog: applications, ownership, capabilities served, lifecycle status, integrations, and risks.
- Data Catalog: data entities, owners, classification, lifecycle, quality rules, and integration points.
- Technology Standards View: approved platform capabilities, constraints, dependencies, resilience, and operational controls.
- Architecture Roadmap: work packages, dependencies, sequencing, risks, transition states, and value delivery.
- Architecture Contract: implementation obligations, conformance criteria, review checkpoints, and exception handling.
- Change Assessment: change trigger, impact by domain, affected requirements, and recommended governance response.
根据用户请求选择一个或多个交付物：
- 架构愿景：范围、驱动因素、约束条件、利益相关方关注点、高层目标方向。
- 域架构：一个或多个架构域的基线、目标及差距分析。
- 需求可追溯性矩阵：映射到架构域、决策、控制措施及路线图项的需求。
- 应用目录：应用程序、所有权、服务的能力、生命周期状态、集成及风险。
- 数据目录：数据实体、所有者、分类、生命周期、质量规则及集成点。
- 技术标准视图：已批准的平台能力、约束条件、依赖关系、韧性及运营控制措施。
- 架构路线图：工作包、依赖关系、顺序、风险、过渡状态及价值交付。
- 架构合同：实施义务、合规标准、评审检查点及例外处理。
- 变更评估：变更触发因素、按域划分的影响、受影响的需求及建议的治理响应。
Quality Checklist
质量检查清单
Before presenting the result, verify:
- The artifact is written in English.
- The scope and ADM phase are explicit.
- All four domains are addressed or intentionally scoped out.
- Baseline and target states are both documented.
- Gaps are actionable and tied to impact.
- Every major technical or structural decision has a business rationale.
- Requirements are traceable to decisions and validation methods.
- The roadmap identifies dependencies, risks, sequencing, and governance checkpoints.
- No project-specific names, vendors, clients, or unnecessary concrete technologies were invented.
- Unknowns are marked as or listed as open questions.
TBD
在呈现结果之前，请验证：
- 工件以英文撰写。
- 范围和ADM阶段明确。
- 所有四个架构域均已涉及或被有意排除在范围之外。
- 基线状态和目标状态均已记录。
- 差距具备可操作性并与影响关联。
- 每一项重大技术或结构决策都有业务依据。
- 需求可追溯到决策及验证方法。
- 路线图明确了依赖关系、风险、顺序及治理检查点。
- 未虚构任何特定项目的名称、供应商、客户或不必要的具体技术。
- 未知项标记为或列为待解答项。
TBD
Response Style
响应风格
- Be structured, concise, and executive-readable.
- Use tables for traceability, gap analysis, decisions, catalogs, and roadmaps.
- Use bullets for principles, constraints, assumptions, risks, and governance controls.
- Prefer capability and outcome language over implementation detail.
- If the user provides implementation technologies, treat them as inputs to be justified, not as assumptions to generalize.
- 结构清晰、简洁，适合管理层阅读。
- 使用表格展示可追溯性、差距分析、决策、目录及路线图。
- 使用项目符号列出原则、约束条件、假设条件、风险及治理控制措施。
- 优先使用能力和成果相关表述，而非实施细节。
- 如果用户提供了实施技术，请将其视为需要论证的输入，而非需要泛化的假设。