企业架构实践（二）：从系统清单到应用关系图

一、知道有哪些系统，还不够

在上一篇文章中，我从日常 IT 管理工作的角度，梳理了企业现有的业务系统、集成服务、公共平台和基础设施。

这项工作让我对企业 IT 环境有了一个初步的整体认识。

但整理完系统清单后，一个问题也随之出现：

如果这些系统之间存在各种联系，我们应该如何把它们的关系表达清楚？

以制造企业为例，ERP、MES 和 WMS 分别承担不同的业务职责。它们可能需要交换业务数据，也可能依赖一些公共服务。如果只把这些系统罗列在一张表格中，就很难看出系统之间的实际联系。

在日常运维中，这些关系可能已经存在于我们的经验里。

例如，MES 与 ERP 之间的数据同步出了问题，我们可能知道应该检查哪些服务；某个应用无法访问文件，我们也可能知道需要检查哪些存储组件。

但是，如果这些信息只存在于个人经验中，就不容易统一理解，也不方便交接、评审和后续规划。

因此，我想尝试把系统清单进一步整理成应用关系图。

这并不是为了画一张看起来复杂的架构图，而是希望通过一种比较直观的方式，说明系统各自承担什么职责、系统之间如何交互，以及一个系统发生变化时，可能会影响哪些其他系统。

二、应用关系图应该表达什么？

应用关系图（Application Relationship Diagram）可以用来展示企业应用及其相互关系。

具体需要表达什么，取决于这张图的用途。

如果用于向管理人员介绍企业 IT 环境，可能只需要展示主要业务系统和它们之间的关系。

如果用于技术评审或故障分析，就需要进一步展示集成服务、消息中间件、接口类型，以及必要的技术依赖。

如果用于规划未来架构，还需要区分现有系统、计划建设的系统，以及希望达到的目标状态。

因此，画图之前，最好先明确目的。

对于当前的学习和实践，我准备先聚焦于两个问题：

1. 主要应用系统之间有哪些业务交互？
2. 这些交互是通过什么技术方式实现的？

这两个问题看似简单，但已经可以帮助我们发现不少容易被忽略的细节。

2.1 先区分系统职责

在画图之前，应该先明确各系统的职责。

以目前的环境为例：

这张表主要用于说明系统职责，而不是完整的技术设计。

例如，D365 F&O 和易飞 ERP 都属于 ERP 系统，但它们服务于不同的业务环境，目前是独立运行的两套系统。

不能仅仅因为它们都属于 ERP，就把它们画成存在直接交互关系的两个系统。

同样，ERP Sync Service 虽然名称中带有 ERP，但它在当前环境中不仅仅是一个可以忽略的辅助程序，而是 D365 F&O 与后续集成环节之间的独立集成组件。

在应用关系图中，应该把它单独表示出来。

系统的名称可以帮助我们理解它的用途，但真正决定架构图如何绘制的，是它在实际业务和技术环境中的职责。

2.2 区分业务关系与技术关系

这是我在梳理应用关系时认为比较重要的一点。

业务关系与技术关系并不是同一回事。

例如，D365 F&O 和 MES 之间存在生产业务数据交互，这是业务层面的关系。

但实际实现过程中，D365 F&O 并不是直接与 RabbitMQ 交互，而是通过 ERP Sync Service 和 RabbitMQ 等组件完成相关集成。

因此，可以分别表达两个层次：

• 业务层面： D365 F&O 与 MES 之间存在相关业务数据交互。
• 技术层面： D365 F&O ↔ ERP Sync Service ↔ RabbitMQ ↔ MES。

如果只画第一种关系，就无法体现真实的集成实现。

如果只画第二种关系，却不说明业务目的，读图的人也可能不清楚为什么需要这些组件。

在比较完整的架构文档中，这两个层次可以通过不同的视图表达。

对于初步梳理，也可以先使用一张图展示主要系统和集成链路，再通过文字说明业务背景与技术职责。

