要想做好架构可视化，你必须弄懂这十个关系

大家好！今天我想和大家聊聊企业级架构治理中，架构可视化的一些问题。我的分享分为三部分。首先，讨论为什么要进行架构可视化；其次，探讨如何建立架构可视化的标准；最后聊一下在企业中实施架构可视化要注意的问题。

那么，什么是架构的可视化？为什么要进行架构可视化呢？

为了回答这个问题，我们先来思考一下，怎样将架构“想清楚”、“说清楚”和“画清楚”。

在做架构设计时，我们首先要“想清楚”。架构师和普通开发人员在思考方式上有一个重要的区别。普通开发人员看待问题通常是二元的，一个问题的答案要么黑要么白，要么对要么错。而架构师看待问题的方式则不同。他们遇到问题的时候，首先会思考有哪几种可能的解决方案；然后列出每种方案各自的优缺点；最后通过权衡，选出较好的那个。也就是说，所谓“想清楚”，关键在于架构的权衡。

当我们“想清楚”之后，就需要将我们的思考“说清楚”。只有当我们真正理解了一个问题，才能清晰地阐述出来。反过来，如果一个人能够清晰地表述一个问题，那么也常常意味着他已经理解了这个问题。

从企业级的角度来看，除了帮助我们思考，"说清楚"还有一个重要的作用就是沟通。我们不仅要自己理解架构设计，还要将我们的理解告诉他人，以便有效协作。

然而，“想清楚”和“说清楚”其实并不容易。其中一个主要原因在于自然语言的模糊性。

咱们中国古代有一个著名的诡辩叫做“白马非马”。大意是：如果白马是马，黑马也是马，那么就说明白马就是黑马，进而可以推导出“白就是黑”，然而这是矛盾的，所以白马不可能是马。

这个推理的错误在没有注意“是”字的不同含义。在“白马是马”这个命题中，“是”的意思是“属于”；在“白就是黑”中，“是”的意思是“等价于”。提出这个问题的人混淆了“是”字的不同含义，因此做出错误的结论。这是自然语言模糊性的一个典型的例子。而在软件架构设计中，自然语言天然的不精确性也常常造成问题。

为了解决自然语言的模糊性，就需要将我们的思考和表述进一步“画清楚”。架构设计中的很多微妙之处，只通过口头或文字的描述并不能清晰表达，那么就需要通过架构图以及一些辅助文字，来更加严格地描述。这就是“画清楚”，也就是我们说的架构可视化。好的架构图可以避免歧义，提高思考和沟通效率，这就是我们需要进行架构可视化的原因之一。

事实上，高质量架构设计需要具有严格化，抽象化和规范化的特征。前面说的是严格化，那么抽象化是什么呢？

架构的治理和设计的本质其实是一个建模过程，而建模就是抽象化的过程。想一下小孩儿的玩具车。玩具车就是真实车辆的模型，它抽取了现实世界中的一部分属性，如形状和移动能力，同时忽略了大部分属性，如真实的大小、材质等等。这就足够了，因为玩具车就是为了给小孩儿玩而设计的，它抽取的属性已经满足这个目的了。这种忽略现实中的大部分属性，抽取出一小部分属性来实现特定目的过程，就是抽象。因此建模是一个抽象化过程。而为了实现抽象化，也需要先将模型可视化。

至于规范化，我们会在后面谈。总之，可视化是严格化、抽象化和规范化的前提，是我们进行架构治理和设计不可或缺的工具。

下面我们就来重点聊聊架构规范化的问题，其中最重要的就是建立绘制架构图的标准。我们看看有哪些要注意的问题。

首先，我想强调一下示意图和蓝图的区别。

最近和一个客户聊。他们在企业层面面临着系统重复建设、逻辑不一致和数据孤岛等常见问题。我建议他们首先做一下企业级的架构梳理。然而，他说他们已经做过了，画了很多图，但问题仍然存在。于是我看了一下他们的架构图，发现基本都是示意图，而不是蓝图。

