要想做好架构可视化，你必须弄懂这十个关系
ArchSummit全球架构师峰会约 17 分钟大家好！今天我想和大家聊聊企业级架构治理中，架构可视化的一些问题。我的分享分为三部分。首先，讨论为什么要进行架构可视化；其次，探讨如何建立架构可视化的标准；最后聊一下在企业中实施架构可视化要注意的问题。
架构可视化的必要性那么，什么是架构的可视化？为什么要进行架构可视化呢？
关系一：想清楚、说清楚和画清楚 为了回答这个问题，我们先来思考一下，怎样将架构 “想清楚” 、 “说清楚” 和 “画清楚” 。
当我们“想清楚”之后，就需要将我们的思考“说清楚”。只有当我们真正理解了一个问题，才能清晰地阐述出来。反过来，如果一个人能够清晰地表述一个问题，那么也常常意味着他已经理解了这个问题。
从企业级的角度来看，除了帮助我们思考， "说清楚"还有一个重要的作用就是沟通 。我们不仅要自己理解架构设计，还要将我们的理解告诉他人，以便有效协作。 然而， “想清楚”和“说清楚”其实并不容易。其中一个主要原因在于自然语言的模糊性 。咱们中国古代有一个著名的诡辩叫做“白马非马”。大意是：如果白马是马，黑马也是马，那么就说明白马就是黑马，进而可以推导出“白就是黑”，然而这是矛盾的，所以白马不可能是马。
这个推理的错误在没有注意“是”字的不同含义。在“白马是马”这个命题中，“是”的意思是“属于”；在“白就是黑”中，“是”的意思是“等价于”。提出这个问题的人混淆了“是”字的不同含义，因此做出错误的结论。这是自然语言模糊性的一个典型的例子。而在软件架构设计中，自然语言天然的不精确性也常常造成问题。
为了解决自然语言的模糊性，就需要将我们的思考和表述进一步“画清楚”。架构设计中的很多微妙之处，只通过口头或文字的描述并不能清晰表达，那么就需要通过架构图以及一些辅助文字，来更加严格地描述。这就是“画清楚”，也就是我们说的架构可视化。好的架构图可以避免歧义，提高思考和沟通效率，这就是我们需要进行架构可视化的原因之一。
事实上， 高质量架构设计需要具有严格化，抽象化和规范化的特征 。前面说的是严格化，那么抽象化是什么呢？ 架构的治理和设计的本质其实是一个建模过程，而建模就是抽象化的过程。 想一下小孩儿的玩具车。玩具车就是真实车辆的模型，它抽取了现实世界中的一部分属性，如形状和移动能力，同时忽略了大部分属性，如真实的大小、材质等等。这就足够了，因为玩具车就是为了给小孩儿玩而设计的，它抽取的属性已经满足这个目的了。这种忽略现实中的大部分属性，抽取出一小部分属性来实现特定目的过程，就是抽象。因此建模是一个抽象化过程。而为了实现抽象化，也需要先将模型可视化。 至于规范化，我们会在后面谈。总之， 可视化是严格化、抽象化和规范化的前提，是我们进行架构治理和设计不可或缺的工具 。 建立架构可视化标准下面我们就来重点聊聊架构规范化的问题，其中最重要的就是建立绘制架构图的标准。我们看看有哪些要注意的问题。
关系二：示意图和蓝图 首先，我想强调一下 示意图 和 蓝图 的区别。最近和一个客户聊。他们在企业层面面临着系统重复建设、逻辑不一致和数据孤岛等常见问题。我建议他们首先做一下企业级的架构梳理。然而，他说他们已经做过了，画了很多图，但问题仍然存在。于是我看了一下他们的架构图，发现基本都是示意图，而不是蓝图。
那么，什么是示意图，什么是蓝图呢？我们举个建筑领域的例子。在下图中，左边是大家买楼的时候能看到的沙盘模型，右边是建筑施工的图纸。
沙盘模型就好比示意图，它能让你大概了解房子的外观，满足购房的需求。但如果要建房子，仅凭这个模型就不够了。我们需要一份详细的、准确的图纸，这就是建筑的蓝图。“蓝图”这个词来自于早期的制图技术。那时还没有计算机制图。为了让手工画的图纸能够长期保存，人们会用化学方法进行晒图，处理后的图纸是蓝色的，所以被称为蓝图。
在架构治理和设计中，尽管示意图也有其用途，但我发现很多企业缺少的是蓝图。 蓝图和示意图的关键区别就在一个“准”字。也就是说蓝图应该足够准确 。 有人可能会说：我们做企业级的架构，层次比较高，不需要画得这么“细”，所以不需要蓝图。这种说法其实是混淆了“准确”和“详细”这两个概念。事实上， 准确不代表详细，详细也不意味着准确 。“准确“指的是在特定的抽象层次上，具有完整性，并且和系统保持一致。比如说，如果绘制企业级的应用架构图，理论上应该包含企业的所有系统以及它们的关系，不能多，也不能少。但是在这个层面，并不需要描述每个系统内部的具体情况，因此并不“详细”。这里之所以说“理论上”包含企业的所有系统，是因为实践中我们推荐采用“浮现式设计”，因此在某一时刻未必能做到理论上的全局完整性。这一点在后面会谈到。示意图是为了提供一个宏观视角，用于探索和规划未来的发展方向，并且向领导或其他干系人汇报。示意图并不需要十分准确和规范，只需让干系人能够理解就够了，并且这类图通常不需要持续更新。反过来，蓝图主要用于系统的实际规划、开发和演进，需要指导落地实施，因此需要强调准确性和规范性。另一方面，只要系统发生了架构意义上的变化，蓝图就应该进行相应地更新，以便作为进一步演进的基线。
在前面举的那个客户的例子中，之所以画了很多示意图，仍然无法解决企业中的架构问题，就是因为示意图的准确程度不够，还不足以发现具体的问题。
我们今天说的建立架构可视化的标准，主要就是针对蓝图来说的。
关系三：系统和产品在建立架构图标准之前，我们还要明确一些常见的概念。例如什么是系统、子系统、发布单元、模块、组件和产品。这些概念在业界常常存在不同的理解，有些概念尽管在总体上有类似的理解，但又会存在微妙的区别。作为建立企业级架构标准而言，我们既无必要，也不可能追求业界一致的理解，只需要在企业内部建立一个言之成理的定义，并达成一致就可以了。
为了达到这个目的，我们来分析一下这几个概念，作为大家在自己企业内建立架构标准的参考。
第一个概念是“系统”。在 IT 领域，系统可能是软件系统、硬件系统或者软硬件共同组成的系统。
这里我们主要谈“软件系统”。在后面我们说到“系统”的时候，如果没有特别说明，指的都是软件系统。软件系统可简称为“软件”。在 IT 发展的早期，软件被分为“系统软件”和“应用软件”。系统软件通常包括操作系统、编译系统、数据库引擎等等；应用软件则是建立在系统软件之上，用于解决特定业务问题的软件，例如保险核心业务系统、办公自动化系统等等。
然而，后来产生了一些软件，既不像传统的系统软件那么基础，也不具有特定的业务含义。例如网络服务器、应用服务器和消息服务器等等。这些软件介于传统的系统软件和应用软件“中间”，所以称为“中间件”。
也就是说， 软件系统可以分为“系统软件”、“应用软件”和“中间件” 。其中，应用软件又简称为“应用”。英文是 Application，缩写为 App。前端应用和后端应用都是应用。如果有人说“咱们开发一个 App 吧”，到底指的是前端应用还是后端应用，要根据上下文判断。如果有歧义，要及时澄清。 一个系统又可以划分多个子系统。子系统也是系统 ，只不过相对于它的“父亲”而言，是“子”系统。子系统可以向下进一步分成更细粒度的子系统。一种特殊的系统是“发布单元”，也就是可以独立部署和运行的最小单位。我们常说的单体应用、微服务，以及介于单体和微服务之间的各种中间形态，都可以统称为发布单元。
分析完“系统”，我们再来看看“产品”的概念。这里的产品，我们特指“软件产品”。
在软件工程的早期，并没有产品的概念。然而，随着近年来敏捷和精益方法的兴起，我们开始强调软件产品。那么产品和系统之间的区别是什么呢？
产品一定是面向价值的 。假设我们走进一家西装店，这家店只卖成衣，不单独卖扣子。而隔壁可能有一家店专门卖扣子。对于西装店来说，西装是它的产品，因为西装为它创造了价值，而扣子则不是。而对于卖扣子的店来说，扣子是它的产品，因为扣子为它创造了价值。所以同一个事物，是不是产品，取决它是否为企业直接创造价值，或者说，取决于企业的业务模式。回到软件产品。一个产品就是一个有明确业务价值的系统，比如说银行支持贷款的系统可以说是贷款产品，支持资产托管的系统可以说成是资产托管产品。一个产品可以是一个单独的系统，也可以由其他几个（子）系统组成。另一方面一个系统未必有明确的业务价值。比如说构成企业中台的系统，相对于最终用户而言，就未必是产品。一个系统可以被多个产品复用。
关系四：规范画法和自定义画法理清了这些基本概念，就可以制定架构图的绘制标准了。这时候主要有两种策略，一种是规范画法，一种是自定义画法。还有的策略介于两者之间。
下图中，我针对同一个系统给出了三种画法。
回忆一下我们前面提到的示意图和蓝图。如果你看到一个架构图不是规范画法，同时又没有图例，那它很可能只是个示意图，而非蓝图。因为蓝图需要有图例来保证其语义的严格性。
中间这幅图是 C4 模型。这种画法不算国际标准，但有专门的主页介绍，也有许多人使用，我称其为 民间规范 。企业到底选择哪种策略，取决于自身的偏好。有些人更喜欢遵循业界标准，因为这样可以减少沟通成本，更容易吸收前人经验。有些人则觉得业界标准过于复杂，喜欢建立小而美的自定义标准。这没有绝对的对错之分，只要能够解决企业的问题，并且在企业内部保持统一就可以了。
关系五：架构的维度和粒度 由于系统的复杂性，一个企业建立架构描述标准时，往往要包含多种不同的图，反应了系统的不同角度，这些图构成了一个体系。为了构建这样一个架构标准体系，需要考虑两个方面：一个是 维度 ，一个是 粒度 。下图表示了某个企业根据这两个层面设计的架构标准体系。
其中，图（diagram）用于直观地展示同一维度内的各个组件及其关系；表（catalog）可以详述每个组件的具体属性；矩阵（matrix）可以展示不同维度之间的关系，例如哪些系统支撑了哪些业务，哪些技术支撑了哪些系统等等。
架构可视化的实施建立了好的架构描述标准，并不一定能保证这些标准能够顺利实施。下面我们再谈几个在实施过程中需要考虑的问题。
关系六：“企业”架构和“企业级”架构我们遇到一些企业中负责架构的朋友，常常会问这样的问题：“按照 TOGAF 的说法，企业架构包括业务架构、应用架构、数据架构、技术架构。但是，IT 部门很难驱动业务部门，我们能不能只做应用架构或技术架构呢？如果能的话，是不是就不算企业架构了呢？”
为了回答这个问题，我们需要区分两个概念：“企业架构”和“企业级架构”。下图表示了两个概念的区别。
下面再谈一下有关架构组织的问题。
举一个例子。有一家企业，负责公司架构的同事说他们已经开展了两年的企业级架构工作，公司的 200 多套系统中，90% 都按照统一的标准绘制了架构图。于是，我去访谈开发团队。当我让开发人员向我出示架构图的时候，却发现很多人并不清楚哪里能找到最新架构图，甚至不清楚谁是自己团队的架构师。这意味着架构图没有真正发挥作用，这家公司可能只是“运动式”地推广架构工作。这就不再是技术问题，而是一个组织层面的问题了。
关于组织问题，我今天重点说一下 企业级架构师 和 团队级架构师 的角色和责任，见下图。
企业级架构师站在全局架构的视角，关注企业整体目标的达成。他们负责推动整个组织的架构工作，尤其关注跨系统、跨团队的协作。他们要制定全局性的架构标准和原则，而不需要深入了解每个系统的具体技术细节，但需在原理上有所理解。所以企业级架构师通常是“技术出身”的。此外，企业级架构师也更强调沟通、协作、影响力等软技能。
另一方面，团队级架构师会更专注于实现自己系统的目标。一般要深入了解本系统的技术细节，为本系统设计架构方案。并且，要对全局的架构标准进行落地和反馈，也要协助企业级架构师完成全局目标。在上面的例子中，显然团队级架构师的职责没有明确。
总之，不同层面的架构师的职责既有共性又有差异。企业要为不同的架构师建立不同的能力模型，并落地实施。
关系八：当前架构和目标架构 下面再谈一个微妙的问题，就是架构设计的时间点。 没有时间点的架构图是没有意义的 。比如说。我们访谈一些企业的架构师时，常常遇到下面这样的问题。我们让架构师拿出一张架构图，然后问他：这个架构图是当前架构还是目标架构？这个架构师会犹豫几秒种，然后说这是当前架构。接着，我们开始看架构图中的一些细节，发现有些和当前生产环境的实际情况不符。于是架构师又改口说，这是当前架构为主，但又有一些未来要优化的地方。我们说，那就不是当前架构了，应该就是目标结构。可是架构师又会告诉我们，有很多需要优化的部分并没有在图中反应，因此说是目标架构图也有些牵强。接着，我们又问，那么目前图中优化的部分，计划什么时候完成呢？架构师又会犹豫一下，然后给出一个时间点，比如说未来半年或一年。但很显然，这只是这个架构师现场“拍脑袋”给出的说法，并没有经过深思熟虑，也没有正式向任何一方承诺过。所以，我们发现一个有趣的现象，在很多架构师头脑中，并没有架构设计的时间点这根“弦”。
关于时间点，首先我们要分清当前架构和目标架构的区别，如下图所示。
由于架构会不断演进（尽管比代码演进要慢），所以要做好架构产出物的版本管理。开发中的目标架构和当前架构可以在同一个版本仓库中，用同一个主干管理。而近未来和远未来目标架构一般要用单独的仓库管理。
不同的公司，也可以根据情况采用不同的管理手段，比如说只有一年后的目标架构，没有三年后的目标架构。不过最基本的要求是，任何时刻，总可以获得反应当前生产环境的架构描述。
关系九：前期设计和浮现式设计 关于架构设计的过程，又可以有 前期设计 和 浮现式设计 两种策略。下图表示了两种策略的区别。
可以打一个比方来理解浮现式设计。比如说我们要画一张世界地图。一开始就画得非常详细是很困难的，而且也没必要。那么，我们就可以先把七大洲的大体边界画出来，先让看图的人知道有七个大洲这件事，以及大体的位置。然后，我们觉得亚洲最重要，就可以把亚洲的边界画清晰一点，并且画出亚洲主要的国家和大体的国界。接着，我们又觉得亚洲里中国最重要，于是可以把中国的边界画清楚，然后把中国的主要省市的大体边界画出来。同理，我们可能觉得广东省最重要，广东省中广州市最重要，广州市中番禺区最重要，依次类推。这样，过了一年，可能我们把中国最重要的几个城市画的比较详细了，而非洲可能还根本没有细化。但这已经足够了，因为已经满足了我们的需求。同时，七大洲的大图景也基本呈现了出来，只是等着我们在必要的时候“填空”。随着时间的推移，我们会看到这张地图越来越详细，越来越实用。而不同位置的详细程度则取决于优先级。给人的感觉，就是这张地图是逐渐“浮现”出来的。企业架构治理的过程，其实也是这个道理。
关系十：手工治理和自动化治理 最后，我们谈谈通过 手工 还是 自动化 的方式进行架构治理，其实就是使用工具的问题。下图表示了理想的架构治理和设计工具的一些特征。
企业架构在八十年代就已经提出了。但时至今日，许多企业在实际落地时仍然面临困难。原因有很多方面。其中之一恐怕是缺乏合适的工具。作为 IT 行业的我们，不断为业务提供工具支持，但对于 IT 自身的任务，比如架构设计，却不一定有趁手的工具。这是个有趣的现象，就是俗话说的“灯下黑”吧。
有些朋友说它们已经使用了自动化工具，比如说使用了 Visio、draw.io 等工具来绘制架构图。不过，这些只是“绘图”工具，而不是真正的架构工具。绘图工具只能画“图”，而无法理解图中表达的架构 知识 。所以，仅仅依靠绘图工具，我仍然把它算作“手工”方式。真正的架构工具能够理解架构中多维度的、结构化的知识。借助这些知识，可以自动化地完成很多工作。例如架构设计验证，架构守护、架构图生成、API 管理、代码生成、架构资产库管理、版本管理等等。
工欲善其事，必先利其器。目前多数企业中的系统都是数量繁多，关系复杂。开始进行架构治理的时候，可以暂时采用手工方式，长远来看，一款合适的工具是很有必要的。目前国内外有不少工具可供选择，我们要在功能、价格、成熟度等方面进行权衡。
以上就是我今天想要和大家分享的一些经验之谈，希望对大家能有所帮助。谢谢！