更好就足够了吗？| 驱动变革

评论

写在前面：

“出于技艺的追求，工程师常常会以开放的心态去尝试新的工具和做法。其中有些完全可以由我们自己掌控，比如使用哪种文本编辑器、采用什么样的控制台、是VIM还是Emacs风格快捷键等等。但更多的情况是，我们发现的“更好的方法”不仅会影响我们自己，还会影响到团队、部门甚至整个公司。如果我们坚信自己的选择并由衷地希望以更好的方式工作，那就必须能够说服其他人，让他们认可我们的做法，并在工作上作出改变。”

本文是徐昊所写的《驱动变革》第一篇，后续他还将从“职权不是决定因素”、“行为的改变”、“获取信任和确立愿景”以及“提升紧迫感”等几个角度分别阐述驱动变革的意义及方式。敬请期待。

作为工程师的我们为什么要学习驱动变革？为什么必须成为变革者？请先试想一下这两个场景：

• 你在代码库中发现非常多的重复代码，这些代码不仅功能趋同而且结构类似。在进行了简单的重构之后，你发现这些代码其实是一类公用组件，可以在很多业务场景下重复使用。这个时候，你准备把它提取成一个单独的共用项目或者叫基础模块，在消除掉这些重复的同时，改善代码结构并且让未来的功能开发更加简单有效。你希望其他人支持你的做法，并着手修改他们所负责的代码。

• 你所工作的小组正在为某企业客户开发一款调查问卷软件的升级版，采用的技术栈
是 .NET、ASP .NET MVC和SQL Server。随着项目的进行，你发现所有数据都可以由问卷实体进行聚合（aggregating）。如果使用关系型数据库，这种聚合关联关系复杂而且效率不高。而使用文档数据库（Document Database）不仅能简化开发，而且常用查询的执行效率会提高很多倍。你希望能由SQL Server切换到文档数据库——比如MongoDB。

这两个场景你应该觉得非常熟悉，这是工程师经常遇到的境况：由于非常了解手头所做的工作，通常会比组织中其他人更早、也更敏锐地发现更好工作方式。比如更好的编码方式、更恰当的编程语言和工具，还有更合理的工程实践等等。出于技艺的追求，我们会以更开放的心态去尝试新的工具和做法。其中有些完全可以由我们自己掌控，比如使用哪种文本编辑器、采用什么样的控制台、是VIM还是Emacs风格快捷键等等。但更多的情况是，我们发现的“更好的方法”不仅会影响我们自己，还会影响到团队、部门甚至整个公司。如果我们坚信自己的选择并由衷地希望以更好的方式工作，那就必须能够说服其他人，让他们认可我们的做法，并在工作上作出改变。

作为工程师，通常我们对这个问题最直接的反应是以结果说话。相信只要有更先进的技术、更好的结果、更多的产出，那么我们所期待的变化就会自然而然地发生。然而实际情况恰恰不是这样的，我们容易低估变革的难度和阻力，而高估技术因素在变革中的影响力。比如上面所说的两个场景： 第一个是重构代码并调整项目结构，第二个是更换技术栈中的组件。看起来都是收益明确的“技术决定”，但这些决定带来的变化可能是非常深远的，阻力也可能完全来自意想不到的地方。

架构与组织结构改变

首先来看第一个例子——重构代码并调整项目结构。这里的盲点是Conway法则——组织结构是软件架构的倒影，阻力来自因为架构变化带来的组织结构变化。

你所重构出来的公共模块会在很多业务场景下重复使用，假使让所有使用了这些模块的小组共同维护这些组件，就会带来非常大的沟通成本。无论是API的变化还是特性的取舍，都没有办法在某个小组内单独决定，因为它现在已经是共用模块了。最简单的情况是由某个人——很可能就是你——来协调对公共模块的修改。那么在不久的将来，如果公共模块的需求足够多，实际上就会出现一个独立的公共模块小组或团队。这是由技术决策带来的团队结构和人力分配的调整。如果不能把这个因素纳入考量，重构就可能会失败。

你可能会想这真的会发生吗？重构一下代码结构能有这么大的影响吗？这当然不是编造的，我来讲个现实中发生的案例。

曾经有一个团队，他们采用的技术栈是 .NET。最开始的架构也很简单，前端采用
ASP.NET MVC，后端使用Entity Framework进行存储。然而这个系统的领域模型比较复杂，有很多小的细力度对象。使用Entity Framework进行持久化的时候，类型映射的代码非常复杂，但这些对象引用关系相对比较简单。这时候有个技术非常不错的小伙子，为了解决底层的持久化问题，开始寻找不同的解决方案。于是他边写功能代码边自己做了一套不同于Entity Framework的持久化框架，通过SQL Server的XML字段和 .NET对象序列化完成所有持久化的操作。

他做完演示之后，大家都觉得很不错，于是就开始着手重构其他代码。这时候麻烦来了，他做框架的时候，是根据他所熟悉的业务进行的抽象，有很多没有考虑到的地方。不过他手很快，白天提的需求晚上就能改好，后来慢慢发现由于整组人都在用这个东西，别人又没他了解的多，不如让他专门来做这个框架。渐渐他就不做其他的需求而是专门来做框架，于是他自己就成了一个小团队。

这就是因重构而产生团队结构变化的例子。这个案例之所以能够成功，除了他个人的一些做法之外，主要是因为这个团队负责整个软件的交付，责任结构比较简单，内部分工的变化对整体交付没有影响。如果不是这样的结构，又不事先考虑组织变革的成本，那么架构重构基本上就会失败。

