（借此文章也向一直关注我的我的粉丝朋友报个平安，我还活着）
“架构”这个词本身是来自建筑学，所以「软件架构师与建筑工程架构师」是有着很多的相似之处，但也有很大的区别。工程架构师的工作内容比较容易去想象、去理解，核心的工作内容与软件架构师在概念上实际上差不多，下面「类比说明一下也会更容易理解一些」。
一、建筑工程架构师与软件架构师相似之处
-
工程架构师做施工图纸，软件架构师做系统架构。根据业主需求给施工(研发)人员提供项目的落地具体设计标准及依据。 -
工程架构是明确建筑材料(水泥标号等)，软件架构师也要做软件材料及工具的选型。 「合理的选型及集成能够成倍的提升项目研发效率，降低后期运维成本。」 -
与实施团队紧密沟通，针对项目实施过程中遇到的技术问题，能够及时给出调整方案以及实施路径。 -
协助项目管理方负责把控项目进度、质量。（因为 「架构师是最清楚具体任务落地的难度，需要多长时间」，如何根据设计验收项目质量）
二、建筑工程架构师与软件架构师不同之处
软件与建筑工程最大的区别在于：「建筑开始动工之后就不会做大的调整」，既往经验相对成熟。而「软件项目架构师」经常面临的问题是“「坐着飞机换飞机引擎」”，所以软件架构师的考量要更多，比如：
-
扩展性：现在盖2层楼，要在这基础上盖到10层，这种现象其实不太可能出现，但是在软件项目中就经常出现。如果通过初期设计，就把相关的扩展能力接口留好，是很考验软件架构师的能力。 -
高可用：建筑工程不会考虑高可用的问题，盖一个小区就给一批居民入住，验房后房子出现问题自己负责。而软件系统出现问题，得事先准备好另一个系统(小区)给居民随时入住与切换，不能出现系统不可用的情况。 -
等等技术问题
三、管理型软件架构师职责
上面提到的一类架构师是落地到某一个具体的项目组，「还有一类架构师做架构管理，通常也称为技术经理」。技术经理需要考虑的问题，比如：
-
复用性：一份代码在这个项目能用，在另一个项目也能用，这部分就是「公共组件」。如何抽取公共组件，方便组件向各个项目集成，也是管理型架构师需要考虑的问题。
-
「技术能力的沉淀与传播」：把知识以可传播的媒介沉淀下来，在未来的建设项目中复用既有经验。把技术能力传播出去，不能只是把自己搞的很厉害，要让大家都很厉害。
-
「多个项目组的技术统一性拉齐」，不能同一类的项目，这个项目组用这种技术干，下一个项目组用其他技术实现。导致的问题是：项目组之间的技术经验无法复用，人员无法复用。
四、软件架构师参与的工作
造成架构师职责模糊感的原因，「架构师干了活却没有面向领导层的直接输出物，所以领导可能分不清架构师的工作内容」。
-
面向需求人员：项目落地最终是要对接到架构师，因为架构师根据需求做一系列的数据库设计等等
-
面向项目经理：项目经理进行任务分解也是要根据设计来的。如果项目经理纯业务不懂技术，任务分解以及进度管控实际是需要架构师来做的。
-
面向开发人员：开发人员遇到问题，第一个想的就是这个东西是谁设计的？找架构师。在大部分团队中架构师本身就是开发人员。
-
面向运维人员：服务器环境管理，以及运维其实是对技术要求很高的，仅次于架构师。如果团队运维水平不达标，或者没有专业运维团队，这部分还是架构师。
-
面向测试人员：测试人员对于功能的实现效果出现疑问，对接开发人员，问题的最终说明还要归结到设计者：架构师。
五、架构师与业务知识的关系
「在一个项目落地之后，架构师几乎是整个项目组最懂业务的」，这个观点可能比较突兀。 我解释下：
-
架构师不懂业务就没有办法做设计，做出来的设计也会出现偏差和问题。 -
开发人员遇到开发问题、技术难点，第一想法是找设计者：架构师。所以架构师最清楚需求落地里面的所有弯弯绕绕、关键点以及注意事项。
但是有一种软件行业的普遍现象认为：「技术架构师不懂业务，我觉得症结在于」（当然也是我自己不太成熟的想法）：
-
一直在做新项目、新领域、新行业，或者历史领域及行业没有知识的沉淀和传播。准确的说： 「不是架构师不懂业务，这个是大家都不懂。」 -
架构师排斥成为业务需求的入口和挖掘者，被领导认为不懂业务。我个人觉得这个就是给架构师角色定位的问题，是 「要利用架构师的能力基础上挖掘业务+技术融和去做行业解决方案的研究？还是要将架构师落入具体的项目中进行架构实施？」如果确实没有明确定位，就只能排斥其中相对不明确的一方面。 「前者需要静下来，后者需要动起来，确实很难兼容。」
本文分享自微信公众号 - 字母哥课堂（zimug_blog）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
