企业架构实践（四）：从系统接口到数据架构——数据来源、流向与一致性

一、系统之间传递的是数据，但数据本身也有架构

在上一篇文章中，我们讨论了企业应用集成，介绍了 Web Service、RabbitMQ 和集成服务在系统交互中的作用。

通过这些技术，ERP、MES 和 WMS 等系统可以交换业务信息，支持不同业务环节之间的协作。

但继续往下分析，会发现一个问题：

系统之间完成了数据传递，并不代表数据管理的问题已经解决。

例如，ERP 将物料信息发送给 MES，MES 接收后可以使用这些信息。但我们还需要进一步了解：

• 物料信息最初由哪个系统维护？
• 哪个系统负责审核和发布？
• 其他系统中的物料信息是否允许修改？
• 物料信息发生变化后，如何同步到其他系统？
• 如果同步失败，如何发现和恢复？
• 不同系统中的同一物料，如何确认是同一个业务对象？

这些问题已经不只是接口开发的问题，而是涉及企业的数据管理方式。

学习 TOGAF Standard 10 时，我逐渐认识到，数据架构（Data Architecture）并不是简单地整理数据库表结构，也不只是建立一个数据仓库。

它需要从企业整体的角度，理解数据有哪些、数据由谁管理、数据如何流转，以及不同系统之间如何使用这些数据。

对于制造企业而言，物料、BOM、客户、供应商、生产订单和库存等数据，都可以作为理解数据架构的切入点。

二、先区分业务数据与技术数据

在日常 IT 工作中，我们经常会接触各种数据。

数据库中有表和字段，接口中有 JSON 或 XML 报文，消息队列中有消息内容，报表平台中有各种指标。

但这些数据并不都属于同一个层次。

从企业架构的角度来看，可以先简单区分为两类。

2.1 业务数据

业务数据直接描述企业的业务对象和业务活动。

例如：

这些数据有明确的业务含义。

例如，物料数据描述企业生产或经营过程中使用的物料；BOM 描述产品组成；生产订单描述生产任务；库存数据反映某个业务时点或业务范围内的库存情况。

它们可能分布在多个系统中，但并不意味着每个系统都应该拥有完整的管理权限。

2.2 技术数据

技术数据主要用于支持系统运行和技术处理。

例如：

• 数据库连接信息。
• API 请求日志。
• 消息队列状态。
• 应用运行日志。
• 监控指标。
• 系统配置。
• 文件存储元数据。

这些数据对于系统运行、故障排查和技术管理非常重要。

例如，RabbitMQ 中的消息可以携带生产订单相关数据，但消息本身属于技术传输过程中的载体，生产订单才是业务对象。

同样，数据库中的一条记录只是业务数据的一种存储形式，不能把数据库表直接等同于企业的数据架构。

数据架构关注的是数据本身的业务含义和管理关系，而不仅仅是数据存放在哪里。

三、理解主数据：谁负责维护数据？

在制造企业中，有一类数据非常值得优先梳理，那就是主数据（Master Data）。

主数据通常是多个业务流程和应用系统共同使用的基础数据。

例如：

• 物料。
• 客户。
• 供应商。
• 产品。
• 组织。
• 员工。

如果这些数据在不同系统中各自维护，就容易出现编码不一致、名称不一致、属性不一致等问题。

3.1 多个系统使用同一类数据，不代表多个系统都应该维护它

假设企业同时使用 ERP、MES 和 WMS。

这三个系统都可能使用物料信息。

但它们使用物料信息的目的不同：

• ERP 可能使用物料信息支持采购、销售、库存和生产计划。
• MES 可能使用物料信息支持生产执行和物料消耗。
• WMS 可能使用物料信息支持收货、上架、拣货和库存管理。

因此，需要进一步明确：

哪个系统负责维护物料的基础信息？

哪个系统负责审核物料数据？

哪个系统只负责接收和使用物料数据？

如果三个系统都允许独立修改同一物料的关键属性，就可能出现数据不一致。

