架构是一种能力，它不是头衔。 换句话说，我们需要具备架构能力，但不一定要成为架构师。就像邓公，他被称为改革开放的总设计师，但他不是设计师。

既然这样，那我们还需要架构师吗？还需要架构部门吗？

我给出的答案是：不需要，因为每个人都应该是架构师。

为什么架构师不work

在来阿里之前，我是在eBay的payments部门工作，当时有一个架构师叫Scott，所有的设计和方案都需要获得他的approve才能通过，结果他成了整个团队的bottleneck，很多事情都block在他那个地方。

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

效率低下尚且不说，这样的折腾最后带来了什么益处呢？说实话，我现在回想起来，除了几个变量命名我觉得Scott说的比较有道理以外，其它还真没什么更有价值的东西了。

这里我想主要问题是因为Scott不在执行团队内部，他不了解细节，所以也很难给出有价值的输入。很多东西，我们认为“他不懂”，也就是他的方案不能让我们信服，自然，合作起来就很困难。

很多人喜欢拿建筑架构和软件架构做类比，认为既然建筑需要建造师，那么软件也应该需要架构师。Too simple, too naive!

其实，二者除了都需要有图纸，都有艺术的成分之外，并没有多少共同之处。

首先，建筑和软件不同。建筑的标准性、确定性要比软件高的多，而软件的灵活性简直是没有边界的，任何一个function都可以有无数的实现方式，没有定式。因此，软件架构图的约束力，要远远低于建筑图纸的约束力。建筑如果不按照设计来，你就不能实现其功能。而软件设计文档和代码，完全可以是两个平行宇宙。

其次，建筑工人和程序员不同。程序员的工作绝对不仅仅是“搬砖”这么简单，软件设计是一个充满挑战的创造性工作。它需要对各种微妙之处进行权衡，只有深入其中，hands-on coding，才能真正的发现问题。因此，飘在开发团队之上，指手画脚的PPT架构师，注定是很难成功的。

为什么架构部门不work

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

几年前的B2B就有一个这样的架构组织。我记得在当年的“架构图”KO会议上，当时的负责人要求我们画架构图，我就质问他这个架构组存在的意义是什么？如果只是画架构图，给老板当ppt用的话，这个图我不愿意画。我当时还严厉的说了句名言——KO不一定要Kick Off，也可以是Kick Out。不止于此，而后我又“上书”到当时B2B的CTO，再然后... 随着CTO的调离，架构负责人的离职，也就没有然后了...

实际上，“架构图”这种务虚活动还好，虽然无用，但也构不成杀伤。真正构成杀伤的是架构组织不甘无为，挖空心思要“做事情”。

可以说，在业务技术部门，架构组这种“想做事”的行为是很危险的，事情越大，杀伤力越大。

何出此言？我们不妨先来看一下，在业务技术部门，架构组织能做什么。

1. 业务架构？我是营销域的，是订单域的，是商品域的，是供应链域的... 你架构组告诉我，你对业务领域，业务流程，业务细节的理解比PD、运营、工程师更懂？恐怕难，一个合格的PD应该能做好业务领域的抽象和业务流程的抽象，至于细节，好像没有人比一线开发更懂。架构组，卒！

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

3. 技术架构？好吧，那我们架构组回归技术本身，做点纯技术的事情总可以吧。对不起，但凡有点价值的技术中间件，已经有中间件团队在做了。还记得，ICBU架构组搞的Hilton容器和AE架构组（中间件团队）的“我行我素”使用SpringBoot吗。这种重复造轮子完全没有必要。在云原生成熟之前，PandoraBoot就是最好的解决方案。架构组，带着整个BU一起——卒！

在此我想稍微提一下支付宝的中间件团队（架构部门？），我不知道历史，也许TecFin的确是有其特殊性。但是，从整个集团角度来说，我认为统一的技术中台，应该是更好的做法。

对一个企业来说，也许在某个特殊阶段，的确需要实体架构组织去保障落实架构工作。