三、结合实际环境梳理应用集成关系

了解基本原则后，可以从现有系统中选取几个典型场景，尝试将系统之间的关系表达出来。

3.1 D365 F&O 与 MES：存在中间集成服务的交互链路

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

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

其中：

• D365 F&O 负责 ERP 侧的相关业务处理。
• ERP Sync Service 负责 ERP 相关的集成业务。
• RabbitMQ 为相关系统之间的消息交互提供支持。
• MES 负责制造执行相关业务。

这里需要特别注意，D365 F&O 并不是直接连接 RabbitMQ。

ERP Sync Service 是独立的集成服务，负责连接 ERP 侧与后续集成环节；RabbitMQ 则承担消息传递方面的职责。

在架构图中，如果把 ERP Sync Service 隐藏起来，只画 D365 F&O 与 RabbitMQ 的连接，就会与实际架构不符。

如果把 RabbitMQ 隐藏起来，只画 ERP Sync Service 与 MES 的连接，也会遗漏真实的消息传递环节。

因此，在需要表达实际技术链路时，这几个组件都应该保留。

为什么要把中间组件单独画出来？

主要有三个原因。

第一，明确系统之间的职责边界。

ERP 业务、集成逻辑、消息传递和制造执行分别由不同组件承担。

把这些组件分开表示，有助于理解各自的职责，也便于后续维护接口文档。

第二，帮助分析问题发生的位置。

假设 MES 没有收到预期的生产业务数据。

这时不能直接判断是 MES 的问题，也不能简单地认定 ERP 接口发生异常。

需要根据实际的数据流向，逐步检查 ERP 侧处理、ERP Sync Service 的处理情况、RabbitMQ 的消息状态，以及 MES 的消费和业务处理过程。

具体应该从哪里开始排查，还要结合数据流向、监控信息和日志来确定。

第三，帮助分析变更影响。

如果 ERP Sync Service 需要升级，或者 RabbitMQ 的部署方式发生变化，就可以提前识别哪些业务流程和应用可能受到影响。

这类信息在系统变更评审时尤其有用。

还需要进一步确认什么？

一张关系图并不能说明所有集成细节。

对于这条链路，还可以逐步补充以下信息：

• 哪些业务数据从 D365 F&O 流向 MES？
• 哪些业务数据从 MES 返回 ERP 侧？
• ERP Sync Service 通过什么接口与 D365 F&O 交互？
• RabbitMQ 中有哪些消息类型或业务队列？
• 消息处理失败时，采用什么方式重试或恢复？
• 如何识别重复消息，以及如何避免重复处理业务数据？

例如，目前的业务交互涉及生产工单下发、生产报工或完工数据回传，以及物料、BOM、库存等相关数据。

不过，不同数据的方向和处理规则可能不同，不能简单地假设所有数据都沿着同一个方向流动。

这些细节适合在接口清单、数据流图或集成设计文档中进一步说明。

第一版应用关系图不必包含所有内容。可以先把主要组件和链路画清楚，再根据需要逐步完善。

3.2 ERP 与 WMS：通过 Web Service 集成

另一个典型场景是 ERP 与 WMS 之间的集成。

与前面 D365 F&O 和 MES 的集成链路不同，目前 ERP 与 WMS 通过 Web Service 进行交互，而不是通过 RabbitMQ。

这说明，即使是同一家企业内部的系统，也不一定采用统一的集成方式。

在应用关系图中，可以用不同的线条或标签区分不同的接口类型。

例如：

• 使用标注为 Web Service 的连接线，表示 ERP 与 WMS 之间的接口关系。
• 使用标注为 Message / RabbitMQ 的连接线，表示通过消息中间件实现的交互关系。

这样做的好处是，读图的人不仅能够看到哪些系统存在联系，还能初步了解它们通过什么方式交互。

不过，图中的线条必须与实际情况一致。如果接口协议、调用方向或通信机制尚未确认，就应该标记为待确认，而不是根据经验直接推断。

