企业官网建设流程全解析

很多企业都画过架构图。

图上有ERP、CRM、数据中台、数据库、接口、服务器和云平台，系统之间连着密密麻麻的线。但真正追问时，往往没人能讲清：

• 这些系统分别支撑什么业务能力？

• 哪些功能正在重复建设？

• 一项战略调整会影响哪些流程和数据？

• 哪些系统应该保留、整合或者下线？

• 未来三年的建设顺序是什么？

问题在于，企业画出了IT现状，却没有真正建立企业架构。

在正式展开之前，我整理了一套《数据仓库建设解决方案》，包含数据平台建设、数据治理和系统整合等实践内容。正在做数字化规划、数据架构或系统升级的读者，可以结合本文一起参考。

资料包需要自取：https://s.fanruan.com/7igmg（复制到浏览器）

一、企业架构不是一张图，而是一套企业设计方法

企业架构，英文是Enterprise Architecture，简称EA。

很多人看到“架构”，首先想到系统、数据库和服务器。实际上，企业架构首先解决的是经营问题，其次才是技术问题。

它要回答的是：

企业为了实现战略目标，需要具备哪些业务能力？这些能力应由什么流程、组织、数据、应用和技术共同支撑？

例如，一家制造企业准备从“销售设备”转向“设备全生命周期服务”。

这不是增加一套售后系统就能完成的，而是需要一系列联动：

• 业务上，增加远程监控、预测性维护和服务续费能力；

• 流程上，打通设备交付、运行监测、故障预警和工单处理；

• 数据上，采集设备状态、维修记录、备件消耗和客户使用数据；

• 应用上，连接MES、IoT平台、CRM、工单和财务系统；

• 技术上，解决设备接入、实时传输、存储计算与权限控制。

因此，企业架构的本质，是把战略逐层翻译成业务能力、业务流程、数据、应用和技术。

一套完整的企业架构，通常包含四个核心领域：

业务架构

说明企业做什么，依靠哪些能力、流程、组织和规则完成。

数据架构

说明企业需要哪些数据，数据由谁负责，如何定义、流动、共享和治理。

应用架构

说明哪些应用支撑业务流程，各应用之间怎样分工、集成和协作。

技术架构

说明应用运行在什么技术底座上，以及如何满足性能、安全、稳定性和扩展性要求。

四类架构必须能够上下追溯：战略决定能力，能力依赖流程，流程产生数据，应用承载流程，技术支撑应用。

实际盘点时，架构图上的数据流不一定等于真实的数据流。某些系统标注为“实时共享”，落地后可能仍靠人工导出Excel；某项指标声称来自ERP，计算时却又拼接了财务和业务部门各自维护的文件。

此时可以先用FineDataLink 5.0接入相关数据库、接口和文件，把数据来源、同步方向与更新周期跑出来，再对照架构图核验。这样识别出的不是“图上应该怎样流”，而是数据当前究竟怎样流。

二、企业架构和技术架构，区别到底在哪里？

二者最大的区别是观察范围不同。

企业架构站在企业整体视角，技术架构站在技术实现视角。

假设企业准备建设统一客户经营平台。

企业架构关心的是：

• 为什么要建设客户经营平台？

• 它支撑哪些战略目标和业务能力？

• CRM、电商、客服和会员系统怎样分工？

• 客户主数据由谁维护？

• 哪些旧系统需要整合或退出？

• 项目应分几个阶段实施？

技术架构则继续向下回答：

• 系统采用单体还是微服务架构？

• 数据库、缓存和消息队列怎样选型？

• 服务之间怎样通信？

• 如何实现高可用、容灾和弹性扩展？

• 身份认证、日志监控和接口安全如何设计？

所以，技术架构是企业架构的一部分，但企业架构不等于技术架构。

现实中，不少“企业架构项目”最后变成技术选型项目：讨论云原生、微服务和数据湖，却没有说明这些技术究竟支撑哪项业务变化。

判断一项技术建设是否必要，可以沿着链路向上追问：

这项技术支撑哪个应用？

应用承载哪个流程？

流程形成哪项业务能力？

能力又服务于什么战略目标？

如果无法回答，技术方案可能只是局部优化，还不能称为企业架构决策。

三、4C模型是什么？它和企业架构不是一回事

不少人习惯写“4C模型”，更通行的名称其实是C4模型。

C4由四个层级组成。

Context：系统上下文

说明目标系统处在什么环境中，与哪些用户和外部系统发生关系。

这一层不讨论数据库和代码，主要回答：系统为谁服务、解决什么问题、依赖哪些外部对象。

Container：容器

这里的Container不只指Docker容器，而是能够独立运行或部署的应用单元，例如Web应用、移动端、后端服务、数据库和消息系统。

这一层回答：系统由哪些主要单元组成，每个单元承担什么职责，彼此怎样通信。

Component：组件

继续拆解容器内部的模块。例如订单服务可以拆成价格计算、库存校验、支付处理和通知组件。

Code：代码

深入到类、接口、函数或代码模块。由于这一层变化频繁，通常只对核心、复杂或高风险模块绘制，不必覆盖整个系统。

C4的价值不在于把图画得更细，而在于针对不同对象控制信息粒度。管理者看Context，架构师看Container，开发负责人看Component，开发人员再深入Code。