很多年前，我在Java社区认识一个朋友，他所在的公司在国内某行业做定制软件开发。这家公司的团队是按业务模块进行划分的，每个小组负责一个模块的交付。我这位朋友算是想法比较活泼的，他希望能够抽取与业务相关的公共组件，从而在现有的项目中提炼出产品和行业解决方案。他在他负责的小组内做了尝试，并取得了一定成功。

他的领导让他征求其他团队的意见，看看是否有推广的前途。然而在这个过程中，他受到项目其他模块团队的质疑：如果公共模块出了问题谁来负责？当他回答说，“我可以用业余时间尽量帮助大家”的时候，最终实施结果也就可想而知了。没有人愿意把交付的成败依靠在某个人的业余时间投入上，而领导又没有足够的动力改变整个团队的结构，那么这个方案也就不了了之了。

核心组件与技能要求

再看第二个例子——更换技术栈中的组件。这里的盲点是协作部门的技能变更。

你所作出的技术决定是正确的。针对这种聚合关系的对象结构，无论从数据存储的效率、查询的效率还是开发的效率来说，文档数据库都会是更好的选择。但是开发仅仅是整个软件生命周期中的一环，除了开发之外还有运维支撑，比如监控、备份、数据恢复、故障诊断等方面，也是非常重要的。特别是对于已经运营了一段时间的软件产品来说，就更是这样了。

在这个例子里，因为是后续升级而不是全新系统，那么客户已经围绕SQL Server建立了完整的运维体系。那么如果把数据库换成MongoDB，就需要围绕MongoDB建立新的运营方式，那么运维团队就需要新的技能和工具才能继续运营这个产品。这是因技术决策而为协作部门带来新的技能要求，如果不能把这个因素纳入考量，就会影响软件的最终投产。

同样为了告诉你这样的事情真的会发生，我举个例子。

最近有个团队，在帮助某客户研发医疗管理系统。该系统是个有多年历史的遗留系统。由于设计的早，架构上有很多不尽合理的地方。在这次的研发中，客户希望可以撷取业内较好的工程实践，以支撑未来的架构演化。这个团队采用了micro-service的方式架构整个应用，把独立的模块分解成独立的服务。部署上为了更好的弹性，抛弃了原有系统的应用程序服务器模型，而是采用内嵌Web容器的方式。

在开发了一段时间之后，有医院方的人员来参加成果展示。这时候，负责这个系统运营的IT部门表达了强烈的不满。原因是，他们的运营人员主要通过应用程序服务器的控制台管理所有应用程序。而一旦变成多进程的micro-service后，原有运维工作就需要依赖linux平台上的日志、进程管理监控工具才能完成。他们的运维人员完全没有这方面的经验。当时的结果是，micro-service仅在测试环境中使用，而生产系统必须采用应用服务器的模式。

这是好的、先进的技术因为没有预估好协作部门的技能水平而失败的例子。当然，考虑到这个问题而把一些相对激进的好技术推行成功的故事也是有的。

在Ruby还不是很流行的时候，有个团队想在项目中使用Ruby Watir作自动化功能测试。而客户的情况是：他们已经花了大价钱购买了HP的Quality Center和QuickTest Pro。这两个都是商业软件，都需要高昂的版权费用。这两个软件分别由业务人员和QA团队使用，业务人员使用Quality Center来记录需求和测试案例，自动化功能测试主要由QA团队完成。QA团队主要采用录制脚本结合VB Script的方式来编写测试，测试全部由QuickTest Pro执行。

力主使用Ruby Watir的是研发团队，因为当时ruby很新潮同时Watir的执行效率比QuickTest Pro要好很多，但QA团队并没有表现出对Ruby的热衷。这时候团队里的工程师研究了QuickTest Pro的编码风格。发现QuickTest Pro中测试主要依赖三个部分：Object Repository用于表示页面元素和常量、Data Sheet用于记录测试数据、VB Script用于实现测试步骤。于是他们使用Ruby做了一套框架：PageObjet用于表示页面元素和常量、Fixture用于记录测试数据、定制的领域专用语言（DSL）用于实现测试步骤，同时整合Quality Center以统计测试报告。这个框架让QA团队感觉到工作方式其实没有什么太大变化，基本都能与QuickTest Pro中的概念一一对应，并且不会影响Quality Center的使用。就同意尝试
使用它。大约四周之后，整个测试部门就开始了由QuickTest Pro到Ruby Watir的迁移，QuickTest Pro就完全废止不用了。所以只要方法正确，这种看似不可能的变化——抛弃已经采购的商业软件转而使用开源软件和不知名的小语种——也是可以顺利完成的。

我还可以列举出非常多的例子，看起来都是好的技术决策，然而最终左右这些决策成功与否的并不全是技术因素。我想你已经大概明白我的意思了：仅有更好方案是不够的。更先进的技术、更好的结果、更多的产出，并不能让我们所期待的变化自然而然地发生。哪怕只是某些技术上的改进，单单是个体的变化已经不够了。那么如果我们不希望年复一年地工作在腐烂的代码库上，使用陈旧的技术栈、落后的工具、过时的工程实践，我们必须学会驱动变革，成为卓有成效的变革者。

更多精彩洞见，请关注微信公众号：ThoughtWorks洞见

Share

Layered Microservices Architecture

评论

位置

2018年11月第19期技术雷达（点击此处下载），技术象限，建议暂缓。

标签

Microservices，Architecture，Anti-pattern

目标受众

系统架构师，技术管理者，开发设计人员

关注问题

构建微服务架构首当其冲要解决的问题，就是业务服务如何划分的问题。我们发现很多组织在技术快速发展的今天，仍然会重蹈过去的覆辙，对于服务按照以前的多层架构的分层方式进行划分。这样的架构不但没有尝到微服务所带来的独立交付业务价值的甜头，还要承受微服务所引入的运维复杂度。

