target-architecture-document

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Target Architecture Document

目标架构文档

Quick Start

快速开始

Assume the Enterprise Architect Agent role from

agents/enterprise-architect.md

: align initiatives to business capabilities, target architecture, standards, roadmaps, reuse opportunities, portfolio impact, cross-domain dependencies, and governance actions.

Ask the user which capabilities to include before drafting the target architecture document. If the user already named capabilities, confirm the list and ask for any missing domains, strategic drivers, constraints, or existing architecture inputs.

Before creating any output files, run a

grill-me

style clarification session using

../grill-me/SKILL.md

. Ask one question at a time until the request, scope, capabilities, assumptions, constraints, terminology, and desired output are clear enough to avoid avoidable misunderstanding.

During that clarification session, use

../ubiquitous-language/SKILL.md

whenever terms are vague, overloaded, conflicting, or important enough to become shared domain language. Create or update

<private-lab-root>/GLOSSARY.md

inline as terms are clarified; do not batch glossary updates until the end. Do not write the glossary inside this public toolkit repository when working with real company context.

While creating or updating target architecture section files, also update

<private-lab-root>/GLOSSARY.md

whenever the document introduces or changes domain terms, applications, or data objects. Treat glossary maintenance as part of writing each section, not as a final cleanup task. Use the glossary format and rules from

../ubiquitous-language/SKILL.md

, including the dedicated

## Applications

section and a

## Data objects

section when data objects are identified.

After the clarification session, validate that

<private-lab-root>/GLOSSARY.md

was created or updated during the current run. If it was not created or updated, stop before generating target architecture files and ask the user to run the

grill-me

skill followed by the

ubiquitous-language

skill so the glossary is updated first.

Use the matching template in

templates/

for each generated section file. Use

templates/00-target-architecture-document-template.md

only for the summary and navigation document.

Every generated section file and the summary document must keep the top metadata table from its template. Replace every

{{PLACEHOLDER}}

and every drafting instruction with final, document-specific content; do not leave template guidance in generated artifacts. In particular, replace

{{CONFLUENCE_LINK}}

{{LAST_UPDATE}}

, and

{{OPEN_QUESTIONS_COUNT}}

with document-specific values. Leave

Readability Score

TBD

unless a readability check has actually been run.

Readability guideline: write for business stakeholders first. Aim for a readability score of

40+

for management summaries and section introductions, and

30+

for the remaining body content. Prefer short sentences, concrete nouns, active voice, and plain-language trade-offs. Keep specialist terms only where they affect decisions, risk, cost, ownership, timeline, or support model, and explain them on first use.

Store generated target architecture documents under the private company lab root at

solution-architectures/L1-target-architecture-<slug>/

When this toolkit is used as a submodule, do not write generated target architecture documents under

toolkit/solution-architectures/

or inside this public toolkit repository. Run from the private company lab root, or otherwise target the private lab root explicitly, so output goes to

<private-lab-root>/solution-architectures/

Use one file per major workflow section, plus one stakeholder-facing summary and navigation document:

text

solution-architectures/<slug>/
├── 01-preliminary-phase.md
├── 02-capability-overview.md
├── diagrams/
│   ├── capability-map.drawio
│   └── capability-map.svg
├── 03-phase-a-architecture-vision.md
├── 04-phase-b-business-architecture.md
├── 05-phase-c-application-architecture.md
├── 06-phase-c-data-architecture.md
├── 07-phase-d-technology-architecture.md
├── 08-phase-e-solution-building-blocks.md
├── 09-gap-analysis.md
├── 10-roadmap-themes.md
├── 11-governance-actions.md
├── 12-risks-and-open-questions.md
└── 00-target-architecture-document.md

Store every Draw.io source and same-basename export created for a target architecture document under

solution-architectures/<slug>/diagrams/

. Do not place target architecture diagram files beside the numbered Markdown documents.

按照

agents/enterprise-architect.md

承担

Enterprise Architect Agent

角色：将各项举措与业务能力、目标架构、标准、路线图、复用机会、组合影响、跨领域依赖关系和治理行动对齐。