那么，什么是示意图，什么是蓝图呢？我们举个建筑领域的例子。在下图中，左边是大家买楼的时候能看到的沙盘模型，右边是建筑施工的图纸。

沙盘模型就好比示意图，它能让你大概了解房子的外观，满足购房的需求。但如果要建房子，仅凭这个模型就不够了。我们需要一份详细的、准确的图纸，这就是建筑的蓝图。“蓝图”这个词来自于早期的制图技术。那时还没有计算机制图。为了让手工画的图纸能够长期保存，人们会用化学方法进行晒图，处理后的图纸是蓝色的，所以被称为蓝图。

在架构治理和设计中，尽管示意图也有其用途，但我发现很多企业缺少的是蓝图。蓝图和示意图的关键区别就在一个“准”字。也就是说蓝图应该足够准确。

有人可能会说：我们做企业级的架构，层次比较高，不需要画得这么“细”，所以不需要蓝图。这种说法其实是混淆了“准确”和“详细”这两个概念。事实上，准确不代表详细，详细也不意味着准确。“准确“指的是在特定的抽象层次上，具有完整性，并且和系统保持一致。比如说，如果绘制企业级的应用架构图，理论上应该包含企业的所有系统以及它们的关系，不能多，也不能少。但是在这个层面，并不需要描述每个系统内部的具体情况，因此并不“详细”。这里之所以说“理论上”包含企业的所有系统，是因为实践中我们推荐采用“浮现式设计”，因此在某一时刻未必能做到理论上的全局完整性。这一点在后面会谈到。

示意图是为了提供一个宏观视角，用于探索和规划未来的发展方向，并且向领导或其他干系人汇报。示意图并不需要十分准确和规范，只需让干系人能够理解就够了，并且这类图通常不需要持续更新。反过来，蓝图主要用于系统的实际规划、开发和演进，需要指导落地实施，因此需要强调准确性和规范性。另一方面，只要系统发生了架构意义上的变化，蓝图就应该进行相应地更新，以便作为进一步演进的基线。

在前面举的那个客户的例子中，之所以画了很多示意图，仍然无法解决企业中的架构问题，就是因为示意图的准确程度不够，还不足以发现具体的问题。

我们今天说的建立架构可视化的标准，主要就是针对蓝图来说的。

在建立架构图标准之前，我们还要明确一些常见的概念。例如什么是系统、子系统、发布单元、模块、组件和产品。这些概念在业界常常存在不同的理解，有些概念尽管在总体上有类似的理解，但又会存在微妙的区别。作为建立企业级架构标准而言，我们既无必要，也不可能追求业界一致的理解，只需要在企业内部建立一个言之成理的定义，并达成一致就可以了。

为了达到这个目的，我们来分析一下这几个概念，作为大家在自己企业内建立架构标准的参考。

第一个概念是“系统”。在 IT 领域，系统可能是软件系统、硬件系统或者软硬件共同组成的系统。

这里我们主要谈“软件系统”。在后面我们说到“系统”的时候，如果没有特别说明，指的都是软件系统。软件系统可简称为“软件”。在 IT 发展的早期，软件被分为“系统软件”和“应用软件”。系统软件通常包括操作系统、编译系统、数据库引擎等等；应用软件则是建立在系统软件之上，用于解决特定业务问题的软件，例如保险核心业务系统、办公自动化系统等等。

然而，后来产生了一些软件，既不像传统的系统软件那么基础，也不具有特定的业务含义。例如网络服务器、应用服务器和消息服务器等等。这些软件介于传统的系统软件和应用软件“中间”，所以称为“中间件”。

也就是说，软件系统可以分为“系统软件”、“应用软件”和“中间件”。其中，应用软件又简称为“应用”。英文是 Application，缩写为 App。前端应用和后端应用都是应用。如果有人说“咱们开发一个 App 吧”，到底指的是前端应用还是后端应用，要根据上下文判断。如果有歧义，要及时澄清。

一个系统又可以划分多个子系统。子系统也是系统，只不过相对于它的“父亲”而言，是“子”系统。子系统可以向下进一步分成更细粒度的子系统。

