企业官网建设流程全解析

简介：这份《数字化转型企业架构设计手册（交付版）》面向企业架构师、数字化转型负责人及IT规划人员，系统讲解企业架构（EA）从方法到落地的完整框架。内容围绕企业架构内容框架、现状分析、设计方法与管控方法四大板块展开，涵盖业务架构9个业务域、380个业务分类、1090个业务流程，数据架构10个数据域、71个数据主题、802个概念实体，以及应用架构与技术架构的模块划分与交互关系，并融合TOGAF与领域驱动设计（DDD）形成CSG-EAF 2.0总体框架。资源包共1个pptx文件，约6.3MB，以图文并茂的幻灯片形式呈现架构分层、元模型、制品清单与设计原则，便于直接用于汇报或培训。目前已有141人学习下载，适合需要搭建企业架构体系、梳理业务与IT映射关系、推进数字化变革落地的中高级从业者参考借鉴。

1. 数字化转型企业架构设计手册：105页交付版里到底装了什么

很多团队做数字化转型，PPT 画了一堆框框图，真到落地时业务、数据、应用、技术四条线各说各话，评审会上被问一句“这个应用模块挂在哪个业务域下”就卡壳。这份 105 页的《数字化转型企业架构设计手册（交付版）》就是冲着这个痛点来的——它不是概念科普，而是一套已经跑通的 EA 基线交付物模板，把业务架构、数据架构、应用架构、技术架构四层拆成了可清点的制品清单。手册里给出的基线数据很具体：业务架构 9 个业务域、380 个业务分类、1090 个业务流程、2523 个业务协作关系；数据架构 10 个数据域、71 个数据主题、802 个概念实体、2169 条数据分布；应用架构 10 个应用域、27 个应用、628 个应用模块、1114 条应用模块分布；技术架构 8 个技术域、23 个技术平台、266 个技术模块。适合正在搭 EA 框架的架构师、做数字化规划的产品经理，以及需要交付架构蓝皮书的咨询顾问。

2. CSG-EAF 2.0 框架拆解：TOGAF 与 DDD 怎么拼成一张图

这套手册的核心不是照搬 TOGAF，而是把传统架构设计方法和领域驱动设计做了融合，形成了一套叫 CSG-EAF 2.0 的总体框架。理解这个框架的拼接逻辑，比直接翻到制品清单更重要，因为后面所有设计步骤都是从这张框架图里推导出来的。

2.1 四层架构的输入输出关系

手册把企业架构分成业务架构（BA）、数据架构（IA）、应用架构（AA）、技术架构（TA）四层，但它们不是并列关系，而是有明确的上下游。业务架构是源头，定义企业做什么、怎么做；数据架构承接业务架构里的业务对象和业务活动，把它们抽象成概念实体和数据标准；应用架构再基于数据架构定义的数据模型，设计应用模块和服务；技术架构最后托底，提供技术组件、技术平台和部署节点。

这个链条在手册里有一句很关键的描述：通过业务价值流设计业务对象，基于业务对象设计数据标准，业务对象引用数据标准实现流程与数据的拉通设计。也就是说，业务对象是贯穿四层的那根针。如果你在业务架构阶段没有把业务对象识别清楚，后面数据模型就是空中楼阁，应用模块的功能项也会失去锚点。

手册里给出的架构元素层级也值得注意：架构元素（Element）是最小颗粒度，比如 Process、Activity、Organization、业务对象、逻辑实体、应用系统、应用系统模块；架构制品（Artifact）是工作产品，分结构化和非结构化；架构交付件（Deliverable）是由一系列 Artifact 实例组成的文档，比如财经 OLTP 架构蓝皮书。这个三层定义决定了你交付时到底交什么——不是交一堆图，而是交可清点、可追溯的制品集合。

2.2 双向设计过程：自顶向下与自下而上

手册明确说架构设计是“双向过程”。自顶向下是端到端业务流程和核心业务能力梳理，结合数字技术做优化，推动数字业务化；自下而上则是引入领域模型设计，把业务对象通过数据模型孪生到数字化世界，实现业务数字化。

这两条线在实操中对应不同的工作坊形式。自顶向下通常用价值流图做引导，从企业级价值流拆到专业级价值流，再拆到操作级流程；自下而上则是在具体业务域里做领域建模，识别核心对象和普通对象，再映射到数据模型。手册里有一张图专门画了这个对应关系：业务域、二级业务分类、业务能力、业务对象、业务服务、操作级业务流程、业务步骤，这些元素在两条线上是交叉引用的。

我一般会建议团队先跑一遍自顶向下的价值流梳理，把业务域和一级业务分类定下来，再选一个试点域做自下而上的领域建模。如果反过来，先做领域建模，很容易陷入细节，最后拼不成全局图。