例如，ERP 中的物料名称已经修改，但 MES 和 WMS 仍然保留旧名称；或者不同系统对同一个物料使用了不同的编码。

这类问题并不一定是接口故障，而可能是数据管理职责不清晰造成的。

3.2 什么是权威数据源？

在数据架构中，经常会遇到一个概念：权威数据源（Authoritative Source）。

简单来说，就是针对某一类数据，明确由哪个系统或业务部门负责提供权威信息。

例如，可以根据企业实际管理方式，为物料、客户和供应商分别确定权威数据源。

这里需要强调：

权威数据源不一定是所有数据都存放的地方，而是负责维护和确认某类数据正确性的来源。

其他系统可以保存数据副本，用于自己的业务处理，但不一定拥有修改和发布该数据的权限。

举个例子：

如果企业规定 ERP 负责维护物料主数据，那么 MES 可以接收物料信息并用于生产业务，但不应随意修改 ERP 负责管理的关键主数据属性。

如果 MES 需要补充生产执行过程中产生的信息，则可以由 MES 管理这些生产执行数据。

这样，不同系统就有了相对清晰的数据管理边界。

3.3 一个系统不一定是所有数据的唯一权威来源

在实际企业环境中，不同数据可能由不同系统负责。

例如：

这张表只是用于说明不同数据可能有不同的管理来源，并不是对所有制造企业的统一规定。

实际情况需要结合业务流程和系统职责确认。

例如，BOM 可能由 PLM 管理，也可能由 ERP 管理；客户信息可能由 CRM 管理，也可能由 ERP 作为主要维护系统。

不能仅凭系统名称决定数据归属。

四、数据在不同系统之间如何流动？

明确数据来源之后，下一步就是梳理数据流向。

这一点与上一篇讨论的应用集成有直接关系。

应用架构关注系统之间如何交互，而数据架构还需要进一步关注交互的具体内容。

4.1 以 D365 F&O 与 MES 为例

目前，D365 F&O 与 MES 之间的集成链路为：

D365 F&O ↔ ERP Sync Service ↔ RabbitMQ ↔ MES

这条链路不仅涉及系统之间的连接，还涉及业务数据的传递。

例如，相关业务数据包括：

• 生产工单。
• 物料信息。
• BOM。
• 库存等相关信息。
• 生产报工和完工数据。

从业务角度来看，可以初步理解为：

这里需要注意，表格中的业务方向是从整体业务关系进行归纳，具体接口可能存在多个处理阶段，实际方向和字段范围仍然需要以接口定义为准。

数据流向与技术链路也不是一回事。

例如，生产工单从 ERP 侧传递到 MES，在技术实现上仍然需要经过 ERP Sync Service 和 RabbitMQ。

因此，完整的数据流分析需要同时考虑：

1. 数据从哪个业务系统产生。
2. 数据经过哪些集成组件。
3. 数据最终由哪个系统接收。
4. 接收方如何处理和保存数据。
5. 处理结果如何反馈或确认。

如果只画一条从 ERP 指向 MES 的箭头，就无法表达完整的技术实现。

如果只画 ERP Sync Service 和 RabbitMQ 的连接，也无法说明传递的业务数据是什么。

这两种信息需要结合起来看。

4.2 以 ERP 与 WMS 为例

ERP 与 WMS 之间通过 Web Service 进行集成。

在数据架构分析中，可以进一步整理：

• 哪些数据由 ERP 提供给 WMS？
• 哪些数据由 WMS 返回 ERP？
• 数据是实时调用还是批量处理？
• 接口返回成功代表什么？
• 数据处理失败后如何重新处理？
• 如何确认两边的数据保持一致？

例如，库存相关数据在 ERP 和 WMS 中可能都有记录。

但需要注意，两个系统中的库存数据未必具有完全相同的业务含义。

WMS 可能更关注仓库、库位、批次和实际作业数量；ERP 可能更关注财务库存、业务库存以及相关业务单据。

如果不先明确库存数据的定义，就很容易在接口开发和报表统计中产生理解偏差。

因此，数据架构不仅要记录数据流向，还需要理解数据在不同业务系统中的含义。