一种特殊的系统是“发布单元”，也就是可以独立部署和运行的最小单位。我们常说的单体应用、微服务，以及介于单体和微服务之间的各种中间形态，都可以统称为发布单元。

分析完“系统”，我们再来看看“产品”的概念。这里的产品，我们特指“软件产品”。

在软件工程的早期，并没有产品的概念。然而，随着近年来敏捷和精益方法的兴起，我们开始强调软件产品。那么产品和系统之间的区别是什么呢？

产品一定是面向价值的。假设我们走进一家西装店，这家店只卖成衣，不单独卖扣子。而隔壁可能有一家店专门卖扣子。对于西装店来说，西装是它的产品，因为西装为它创造了价值，而扣子则不是。而对于卖扣子的店来说，扣子是它的产品，因为扣子为它创造了价值。所以同一个事物，是不是产品，取决它是否为企业直接创造价值，或者说，取决于企业的业务模式。

回到软件产品。一个产品就是一个有明确业务价值的系统，比如说银行支持贷款的系统可以说是贷款产品，支持资产托管的系统可以说成是资产托管产品。一个产品可以是一个单独的系统，也可以由其他几个（子）系统组成。另一方面一个系统未必有明确的业务价值。比如说构成企业中台的系统，相对于最终用户而言，就未必是产品。一个系统可以被多个产品复用。

理清了这些基本概念，就可以制定架构图的绘制标准了。这时候主要有两种策略，一种是规范画法，一种是自定义画法。还有的策略介于两者之间。

下图中，我针对同一个系统给出了三种画法。

最左边的图是用 UML 画的，每个方框都代表一个发布单元。将发布单元括起来的包代表系统。由于 UML 是 OMG 官方的国际标准，这种方式可以称之为规范画法。

最右边的图则是自定义画法。一个企业可以不使用国际标准，而是自行定义。例如，有的企业可能喜欢用圆角框表示系统，直角框表示发布单元。他们的依赖关系可能用实线箭头表示，而不是虚线。由于这是企业自定义的，所以一定要有图例来解释各个符号的含义。反之，规范画法一般不需要显式地给出图例，因为符号的含义已经被国际标准所定义了。

回忆一下我们前面提到的示意图和蓝图。如果你看到一个架构图不是规范画法，同时又没有图例，那它很可能只是个示意图，而非蓝图。因为蓝图需要有图例来保证其语义的严格性。

中间这幅图是 C4 模型。这种画法不算国际标准，但有专门的主页介绍，也有许多人使用，我称其为民间规范。

企业到底选择哪种策略，取决于自身的偏好。有些人更喜欢遵循业界标准，因为这样可以减少沟通成本，更容易吸收前人经验。有些人则觉得业界标准过于复杂，喜欢建立小而美的自定义标准。这没有绝对的对错之分，只要能够解决企业的问题，并且在企业内部保持统一就可以了。

由于系统的复杂性，一个企业建立架构描述标准时，往往要包含多种不同的图，反应了系统的不同角度，这些图构成了一个体系。为了构建这样一个架构标准体系，需要考虑两个方面：一个是维度，一个是粒度。下图表示了某个企业根据这两个层面设计的架构标准体系。

维度是指从哪个角度看问题，比如业务架构、应用架构、数据架构、技术架构等。粒度是指架构的覆盖范围，比如企业级的架构，需要从公司领导的视角考虑整个公司的范围，而室组级，只需要考虑开发室组的范围。

虽然架构图很重要，但是仅仅通过图尚不能把架构完全说清楚，还需要结合表和矩阵。TOGAF 认为，通过图、表和矩阵这三种工具就可以清楚地描述架构的各个方面。

其中，图（diagram）用于直观地展示同一维度内的各个组件及其关系；表（catalog）可以详述每个组件的具体属性；矩阵（matrix）可以展示不同维度之间的关系，例如哪些系统支撑了哪些业务，哪些技术支撑了哪些系统等等。

建立了好的架构描述标准，并不一定能保证这些标准能够顺利实施。下面我们再谈几个在实施过程中需要考虑的问题。