2.3 架构管控的闭环设计

手册把架构管控单独列为一章，包括管控模式、组织、流程、标准规范和评估机制。这部分在 105 页里占的篇幅不算大，但它是让架构不变成“墙上挂图”的关键。手册里提到的架构遵从检查反馈机制，本质上是把架构制品和项目实施计划挂钩——立项时要引用架构制品，设计时要遵从架构原则，实施后要反馈架构变更。

一个常见的误区是把架构管控做成审批流程，每份文档都要架构师签字。手册里的做法更轻：通过架构资产运营支撑，让项目组自己就能查到该用哪个业务对象、哪个数据标准、哪个应用模块。管控的重心从“卡”变成“供”，这个思路在实操中阻力小很多。

3. 业务架构落地：从价值流到业务对象的五步操作

业务架构是四层里最容易被做成“业务功能列表”的一层。手册里给了明确的五步设计步骤，每一步都有输入、输出和成果物。照着这个步骤走，至少能保证业务架构不是拍脑袋拍出来的。

3.1 价值流梳理与业务域划分

第一步是价值流梳理，分企业级价值流和专业级价值流。企业级价值流图是全局视角，通常 5 到 8 条，比如资产全生命周期管理、供应链这类。专业级价值流是在某个业务域内展开，比如供应链域下的招标管理、非招标管理。

手册里给出的业务域数量是 9 个，一级业务分类 380 个。这个量级说明业务域划分不能太细，否则一级分类会爆炸。我一般会建议业务域控制在 8 到 12 个之间，一级业务分类每个域下不超过 50 个。如果超了，说明要么域划得太窄，要么分类颗粒度太细。

价值流梳理的输出是价值流图，输入是战略/愿景/策略、业务目标、政策法规、业务指标、组织架构。这里有个实操细节：政策法规和组织架构是约束条件，不是设计对象。业务架构定义的是角色，不是组织和岗位，手册里专门有一条原则说“定义角色，不直接定义组织和岗位，业务架构不与组织架构强耦合”。这条原则在组织调整频繁的企业里能省很多返工。

3.2 业务能力与业务流程的映射

第二步是业务能力梳理，第三步是业务流程梳理。手册里的逻辑是：基于专业级价值流分解的核心业务能力，被业务流程承载。也就是说，业务能力是“做什么”，业务流程是“怎么做”，两者是多对多的关系。

业务能力框架和业务流程清单是这一步的核心输出。手册里给出的业务流程数量是 1090 个，业务协作关系 2523 条。协作关系这个数字很关键，它决定了后面应用集成清单的复杂度。如果协作关系梳理不清楚，应用架构里的集成关系就会漏。

实操中，业务能力梳理容易犯的错是写成部门职责。手册里的原则第四条说得很直接：业务架构不是对业务职能的划分，要破除部门墙，防止业务孤岛。判断标准很简单——如果一条业务能力换个部门名字还能成立，那它可能是职能而不是能力。

3.3 业务对象识别与关键要素梳理

第四步是业务对象识别，第五步是关键要素梳理。业务对象是连接业务架构和数据架构的桥梁，手册里把业务对象分为普通对象和核心对象，业务活动也分普通活动和核心活动。核心对象和核心活动是领域建模的重点。

业务对象/BI 清单是这一步的输出之一。BI 在这里指的是业务指标（Business Indicator），不是商业智能。手册里把管理指标和操作指标分开梳理，操作指标要与操作级流程对应。这个区分很重要，因为管理指标通常跨流程，操作指标则绑定在具体流程步骤上。

关键要素梳理还包括识别业务步骤风险点和制定业务步骤控制措施。这部分在手册里篇幅不大，但在强监管行业里是刚需。风险点和控制措施要挂在业务步骤上，而不是挂在流程上，因为流程层面的风险描述太粗，落不到系统控制点。

4. 数据、应用、技术三层架构的制品清单与交付要点

业务架构定完之后，数据、应用、技术三层是并行推进的，但彼此之间有严格的引用关系。手册里给出的制品清单总共 35 个，本次设计新增 14 个，下面按层拆开说。

4.1 数据架构：从概念实体到数据分布

数据架构的起点是数据资产目录，包含数据域、数据主题、概念实体。手册里的基线是 10 个数据域、71 个数据主题、802 个概念实体。概念实体是从业务对象抽象出来的，一个业务对象可能对应多个概念实体，也可能多个业务对象映射到一个概念实体。