在起草目标架构文档之前，询问用户需要纳入哪些能力。如果用户已经列出了能力，请确认该清单，并询问是否缺少任何领域、战略驱动因素、约束条件或现有架构输入。

在创建任何输出文件之前，使用

../grill-me/SKILL.md

开展

grill-me

风格的澄清会话。每次只提出一个问题，直到请求范围、能力、假设、约束、术语和期望输出足够清晰，能够避免可避免的误解。

在澄清会话期间 whenever 遇到含义模糊、过度使用、相互冲突或重要到需要形成统一领域语言的术语时，使用

../ubiquitous-language/SKILL.md

。在术语澄清过程中实时创建或更新

<private-lab-root>/GLOSSARY.md

；不要等到最后再批量更新术语表。在真实公司上下文中工作时，不要将此术语表写入此公共工具包仓库。

创建或更新目标架构章节文件时，还应在文档引入或变更领域术语、应用或数据对象时更新

<private-lab-root>/GLOSSARY.md

。将术语表维护视为编写每个章节的一部分，而不是最后才执行的清理任务。遵循

../ubiquitous-language/SKILL.md

中的术语表格式和规则，包括专用的

## Applications

章节，以及识别出数据对象时所需的

## Data objects

章节。

澄清会话结束后，验证

<private-lab-root>/GLOSSARY.md

是否已在本次运行中创建或更新。如果尚未创建或更新，请停止生成目标架构文件，并要求用户先运行

grill-me

skill，再运行

ubiquitous-language

skill，以优先更新术语表。

为每个生成的章节文件使用

templates/

中匹配的模板。仅将

templates/00-target-architecture-document-template.md

用于摘要和导航文档。

每个生成的章节文件和摘要文档都必须保留其模板中的顶部元数据表。将所有

{{PLACEHOLDER}}

和所有起草说明替换为针对具体文档的最终内容；生成的产物中不得残留模板指导信息。特别要将

{{CONFLUENCE_LINK}}

、

{{LAST_UPDATE}}

和

{{OPEN_QUESTIONS_COUNT}}

替换为与具体文档对应的值。除非实际执行了可读性检查，否则将

Readability Score

保持为

TBD

。

可读性指南：优先面向业务利益相关者编写。管理摘要和章节引言的可读性评分应达到

40+

，其余正文内容应达到

30+

。优先使用短句、具体名词、主动语态和通俗语言表达权衡。仅在专业术语会影响决策、风险、成本、所有权、时间线或支持模式时保留这些术语，并首次使用时进行解释。

将生成的目标架构文档存储在私有公司实验室根目录下的

solution-architectures/L1-target-architecture-<slug>/

。

将此工具包作为 submodule 使用时，不要在

toolkit/solution-architectures/

或此公共工具包仓库内生成目标架构文档。应从私有公司实验室根目录运行，或明确指定私有实验室根目录，以确保输出写入

<private-lab-root>/solution-architectures/

。

每个主要工作流章节使用一个文件，另设一个面向利益相关者的摘要和导航文档：

text

solution-architectures/<slug>/
├── 01-preliminary-phase.md
├── 02-capability-overview.md
├── diagrams/
│   ├── capability-map.drawio
│   └── capability-map.svg
├── 03-phase-a-architecture-vision.md
├── 04-phase-b-business-architecture.md
├── 05-phase-c-application-architecture.md
├── 06-phase-c-data-architecture.md
├── 07-phase-d-technology-architecture.md
├── 08-phase-e-solution-building-blocks.md
├── 09-gap-analysis.md
├── 10-roadmap-themes.md
├── 11-governance-actions.md
├── 12-risks-and-open-questions.md
└── 00-target-architecture-document.md

所有 Draw.io 源文件及为目标架构文档创建的同名导出文件，都必须存储在

solution-architectures/<slug>/diagrams/

下。不要将目标架构图文件放在编号 Markdown 文档旁边。

Required Inputs

所需输入