画数据平台的Container图时，我们项目组会把FineDataLink 5.0作为数据集成单元放入架构：

上游连接业务数据库、API和文件，下游连接数仓与分析平台。继续下钻到Component层，才展开数据连接、转换任务、调度依赖和运行监控。这样，同一套架构既能说明平台边界，也能支撑后续任务设计。

但要注意，C4是一种软件架构表达方法，不是完整的企业架构方法。它能够讲清系统内部结构，却不会自动回答战略目标、业务能力、投资优先级和架构治理问题。

四、TOGAF是什么？重点不是模板，而是ADM

TOGAF是企业架构领域常见的方法框架，其核心是ADM，即架构开发方法。

ADM形成了一套持续循环：

1. 明确架构愿景与建设范围；

2. 设计业务架构；

3. 设计数据与应用架构；

4. 设计技术架构；

5. 识别实施方案和工作包；

6. 制定迁移顺序与投资计划；

7. 开展实施治理；

8. 根据业务变化持续调整架构。

很多企业应用TOGAF时，容易把它理解成文档目录：业务架构做一份PPT，数据架构画几张主题域，应用架构列一张系统清单，技术架构再补一张部署图。

真正重要的是建立三种状态之间的关系：

• 现状架构：当前能力、流程、数据和系统存在哪些问题；

• 目标架构：未来需要形成什么能力和结构；

• 迁移架构：从现状走向目标，中间需要经过哪些阶段。

例如，目标是建立统一经营数据平台，但当前ERP、CRM和供应链系统不能一次性全部改造。

迁移阶段往往先保留原系统，通过FineDataLink 5.0建立同步链路，将分散数据汇入统一数据层；

待指标口径、主数据和应用边界稳定后，再逐步调整接口和替换旧任务。这里的数据链路不是最终架构本身，而是现状向目标过渡时的一部分。

没有迁移路线的目标架构只是一张愿景图，没有实施治理的架构则容易被项目逐步架空。

五、企业架构、技术架构、C4和TOGAF怎样放在一起？

这几个概念不是竞争关系，而是分别解决不同层面的问题：

• 企业架构定义企业需要管理哪些业务与IT关系；

• 技术架构解决系统运行、集成、安全和性能问题；

• TOGAF指导现状分析、目标设计、迁移与治理；

• C4用分层视图表达软件系统的结构。

可以把它们概括为：

企业架构定义“要管理什么”，

TOGAF说明“架构工作怎样推进”，

技术架构回答“技术底座怎样实现”，

C4负责“系统结构怎样表达”。

以供应链协同建设为例，企业架构先识别采购协同、交付跟踪和库存共享能力；TOGAF用于分析现状、设计目标并制定迁移路径；技术架构确定接口、消息、安全和部署规范；C4再把供应链平台及内部结构画清楚。

进入数据链路建设时，采购、库存、订单和财务数据会按照目标架构重新确定流向。

实际任务在FineDataLink 5.0中按全量初始化、增量同步、字段转换和调度依赖分别配置，架构评审时再结合运行记录检查数据时效、上下游依赖和异常恢复情况。

此时，架构不只存在于图中，也能从具体链路验证设计是否成立。

六、企业架构真正落地，需要抓住五个步骤

第一步：从高价值业务问题切入

不要一开始就盘点所有系统。可以先选择订单交付周期过长、客户数据分散、库存无法协同等具体问题。

场景越明确，越容易判断需要哪些能力、数据和系统。

第二步：建立“战略—能力—流程”关系

明确战略目标需要哪些业务能力，每项能力通过哪些流程实现，并识别能力短板。

企业缺少的可能不是系统，而是跨部门流程、统一规则或明确的数据责任。

第三步：建立“流程—数据—应用”关系

继续识别每个流程产生什么数据、使用什么数据、由哪些应用承载。

这一阶段重点识别三类问题：

• 同一能力被多个系统重复建设；

• 同一数据存在多个来源和口径；

• 流程已经跨部门，系统边界仍按部门割裂。

第四步：设计现状、目标与迁移架构

目标架构不能只描述最终状态，还要说明哪些系统保留、哪些整合、哪些下线，以及每个阶段交付什么业务价值。

迁移顺序通常要同时考虑业务价值、技术依赖、实施风险和数据基础，而不能只按照系统上线时间排列。

第五步：把架构治理嵌入项目流程

新系统立项、接口调整、数据口径变化和旧系统下线，都应检查是否符合目标架构。

架构治理不是要求所有项目机械遵守旧图，而是持续回答：

• 新需求能否复用已有能力？

• 是否正在重复建设系统？

• 数据责任和来源是否清楚？

• 项目是否偏离目标架构？

• 原定架构是否已经不适应业务变化？

架构既要约束项目，也要接受项目实践的反向验证。

结语

企业架构最容易被误解成一张庞大的系统关系图。

但它真正要做的，是把企业战略翻译成业务能力，把能力落实到流程、数据和应用，再通过技术建设、迁移项目与持续治理完成实施。

企业架构解决整体方向，技术架构解决技术实现，TOGAF提供推进方法，C4负责分层表达。

当这四者被放在正确的位置上，架构才会从技术部门的图纸，变成企业共同判断“为什么建设、建设什么、先做什么、如何持续演进”的决策工具。