架构是一种能力，它不是头衔。换句话说，我们需要具备架构能力，但不一定要成为架构师。就像邓公，他被称为改革开放的总设计师，但他不是设计师。
既然这样，那我们还需要架构师吗？还需要架构部门吗？我给出的答案是：不需要，因为每个人都应该是架构师。
为什么架构师不 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 一起——卒！
人人都是架构师
它需要你具备洞察问题本质要素，理清要素之间的关系，以及制定相应策略的能力。
①作为技术一线员工，也许你的工作时间并不长，架构能力相对较弱，没有捷径，学习学习再学习，成长成长再成长，架构作为能力是可以习得的，没那么高深。
②作为技术团队 Leader，你必须要具备一定的架构能力了，不管是业务架构还是应用架构。
TL 都应该具备能发现问题里的本质要素，以及理清要素之间关系的能力。如果你已经是一名 TL，然而架构能力还比较欠缺，则需要尽快去补足。
不足没有关系，有关系的是停止了学习和成长。就像怀素说的，很多后劲不足的人主要是过早的停止了学习和成长，你的能力应该是围绕着你的层级震荡的，这个震荡范围偏差不会太大，迟早会归于一个相对合理的区间。
③作为 CTO（没吃过猪肉，但看过猪跑），CTO 没得选了，必须是一个非常、非常优秀的架构师才行。你不仅要熟悉业务架构，精通技术架构。
更重要的是因为屁股问题（康威定律），你还要去设计组织架构，让生产关系适应生产力的发展。唯有如此，技术才能稳定高效的支撑业务发展。
我想，这也是为什么技术中台已经成功，业务中台还在探索的原因吧。
如何践行
作者：从码农到工匠
编辑：陶家龙
出处：转载自微信公众号从码农到工匠（ID：craftsman_frank）
精彩文章推荐：