我们遇到一些企业中负责架构的朋友，常常会问这样的问题：“按照 TOGAF 的说法，企业架构包括业务架构、应用架构、数据架构、技术架构。但是，IT 部门很难驱动业务部门，我们能不能只做应用架构或技术架构呢？如果能的话，是不是就不算企业架构了呢？”

为了回答这个问题，我们需要区分两个概念：“企业架构”和“企业级架构”。下图表示了两个概念的区别。

“企业架构”强调的是端到端的整体性，即从业务架构到技术架构等各个环节，都覆盖到了。即使不是整个企业做，只要我们完成了所有层面的架构，那就可以叫做企业架构。而“企业级架构”强调的是横向，即跨系统、跨部门、跨团队的设计，至于做哪一个层面，则可以根据具体情况选择。

所以，我们不需要拘泥于定义上的企业架构，而是可以从企业级的架构入手。可以根据企业的具体痛点，决定先做企业级的业务架构、应用架构还是技术架构。然后再逐步扩展的架构的其他层面。

下面再谈一下有关架构组织的问题。

举一个例子。有一家企业，负责公司架构的同事说他们已经开展了两年的企业级架构工作，公司的 200 多套系统中，90% 都按照统一的标准绘制了架构图。于是，我去访谈开发团队。当我让开发人员向我出示架构图的时候，却发现很多人并不清楚哪里能找到最新架构图，甚至不清楚谁是自己团队的架构师。这意味着架构图没有真正发挥作用，这家公司可能只是“运动式”地推广架构工作。这就不再是技术问题，而是一个组织层面的问题了。

关于组织问题，我今天重点说一下企业级架构师和团队级架构师的角色和责任，见下图。

企业级架构师站在全局架构的视角，关注企业整体目标的达成。他们负责推动整个组织的架构工作，尤其关注跨系统、跨团队的协作。他们要制定全局性的架构标准和原则，而不需要深入了解每个系统的具体技术细节，但需在原理上有所理解。所以企业级架构师通常是“技术出身”的。此外，企业级架构师也更强调沟通、协作、影响力等软技能。

另一方面，团队级架构师会更专注于实现自己系统的目标。一般要深入了解本系统的技术细节，为本系统设计架构方案。并且，要对全局的架构标准进行落地和反馈，也要协助企业级架构师完成全局目标。在上面的例子中，显然团队级架构师的职责没有明确。

总之，不同层面的架构师的职责既有共性又有差异。企业要为不同的架构师建立不同的能力模型，并落地实施。

下面再谈一个微妙的问题，就是架构设计的时间点。没有时间点的架构图是没有意义的。

比如说。我们访谈一些企业的架构师时，常常遇到下面这样的问题。我们让架构师拿出一张架构图，然后问他：这个架构图是当前架构还是目标架构？这个架构师会犹豫几秒种，然后说这是当前架构。接着，我们开始看架构图中的一些细节，发现有些和当前生产环境的实际情况不符。于是架构师又改口说，这是当前架构为主，但又有一些未来要优化的地方。我们说，那就不是当前架构了，应该就是目标结构。可是架构师又会告诉我们，有很多需要优化的部分并没有在图中反应，因此说是目标架构图也有些牵强。接着，我们又问，那么目前图中优化的部分，计划什么时候完成呢？架构师又会犹豫一下，然后给出一个时间点，比如说未来半年或一年。但很显然，这只是这个架构师现场“拍脑袋”给出的说法，并没有经过深思熟虑，也没有正式向任何一方承诺过。所以，我们发现一个有趣的现象，在很多架构师头脑中，并没有架构设计的时间点这根“弦”。

关于时间点，首先我们要分清当前架构和目标架构的区别，如下图所示。

当前架构反应架构的现状，总是和当前生产环境的系统架构保持一致。可以作为架构演进的基线。

而目标架构通常又可以分为开发中目标架构、近未来目标架构和远未来目标架构。其中，近未来目标架构直接指导当前迭代的开发，也就是和当前迭代的目标相一致，要求足够准确和详尽。而近未来（例如一年后的目标）和远未来（例如三年后的目标）则表示未来的大体方向，一般比较粗略。

