组织的技术系统中通常有一个复杂的依赖关系网络，这并不总是容易找到和理解的。

通常有很多图表示例，但是，虽然我们不是Netflix，我们在TheFork遇到了一些问题。

• 样式和术语的一致性不足（通过颜色来表示含义，“域”到底是什么意思，没有统一语言等）
• 工具混杂，没有集中存储（难以查找和浏览，图表散见于LucidChart、Miro、Notion、GitHub等平台）
• 根据不同受众调整适当的细节层次（例如，高级管理人员、架构师、开发人员、产品经理、安全和运维团队）
• 在多个视图中显示相同的图示元素（每次都要重新绘制，而不是重用，再次导致一致性不足）

最大的问题就是 -> 这些图现在还跟得上吗？？？

更新啦！

作为一个新团队成员，我如何才能快速上手我需要负责的系统，而不用问太多人，或把自己急疯？

当我开发新功能时，如何知道哪些其他的团队和系统可能受到影响（避免意外）？

我们已经在采用一个新的企业架构（EA）框架来根据能力组织我们的团队和系统。我们之前是手绘的图表，但我们不是应该将这些手绘图自动化，然后将其映射到技术现实中吗？

我们将元模型扩展为将技术组件映射到我们企业架构框架中，定义如下所示：

定义：功能能力抽象的最高程度

子领域: 分组能力的第二个层次

能力: 单一领域内由一个团队负责和管理的功能逻辑组

部件：一个可以独立使用的技术组件

受C4模型的启发，我们提出了以下图表类型：用户可以在这几个层次之间进行互动探索。

全景视图让高层领导和产品团队了解组织结构和能力分配。

横屏模式

这些功能可以直接点击进入功能视图，该视图会展示与其他系统部分之间的依赖关系（即影响范围），帮助设计新的功能特性。

能力视角

从这里你可以回到顶部，或者深入到组件视图，这些视图允许开发团队查看新功能和现有功能的影响和依赖，同时展示复杂性：

组件视图界面

拥有模型和静态图的好处是，我们能够在多个视图（在不同细节层次和元数据中）重用相同的“对象”，并在多个视图中使用它们，通过搜索使它们更容易被发现。这使它们更加熟悉、一致和易读，并节省大家的时间。

我们研究了一些现有的第三方工具，比如IcePanel，但决定先扩展我们自己内部的‘TheFork Map’工具。

这个工具已经通过解析我们的软件组件的配置来可视化它们之间的依赖。这为我们金字塔底层的基础提供了起点。但我们进一步扩展了它的功能，还显示了更多的信息。

• 消息代理流程
• 数据存储系统
• 包和库的使用
• 第三方系统依赖（还在开发中）
• 技术债务的测量（通过我们内部的Beacon工具，详情见 链接）

TheFork 地图功能 — 数据来源介绍

为了添加功能视图，我们扩展了其功能，使其能够查询其他元数据源并生成每个图的PlantUML标记文件。然后将其转换为SVG，并在我们现有的Next.js网站上进行可视化展示。

我们每晚自动生成所有可视化，以保持同步。

这个工具还能够：

• 充当一个应用目录：作为一个单一的集中位置，查看团队的所有权情况和其他指标，并为进入其他工具（如Datadog）提供入口。
• 连接并展示我们的技术债务管理举措（请参阅我之前写的关于自动执行决策的文章和我的同事Nicholas Suter的这篇精彩的深度分析文章）。

我们看到了许多令人兴奋的可能性来增强此工具的功能，包括：

• 第三方工具的集成和迁移：例如 Backstage、Cortex、DataDog 等。这些工具虽然在某些方面与我们已经构建的内容有所重叠，但很难在单一工具中整合所有功能。即使我们进行迁移，所做的元数据准备工作仍然有用。
• 基于数据集（如基础设施和 GDPR 等）的新视图和抽象层
• 使用 BPMN 语言可视化业务流程
• 可视化数据流

下面是一些总结。

有这样的工具能带来很多好处：

• 相信图表（新鲜感）
• 更简单的技术分析和解决方案设计
• 我们当前债务和架构问题的可视化
• 让新团队成员更快上手
• 中央访问点（应用目录入口）

我们总体上对迄今为止所建立的东西感到满意，这让我们能轻松地看到我们的企业模型如何与技术现实对应，并且只需最小的努力就能保持最新。

不过，在我们向西蒙·布朗的架构图成熟度模型的第五级前进的过程中，我们还可以做许多改进！