五、为什么多个系统之间容易出现数据不一致？

数据不一致是企业系统集成中比较常见的问题。

即使接口已经正常运行，也不代表不同系统中的数据一定完全一致。

原因可能来自多个方面。

5.1 数据同步失败

例如，ERP 已经创建了一条生产订单，但由于接口异常，MES 没有成功接收。

此时，两个系统中的业务数据状态就可能不同。

如果没有相应的异常记录和补偿机制，这类问题可能一直存在，直到业务人员发现。

5.2 数据更新不同步

假设 ERP 中某个物料的基础信息发生变化。

如果相关变更没有及时传递到 MES 或 WMS，其他系统就可能继续使用旧数据。

这不一定意味着接口完全失败，也可能是同步延迟或变更事件没有被正确处理。

5.3 重复数据处理

在接口重试或消息重新投递的情况下，同一条业务数据可能被重复处理。

例如，同一笔生产报工如果被重复提交，可能导致数量重复累计。

因此，对于重要业务数据，需要考虑幂等性（Idempotency）。

简单来说，就是同一项业务请求即使被重复提交，也应该能够避免产生不符合预期的重复业务结果。

5.4 数据定义不一致

这是比较容易被忽视的一种情况。

例如，ERP 和 MES 都有库存数量字段，但两边的统计范围可能不同。

一个系统可能记录账面库存，另一个系统可能记录实际可用库存；一个系统按仓库统计，另一个系统按库位和批次统计。

字段名称相同，不代表业务含义相同。

因此，在数据架构中，需要关注数据定义和业务口径，而不仅仅是字段名称。

5.5 数据处理顺序不同

有些业务数据存在先后依赖。

例如，生产订单可能依赖物料信息和 BOM 信息。

如果生产订单先到达，而相关物料或 BOM 数据尚未准备好，MES 就可能无法正常处理该订单。

这种情况说明，数据集成不仅要关注数据是否传递，还需要考虑数据之间的依赖和处理顺序。

六、数据一致性应该如何管理？

数据一致性不是简单地通过定时同步就能够完全解决的。

需要根据不同数据的业务重要性和使用方式，确定合适的管理机制。

6.1 明确数据的管理责任

首先，需要明确每类数据由谁维护。

例如：

• 哪个系统负责创建？
• 哪个系统负责修改？
• 哪个系统负责审核？
• 哪个系统负责发布？
• 其他系统是否允许修改相关数据？

如果这些职责不清晰，接口越多，数据管理就越复杂。

因此，数据架构应该与业务管理流程结合起来。

6.2 明确数据同步机制

不同数据可能需要不同的同步方式。

例如：

这些方式没有绝对的优劣。

需要根据业务时效性、数据规模、系统能力和运维成本综合选择。

例如，某些基础资料的变更可以采用事件驱动或定时同步，而某些业务操作可能要求及时返回处理结果。

6.3 建立异常处理和补偿机制

数据同步失败后，不能只依赖人工发现。

可以根据实际情况建立：

• 接口调用日志。
• 消息处理状态。
• 失败记录。
• 重试机制。
• 人工补偿入口。
• 数据核对机制。

例如，对于重要生产数据，可以定期比较 ERP 与 MES 中的关键业务记录，发现长时间未完成同步的数据。

这里的重点不是追求所有数据实时一致，而是根据业务要求明确允许的延迟范围，并确保异常能够被发现和处理。

6.4 明确数据一致性的业务要求

不同数据对一致性的要求可能不同。

例如，物料基础信息发生变化后，其他系统可能允许短时间内存在同步延迟。

但对于某些关键生产业务数据，如果长期没有同步，就可能影响生产执行。

因此，需要根据数据的重要性确定相应的要求。

可以从以下几个方面考虑：

• 数据允许延迟多久？
• 发生不一致后，多久需要发现？
• 哪些数据必须及时处理？
• 哪些数据允许批量同步？
• 数据不一致时由哪个部门或系统负责处理？

这些要求最终需要与业务部门共同确认。