解决方案

按照业务能力（business capabilities）而非技术能力来划分团队和服务。

解读

对于N年前的多层架构来说，层往往是按照技术能力来划分的。以最典型的三层架构为例，包含用户界面层、业务逻辑层和数据访问层，分别由擅长前端、后台和数据库的团队来维护。每一层可以部署在不同的服务器上，构成了分布式系统的雏形。

但这样的架构很快就会出现问题。因为用户访问的是业务功能，不是上述某一个特定的层，所以用户的每一次访问都会贯穿这三层服务。任何一层出现问题，都会导致这次访问失败。而每当新的功能需要交付时，都必然要修改和重新部署所有的层次。

我们常用切蛋糕来举例子。分层架构就像是横切蛋糕，切下来的每一块都只是那一层的原材料，可能是奶油，可能是水果，也可能是慕斯。但每一块都不是完整的蛋糕（业务功能）。只有纵切蛋糕，奶油水果慕斯蛋糕一应俱全，才是用户真正想要的东西。所以我们都是纵切，切出来的每一块蛋糕都是可以分给别人吃的（独立交付的单元）。

微服务架构正是基于此诞生的。它打破了传统多层架构的束缚，以业务能力而非技术能力来划分服务和组件。比如在电商系统里常见的微服务可能包括商品服务、订单服务、支付服务等，而在传统多层架构下这些只是业务逻辑层和数据访问层的一部分内容。微服务和传统多层架构对于服务的划分，是正交的。

随着近年来的飞速发展，微服务已经逐渐成为主流架构。但无论技术如何快速变化，一些企业仍然想方设法地重新实现过去的反模式。分层式微服务架构（Layered Microservices Architecture）就是这样一种反模式。它打着微服务的旗号，但仍然按照技术能力来划分服务。比如用户体验API、进程API或系统API等。这导致任何有价值的业务变更，都需要缓慢而昂贵的多团队合作。微服务独立演进、独立交付、快速响应变化的好处一个也体会不到。

之所以陷入这样的误区，还是康威定律在背后起着作用。因为组织仍然按照技术能力而不是业务能力来划分团队，那么步入以技术能力来划分服务的歧途也就在所难免了。

因此在最新的第19期ThoughtWorks技术雷达中，分层式微服务架构首次入选，并进入“暂缓”行列。我们强烈建议组织评估这种分层方式带来的影响，我们更推荐根据业务能力来划分服务和团队。

注意，这里的分层（layered）特指按照技术能力来划分微服务，会导致教条式的逐层调用。它并不代表按照业务划分的微服务之间，根据不同服务的职责所划分的层次。比如，有些服务负责具体的业务能力，有些服务则会将不同业务服务组合起来，并提供一个对调用端更加友好的接口，我们常常称之为Composer或Orchestrator。这样的“分层”属于categorized，不是layered。

相关Blip

Share

数据中台演进之AI中台

评论

数据中台

数据中台对一个企业，起着至关重要的作用，在数据中台这个称谓成型之前，各个企业分别都在用不同的方式来尽可能的利用数据产生的价值，同时也处理着数据带来的问题。例如各个业务系统以烟囱架构形式存在，长期以往导致数据孤岛，数据隔离，数据一致性等一系列的问题，那么当我们需要充分利用数据的时候，就不得不去考虑怎么解决这些问题。于是各个企业分别形成数据团队或者数据部分开始继续数据整顿工作，数据仓库，数据湖，主数据治理等一系列的工作应运而生。

本质上，这些工作都是因为业务需要不得不进行的一系列数据治理的动作，对于如何利用数据来发力，并没有形成一个强有力的底座。有点像头痛医头，脚痛医脚，各个业务系统规范不一致了，于是开展了元数据治理，数据分析的时候数据关联不上了，于是不得不进行主数据治理。

在进行了很多年的数据工作之后，数据中台这个概念逐渐有人提出了，可能阿里的《企业IT转型之道：阿里巴巴中台战略思想与架构实践》这本书，把这个概念推向了一个高度，似乎定下了一个参考答案。中台战略我们常说：大中台，小前台，在这种模式下非常频繁出现的字眼是：共享。那么共享到底共享的是什么？共享的便是数据的服务。中台战略并不是搭建一个数据平台，但是中台的大部分服务都是围绕数据而生，更加巧妙的地方是中台战略让数据在数据平台和业务系统之间形成了一个良性的闭环。于是，数据和业务系统融为了一体。

上图是一个浓缩的描述，可以看到，数据中台在业务侧解决的还是能用的问题，只是有了数据中台后，我们构建出能用的服务变得更快速，更加的标准化，但是在好用方面，数据中台相对乏力。

因此在中台架构之后我们逐步认识到，原来数据的价值并不只是个运营出个参考的分析报表，做一系列的预算。数据中台为大型企业数据利用最大化提供了一个参考的案例。常说的深度学习，机器学习等等一系列技术在这个平台上似乎找到了一个发力点，开始在这里施展拳脚。

但是，中台并不是数据分析利用的终点，仔细看数据分析的历程，可以归纳发现数据利用大概有如下三个阶段：

第一阶段：响应运营

响应运营是数据分析最直接也是最原始的需求，没有谁会不关心自己的用户留存率，没有谁会不关心自己的营收额。同时对于出现故障，预测分析，同样也是非常重要的事情。但是在运营分析过程中，发现一系列的问题，例如各个业务系统的数据存储格式，存储介质都不相同，那么在进行基本的运营分析的时候则无法流畅的进行，不得不进行一系列的数据治理。常见的主数据，元数据就是发生在这个阶段，只是数据仓库将主数据和元数据治理进行了规范化。

第二阶段：响应业务

