架构是一种能力，它不是头衔。换句话说，我们需要具备架构能力，但不一定要成为架构师。
图片来自 Pexels
既然这样，那我们还需要架构师吗?还需要架构部门吗?我给出的答案是：不需要，因为每个人都应该是架构师。
为什么架构师不 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 的调离，架构负责人的离职，也就没有然后了......
实际上，“架构图”这种务虚活动还好，虽然无用，但也构不成杀伤。真正构成杀伤的是架构组织不甘无为，挖空心思要“做事情”。
可以说，在业务技术部门，架构组这种“想做事”的行为是很危险的，事情越大，杀伤力越大。
何出此言?我们不妨先来看一下，在业务技术部门，架构组织能做什么?
①业务架构?
我是营销域的，是订单域的，是商品域的，是供应链域的... 你架构组告诉我，你对业务领域，业务流程，业务细节的理解比 PD、运营、工程师更懂?
恐怕难，一个合格的 PD 应该能做好业务领域的抽象和业务流程的抽象，至于细节，好像没有人比一线开发更懂。架构组，卒!
②应用架构?
需求相对清晰之后，我一个在应用架构领域尚且有一些影响力的 TL 在和团队讨论边界划分，设计方案的时候，时常会争论不休。
你一个架构组的“外人”想来指手画脚?呵呵，你这是有多低估程序员的自尊心啊。架构组，卒!
③技术架构?
好吧，那我们架构组回归技术本身，做点纯技术的事情总可以吧。对不起，但凡有点价值的技术中间件，已经有中间件团队在做了。
还记得，ICBU 架构组搞的 Hilton 容器和 AE 架构组(中间件团队)的“我行我素”使用 Spring Boot 吗?
这种重复造轮子完全没有必要。在云原生成熟之前，PandoraBoot 就是最好的解决方案。架构组，带着整个 BU 一起——卒!
在此我想稍微提一下支付宝的中间件团队(架构部门?)，我不知道历史，也许 TecFin 的确是有其特殊性。
但是，从整个集团角度来说，我认为统一的技术中台，应该是更好的做法。
对一个企业来说，也许在某个特殊阶段，的确需要实体架构组织去保障落实架构工作。
但大部分情况下，特别是在技术体系已经相对完备的情况下。比如在阿里，业务技术部门，最好是不要在 BU 内设立专门的架构组织。
相信我，在我的职业生涯中，看到过很多业务技术部门设立的技术架构组织案例，基本都是以失败而告终。
人人都是架构师
架构师不行，架构部门也不行。那架构的事情谁来做呢?看一下你座位左边的，再看一下你座位右边的，再看一下你主管.... 别看了，他们是要做，你自己也要做，人人都是架构师。
首先，让我们来看一下什么是架构能力，我认为广义的架构能力，应该是一套分析问题、解决问题的方法论。
它需要你具备洞察问题本质要素，理清要素之间的关系，以及制定相应策略的能力。
从这个视角出发，我认为架构能力就是核心竞争力，每个工程师都应该具备一定的架构能力，人人都应该是架构师。
怎么理解?我认为有如下三点：
①作为技术一线员工，也许你的工作时间并不长，架构能力相对较弱，没有捷径，学习学习再学习，成长成长再成长，架构作为能力是可以习得的，没那么高深。
②作为技术团队 Leader，你必须要具备一定的架构能力了，不管是业务架构还是应用架构。
TL 都应该具备能发现问题里的本质要素，以及理清要素之间关系的能力。如果你已经是一名 TL，然而架构能力还比较欠缺，则需要尽快去补足。
不足没有关系，有关系的是停止了学习和成长。就像怀素说的，很多后劲不足的人主要是过早的停止了学习和成长，你的能力应该是围绕着你的层级震荡的，这个震荡范围偏差不会太大，迟早会归于一个相对合理的区间。
③作为 CTO(没吃过猪肉，但看过猪跑)，CTO 没得选了，必须是一个非常、非常优秀的架构师才行。你不仅要熟悉业务架构，精通技术架构。
更重要的是因为屁股问题(康威定律)，你还要去设计组织架构，让生产关系适应生产力的发展。唯有如此，技术才能稳定高效的支撑业务发展。
听说，腾讯没有 CTO，所以他们每个 BU 都有一套自己的技术栈和中间件，大家各自为政。
如果上图对腾讯的架构描述属实的话，我觉得最好他们还是要有一个 CTO 比较好。
因为很明显，对于通用的技术解决方案，比如大数据处理，技术中间件。没必要重复造轮子，复用很明显是更加科学的做法。
在这一点上，如下图所示，我认为阿里无疑是走在腾讯前面的。其中，数据中台和技术中台，我认为是阿里做的最好，也是最 NB 的地方。
至于业务中台为什么旁边飘着一朵小乌云呢，这是因为业务的抽象复用要比技术的抽象复用难的多的多的多，不同业务面临的业务问题的差异是巨大的，而不同业务面临的技术问题相对业务问题，要稳定的多。
我想，这也是为什么技术中台已经成功，业务中台还在探索的原因吧。
如何践行
最后，分享一下我是如何在团队做“架构师”的。
一方面，我会不遗余力的培养团队成员的架构能力，我会不断的和他们探讨系统的边界是否合理，模型抽象是否合理，流程抽象是否合理，模块设计是否合理。
并要求他们说清楚设计背后的思考和理念是什么，然后用我自己的方法论、思考和他们去碰撞，这样反复进行，我和团队都会有所成长。
另一方面，我会 hands-on coding，参与核心业务逻辑的编码工作，这点很重要。
一定要深入代码细节中去做架构，因为很多问题只有在 Coding 的过程中才会暴露出来。
另外，无谓的讨论是低效的，验证架构是否合理的方式，就是结合业务场景，写代码去验证。
设计是否合理，是否优雅，在 Coding 的过程中，便能获得很好的反馈。我不止一次，在写代码的过程中，去重构原来的设计，甚至是完全推翻重来。
总而言之，架构作为一种能力，作为我们工程师的核心成长目标，值得我们去孜孜不倦的追求。而架构师作为一个职位，在大部分情况下，它就是个“呵呵”。
作者：从码农到工匠
编辑：陶家龙
出处：转载自微信公众号从码农到工匠(ID：craftsman_frank)
