架构师成功沟通的三个关键
软件架构师们总是跟我说，他们的利益相关者并不关心他们的架构。于是我问：你真的跟他们解释清楚你的架构了吗？我得到的答案是：一年前我和他们讨论过。因为架构的重要性，架构师们希望架构知识能自行传播。但问题是，这种自行传播并不会发生。也许是因为“重要的事情”经常被“紧急的事情”压倒，也许是因为架构本身存在一些复杂性。因此，进行恰到好处的架构沟通是架构师的一项任务，但这件事情却经常被忽略。
这就提出了一个问题：架构师应该花多少时间在沟通上？Philippe Kruchten（一位著名的研究人员）在“软件架构师要做些什么”一文中给出了答案。
https://pkruchten.files.wordpress.com/2010/05/kruchten_2008_journal-of-systems-and-software.pdf
要想取得成功，一名软件架构师或软件架构团队，必须在外部关注点和内部关注点之间取得某种微妙的平衡。外部关注点包括：倾听客户和用户的声音、关注技术的发展、规划长期的愿景、推动开发团队前进。内部关注点包括：花时间做出正确的设计决策，并加以验证和记录。与这种平衡偏离太远的团队将会陷入一些陷阱，我们将这些陷阱叫作软件架构团队的反模式。
Kruchten 总结了架构师的三种工作模式，大致可以映射成信息的输入、处理和输出。
内部工作：这是架构师的深层工作，本质上就是思考和处理信息。如果是在一个架构师团队中，这可能涉及到沟通。
内部沟通：架构师必须了解很广泛的知识，包括去倾听、阅读和问问题。
对外沟通：在建立了新信息后，架构师需要将它们传播出去，包括文稿演示、写文档和提供支持。
Kruchten 认为，这三者之间最理想的比例应该是 50：25：25。所以架构师只需要花一半的时间在架构上，另一半花在了解当前状态以及传播目标状态上。
如果这种平衡被打破，就会出现各种问题。
例如，一个完美主义者常常忽略外部沟通，Kruchten 将这种架构称为“镀金”架构。虽然做出的产品很棒，但一问世可能就过时了。
忽视内部沟通和外部沟通的架构师就像被关在“象牙塔”里。虽然做出来的产品可能可以在内部保持一致，并且足够漂亮，让产品所有者沾沾自喜，但却脱离了实际。学院派尤其容易掉到这个陷阱里。
如果架构师忽视了内部工作，那么架构一致性缺失的问题就会在整个产品中表现出来。架构的组成部分可能是经过精心制作的，但不能很好地组合在一起。
太过关注外部沟通让架构师变成了顾问。虽然开发人员对架构师提供的支持表示赞赏，但架构背后却缺乏具有凝聚力的思想。
在实践当中，架构师们似乎不会太过关注内部沟通。这样的架构师可能既不写架构文档，也不为团队提供支持。因此，他们提供不了任何具有表面价值的产品，也无法长久生存下去。
让我们回到最初问题：为什么人们对架构不够了解？假设有一个架构，架构师不是在“镀金”，就是在“象牙塔”里。这两种情况都缺乏对外沟通，所以应该把更多的注意力放在这里。以下是一些对于我来说比较适用的想法。
我喜欢异步传播，埃隆·马斯克也是，所以我确信这种方式是有效的。
异步传播的一大优点是它具有比较好的传播性。例如，对于电子邮件，你可以快速复制粘贴或转发信息。实际上，书面信息在一般情况下来说具有很好的传播性。其他媒体形式，如播客或视频也具有传播性，但我很少看到它们被用在软件架构当中。
最常用的是图表，但可惜的是，图表的关注点过于极端。我见过很多很多的架构图，因为缺少文字解释而让人难以理解。有些架构图其实很糟糕（例如使用了不一致的符号），但即使是好的架构图也需要有上下文信息。
优秀的演讲幻灯片都有相似点，它们都是为演示文稿而设计的。例如，乔布斯的演讲就颇具传奇色彩。
这张幻灯片上有三个图标，分别代表了三种相关的技术。在接下来的几秒钟里，乔布斯宣布将这三种技术融合在一起，变成了 iPhone。幻灯片是叙述背景的一部分，但它本身是没有什么意义的。如果你设计的幻灯片本身可以作为讲义使用，那么你的演示就会受到影响。
如果你记得要演示的内容，那就可以把幻灯片作为提醒。同样，我假设大多数架构图仅作为记忆辅助用途。要成为一种有效的沟通媒介，需要赋予它们更多的内容。
异步传播的一种方式是使用架构决策记录，我之前已经 介绍 过了。决策记录本身应该是可理解的，因此你可以向人们提供它们的链接，让他们自己去了解架构，不需要向他们解释。当然，这并不是说你要把更多的时间花在对外沟通上，而是要更有效地利用这些时间。
在过去的两年里，我每周都会给项目成员（大概有 250 人）发一份简报。此外，还有其他几十个人也会收到简报，因为他们明确提出需要简报。这说明至少有一半人不是我的目标受众，因为他们不是开发人员。但是，即使是管理人员也很喜欢这样，因为简报让他们对项目中使用的技术有了一定的印象。我的部门主管就说：“请不要停止写简报！”
简报包含了我一周内处理的所有事情，这可能是一个我觉得还不够为人们所了解的小工具。它包含了新的架构决策记录和即将到来的或正在进行的活动。
写博客的经验有助于写好简报。我在这个网站发表的最早一篇博文是在 2009 年写的，但我在那之前的几年就已经写过博客了。写简报最重要的是要坚持始终如一。
我会用到一些有趣的图片，它们在简报中起到不同寻常的作用。很多人告诉我，他们最开始只是想看看这些有趣的图片，到最后却不知不觉地把整封邮件都看了。此外，一些人告诉我，看简报是他们一周当中最重要的事情。
写科学论文对你也很有帮助。如果能得到同事的正确评价，你就可以训练自己写出简洁而正确的简报。我的简报只包含简短的摘要，但也提供了大量链接，可以进一步阅读更详细的资料。有时候我甚至会偷偷地做一些自我宣传，比如在简报中加入我的博客链接。
《Made to Stick》一书介绍了很多可以让信息更容易被记住的方法，其中之一就是具象化。书中讲述了在车间工作的工人和绘制图纸的工程师这两种角色之间的冲突，这与架构师与开发人员之间的冲突非常相似。
工人在想，为什么你们不直接到车间来告诉我零件应该怎么安装？工程师在想，我该怎么做才能把图纸做得更好？双方是否应该有更多的同理心，并在中间的某个位置达成共识？事实上不是这样的。解决的办法应该是让工程师改变他们的行为。为什么？正如 Bechky 指出的那样，物理机器是最有效的沟通领域，每个人都能熟练地理解机器。因此，问题应该放在机器层面解决。这个故事的寓意并不是要“把事情简单化”。工人面临复杂的问题，他们需要聪明的答案。这个故事的寓意是要找到一种“通用的语言”，一种每个人都能流利表达的语言。这种通用语言就是具象化。
这听起来和我们最初的问题非常相似。开发人员可能会忽略架构，因为架构对于他们手头要解决的问题来说不够具象化。这本书建议的解决方案不是让开发人员接受更好的培训，而是让架构师承担起为具体的场景解释架构的职责。
我的简报也强调了这一点。因为我每个星期都需要挑选一些细节的东西放到简报中。即使这些东西并不会与每个人都相关，但它们会促使我去解释更广泛的架构背景。
抽象是专家们的“专属品”，是对已广为人知的具象概念的概括。但是，如果概念还没有被很好地理解，进行抽象就没有意义。所以，架构师应该减少谈论大的概览，至少应该保持简短。
要进行具象化的沟通，架构师需要做大量的工作。但请记住，这应该只占用你 25% 的时间。你可以使用更具传播性的异步传播方式，正如我之前提出的第一个建议。
如果缺乏沟通，架构师应该承担起这个职责。如果架构师注意到人们对架构不了解，他们必须改进他们的外部沟通方式。对此，我有三点建议：
编写良好的架构决策记录
定期撰写简报
针对具体的场景解释架构
还不过瘾？试试它们