3.3 公共服务也应该纳入应用关系图

在梳理应用关系时，容易出现一个问题：只关注 ERP、MES、WMS 等业务系统，而忽略公共服务。

但从实际运行情况来看，公共服务同样可能影响多个应用。

例如，业务系统可能调用 Document Generator 生成文件，生成后的文件存储在 MinIO 中；相关业务场景也可能使用 Message Service 发送企业微信或 Email 消息。

这些关系可以根据实际调用情况逐步补充。

需要注意的是，公共服务之间并不一定都存在直接连接关系。

例如，Document Generator 生成文件并将其保存到 MinIO，并不意味着所有使用 Document Generator 的系统都需要直接连接 MinIO。具体调用关系取决于实际设计。

因此，画图时应该尽量遵循一个原则：

只表达已经确认的关系，不根据技术名称或常见用法自行推断系统之间的连接。

如果某项关系还没有确认，可以先记录在待核实清单中。

这样比直接画出一条可能并不存在的连接线更可靠。

四、应用关系图不等于基础设施架构图

在企业 IT 环境中，应用系统和基础设施之间也存在大量关系。

例如，MES 和 ERP Sync Service 部署在 Kubernetes 中；RabbitMQ 也部署在 Kubernetes 中，但采用单实例部署方式。

MinIO 则通过 NFS 使用持久化存储，而 NFS 服务运行在 Linux 虚拟机上，相关虚拟磁盘由 VMware vSAN 提供存储支持。

这些关系同样重要。

但如果把所有业务系统、接口、数据库、容器、虚拟机、存储和网络设备都放在一张图里，图很快就会变得难以阅读。

因此，我认为可以根据不同的分析目的，将架构信息拆分成几种视图。

4.1 应用关系视图

主要展示：

• 业务应用。
• 集成服务。
• 公共应用服务。
• 应用之间的主要接口关系。
• 必要的接口类型和数据流向。

它主要回答：哪些应用存在联系，以及它们如何交互？

4.2 技术部署视图

主要展示：

• 应用部署在哪些运行平台上。
• 哪些服务运行在 Kubernetes 中。
• 哪些应用依赖数据库或消息中间件。
• 文件存储依赖哪些存储服务。
• 相关技术组件之间的运行依赖。

它主要回答：这些应用和服务运行在哪里，以及它们依赖哪些技术设施？

4.3 业务数据流视图

主要展示：

• 哪些业务数据在系统之间流转。
• 数据从哪里产生。
• 数据由哪些系统处理。
• 数据最终流向哪里。
• 哪些环节可能涉及数据转换或业务规则。

它主要回答：业务数据如何在企业系统之间流动？

这三种视图之间存在联系，但不必强行合并成一张图。

例如，应用关系图可以展示 D365 F&O、ERP Sync Service、RabbitMQ 和 MES 之间的联系；技术部署图可以进一步说明这些组件的运行环境；数据流图则可以分别展示生产工单、报工和其他业务数据的流向。

不同的图解决不同的问题。

五、如何让应用关系图真正发挥作用？

架构图的价值不在于图形是否精美，而在于它是否能够帮助人理解现状、分析问题和做出决策。

结合日常 IT 管理工作，我认为可以从以下几个方面逐步完善应用关系图。

5.1 为每条连接线补充必要的信息

一条连接线可能代表不同的含义。

它可能表示接口调用、消息传递、数据同步，也可能表示某种技术依赖。

如果没有任何说明，读图的人很容易产生不同理解。

因此，在条件允许的情况下，可以为连接线补充以下信息：

不一定每张图都需要展示全部信息。

如果图面空间有限，可以只保留主要信息，再通过接口清单补充详细内容。

5.2 记录系统之间的依赖关系

系统之间的依赖关系，不只是技术问题，也会影响日常运维和变更管理。

例如，某个公共服务被多个业务系统使用，那么在调整该服务之前，就需要先确认影响范围。