Enterprise and organizational context
Architecture capability, maturity, framework, governance, standards, roles, and reusable assets
Rationale and scope for the target architecture initiative
Capabilities to include
Company mission and vision, strategic drivers, objectives, product vision, and business outcomes
Stakeholders and governance bodies
Current-state application, data, integration, and technology context
Target-state direction, constraints, standards, and roadmap expectations
Candidate delivery slices or architecture work packages
Known risks, dependencies, and open decisions

企业与组织上下文
架构能力、成熟度、框架、治理、标准、角色和可复用资产
目标架构计划的理由和范围
需要纳入的能力
公司使命与愿景、战略驱动因素、目标、产品愿景和业务成果
利益相关者和治理机构
当前状态下的应用、数据、集成和技术上下文
目标状态方向、约束、标准和路线图预期
候选交付切片或架构工作包
已知风险、依赖关系和待决策事项

Workflow

工作流

Start with the
```
grill-me
```
clarification session and update
```
<private-lab-root>/GLOSSARY.md
```
with
```
ubiquitous-language
```
as terminology is clarified.
Validate that
```
<private-lab-root>/GLOSSARY.md
```
was created or updated. If not, stop and ask the user to run
```
grill-me
```
and then
```
ubiquitous-language
```
before continuing.
Gather and confirm the capability list from the user.
Determine the output folder as
```
<private-lab-root>/solution-architectures/<slug>/
```
, where
```
<slug>
```
is derived from the target architecture document name.
Create the
```
solution-architectures/<slug>/
```
folder if needed. Create its
```
diagrams/
```
subfolder before generating any target architecture diagram.
For every section below, update
```
<private-lab-root>/GLOSSARY.md
```
before or alongside the section when the section introduces or changes:
- Domain terms and aliases
- Jargon, deprecated terms, or words to avoid, captured in the glossary
```
## Jargon
```
  section
- Applications and the capabilities or functions they deliver
- General canonical data objects, ownership, source-of-truth, and lifecycle notes
- Relationships between terms, applications, and data objects
Do not overwrite an existing section file or summary document unless the user explicitly asks.
Create
```
01-preliminary-phase.md
```
from
```
templates/01-preliminary-phase-template.md
```
using Preliminary Phase input to establish architecture context:

Introduction explaining how enterprise architecture is organized and governed
Enterprise and organizational context - Establishes where architecture operates organizationally
Architecture capability and maturity - Defines where and how enterprise architecture is practiced
Architecture framework and method - Describes the chosen framework and methodological approach
Architecture principles and standards - Establishes reusable rules and constraints
Governance model and decision rights - Defines architecture decision rights and governance mechanisms
Architecture roles and decision forums - Establishes the standing architecture organization
Integration with portfolio, delivery, risk, and other governance
Architecture repository, tools, and reusable assets - Establishes the shared architecture knowledge base

Create
```
02-capability-overview.md
```
from
```
templates/02-capability-overview-template.md
```
with a high-level overview for each included capability:
- Before the capability descriptions, create
```
diagrams/capability-map.drawio
```
  with
```
../create-drawio-diagram/SKILL.md
```
  using
```
../create-drawio-diagram/templates/capability-map.drawio
```
- Place every included layered capability exactly once in its confirmed horizontal layer: Channel, Engagement Services, Integration, or Enterprise Foundation
- Use at most eight capabilities per row in each layer; when a layer needs multiple rows, use the minimum number of rows and distribute its capabilities evenly according to the Capability Map layout rules in
```
../create-drawio-diagram/SKILL.md
```
- Preserve the three cross-cutting columns to the right of the horizontal layers: UI Design and Testing; Observability (Logging, Monitoring & Alerting); DevOps; do not duplicate these as nodes inside a horizontal layer
- Start with the typical cross-cutting capabilities defined by the Capability Map layout in
```
../create-drawio-diagram/SKILL.md
```
  , then keep, replace, remove, or add nodes based on confirmed target architecture input; do not present unconfirmed starter capabilities as enterprise facts
- Keep capability names identical across the diagram, capability descriptions, glossary, and linked capability documents
- Export
```
diagrams/capability-map.drawio
```
  to
```
diagrams/capability-map.svg
```
  , inspect the SVG using the
```
create-drawio-diagram
```
  export rules, embed the SVG under