技术人员可以提供实现方案，但数据管理规则不能完全由技术实现来代替。

七、从数据架构角度重新审视企业系统

通过前面的分析，可以看到，数据架构并不是独立于应用架构存在的。

它与业务架构、应用架构和技术架构都有密切关系。

7.1 与业务架构的关系

业务架构决定企业需要哪些业务数据，以及这些数据在业务流程中如何使用。

例如，生产订单、物料和 BOM 都与生产业务有关。

如果不理解业务流程，就很难准确判断这些数据的来源和管理责任。

7.2 与应用架构的关系

应用架构说明哪些系统负责创建、处理和使用数据。

例如，D365 F&O、ERP Sync Service、RabbitMQ 和 MES 共同参与相关生产数据的传递。

如果不了解应用之间的关系，就很难完整描述数据流向。

7.3 与技术架构的关系

技术架构提供数据存储和传递的运行基础。

例如：

• PostgreSQL 和 MySQL 用于关系型数据存储。
• RabbitMQ 用于消息传递。
• MinIO 用于对象存储。
• NFS 提供网络文件存储访问。
• Dremio 和 Superset 支持数据查询与分析。

但需要注意，使用同一种数据库或数据平台，并不意味着不同系统之间已经建立统一的数据管理机制。

技术平台解决的是数据存储、访问和处理方面的问题，而数据架构还需要解决数据含义、来源、责任和使用规则等问题。

八、下一步：从数据清单走向数据架构

如果要进一步开展数据架构梳理，我认为可以先从几个简单的工作开始。

8.1 建立核心数据清单

先整理企业主要业务数据，例如：

• 物料。
• 产品。
• BOM。
• 客户。
• 供应商。
• 生产订单。
• 生产报工。
• 库存。
• 采购订单。
• 销售订单。

不需要一开始就覆盖所有字段，先明确数据类别和业务含义即可。

8.2 明确数据来源和管理责任

为每类数据确定：

• 主要维护系统。
• 业务责任部门。
• 数据使用系统。
• 是否存在多个系统分别维护的情况。

这一步可以帮助发现数据管理职责不清晰的问题。

8.3 梳理关键数据流

针对重要业务流程，绘制数据流向图。

例如：

生产工单从 ERP 侧进入 MES，MES 完成生产执行后，再将报工和完工相关数据反馈到 ERP 侧。

同时记录实际经过的集成组件和接口方式。

8.4 建立数据质量与一致性检查机制

根据业务需要，逐步补充数据校验规则、同步状态、异常处理和数据核对机制。

对于关键数据，可以明确数据质量要求和异常处理责任。

这些工作不一定要一次性完成，可以从影响较大的业务数据开始。

九、这一阶段的实践总结

通过从应用集成进一步分析数据流转，我对数据架构有了更具体的认识。

数据架构并不只是数据库设计，也不只是把不同系统中的数据集中起来。

它需要回答一些更基础的问题：

• 企业有哪些重要业务数据？
• 每类数据由谁负责维护？
• 哪个系统是权威数据源？
• 数据如何在不同系统之间流转？
• 不同系统如何理解和使用同一类数据？
• 数据不一致时如何发现和处理？

这些问题与企业业务流程密切相关，也会影响应用集成和系统建设。

对于制造企业而言，ERP、MES 和 WMS 之间的数据交互只是其中一部分。随着系统数量和业务复杂度增加，数据来源、数据标准、数据质量和数据管理责任都会变得更加重要。

我目前的理解是，数据架构的第一步并不是设计一个庞大的数据平台，而是先把核心业务数据梳理清楚，明确它们的来源、用途和流转关系。

只有先理解数据，后续的数据集成、数据分析和数据治理才有比较可靠的基础。

下一篇，我准备继续回到企业 IT 的整体视角，讨论另一个重要领域：技术架构（Technology Architecture）。从 Linux、VMware、Kubernetes、数据库、中间件和存储等现有技术环境出发，看看如何理解技术平台之间的依赖关系，以及如何从系统运行环境逐步形成技术架构视图。