数据分析停留在运营阶段的时候，对企业来讲最大的感受就是投入产出比不对称，这个问题在大数据爆发的时间点更为凸显。例如在今天的业务场景下，传统的数据仓库已经解决不了海量数据，异构数据等一系列问题，而大行其道的大数据分析技术，门槛高，硬件需求高。要实施一个大数据平台，成立一个大数据团队，并不是一个小成本的开销，更何况现在有不少数据分析团队会通过机器学习等手段去对数据做分析来响应运营，这就加剧了成本和门槛的进一步提高。

于是像数据中台这样的思想就被提了出来，既然数据是从业务系统产生的，那么是否业务系统也需要数据分析结果呢？对于数据平台来说，数据平台本身提供两大能力：数据存储和数据计算的能力。那么业务系统的数据存储和数据计算能力是否可以剥离到数据平台，仅仅让业务系统很轻量的维护自己的业务流程操作？所以中台剥离的复杂的业务环境，再配合微服务等技术，一下子让人感受一个词：共享。

而对业务场景来说，很多时候是需要数据的服务的，例如用户的基本信息管理，用户的行为数据分析，这些数据不但可以暴露给业务系统使用，甚至可以直接丢给终端用户自行使用，而这种契合点，让数据平台变成了一个服务，提供给业务系统，而对终端用户来说，自己消费自己数据的同时也在继续产生数据，这样数据就形成了闭环。

第三阶段：创造业务

业务不会总停滞不前，因为人的生活会改变，想要的体验会改变，所以业务系统的功能会跟着改变，当我们发现数据可以逐步变成通用服务提供给业务系统的时候，就会思考，数据是否可以变成个性化服务提供给终端用户？例如不一样的得到不一样的推荐？这是一个非常简单的例子。但是当越来越多这样的服务之后，组合创造的可能性会变高，组合带来的个性化体验会更好，这就是数据服务的创造业务的阶段。

数据中台之AI中台

数据中台解决的是第二阶段的问题，对第三阶段对问题并没有特别好的支撑，因为数据中台本身还是围绕数据服务来进行的，而非围绕智能服务来进行的。举个例子，从未来来讲，系统一定会越来越个性化，甚至每一个人看到的登陆界面都不一样，系统可以根据对应的终端用户自行生产出符合该用户习惯的系统界面。那么对于这样的场景和服务产生，我们需要怎样的平台来诞生，我们的整个软件开发架构和流程是否都会重造？

从CI/CD的角度来讲，我们的CI/CD保障了我们的软件输出按照既有的设定测试结果方向靠齐，那么在个性化服务下，我们应该构建怎样的pipeline来管理和发布这些模型？这和工业4.0提出的智能制造非常类似，早期我们通过流水线的形式让各种不一样的业务，不一样的软件通过一种统一的流水线的方式运作，但是在智能制造的前提下我们期望为每一个不一样的终端用户提供不一样的服务，那么统一的流水线是否依旧适用？

AI中台便是数据中台的进一步延伸，也是为了解决上面的问题，让数据利用达到第三个阶段：创造业务。既然有创造业务就有售卖业务，如下图所示：

可以看到，上图是目前最常见的软件平台的运作方式，开发人员开发出了对应的软件服务后，提供给终端用户使用，虽然会有销售售卖该服务，但是更多的是拿着一个锤子找钉子，而不是给钉子快速制作一把合适的锤子再去售卖。

AI中台尝试提供一种能力，来达到这样一个效果：

将整个软件组装出来的服务，如同个性化的产品一样去售卖，这样的服务就是量身定做的，非你莫属的。那么整个运营模式就变成了，AI平台提供了一种快速构建智能服务的过程，服务售卖者将自己动手做出来的服务拿出去售卖，这个和paas平台非常相似，但是paas提供的是一个业务无关性的售卖机制。借助一个平台，将软件的服务个性化的创造，这可能是未来的发展趋势。

通过下图可以看到，各个企业或者行业，都在第三个阶段做了不同的探索和努力：

但是又各自遇到不同的问题，总结起来发现在落地过程中，通常存在以下问题或者挑战：

从数据中台的演进

AI中台不是一蹴而就的，也许达到最终的效果有非常长的路要走，但是我们可以考虑逐步的演进过去，首先的步骤就是可以将数据中台智能化，所谓的智能化是指将在数据中台进行的一系列的数据服务构建操作，更加的智能化，从数据的接入，存储，分析展现，训练，到pipeline都更加智能化。例如对于通用的CI/CD来说，test不过则会构建失败，那么决定一个推荐模型构建失败的条件是什么？显然现有的CI/CD并不能很好的为此服务。

其次，对于中台使用者来说，目前基于数据中台的一个智能服务模型开发来说，流程如下：

基本类似于一个横向的烟囱架构，带来的问题比较明显，因为黑盒的原因导致目前对一个模型的工作进行拆分的时候，都不是特别的顺畅，当然因为目前大部分业务场景依旧以流程为主，没有太多的智能服务，所以一系列的问题并没有明显的被暴露出来：

  • 借助于现有数据平台手工进行数据操作
  • 烟囱架构开发，对人员能力要求高
  • 环节无法有效拆分，响应周期慢
  • 智能场景规模化，管理复杂
  • 训练，部署，发布依赖于手工部署缺乏有效的流水线
  • 和数据平台孤立，缺乏统一的数据服务接口
  • 基础设施隔离，无法动态进行资源的分配和管理