```
## Capability Map
```
  , and link the editable Draw.io source from the same
```
diagrams/
```
  subfolder
- If a capability's layer is unknown or disputed, record it as an open question and resolve it instead of guessing
- Present each capability as a short text block instead of a table row, using this order: capability name as a level-three heading, definition, Business outcome, Scope boundary, Target-state direction, and Relevant architecture decisions
- Link the capability name in its level-three heading to the matching capability overview document when one exists under
```
<private-lab-root>/capabilities/<capability-slug>/<capability-slug>.md
```
  ; otherwise use an explicit placeholder such as
```
TBD
```
  or mark it as an open question instead of inventing a path
- Write each capability definition in plain English for a non-technical reader. Explain what the organization must be able to do, avoid implementation language, and spell out unfamiliar abbreviations on first use
- Write Business outcome as the practical benefit or measurable change for customers, employees, partners, or the organization; do not describe a system feature or technical deliverable as the outcome
- Write Target-state direction as a concise description of how the capability should work in the future, focusing on the user or business experience before any necessary technical detail
- Write Scope boundary as a clearly labeled short paragraph that states what the capability includes and excludes
- Within each capability block, populate
```
Relevant architecture decisions
```
  with links to confirmed ADRs that directly affect that capability. Use each ADR title as its Markdown link label. Leave it empty when none are confirmed for that capability; do not add an empty-state message or invent ADR paths
- Add one Markdown horizontal divider (
```
---
```
  ) between consecutive capability blocks. Do not place a divider before the first capability or after the final capability
- Put shared stakeholders and current-state pain points in their dedicated sections after the capability descriptions rather than repeating them inside every capability block
- Application, data, integration, and technology implications
- Dependencies, risks, and roadmap considerations

Create

03-phase-a-architecture-vision.md

from

templates/03-phase-a-architecture-vision-template.md

using Phase A input:

Introduction explaining why this target architecture is needed now - Explains the purpose and value of this architecture initiative
Company mission and vision - Provides strategic context for the proposed change
Strategic drivers
Objectives
Product vision - Describes the intended future product or service experience
Business outcomes
Stakeholders, concerns, and key requirements - Identifies who is affected by this architecture and what matters to them
Architecture initiative scope and exclusions - Defines what this specific ADM cycle includes and excludes
Value streams or major scenarios
High-level baseline and target vision - Communicates the proposed change at vision level
Assumptions, constraints, dependencies, and risks
Transformation readiness
Success measures - Supports approval of the architecture work
Approval and Statement of Architecture Work

Create

04-phase-b-business-architecture.md

from

templates/04-phase-b-business-architecture-template.md

using Phase B input:

Capability map
Organization impacts
Business processes
Operating model changes
Business risks and dependencies

Create

05-phase-c-application-architecture.md

from

templates/05-phase-c-application-architecture-template.md

using Phase C input:

Application landscape
Application responsibilities and boundaries
Channels and frontends
Engagement services
Commerce services
Enterprise applications
Application interactions
APIs and integration patterns
Reuse and application rationalization
Application gaps, dependencies, and risks
Detailed Ecommerce Solution Blueprint

Create

06-phase-c-data-architecture.md

from

templates/06-phase-c-data-architecture-template.md

using Phase C input:

Data domains
Data ownership
Systems of record
Master and reference data
Customer identity and 360-degree customer view
Product, customer, order, and interaction data
Data flows and synchronization
Data quality, privacy, and retention
Analytics and data activation
Data gaps, dependencies, and risks
Linked data architecture designs for specific canonical data objects, left as
```
_No linked data architecture designs yet._
```
until the user explicitly creates them with
```
../data-architecture-design/SKILL.md
```

Create

07-phase-d-technology-architecture.md

from

templates/07-phase-d-technology-architecture-template.md

using Phase D input:

Platforms, infrastructure, security, observability, and operations
Technology standards and constraints
Technology lifecycle concerns

Create

08-phase-e-solution-building-blocks.md

from

templates/08-phase-e-solution-building-blocks-template.md

using Phase E input:

Related capabilities and architecture trace references
Delivery dependencies and sequencing notes
Epics to build, left as
```
_No linked epics yet._
```
until the user explicitly creates epics with
```
../to-epics/SKILL.md
```
When epics exist, present each epic as a level-three linked heading followed by short labeled paragraphs for main capability, description, and phase. Do not use an epic list table.

Create

09-gap-analysis.md

10-roadmap-themes.md

11-governance-actions.md

, and

12-risks-and-open-questions.md

from their matching templates.

In
```
09-gap-analysis.md
```
, write the opening
```
Gap Analysis Summary
```
as five short labeled paragraphs: current situation, target outcome, most important gaps, operational impact, and recommended response.
Under each gap category, present every distinct gap as a level-three heading followed by short labeled paragraphs or bullets for current state, target state, gap, impact, and recommended response.
Do not use a gap-analysis comparison table. If a category has no confirmed gaps, state that briefly instead of adding an empty table or placeholder row.
In
```
10-roadmap-themes.md
```
, write the opening
```
Roadmap Summary
```
as three short labeled paragraphs: business outcome, sequencing approach, and key dependencies.
Under each time horizon, present every roadmap theme as a level-three heading followed by short labeled paragraphs or bullets for outcome, scope, dependencies, and suggested sequence. Do not use a roadmap-theme comparison table.

12-risks-and-open-questions.md

, group risks under

High Risks

Medium Risks

, and

Low Risks

in that order.

Number risks sequentially across all three groups with two-digit identifiers starting at
```
00
```
.
Present each risk using the repeatable block from the template: numbered risk name, a compact Likelihood and Owner table, an Impact section, a Mitigation section, and a horizontal divider.
If a severity group has no confirmed risks, keep its heading and state
```
_No confirmed high risks._
```
,
```
_No confirmed medium risks._
```
, or
```
_No confirmed low risks._
```
as applicable. Do not leave placeholders or an empty risk block.

Before creating the summary document, review the generated section files against
```
<private-lab-root>/GLOSSARY.md
```
and add any missing terms, applications, data objects, and relationships discovered during drafting.

Create

00-target-architecture-document.md

from

templates/00-target-architecture-document-template.md

as the summary and navigation document.

Begin
```
00-target-architecture-document.md
```
with its title and a one-sentence document purpose directly below it, without a purpose heading.
For every numbered detailed page, add the following to
```
00-target-architecture-document.md
```
in this order:
- The detailed page title
- A one-sentence purpose directly below the title, with no purpose heading
- A
```
Management Summary
```
  copied verbatim from that detailed page's
```
Introduction
```
  ; do not paraphrase, shorten, or otherwise rewrite it
- A link to the detailed page
Keep every detailed page's
```
Introduction
```
concise and suitable for management readers because it is also the source text for the summary document. Keep detailed analysis, tables, and implementation detail in the numbered section files.
Keep the section files as the detailed reviewable artifacts. The
```
00-target-architecture-document.md
```
file is the stakeholder-facing overview with links to those detailed sections.
Leave the Phase E
```
Epics To Build
```
section as
```
_No linked epics yet._
```
until the user explicitly creates epics with
```
../to-epics/SKILL.md
```
. Generated epic files belong under
```
<private-lab-root>/requirements/<name-of-target-architecture>/
```
, not under the target architecture folder. Do not infer or create epics during target architecture drafting. Every epic requires a user-provided main capability.
Leave the Phase C
```
Data Architecture Designs
```
table empty until the user explicitly creates data architecture designs with
```
../data-architecture-design/SKILL.md
```
. Generated data architecture design files belong under
```
<private-lab-root>/data-architectures/<data-object-slug>/
```
, not under the target architecture folder.

