我要批判架构师！

我在阿里巴巴工作期间是一个名副其实的“刺头”，批判中台、批判架构师、批判技术管理者，当然，也包括自我批判。

今天来聊聊批判架构师！

Martin Fowler 在他的一篇 IEEE 论文“Who Needs an Architect？”中提到，

能使团队更加敏捷的架构师比只做决定的架构师要更有价值，因为只做决定的架构师会成为团队的瓶颈（bottleneck）。显然，一个架构师的价值和他做的决定是成反比的。

实际上，在这篇文章中，Martin 甚至不认为架构师（Architect）这个名词是合适的，他认为更合适的叫法应该是向导（Guide），即一个更有经验的人带领团队走出复杂的迷雾。

尴尬的架构师

在进入阿里巴巴工作之前，我就职于 eBay 的支付部门。当时有一位架构师，所有的设计和方案都需要获得他的审批才能通过，结果他成了整个团队的瓶颈，很多事情都堆积在他那里。

工程师很难受，光是给他介绍和讨论业务及系统设计就需要花费大量的时间（因为时差原因，经常要讨论一周才有定论）；他也不容易，要理解每个系统的结构和业务细节也是很累的。

这里存在的主要问题是这位架构师不在执行团队内部，不了解细节，所以很难给出有价值的建议。对于很多细节，我们认为他不懂，他的方案也无法让我们信服，合作起来自然就很困难。

尴尬的架构部门

如果说架构师是轻量级解决方案，那么还有一个“大规模杀伤性武器”——设立一个专门的架构部门。

在阿里巴巴的 B2B 部门曾经就有这样一个架构组。我记得在当年的启动会上，负责人要求我们画架构图，我质问他这个架构组存在的意义是什么。如果只是画架构图，给老板当 PPT 用的话，那么我不愿意画这个图。

实际上，画架构图这种务虚任务还好，虽然用处不大，但也构不成杀伤力。真正构成杀伤力的是架构组不甘无为而挖空心思要“做事情”。可以说，在业务技术部门，架构组这种想做事的行为是很危险的，事情越大，杀伤力越大。

为什么这么说呢？我们不妨先来看一下，在业务技术部门中的架构组能做什么。

（1）业务架构？我是营销域的、订单域的、商品域的、供应链域的……如果架构组想比产品经理、运营人员、工程师更懂业务领域、业务流程和业务细节，恐怕很难。一个合格的产品经理应该能做好业务领域的抽象和业务流程的抽象，至于细节，好像没有人比一线开发人员更懂。——架构组，卒！

（2）应用架构？需求相对清晰之后，在应用架构领域有一些影响力的团队负责人（Team Leader，TL）在和团队讨论边界划分和设计方案的时候，尚且会时常争论不休。架构组的“外人”想来指手画脚？这是多么碾压程序员的自尊心啊！——架构组，卒！

（3）技术架构？好吧，让我们架构组回归技术本身，做点纯技术的事情。可是对不起，但凡有点价值的技术中间件都已经有中间件团队在做了。——架构组，带着整个部门一起，卒！

因此，在企业内部设立架构部门是一件要十分谨慎对待的事情。

对一个企业来说，在某个特殊阶段，也许的确需要实体架构组织去保障落实架构工作。但在大部分情况下，特别是在技术体系已经相对完备的情况下，最好不要在部门（Business Unit，BU）内设立专门的架构组织。在我的职业生涯中，我看到过很多业务技术部门尝试设立技术架构组织，基本都以失败告终。

人人都是架构师

架构师不行，架构部门也不行。那由谁来做架构的事情呢？

看一下你左边的同事，再看一下位右边的同事，再看一下你的主管……别看了，他们的确要做，然而你自己也要做——人人都是架构师。

在探讨架构师的工作职责之前，我们先来看一下什么是架构。关于这个问题，每个人的答案可能都不一样。我曾经看过一本技术书，其中用了一章的篇幅讨论架构的定义，但是最终也没有说得很明白。我个人比较认可的关于架构的定义是来自 IEEE 的定义。简单来说，架构的定义就是要素结构+关系+指导原则。要素（Components）是指架构中的主要元素，结构是指要素之间的相互关系（Relationships），再配合指导原则（Guidelines），便构成了架构，如图 1 所示。

图 1  架构的定义

从架构定义中，我们不难发现，架构师所要具备的架构能力实际上就是一套分析问题、解决问题的方法论。它需要你具备洞察问题本质要素、厘清要素之间的关系，以及制定相应策略的能力。

从这个角度出发，架构能力就是核心竞争力，每个工程师都应该具备一定的架构能力，人人都应该是架构师。

（1）作为技术一线的员工，如果你工作的时间并不长，架构能力相对较弱，那么没有捷径，只有学习学习再学习、成长成长再成长，架构能力是可以习得的，没那么高深，但也没那么容易，需要长期积累。

（2）作为技术团队负责人（TL），你必须要具备一定的架构能力。不管是对于业务架构，还是应用架构，TL 都应该具备发现问题的本质要素及厘清要素之间关系的能力。如果你是一名比较欠缺架构能力的 TL，那么你需要尽快去补足，不足没有关系，可怕的是停止了学习和成长。正如我比较欣赏的一位技术负责人怀素所说的，很多后劲不足的人主要是过早地停止了学习和成长，你的能力应该是围绕着你的层级上下震荡的，这个震荡范围偏差不会太大，迟早会归于一个相对合理的区间。

（3）作为首席技术官（CTO），那么没的选了，你必须是一个非常优秀的架构师才行。你不仅要熟悉业务架构、精通技术架构，还要通过组织架构设计去解决部门墙问题，让生产关系适应生产力的发展。唯有如此，才能使技术稳定高效地支撑业务发展。

有一些互联网公司没有 CTO，他们每个业务单元都有一套自己的技术栈和中间件，大家各自为政，如图 2 所示。

图 2  各自为政的技术体系

针对上述技术体系，最好设置一名 CTO。因为对于通用的技术解决方案，比如大数据处理、技术中间件，没必要重复造轮子，显然复用是更科学的做法。

本文节选自《程序员的底层思维》一书，想要了解更多相关内容，欢迎阅读本书！

▊ 《程序员的底层思维》

张建飞 著

• 这是一本超越具体编程技法的技术书：职场晋升不仅需要技术能力，更重要的是思维能力。本书带你学会用底层思维解决复杂技术问题，突破职场“天花板”。

• 这也是一本培养思维能力的通用技能书：打破认知局限，培养通用的思维能力。本书帮你跳出思维定势，轻松解决生活及工作中遇到的问题。

本书涵盖程序员应知应会的 16 种思维能力，共 18 章，分为三部分。

第一部分主要介绍抽象思维、逻辑思维、结构化思维、批判性思维、维度思维、分类思维、分治思维、简单思维，以及成长型思维等解决日常问题的基础思维能力。

第二部分结合软件行业的特点，主要介绍解耦思维、契约思维、模型思维、工具化思维、量化思维、数据思维，以及产品思维等专业思维能力。

第三部分主要是对上述思维能力的综合运用实践。

粉丝专享六折优惠，扫码即购！