但大部分情况下，特别是在技术体系已经相对完备的情况下。比如在阿里，业务技术部门，最好是不要在BU内设立专门的架构组织，相信我，在我的职业生涯中，看到过很多业务技术部门设立的技术架构组织案例，基本都是以失败而告终。

人人都是架构师

架构师不行，架构部门也不行。那架构的事情谁来做呢？看一下你座位左边的，再看一下你座位右边的，再看一下你主管.... 别看了，他们是要做，你自己也要做，人人都是架构师。

首先，让我们来看一下什么是架构能力，我认为广义的架构能力，应该是一套分析问题、解决问题的方法论。它需要你具备洞察问题本质要素，理清要素之间的关系，以及制定相应策略的能力。

从这个视角出发，我认为架构能力就是核心竞争力，每个工程师都应该具备一定的架构能力，人人都应该是架构师。 怎么理解？

1. 作为技术一线员工，也许你的工作时间并不长，架构能力相对较弱，没有捷径，学习学习再学习，成长成长再成长，架构作为能力是可以习得的，没那么高深。

2. 作为技术团队Leader，你必须要具备一定的架构能力了，不管是业务架构还是应用架构。TL都应该具备能发现问题里的本质要素，以及理清要素之间关系的能力。如果你已经是一名TL，然而架构能力还比较欠缺，则需要尽快去补足。不足没有关系，有关系的是停止了学习和成长。就像怀素说的，很多后劲不足的人主要是过早的停止了学习和成长，你的能力应该是围绕着你的层级震荡的，这个震荡范围偏差不会太大，迟早会归于一个相对合理的区间。

3. 作为CTO（没吃过猪肉，但看过猪跑），CTO没得选了，必须是一个非常、非常优秀的架构师才行。你不仅要熟悉业务架构，精通技术架构。更重要的是因为屁股问题（康威定律），你还要去设计组织架构，让生产关系适应生产力的发展。唯有如此，技术才能稳定高效的支撑业务发展。

听说，腾讯没有CTO，所以他们每个BU都有一套自己的技术栈和中间件，大家各自为政。

如果上图对腾讯的架构描述属实的话，我觉得最好他们还是要有一个CTO比较好。因为很明显，对于通用的技术解决方案，比如大数据处理，技术中间件。没必要重复造轮子，复用很明显是更加科学的做法。

在这一点上，如下图所示，我认为阿里无疑是走在腾讯前面的。其中，数据中台和技术中台，我认为是阿里做的最好，也是最NB的地方。至于业务中台为什么旁边飘着一朵小乌云呢，这是因为业务的抽象复用要比技术的抽象复用难的多的多的多，不同业务面临的业务问题的差异是巨大的，而不同业务面临的技术问题相对业务问题，要稳定的多。我想，这也是为什么技术中台已经成功，业务中台还在探索的原因吧。

如何践行

最后，分享一下我是如何在团队做“架构师”的。

一方面，我会不遗余力的培养团队成员的架构能力，我会不断的和他们探讨系统的边界是否合理，模型抽象是否合理，流程抽象是否合理，模块设计是否合理。并要求他们说清楚设计背后的思考和理念是什么，然后用我自己的方法论、思考和他们去碰撞，这样反复进行，我和团队都会有所成长。

另一方面，我会hands-on coding，参与核心业务逻辑的编码工作，这点很重要。一定要深入代码细节中去做架构，因为很多问题只有在coding的过程中才会暴露出来。另外，无谓的讨论是低效的，验证架构是否合理的方式，就是结合业务场景，写代码去验证。设计是否合理，是否优雅，在coding的过程中，便能获得很好的反馈。我不止一次，在写代码的过程中，去重构原来的设计，甚至是完全推翻重来。

总而言之，架构作为一种能力，作为我们工程师的核心成长目标，值得我们去孜孜不倦的追求。而架构师作为一个职位，在大部分情况下，它就是个“呵呵”。