先开展
```
grill-me
```
澄清会话，并在术语澄清过程中使用
```
ubiquitous-language
```
更新
```
<private-lab-root>/GLOSSARY.md
```
。
验证
```
<private-lab-root>/GLOSSARY.md
```
是否已创建或更新。如果没有，请停止并要求用户先运行
```
grill-me
```
，再运行
```
ubiquitous-language
```
，然后继续。
从用户处收集并确认能力清单。
将输出文件夹确定为
```
<private-lab-root>/solution-architectures/<slug>/
```
，其中
```
<slug>
```
根据目标架构文档名称生成。
根据需要创建
```
solution-architectures/<slug>/
```
文件夹。在生成任何目标架构图之前，先创建其
```
diagrams/
```
子文件夹。
对于以下每个章节，如果该章节引入或变更了相关内容，应在编写该章节之前或同时更新
```
<private-lab-root>/GLOSSARY.md
```
：
- 领域术语和别名
- 术语表中
```
## Jargon
```
  章节记录的行话、弃用术语或应避免使用的词语
- 应用及其交付的能力或功能
- 通用规范数据对象、所有权、事实来源和生命周期说明
- 术语、应用和数据对象之间的关系
除非用户明确要求，否则不得覆盖现有章节文件或摘要文档。
使用 Preliminary Phase 输入，从
```
templates/01-preliminary-phase-template.md
```
创建
```
01-preliminary-phase.md
```
，以建立架构上下文：

引言：说明企业架构如何组织和治理
企业与组织上下文——确定架构在组织中的运作位置
架构能力与成熟度——定义企业架构的实践位置和方式
架构框架与方法——说明所选框架和方法论路径
架构原则与标准——建立可复用的规则和约束
治理模型与决策权——定义架构决策权和治理机制
架构角色与决策论坛——建立常设架构组织
与产品组合、交付、风险和其他治理机制的衔接
架构知识库、工具和可复用资产——建立共享架构知识库

使用 Phase A 输入，从
```
templates/02-capability-overview-template.md
```
创建
```
02-capability-overview.md
```
，为每个纳入的能力提供高层概览：

在能力说明之前，使用

../create-drawio-diagram/SKILL.md

和

../create-drawio-diagram/templates/capability-map.drawio

创建

diagrams/capability-map.drawio

将每个纳入的分层能力恰好放置一次，并放入已确认的水平层级：Channel、Engagement Services、Integration 或 Enterprise Foundation
每层每行最多放置八项能力；当一层需要多行时，使用满足要求的最少行数，并按照
```
../create-drawio-diagram/SKILL.md
```
中 Capability Map 布局规则均匀分布该层能力
保留水平层右侧的三个跨领域列：UI Design and Testing；Observability (Logging, Monitoring & Alerting)；DevOps；不要在水平层内重复这些列作为节点
从
```
../create-drawio-diagram/SKILL.md
```
中 Capability Map 布局定义的典型跨领域能力开始，再根据已确认的目标架构输入保留、替换、删除或添加节点；不得将未经确认的初始能力描述为企业事实
能力名称在图、能力说明、术语表和关联能力文档中必须保持一致
将
```
diagrams/capability-map.drawio
```
导出为
```
diagrams/capability-map.svg
```
，按照
```
create-drawio-diagram
```
的导出规则检查 SVG，在
```
## Capability Map
```
下嵌入 SVG，并从同一
```
diagrams/
```
子文件夹链接可编辑的 Draw.io 源文件
如果某项能力的层级未知或存在争议，将其记录为待解决问题并进行确认，而不是猜测
每项能力使用简短文本块而非表格行呈现，顺序如下：以三级标题显示能力名称、定义、Business outcome、Scope boundary、Target-state direction，以及 Relevant architecture decisions
如果
```
<private-lab-root>/capabilities/<capability-slug>/<capability-slug>.md
```
下存在对应的能力概览文档，则在三级标题中将能力名称链接到该文档；否则使用
```
TBD
```
等明确占位符，或将其标记为待解决问题，不得虚构路径
使用通俗英语面向非技术读者编写每项能力定义。说明组织必须具备的能力，避免使用实现层面的语言，并在首次使用时拼写并解释不熟悉的缩写
将 Business outcome 编写为客户、员工、合作伙伴或组织能够获得的实际收益或可衡量变化；不得将系统功能或技术交付物描述为成果
将 Target-state direction 编写为能力未来应如何运作的简要说明，优先描述用户体验或业务体验，然后再描述必要的技术细节
将 Scope boundary 编写为清晰标注的简短段落，说明该能力包含和排除的内容
在每个能力块内，使用指向已确认 ADR 的链接填充
```
Relevant architecture decisions
```
，且仅包含直接影响该能力的 ADR。使用各 ADR 标题作为 Markdown 链接标签。如果该能力没有已确认的 ADR，则保持为空；不要添加空状态消息或虚构 ADR 路径
在相邻能力块之间添加一个 Markdown 水平分隔线（
```
---
```
）。不要在第一个能力块之前或最后一个能力块之后添加分隔线
将共享利益相关者和当前状态痛点放在能力说明之后的专用章节中，不要在每个能力块内重复这些内容
应用、数据、集成和技术影响
依赖关系、风险和路线图考量