从一个好的体系来讲，AI中台是借助数据中台的能力，但是具备构建智能服务的能力，AI中台尝试解决如下的问题：

  • 和数据平台结合，利用数据平台的能力作为数据支撑，最大化的发挥数据平台的价值
  • 拆分服务构建环节，智能服务开发流程化，快速响应业务需求
  • 利用元数据管理方式，提供统一的标准格式，场景可以多人协同配合开发
  • 基础设施共享化，模型的训练和发布与数据平台有效绑定，服务的构建自动化
  • 统一的元数据管理系统，模型的全生命周期可管理
  • 通用AI能力平台化，降低人员要求，提升协作效率

所以就要求我们对服务构建的过程进行如下拆分：

首先需要从基础设施层面进行集成，常规的数据中台依赖于大量的CPU和内存，而相反，机器学习模型对GPU的依赖反而更高，但是又不能脱离数据中台，因为它依旧需要利用数据中台的存储和计算能力来处理大量的数据，所以如何通过一个接口，一个调度器，一个pipeline来集成整个工作流，就成了需要考量的事情了。

从整个大的来讲，AI中台至少应该分为一下几个层级：

在数据中台的基础上扩展对GPU级别资源的管理和整合能力，调度层提供统一的任务，服务，智能CI/CD等服务，对AI平台来讲，提供的能力聚焦在：利用算法，模型，框架如何动态和快速的组装和产生出能支持创新的服务上。

结尾

AI中台是数据中台在业务上的演进，是系统服务的重组的过程，因素还是那些因素，就像工业4.0里面的螺丝钉还是那些螺丝钉，但是每个螺丝钉都被打上了个性化的标签。不过，被打了标签的钉子，还是原来的钉子吗？这是个问题，但是在落地实施过程中，我能够发现，虽然以AI中台进行落地实施，但是实际的这个过程，却是“持续智能”的一种体现，关于“持续智能”，则是在AI落地的核心思想，后续再做重点分享。

即日起至2019年2月23日前，为技术雷达十周年峰会福利发放时间！购买即可享 早鸟票七折优惠 ，峰会报名仅为¥1024.00元！（数量有限，先到先得！）

Share

可视化架构设计——C4介绍

评论

好多年前，同事徐昊说过的一句话给了我很大启发，他说“纸上的不是架构，每个人脑子里的才是”。这句话告诉我们，即便是天天工作在一个团队里的人，对架构的认识也可能是不一样的。每个人嘴上说的是类似的话，但心里想象的画面仍然是不一样的。在多年的工作中，我越来越认可这句话所揭示出的道理。软件开发是一个团队协作的工作，混乱的理解会造成架构的无意义腐化、技术债的无意识积累、维护成本的无价值上升。

最近听到一句话，“那些精妙的方案之所以落不了地，是因为没有在设计上兼容人类的愚蠢”。话糙理不糙，虽然最终人们选择的方案的思想都是在十年前甚至几十年前就已经存在的，然而在技术升级到足以“兼容”人类的愚蠢之前，这些思想只能在学术的故纸堆里睡大觉。当然话糙确实也会有一个问题，将一个思想性问题转化成了情绪性问题。人们容易把一些糟心的事情归因到人类的愚蠢，在宣泄完不满情绪后就停止思考了。作为知识工作者，我们的思维不能停步，我们需要思考到底人类有哪些愚蠢，分别用什么方法去避免或者“兼容”。

可以肯定彼此明明对自己开发的软件有不一样的认识却天天在一起讨论问题并试图把软件做好是一件愚蠢的事情，为了兼容这种愚蠢我们需要采用可视化的方法。

为什么需要可视化呢，主要还是语言不靠谱。人类语言真的是太随意了，只要你想，你可以说你见过一个方形的圆，并为此与别人辩论。但是无论如何你也画不出来一个方形的圆，这就是我们需要可视化的原因。

今天我们介绍一个工具，叫做C4 model，这是我近几年见到的一个比较难得跟我的认知有大量共鸣的工具。

该工具的作者在多年的咨询中经常发现，很多个人画出来的架构图都是不一样的，但也不是说谁画错了，而是每个人的抽象层次不一样。抽象层次这种东西，说起来好像存在，但真要说清楚还挺难，于是作者类比地图，提出了缩放的概念。（两年前我在教学生的时候提过同样的概念）如下图：

上面的四张地图就是想说明，当我们看待真实世界的“架构图”时候，也是要不停的缩放，在每一个层次刻意忽略一些细节才能表达好当前抽象层次的信息。所以他类比着把架构也提出了四个抽象层次：

从上到下依次是系统System、容器Container、组件Component和代码Code。（咦，那为什么叫C4呢，因为系统的图叫System Context，系统上下文图。为了凑四个C也是够拼的。）

基于这四个层次的抽象，C4模型由4张核心图和3张附属图组成，分别用于描述不同的场景，下面我们一一介绍一下。

四张核心图

系统上下文图

如上图所示，这个图表达的是你所开发的系统和它的用户以及它所依赖的系统之间的关系。从这个图上我们已经看出来C4图形的几个关键图形：

C4说穿了就是几个要素：关系——带箭头的线、元素——方块和角色、关系描述——线上的文字、元素的描述——方块和角色里的文字、元素的标记——方块和角色的颜色、虚线框（在C4里面虚线框的表达力被极大的限制了，我觉得可以给虚线框更大的扩展空间）。

通过在不同的抽象层次上，重新定义方块和虚线框的含义来将我们的表达限制在一个抽象层次上，从而避免在表达的时候产生抽象层次混乱的问题。

那么在系统上下文图里，方块指代的是软件系统，蓝色表示我们聚焦的系统，也就是我开发的系统（也可能是我分析的系统，取决于我是谁），灰色表示我们直接依赖的系统，虚线框表示的是企业的边界。通过这些图形化的元素表达我们可以看出来各个系统彼此之间的关系。

容器图