由于架构会不断演进（尽管比代码演进要慢），所以要做好架构产出物的版本管理。开发中的目标架构和当前架构可以在同一个版本仓库中，用同一个主干管理。而近未来和远未来目标架构一般要用单独的仓库管理。

不同的公司，也可以根据情况采用不同的管理手段，比如说只有一年后的目标架构，没有三年后的目标架构。不过最基本的要求是，任何时刻，总可以获得反应当前生产环境的架构描述。

关于架构设计的过程，又可以有前期设计和浮现式设计两种策略。下图表示了两种策略的区别。

前期设计（Big Design Up Front, BDUF）是指在开发一个大项目的早期就设计出所有架构方案；或者在进行企业架构治理早期，就集中一段时间把所有系统的架构都梳理出来。这其实是一种“瀑布模型”的方式。对于大项目的开发，可能造成基于猜测的架构设计，无法真正设计出合理的架构；而对于企业架构治理来说，很容易陷入“一阵风”的运动式实施，难以取得实际效果。尽管近年来敏捷的思想已经比较普及，但在架构治理领域，有时还会见到这种错误。

而浮现式设计（Emergnet Design），则是在项目进行中，根据优先级，不断细化架构设计，同时又兼顾架构整体的一种方法。是一种符合敏捷开发理念的方式。

可以打一个比方来理解浮现式设计。比如说我们要画一张世界地图。一开始就画得非常详细是很困难的，而且也没必要。那么，我们就可以先把七大洲的大体边界画出来，先让看图的人知道有七个大洲这件事，以及大体的位置。然后，我们觉得亚洲最重要，就可以把亚洲的边界画清晰一点，并且画出亚洲主要的国家和大体的国界。接着，我们又觉得亚洲里中国最重要，于是可以把中国的边界画清楚，然后把中国的主要省市的大体边界画出来。同理，我们可能觉得广东省最重要，广东省中广州市最重要，广州市中番禺区最重要，依次类推。这样，过了一年，可能我们把中国最重要的几个城市画的比较详细了，而非洲可能还根本没有细化。但这已经足够了，因为已经满足了我们的需求。同时，七大洲的大图景也基本呈现了出来，只是等着我们在必要的时候“填空”。随着时间的推移，我们会看到这张地图越来越详细，越来越实用。而不同位置的详细程度则取决于优先级。给人的感觉，就是这张地图是逐渐“浮现”出来的。企业架构治理的过程，其实也是这个道理。

最后，我们谈谈通过手工还是自动化的方式进行架构治理，其实就是使用工具的问题。下图表示了理想的架构治理和设计工具的一些特征。

企业架构在八十年代就已经提出了。但时至今日，许多企业在实际落地时仍然面临困难。原因有很多方面。其中之一恐怕是缺乏合适的工具。作为 IT 行业的我们，不断为业务提供工具支持，但对于 IT 自身的任务，比如架构设计，却不一定有趁手的工具。这是个有趣的现象，就是俗话说的“灯下黑”吧。

工欲善其事，必先利其器。目前多数企业中的系统都是数量繁多，关系复杂。开始进行架构治理的时候，可以暂时采用手工方式，长远来看，一款合适的工具是很有必要的。目前国内外有不少工具可供选择，我们要在功能、价格、成熟度等方面进行权衡。

以上就是我今天想要和大家分享的一些经验之谈，希望对大家能有所帮助。谢谢！

钟敬，Thoughtworks 首席咨询师，数字化转型与运营团队 DDD 负责人，在 IT 界从业 20 余年，先后在中多家中外企业任职，带领团队成功地开发与维护了多个系统，并负责公司的敏捷转型及企业架构工作。擅⻓软件开发方法学、领域驱动设计、企业架构、敏捷及精益方法，企业研发效能提升等。注重学习和推广软件开发的最佳实践，提倡工匠精神。是 Martin Fowler 《分析模式》的译者，并参与审校了《领域特定语言》的翻译。在极客时间开设了《手把手教你落地 DDD》课程。