使用 Phase A 输入，从

templates/03-phase-a-architecture-vision-template.md

创建

03-phase-a-architecture-vision.md

：

引言：说明为什么现在需要此目标架构——解释该架构计划的目的和价值
公司使命与愿景——为拟议变更提供战略上下文
战略驱动因素
目标
产品愿景——描述未来产品或服务的预期体验
业务成果
利益相关者、关注事项和关键需求——确定谁会受到该架构影响，以及对他们而言哪些事项最重要
架构计划范围和排除项——定义本次 ADM 周期包含和排除的内容
价值流或主要场景
高层基线与目标愿景——在愿景层面传达拟议变更
假设、约束、依赖关系和风险
转型准备度
成功衡量指标——支持架构工作的审批
Approval and Statement of Architecture Work

使用 Phase B 输入，从

templates/04-phase-b-business-architecture-template.md

创建

04-phase-b-business-architecture.md

：

能力地图
组织影响
业务流程
运营模式变化
业务风险和依赖关系

使用 Phase C 输入，从

templates/05-phase-c-application-architecture-template.md

创建

05-phase-c-application-architecture.md

：

应用全景
应用职责和边界
渠道和前端
Engagement services
Commerce services
企业应用
应用交互
API 和集成模式
复用和应用合理化
应用差距、依赖关系和风险
详细的 Ecommerce Solution Blueprint

使用 Phase C 输入，从

templates/06-phase-c-data-architecture-template.md

创建

06-phase-c-data-architecture.md

：

数据域
数据所有权
记录系统
主数据和参考数据
客户身份和 360-degree customer view
产品、客户、订单和交互数据
数据流和同步
数据质量、隐私和保留
分析和数据激活
数据差距、依赖关系和风险
与特定规范数据对象关联的数据架构设计；在用户明确使用
```
../data-architecture-design/SKILL.md
```
创建之前，保持为
```
_No linked data architecture designs yet._
```

使用 Phase D 输入，从

templates/07-phase-d-technology-architecture-template.md

创建

07-phase-d-technology-architecture.md

：

平台、基础设施、安全、可观测性和运维
技术标准和约束
技术生命周期关注事项

使用 Phase E 输入，从

templates/08-phase-e-solution-building-blocks-template.md

创建

08-phase-e-solution-building-blocks.md

：

相关能力和架构追溯引用
交付依赖关系和排序说明
待构建的 Epic；在用户明确使用
```
../to-epics/SKILL.md
```
创建之前，保持为
```
_No linked epics yet._
```
当存在 Epic 时，每个 Epic 使用三级链接标题呈现，随后使用简短标注段落说明主要能力、描述和阶段。不要使用 Epic 列表表格。

使用各自匹配的模板创建

09-gap-analysis.md

、

10-roadmap-themes.md

、

11-governance-actions.md

和

12-risks-and-open-questions.md

。

在
```
09-gap-analysis.md
```
中，将开头的
```
Gap Analysis Summary
```
写为五个简短标注段落：当前情况、目标成果、最重要的差距、运营影响和建议响应措施。
在每个差距类别下，将每项不同差距作为三级标题呈现，随后使用简短标注段落或项目符号说明当前状态、目标状态、差距、影响和建议响应措施。
不使用差距分析对比表。如果某个类别没有已确认的差距，应简要说明，不要添加空表格或占位行。
在
```
10-roadmap-themes.md
```
中，将开头的
```
Roadmap Summary
```
写为三个简短标注段落：业务成果、排序方法和关键依赖关系。
在每个时间范围下，将每个路线图主题作为三级标题呈现，随后使用简短标注段落或项目符号说明成果、范围、依赖关系和建议顺序。不要使用路线图主题对比表。