当我们放大一个系统，就会看到容器，如上图所示，C4模型认为系统是由容器组成的。我个人认为，容器是C4模型最大的创举，尤其是在这个单体架构快速崩塌的时代。所谓容器，既不是Docker的容器，也不是JavaEE里的容器，而是借用了进程模型，代指有自己独立进程空间的一种存在。不管是在服务器上的单独进程空间，还是在浏览器里的单独进程空间，只要是单独的进程空间就可以看作一个容器。当然如果你容器化做得好，Docker的Container和这个Container可以一一对应。有了这个概念的存在我们就可以更清晰的去表达我们的架构，而不是总是用一些模糊的东西。

组件图

当我们放大一个容器，我们就会看到组件，如上图所示。组件在这里面很好的把接口和它的实现类打包成一个概念来表达关系。我个人觉得有时候一些存在于代码中，但又不是接口的某些东西，比如Service、Controller、Repository之类也可以用组件图来表达，如果你学了一些没有明确抽象层次的架构知识或者一些单体时代的遗留经验的时候，你可以画出来一些组件图，来印证自己的理解，如下图，是我画的自己对DDD战术设计里面的一些概念的理解：

比起模糊的堆砌在一起的文字，这种表达要清晰的很多，哪怕我的理解是不对的，也容易指出和讨论。

代码图

代码图没什么可说的，就是UML里的类图之类很细节的图。一般是不画的，都是代码生成出来。除非非常重要的且还没有写出代码的组件才画代码图。

以上就是C4的核心图，我们可以看到四种不同的抽象层次的定义会让我们更容易固定住我们讨论的层次，这点上我觉得C4是非常有价值的。

三张扩展图

架构设计设计要考虑的维度很多，仅四张核心图是不够的，所以作者又提供了三张扩展图，可以让我们关注更多的维度。

系统景观图

看得出来，系统景观图是比上下文图更丰富的系统级别的表达。不像上下文图只关注聚焦系统和它的直接关系，连一些间接相关的系统都会标示出来，那些系统的用户以及用户之间的关系也会标示出来，只是内部的用户会用灰色标记。

这个图有什么用呢？在我们分析一个企业的时候，我们需要一个工具帮助我们把一家公司给挖个底掉，做到完全穷尽，才能看到企业的全景图，从而理解局部的正确定位以做好局部设计为全局优化服务。之前我试过以四色建模的红卡、事件风暴的事件两种工具来教人掌握这种能力，一般来说，程序员学员都无法快速掌握这种顺藤摸瓜的分析技巧，毕竟跟程序员的思维还是有些差异的。但是用了系统景观图之后，学员就毫不费力的掌握了这种分析能力，所以我后来都是用这个图来教程序员探索企业的数字化全景图，效果极好，推荐给大家。

动态图

动态图不同于其他表达静态关系的图，它是用来表达动态关系的，也就是不同的元素之间是如何调用来完成一个业务的。所以动态图不仅仅适用于一个层面上，它在系统级、容器级和组件级都可以画，表达的目标是不一样的。

我之前曾经写过名为《像机器一样思考》的一系列文章，在文中也发明了类似的图，不同于本文中关系线上标注的是调用的方法、函数，我更关注的是数据，使用效果也很好。

什么时候用动态图呢？举个小例子，我之前做一个内部的小系统，团队中只有一个有经验的工程师带着十多个毕业生，我便要求他们在开始工作之前都画出动态图来，交由有经验的工程师去评估他们的思路是否正确，如果有问题，就在开始之前就扼杀掉烂设计。不管是毕业生还是初级工程师，改代码的能力都比写代码的能力要差很多，所以将烂设计扼杀在实现之前还是有帮助的。

部署图

前面的几张图都是站在开发的角度思考，但是一个没有充分思考过部署的架构很容易变成一个运维的灾难。所以作者提供了一个部署图。考虑到DevOps运动如火如荼，这个图可以变成很好的Dev和Ops之间沟通的桥梁。我们在实操中发现，Dev和Ops关注点的不同、语言的不一致，在这张图上表现得非常清楚。

图上最大的的实线框不同于虚线框，它表达的是数据中心，当你开始考虑异地载备的时候它就有了意义。数据的同步、实例的数量都会影响部署图的内容。部署图基本都是容器级的，它能很好的表达出来容器到底部署了几个实例，部署在什么样的操作系统上，一个节点部署了几个容器之类，我们在实际使用中，发现需要考虑的信息太多，自己就抽象出了类似于亚马逊上实例规格的Small、Large之类的术语来表达机器配置，增进了开发和运维之间的交流准确性。

为什么C4值得推荐

够直观，对于程序员来说容易理解，容易使用。

我们在开头的时候说过，只有每个人脑子里的才是架构图，如果我们使用一个本身就很难达成一致理解的工具，那成员就会陷入理解的死循环。经过尝试教授不同工具，发现C4模型是最容易理解、最容易使用的工具。可能它的概念是复用了程序员已有的一些认知模型，程序员在学习后都可以迅速的使用起来，并问出一些高质量的问题。

总结

在思维的世界里，我们都是盲人，很多东西我们以为自己知道，实际上画出来之后，才发现很多东西没想到，或者想的是乱的，同时别人也才可以给我们反馈。

有了上面的这个工具，我们就可以开始可视化的架构设计之路了，但路上还有一个心魔需要战胜。在我们的文化里，出错是一件很丢人的事情，所以我们喜欢用一些模糊的描述避免被别人挑战，而可视化是让我们精确的描述出自己的理解，来欢迎别人的挑战。这一个坎不太容易跨过去，但是一旦跨过去、大家形成正向的互动之后，我们的进步速度会变得很快，从而把封闭的人远远的甩在后面，获得组织级的成长推力。我自己就在跟别人的交流之后获得了更深入的洞见，本文已经分享了一些，还有一些内容后续再跟大家分享。