数据源清单和数据字典表是数据架构的落地制品。数据源清单要明确每个数据源的 Owner，手册里的原则第二条说“每个数据必须定义唯一的数据源和数据 Owner，实现同源共享”。这条原则在执行时最大的阻力来自历史系统——老系统往往多个源头写同一份数据，梳理时要先做数据源合并，再定 Owner。

逻辑数据模型和数据流图是设计制品，概念数据模型是规划制品。我一般会建议概念数据模型和逻辑数据模型分开评审，概念模型业务方要签字，逻辑模型 IT 方要签字。如果混在一起评审，业务方看不懂逻辑模型，IT 方不关心概念模型，最后两边都不负责。

4.2 应用架构：模块清单与集成关系

应用架构的核心制品是应用系统模块清单、功能项清单、功能子项清单、功能项分布清单、应用集成清单、应用服务目录。手册里的基线是 10 个应用域、27 个应用、628 个应用模块、292 个应用模块交互关系、1114 条应用模块分布。

应用模块的颗粒度是个容易翻车的地方。628 个应用模块分布在 27 个应用里，平均每个应用 23 个模块。如果模块拆得太细，集成关系会爆炸；拆得太粗，功能项分布就落不到具体模块上。手册里的做法是先按应用域划分，再按业务能力映射，一个业务能力至少对应一个应用模块，但不一定是一对一。

应用集成清单要和业务架构里的业务协作关系对齐。2523 条业务协作关系不可能全部变成应用集成，但每一条应用集成都应该能追溯到至少一条业务协作关系。如果追溯不上，要么是业务协作关系漏了，要么是应用集成设计多了。

4.3 技术架构：技术组件、平台与部署节点

技术架构的制品相对标准：技术组件清单、技术服务清单、技术平台清单、部署节点。手册里的基线是 8 个技术域、23 个技术平台、266 个技术模块。技术架构的原则是全面云化，沉淀企业公共能力，实现各业务场景灵活调用和共享。

技术组件和技术服务的区别在于：组件是部署单元，服务是调用接口。一个技术组件可以暴露多个技术服务，一个技术服务也可以由多个组件实现。部署节点是技术架构和应用架构的交汇点，应用模块最终要部署到节点上，节点的规格和数量决定了应用的性能和可用性。

手册里有一条原则是“应用、平台、基础设施全面云化”，但云化不等于全部上公有云。实操中，核心交易类应用通常部署在私有云或混合云，边缘计算类应用部署在靠近数据源的节点。部署节点的设计要结合数据分布来定，数据分布在哪里，计算就应该尽量靠近哪里。

5. 避坑与排查：架构设计交付中最容易翻车的五件事

这一章不讲理论，只讲我在类似项目里踩过的坑。每一条都按现象、原因、解决来写，能对上号的可以直接拿去排查。

5.1 业务对象识别太粗，数据模型返工

现象：数据架构设计到逻辑模型阶段，发现概念实体和业务对象对不上，业务方不认，IT 方改不动，返工重做业务对象识别。

原因：业务架构阶段为了赶进度，业务对象只识别到业务域级别，没有拆到业务活动级别。手册里明确说业务对象识别要结合业务活动梳理，普通对象和核心对象要分开。如果只识别核心对象，普通对象在数据模型阶段会大量涌现，导致模型不稳定。

解决：业务对象识别至少要做到业务活动级别，每个核心业务活动至少对应一个核心对象。识别完后用业务对象/BI 清单做一次交叉检查，确保每个业务域下的业务对象数量与业务分类数量匹配。如果某个域的业务对象数量明显偏少，大概率是漏了。

5.2 应用模块颗粒度失控，集成关系爆炸

现象：应用架构设计完成后，应用集成清单有上千条，评审时没人能说清楚哪些是必要的，哪些是冗余的。

原因：应用模块拆得太细，每个功能项都拆成了独立模块，导致模块间交互关系数量呈指数增长。手册里的基线是 628 个应用模块对应 292 个交互关系，平均每个模块不到 0.5 个交互。如果交互关系数量超过模块数量，说明模块拆细了。

解决：应用模块的拆分粒度以“能否独立部署和独立升级”为标准。如果两个模块必须同时部署、同时升级，就应该合并。另外，应用集成清单要和业务协作关系做双向追溯，追溯不上的集成关系要么删掉，要么补业务协作关系。

5.3 数据 Owner 定不下来，同源共享变成口号

现象：数据源清单里多个系统写同一份数据，每个系统都说是自己维护的，数据 Owner 迟迟定不下来，数据质量越拖越差。

原因：历史系统建设时没有数据架构管控，各系统按需建表，数据冗余是既成事实。到了架构设计阶段，让任何一个系统放弃写权限都涉及利益调整，推动阻力大。