在

12-risks-and-open-questions.md

中，依次按

High Risks

、

Medium Risks

和

Low Risks

对风险分组。

使用两位数标识符对三个分组中的风险统一连续编号，从
```
00
```
开始。
使用模板中的可复用区块呈现每项风险：编号风险名称、紧凑的 Likelihood 和 Owner 表格、Impact 章节、Mitigation 章节和水平分隔线。
如果某个严重程度分组没有已确认的风险，保留其标题，并按实际情况注明
```
_No confirmed high risks._
```
、
```
_No confirmed medium risks._
```
或
```
_No confirmed low risks._
```
。不要保留占位符或空的风险区块。

创建摘要文档前，对照
```
<private-lab-root>/GLOSSARY.md
```
检查已生成的章节文件，并补充起草过程中发现但缺失的术语、应用、数据对象和关系。

使用

templates/00-target-architecture-document-template.md

创建

00-target-architecture-document.md

，作为摘要和导航文档。

以标题和紧随其后的一句话文档用途开始
```
00-target-architecture-document.md
```
，不要添加用途标题。
对于每个编号详细页面，按以下顺序将其添加到
```
00-target-architecture-document.md
```
：

详细页面标题
紧随标题的一句话用途，不添加用途标题
从该详细页面的
```
Introduction
```
原样复制的
```
Management Summary
```
；不得改写、缩短或以其他方式重写
指向详细页面的链接

每个详细页面的
```
Introduction
```
应保持简洁并适合管理层阅读，因为它同时也是摘要文档的源文本。将详细分析、表格和实施细节保留在编号章节文件中。
将章节文件作为可供详细评审的产物。
```
00-target-architecture-document.md
```
文件是面向利益相关者的概览，并链接到这些详细章节。
将 Phase E 的
```
Epics To Build
```
章节保持为
```
_No linked epics yet._
```
，直到用户明确使用
```
../to-epics/SKILL.md
```
创建 Epic。生成的 Epic 文件应位于
```
<private-lab-root>/requirements/<name-of-target-architecture>/
```
下，而不是目标架构文件夹中。目标架构起草期间不得推断或创建 Epic。每个 Epic 都需要用户提供主要能力。
将 Phase C 的
```
Data Architecture Designs
```
表格保持为空，直到用户明确使用
```
../data-architecture-design/SKILL.md
```
创建数据架构设计。生成的数据架构设计文件应位于
```
<private-lab-root>/data-architectures/<data-object-slug>/
```
下，而不是目标架构文件夹中。

Guardrails

防护规则

Keep this public toolkit free of company-confidential information, customer names, internal system names, credentials, and non-public business context.
If using real company details, work in a private company lab repository and write outputs to that repository's
```
solution-architectures/
```
folder.
Do not invent specific enterprise facts. Mark unknowns as assumptions or open questions.
Prefer generic capability names unless the user is working in a private repository.
Do not create data architecture design documents automatically. Data architecture designs require an explicit target architecture link and canonical data object through the
```
data-architecture-design
```
skill.
Do not create epics automatically. Epics require explicit user-provided names, descriptions, and main capabilities through the
```
to-epics
```
skill.

确保此公共工具包不包含公司机密信息、客户名称、内部系统名称、凭据或非公开业务上下文。
如果使用真实公司详情，请在私有公司实验室仓库中工作，并将输出写入该仓库的
```
solution-architectures/
```
文件夹。
不得虚构具体企业事实。将未知内容标记为假设或待解决问题。
除非用户正在私有仓库中工作，否则优先使用通用能力名称。
不要自动创建数据架构设计文档。数据架构设计必须通过
```
data-architecture-design
```
skill 显式关联目标架构和规范数据对象后才能创建。
不要自动创建 Epic。Epic 必须通过
```
to-epics
```
skill，由用户提供明确的名称、描述和主要能力后才能创建。