注：文中图片均来自：https://c4model.com/

更多精彩洞见，请关注微信公众号：ThoughtWorks洞见

Share

企业转型的三个“小趋势”

评论

2018对我来说是有很多收获、很有意义的一年。整个上半年完成了一个产品、包括分布在东亚和东南亚三个研发中心的分布式团队转型工作。从上周团队负责人反馈的成效来看，确实给产品的质量和团队的工作氛围带来了提升。我很荣幸能够参与到这个产品和团队的转型过程当中，见证了从开发人员到组织管理层一步步的变化。下半年的工作比较零散，主要帮助了几个团队完成了对当前状态的识别和下一步的规划。领域驱动设计社区的影响力在团队的协作之下进一步扩大，年底的大会对整个社区的实践做了一个全方位的检阅和整理，与企业和国外社区的合作也打下了明年尝试构建更广泛生态的基础。

就在刚才，我打开Google日历，回顾了2018年经历的事情和服务过的客户，以及和不同企业、不同层级、不同部门、以及ThoughtWorks同事的每一次沟通，我想可以把我的2018的所思所想，总结成三个我能看到的，并没有那么小的“趋势”。

一、数字技术本身，已经成为企业转型和创新的核心引擎

回顾过去几年我所经历的企业转型，在转型之初，企业一般都会选择从组织和管理的角度入手开启自己的转型步伐。造成这种选择的背后原因有很多。从组织本身来说比如由于历史原因，组织并不具备技术研发能力，更希望从IT管理侧驱动转型；又比如组织确实具备一定的研发能力，但是由于技术水平有限，希望先通过管理的转型进而拉动技术实践的变革。外部来看，市场上管理领域转型方法论的商业运作及影响力要远远好于技术转型的方法论，这可能也是原因之一。从过去若干年的实践经验来看，管理的转型会前置于技术的转型，甚至管理的转型可能是企业转型当中的唯一一个切片。

但在过去几年社区方法论的发展情况来看，技术实践的演进速度要远远快过管理实践的演进。从极限编程到持续交付、再到DevOps，技术实践本身已经超越了所谓仪式（Ceremony）的范畴，逐渐走向真正的“一切Dev说了算”。从企业的具体实践来看，先突破技术的瓶颈，进而逐渐引入管理实践和组织变革，也成为一种可行的转型思路。

举个例子，在第四季度我参与了一家日本汽车制造企业的供应链管理变革项目。与我们同时进行的，是该企业集团内部的精益生产变革项目。两个改进小组同时进场，同时开展工作。精益变革小组的改进举措包括了自动化掉现有的人工工作、加强组织间的信息共享和协作等。我们小组的方案是以数据为核心，首先提升数据的质量，利用新技术（区块链等）强化数据的收集渠道，然后通过数据的透明，尽早（8周之前）将供应链的风险与问题暴露给企业，从而加强供应链本身的可预测性和可管理性，进而赋能供应链生态中的日本企业在精益生产方面的诉求。在落地过程中，仍然建议要从管理和组织的维度去变革，来更好的收集数据、分析数据、利用数据指导生产。

在这个案例中，过程还是有些波折的。例如处于差异化竞争的考虑，我们一直在避免走到管理咨询的道路上去，但是最后发现如果没有管理方面的配合，即使技术转型的基础搭建起来了，整体上的转型过程仍然可能遇到组织配合和合作的陷阱，使得转型方案没有办法100%落地。但当我们站在企业的角度（要知道日本是精益生产的起源地，大多数客户自身都是精益专家）来看，另外一条精益改进的道路，即从管理的维度逐步展开持续改进，并没有给出一个全局性的问题识别结论和解决方案。这种从管理维度逐步改进的方案，风险可能是经过了一段时间之后发现并没有带来什么效果。对于这家企业来说，像我经历的其他很多企业一样，从逻辑上看风险更低、投资回报比更合理的选项，是让技术变革成为驱动整个供应链变革的核心动力。

这个案例给我的另一个启示是，在转型的过程中数据的收集策略和分析策略应该是转型的前置条件。不能说清楚数据上的收益、没有技术手段及时收集和分析数据、亦或不能及时反馈数据上的进展，转型的过程就好像是在黑夜里摸着石头过河。组织活动的开展看上去轰轰烈烈，但是当咨询顾问一走，或者当这阵风过去，一切又恢复到了老样子上。

二、业务和技术的融合，成为企业转型的焦点

2017年，我的工作重心还聚焦在微服务和敏捷转型上。在那个时候我和我的同事经常会跟客户讲，转型项目成功的关键是能够加入业务部门，让业务人员真切地看到转型的好处。获得了业务部门的支持，转型的影响力就能出来，变革项目也会持久。到了2018年，几乎同样的话我们已经没有机会再主动提出，而客户在第一次或者第二次交流的时候，就会主动问到你们有什么手段和方法可以让业务部门更主动的加入进来，可以让我们的转型得到业务部门的支持。

在这一年中，我的另一个主要客户一直在努力寻找这个问题的答案。企业为了追求业务的响应能力，从根本上认识到了机构业务的实质是基于技术提供的服务。基于这个基础假设，该机构打破业务和技术的壁垒，将业务和技术做了重新的整合，实现了IT能力前置，以赋能业务。2018年，我同样很荣幸能够参与到这个企业的转型过程当中，亲眼见证他们是如何重新定义了业务和技术的协同合作方式，并且用新的方式来推进新产品研发的。