如果一个系统依赖消息中间件，还需要考虑中间件不可用时，业务会受到什么影响。

如果应用依赖外部存储，则需要考虑存储服务异常时的业务表现，以及数据恢复要求。

这些信息可以逐步形成依赖清单。

依赖清单不必一开始就非常复杂。先记录主要系统、直接依赖对象、依赖原因和相关业务影响，已经可以提供不少帮助。

5.3 区分现状与目标

架构文档还需要区分当前实际状态和未来计划。

例如，某个系统已经完成 SSO 接入，和某个系统计划接入 SSO，是两种不同的状态。

如果将两者混在一起，读图的人就可能误以为某项能力已经实现。

同样，当前 RabbitMQ 采用单实例部署，与未来计划采用其他部署方式，也应该分别记录。

在绘制架构图时，可以通过图例、状态标签或单独的目标架构图进行区分。

这样既能准确表达现状，也便于后续讨论改进方案。

5.4 让架构图与实际运行环境保持一致

架构图并不是画完就结束了。

随着系统升级、接口调整、应用迁移和技术平台变化，原有关系可能发生变化。

如果架构图长期不更新，它就可能逐渐失去参考价值。

因此，应用关系图最好与系统清单、接口文档和部署信息保持一致。

不一定需要每次小改动都重新绘制整张图，但重要的系统新增、接口变化和部署调整，应该有相应的更新机制。

对日常 IT 管理而言，这样的文档才能逐渐成为可用的工作资料，而不是只在项目启动或评审时使用一次的附件。

六、从应用关系图过渡到 TOGAF 的应用架构

学习 TOGAF Standard 10 时，我逐渐认识到，应用关系图只是理解应用架构的一种方式，并不等于完整的应用架构。

应用架构还需要进一步描述应用的职责、应用之间的协作方式，以及应用如何支持企业的业务能力。

例如，梳理出 D365 F&O、ERP Sync Service、RabbitMQ 和 MES 的关系后，还可以继续研究：

• 这条集成链路支持哪些业务能力？
• 各组件的职责边界是否清晰？
• 哪些接口属于关键业务接口？
• 相关数据由哪个系统负责维护？
• 如果业务流程发生变化，哪些应用需要调整？
• 当前架构与未来业务需求之间是否存在差距？

这些问题已经超出了简单的系统清单和关系图本身。

如果进一步结合 TOGAF 的架构开发方法，就可以在理解现状的基础上，逐步明确业务需求、目标状态、差距以及可能的改进路径。

不过，在实际工作中，并不是所有问题都需要立刻进入完整的架构开发流程。

有些问题只需要完善接口文档，有些需要调整应用设计，还有些涉及多个系统和基础设施，可能需要更系统的分析。

关键在于先明确问题，再选择适合的方法，而不是为了使用某种架构方法而增加不必要的工作。

七、这一阶段的实践总结

从系统清单走向应用关系图，看起来只是增加了一张图，但背后其实是分析角度的变化。

系统清单帮助我们了解企业有哪些系统。

应用关系图进一步展示系统之间的联系。

接口清单可以补充系统交互的技术细节。

数据流图则可以帮助我们理解业务数据如何在系统之间流动。

当这些信息逐渐完善之后，我们就有了一个更加清晰的现状基础，可以进一步分析系统依赖、变更影响以及架构改进方向。

对我来说，这个过程也让我意识到，企业架构不一定要从宏大的规划开始。

从日常工作中熟悉的系统入手，把系统职责、接口关系和实际依赖逐步整理清楚，同样是一种务实的学习方式。

当然，一张应用关系图不可能解决所有问题。它需要与业务流程、数据架构、技术部署和运维资料结合起来，才能发挥更大的作用。

接下来，我准备继续从这些关系出发，进一步研究企业应用集成中的接口、消息和数据流转，尝试把系统之间的连接关系与实际业务过程联系起来。

这也是从了解现状，逐步走向分析架构问题的一个过程。