解决：手册里的原则是“每个数据必须定义唯一的数据源和数据 Owner”，但实操中要分步走。第一步先定数据 Owner，不急着砍数据源；第二步在新系统建设时强制引用数据标准，不再新建冗余数据源；第三步等老系统退役时自然收敛。如果一上来就要求砍数据源，项目大概率推不动。

5.4 架构管控变成审批流程，项目组绕道走

现象：架构管控流程上线后，项目组为了赶进度，先开发再补架构文档，架构遵从检查变成事后补签。

原因：管控流程设计得太重，每个阶段都要架构师审批，审批周期长，项目组等不起。手册里提到的架构管控模式是“支撑和运营”，不是“审批和卡点”。

解决：把架构管控的重心从审批转到供给。架构资产要能让项目组自助查询，业务对象、数据标准、应用模块、技术服务都要有清晰的检索入口。项目组在立项和设计阶段能查到该用什么，就不需要事后补签。审批只保留关键节点，比如架构变更和新增应用模块。

5.5 技术平台重复建设，云化变成堆资源

现象：技术架构设计完成后，发现多个业务域各自建了类似的技术平台，云化没有带来共享，反而增加了资源浪费。

原因：技术平台建设没有和应用架构、数据架构对齐。业务域按自己的需求建平台，技术架构师没有提前介入，导致平台功能重叠。

解决：技术平台清单要和业务域、应用域做交叉矩阵。如果两个业务域的技术平台功能重叠超过 50%，就应该合并或至少共享底层组件。手册里的原则是“沉淀企业公共能力，实现各业务场景灵活调用和共享”，公共能力的识别要在技术架构设计阶段完成，不能等到建设阶段再协调。

6. 架构制品清单的裁剪技巧：35 个制品怎么按项目规模选

手册里给出的 35 个架构制品不是每个项目都要全交。105 页的交付版是完整版，但实际项目里，制品清单要根据项目规模、行业监管要求和团队成熟度做裁剪。裁剪错了，要么交付物不够被审计挑刺，要么做了一堆没人看的文档。

6.1 制品裁剪的三个维度

第一个维度是项目类型。如果是集团级 EA 基线项目，35 个制品基本都要交，因为基线要覆盖全集团。如果是单个业务域的架构设计项目，业务架构和数据架构的制品可以保留，应用架构和技术架构的制品可以简化，比如应用集成清单可以只交域内集成，域间集成引用基线。

第二个维度是监管要求。强监管行业对数据架构的制品要求更细，数据源清单、数据字典表、数据流图通常不能裁剪。业务架构里的风险点和控制措施也不能裁，因为审计要查。应用架构和技术架构的制品相对灵活，可以根据项目范围调整。

第三个维度是团队成熟度。如果团队第一次做 EA，建议先交核心制品，比如业务能力清单、业务流程清单、业务对象清单、数据资产目录、应用系统模块清单、技术组件清单。等团队熟悉了再逐步增加制品。如果一上来就要求全交，团队会被文档压垮，架构设计变成填表。

6.2 制品之间的引用关系检查

裁剪制品时最容易出的问题是引用断裂。比如保留了应用系统模块清单，但裁掉了业务能力清单，应用模块就失去了业务锚点。或者保留了数据资产目录，但裁掉了业务对象清单，数据域和业务域的对应关系就断了。

我一般会建议在裁剪前先画一张制品引用关系图，标出哪些制品是其他制品的输入。被引用的制品不能裁，引用别人的制品可以裁。手册里的制品清单是按业务架构、数据架构、应用架构、技术架构分组的，但引用关系是跨组的，裁剪时要跨组检查。

6.3 一个可复用的裁剪模板

下面这张表是我在多个项目里用过的裁剪模板，按项目规模分三档。表格里的“必交”是指不交会影响架构完整性，“选交”是指根据项目范围决定，“可裁”是指不影响核心架构。

这张表不是标准答案，但能帮你快速判断哪些制品不能省。裁剪的原则是：业务对象、数据源、应用模块这三样是跨层引用的锚点，不管什么规模的项目都建议保留。其他制品可以根据项目范围灵活处理。

6.4 交付前的自检习惯

从那以后我每次交付架构制品前，都会强制走一遍三个检查：第一，业务对象清单和数据资产目录做一次交叉比对，确保每个核心业务对象都能在数据资产目录里找到对应概念实体；第二，应用系统模块清单和业务能力清单做一次映射检查，确保每个应用模块至少支撑一个业务能力；第三，技术组件清单和应用模块清单做一次部署检查，确保每个应用模块都有明确的部署节点。这三个检查走完，架构的骨架就稳了，剩下的细节可以在评审中逐步完善。希望帮到你。

本文还有配套的精品资源，点击获取