业务和技术的融合也对技术团队间的合作带来了新的挑战。一般来说，企业除了赋能业务的技术团队之外，还会存在负责企业级支撑和治理的IT团队。如何处理前端业务技术融合团队与后端支撑治理的平台团队之间的协作关系，就又成为了一个新的课题。其实在很多年以前，我还是个新手咨询师的时候，就听到过我的前辈们在和客户沟通平台与应用团队之间的合作原则：做小平台、做大应用。平台做小只实现基本的治理，做大应用提升对业务的响应能力。这个当年似乎是真理的建议放到今天看来，似乎显得不合时宜。阿里的中台概念一抛出，企业都纷纷表示希望引入中台来帮助自己提升业务响应力，降本增效，同时打破数据的壁垒来建立统一的数据中台。2018年，伴随着《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》一书的火热，中台已经成了国内技术市场的焦点，并且可以确定的事，中台的概念在2019年会进一步的放大和强化。

三、架构的转型是企业转型成功的拱心石（keystone）

中台概念一出现，一开始我个人的理解是这是一种企业架构治理手段，或者说是企业架构风格的一种新发展。但是经过了几个月的摸索和实践，中台的范围和目标要远大于企业架构的范畴。作为一名领域驱动设计的实践者，分清问题域和解决方案域是基本要求。我认为中台作为一种解决方案，主要解决了企业的三个主要问题。

第一、降低企业架构治理成本和开发成本。在之前的企业架构实践当中，治理各个不同业务单元的IT系统建设一直是一个普遍的痛点。企业架构师的很大一部分工作，是来评审各个业务单元所要开发应用的设计文档和实施规划，最终给出一个结论“这个应用是否可以开发建设”。有了中台以后，企业架构师可以将企业级的业务规则，统一封装在中台内部；而将业务应用和创新的职能，以及业务部门内部的应用级规则，交给了业务部门本身。因此，不需要由企业架构师进行统一审核，这提升了企业架构落地的效率和有效性。

第二、打通数据壁垒，提升数据利用能力。在以前的企业应用构建方式当中，由于种种原因，各个业务单元的系统之间的数据是很难打通的，或者打通以后反而使得数据质量出现下降，使得利用数据产生业务洞见的效果大打折扣。中台从概念的维度上可以改变这种现状。业务中台可以让企业范围内的数据更有效的收集，数据中台通过数据湖和湖畔市集的建设，利用自服务的方式，赋能业务团队去利用数据来指导业务发展。通过阿里的案例来看，业务中台和数据中台的整合是最大化利用数据的一个很好的方式。

第三、降低应用开发的上市周期。中台提供的企业级服务能力，可以让前端的业务团队更快的组织自己的业务应用，并且依据自己的业务目标来规划自己应用的上线周期。而后段企业级业务规则的变化，会被合理在中台范围之内。一旦业务规则发生变化，中台的变化可以独立于应用，并且可以以最快速度在整个企业的所有应用中生效。这也是中台能够给企业级业务带来的最直接的好处。

从实现落地的角度看，中台的建设很难脱离三件事。

首先，是对于企业级业务规则和企业级服务能力的识别。记得在三年前做微服务咨询的时候，遇到过一个在南京的团队。他们在做的微服务从技术架构的角度来看还是很先进的，但是当我们讨论服务应当如何拆分的时候，就陷入到了复用和可变的细节当中。企业中台的建设也是如此。我们发现很多企业在讨论中台的时候仍然没有去分清“企业级业务规则”和“应用级业务规则”，使得基于复用的中台设计方案看起来边界模糊不清，在落地的时候也会和前端应用团队产生各种合作上的问题。可以预见在2019年，如何去界定中台的边界会是要经常被讨论的问题。我个人仍然认为，在识别企业级业务规则和服务的领域，领域驱动设计（DDD）可以发挥它的作用，帮助企业识别中台的边界在哪里。站在赋能业务的角度看，小平台、大应用的思路仍然是可以工作的。具体平衡点的选择首先要基于最大化的增强业务响应能力，其次是如何使企业业务规则更有效地被执行。

其次，中台是难以脱离现有系统，尤其是后台核心系统的架构治理和改造。在过去十几年的时间内，企业都通过不同手段构建了自己的业务核心系统。这种情况从金融行业到电信行业，再到汽车制造行业都是普遍现象。构建中台能力就要求对既要继承现有核心系统的业务规则，又要将核心系统的能力通过服务化的手段暴露出来，变成中台的支撑或者中台的一部分。如何将核心系统从传统的封闭平台迁移出来，以及如何保证架构改造的过程是安全和完备的，这对每个行业的架构师都是一个巨大的挑战。

最后，是难以脱离对业务目标和愿景的支撑。中台建设的过程相对比较复杂，既需要对现有系统进行改造，又需要构建中台所需要的各种技术基础设施。这样一个复杂的企业级平台系统的构建过程必然是复杂和长期的。这个过程当中如何引入业务部门，如何在MVP版本的中台中就能够为前台应用带来支撑，如何通过DevOps实践最大化赋能中台的构建过程，就成为中台规划和建设过程中必然要考虑的因素。

写在最后

2018年下半年开始到现在，我们和几个企业的团队合作企业核心系统的改造工作，主要以金融行业为主。通过架构改造不仅仅可以让后端核心支撑更多的业务场景，同时也提升了企业内部的开发者体验，提升开发效率，我们也在逐渐完善面向传统海量代码（支持Java、C++、和plsql）的架构分析和治理工具，这些都是在尝试为企业中台建设打下一个好的基础。

希望在2019年能把工具本身开源出来，同时向技术社区和企业介绍面向大规模金融核心系统的架构改造和微服务化的成功经验，希望能够为更多的企业大型核心系统的改造工作提供工具和案例上的支撑。

更多精彩文章，请关注微信公众号：ThoughtWorks商业洞见

Share