可以做，就是你不知道技术细节（注意：我说的是知道，并不是要你去研究），你想做出可行的可用的架构，就太假了。很多所谓的架构师飘得太高了，不知道具体实现，不知道码农们实现得如何。所以，理论要有，实战经验也要有，起码你得知道你PPT上写得比如花还美的架构方案，在实现的时候有没有技术死穴，当下面的开发人员发现这个架构有问题时，你有能力跟他讨论，而不是一句：“我只考虑大方向，细节你们自己解决”来搪塞吧。一个主任医师也有呆实险实，坐临床的日子吧，只是看个人水平，有人进步得快，几个就是主任医师，有些人白了头发都上不了这个级别，你说一个医学院出来的学生临床都没做过，立马来个主任医师，你敢用他的处方？系统架构也是一样的道理，后台的技术你只知道个原理，很多基本的问题你都没遇到过，没解决过，没潜下心来去啃过，只能说你这所谓的架构师是在混饭吃，事实上现在社会上很多这样的人，我们公司新请来一个系统分析员，来到第一句话是：我不编码！老大，你可以不编码，但你不能不会编码呀！

架构师一定要负责整个系统中最核心和最难的地方的编写，并且设计好团队合作开发的方式，能根据编程经验看到未来的变化，架构太重要了，出不得错误，出了错误很难回头，如果一个团队里需要一个架构师，那他一定必须是团队里写代码能力最好的，而且要负责至少40%以上的核心开发工作，并且不能脱离实际业务。不写代码那个可以是部门经理，可以是开发总监，但一定不能是 架构师。记得以前有个说法，架构师，基础开发部门做的都是什么事？脏活，累活，和一般人干不了不愿意干，干完还一时半会看不出效果的活。如果你不负责整个项目的代码实际编写，请闭嘴。因为业务永远在变，项目组的代码永远在变，架构当然也是一直在变的。无论你写什么框架，设计什么项目，脱离了一线，都是扯淡。以前领导说过，团队里应该有两个leader，一个是行政上的，一个无冕的。架构师一般都是那个无冕之王，所有开发对你的尊重和对团队的作用都是毋庸置疑的。我很尊重架构师，我想求一个前端架构师…

先缩小下范围。架构师（Architect）有很多种，有软件架构师， IT 架构师，系统架构师，产品架构师，网络架构师，数据架构师，信息架构师，业务架构师等等。确实一些种类的架构师对编程能力要求不高，平时也不需要写代码，而程序员界的架构师，通常就是指软件架构师（或某些系统架构师），对编程能力的要求是很高的。架构师一定要很强的编码能力之后才能当吗？对于软件架构师来说，通常这是一句废话。一个团队的架构师编码能力不行，会有一系列的不良后果，例如：为什么有些大公司技术弱爆了？ - 张恂老师的回答但是架构师应该都是从程序员来的吧。当然了。正常情况下，高级程序员、技术骨干中的一些具有良好管理素质和能力的人，才能胜任软件架构师。架构师是一个团队的技术领导与技术核心，需要长期的实际开发经验的磨炼与积累。你的编程技术不行，缺乏足够的编码经验，凭什么让整个团队、领导和被你领导的码农们信服？感觉自己编码能力不强，不太喜欢编码，但是喜欢整体框架和设计整体框架和设计，软件架构，这些都属于软件设计中的“上层建筑”、高层设计（high-level design），对产品、系统的成功具有关键的战略性影响，当然很重要。但……

看到 @张恂老师 提到一个名词，叫“PPT架构师”，我不由自主的嘴角弯了起来。这让我想起来去年发生的一件小事：我们跟另一家C轮基本敲定的创业公司谈合作，一个顶着“CTO+首席架构师”光环的人到我们公司来探讨系统的架构。他参照ppt就开始各种指点江山，前台到后台N多分层，各种功能划分，不断提到模块解耦……整个一套架构还是有模有样，放到国内研究生的毕业设计中也绰绰有余。我在听的过程中，一直努力去理解每一部分的设计逻辑但是仍有多半不得其解，心想，艾玛，还真是遇到大神了，不愧是C轮的大公司。讨论环节提了几个我疑惑的问题，基本上没有得到正面回答；聊了聊oauth的授权，跟我说这是细节问题，开发的时候再讨论；中午一起吃饭的时候聊起来java，他说他是做php的。尽管我也知道php是世界上最好的语言，但是尼玛你们的产品后台明明是用java写的！后来了解到，他虽然公司的名头不假，但是整个产品基本是一个主程大叔一杆挑起来的。今天看来，“PPT架构师”真是形象地描述了这个CTO。很多没多少项目经验的但是迫于毕业压力而苦思冥想脑洞大开设计各种系统架构图的研究生们估计做这个ppt架构师很合适。最后再说说我的想……

不写代码的架构师容易变得保守。架构是考虑了各种因素（尤其是业务安全方面）之后做出的妥协，对于开发团队来说是种种要求和限制。 这种限制往往是限制开发团队的开发效率和创造力的。脱离编码的架构师容易失去对一线业务环境和技术环境变化的敏感，沾沾自喜于自己设计的架构和制定的规范阻挡了一次又一次潜在的错误和损失。偶尔发生的事故往往也会发现是开发团队某些方面没有贯彻架构要求，结果往往是更进一步的加强约束，体会不到其对开发效率的副作用。这些都是以前亲身体会到的事实，遗憾的是离职去另一家公司后才发现，当时真的是当局者迷。 其实我都还是一直有编码的，只是编的少了就会犯这种错，更别说不编码了。在当今这个精益创业时代，快速试错和创新才能生存，在一线参与编码的架构师更能够随时想着哪些地方可以给团队“松绑”，哪些新技术可以突破以前设计架构时的一些限制。躲在后方就只会拖前线的后腿了。