35 模块导读：回过头来看，你觉得架构师到底是做什么的？
你好，我是郭东白。我们今天就正式进入模块三的学习了。
我们在开篇词里面介绍了，模块三的目的是向你介绍架构师的能力维度，以及获取这些能力的方法。既然是总结架构师成长的课程，那么“什么是架构师”就是一个绕不过去的话题。
架构师的定义
你肯定会有疑问，为什么课程都过半了才来定义“架构师”呢？再说了，架构师这个岗位不是很普遍嘛，人人都知道啊，用得着定义吗？我先给你三个理由。
第一，业界无标准。“架构师”并不存在一个标准的定义。请你去百度或者Google搜索一下“架构师”这个词，看看能找到一个让人满意的定义吗？你会发现架构师这个角色的定义五花八门，如果说这些定义之间有共性的话，那就是它们两两都不一致！事实上，哪怕是我之前在各类演讲中给出的架构师定义，也有七八种。
第二，语义在漂移。“架构师”是一个正在被滥用的名词。架构师在软件行业原本是一个具有特殊含义的岗位，代表了该岗位人才具有较高的综合能力，于是就成了具有稀缺能力的软件研发人才的代名词。
然而一些不太有节操的公司，却把“架构师”这三个字作为诸多研发岗位的前缀或后缀，让这个岗位看起来至少是个高薪苗子。这种乱蹭热度的现象就把“架构师”这个岗位给污染了，我估计再过十年，说不定还能看到“皇家架构师”这种职位在招聘。
第三，模块所必需。老子有言：“有名万物之始。”没有一个准确的定义，我们就没法锁定“架构师”这个名词的内涵，更无法锁定该岗位角色所必须的能力项。
那么“架构师”的定义是什么呢？如果你读过任何一本关于本体论的哲学论著，就会明白定义一个概念为什么这么难了。
我先给出一些架构师的定义，你可以比较一下：
- “A software architect is a software development expert who makes high-level design choices and tries to enforce technical standards, including software coding standards, tools, and platforms.” ——Wikipedia
- “a person holding this position drives all critical decisions about the organization of the software system.”——Indeed
- “A software architect defines software architecture.”——MSDN
- 软件架构师是一个复杂软件系统的设计者和规划者。——从架构师（dictionary.com architect）一词引申而来
- 软件架构师是软件架构活动的定义、规划和实施保障者。
- 软件架构师是一个以软件架构能力谋生的人。
- 软件架构师是一个具备软件架构能力的人。
- 软件架构师是一个主动的软件架构设计者。
- 架构师是一个具有架构思维的人。
其中，４—９是我在不同场合中曾经使用过的定义。
你如果仔细研究一下，会发现这些定义中还有其他需要解释的概念，比如软件系统、软件架构、架构活动、架构能力、架构思维等。
从另一个角度看，这些定义分别描述的是架构师的工作内容（定义1—5），具备的能力（定义6和7），创造的价值（定义1、2、4、5、8），以及思维方式（定义8和9）。
究竟哪一个是对的呢？似乎每个定义都有一定的道理，不过它们各自覆盖的角度和范围不同，所以也存在一定的差异。事实上，这些定义都与使用的上下文相关。
举个很简单的例子。假设你在观看一个关于狮子和老虎的纪录片，如果开头的文案是“狮子和老虎是地球上两种最大的猫科动物”，那么接下来的内容会是什么呢？如果下一句话是“但是狮子不同于老虎，狮子是群居动物”，你想象到的内容就完全变了。
也就是说，一个名字的定义是为使用它的上下文而服务的。既然我们这个专栏是关于架构师的职业成长，那么我打算使用的定义是：
软件架构师指的是具备软件架构能力的人，或者是以这种能力谋生的人。而所谓的软件架构能力，就是为相对复杂的场景设计并引导一个或多个研发团队，来实施结构化软件系统的能力。
有了这个定义，就可以开始我们这个模块的内容了。模块的主要内容是帮助一名软件行业从业者在架构师这个职业道路上快速成长的，软件架构师的工作职责是“设计和引导实施软件系统”，为公司创造的主要价值是“为复杂场景设计和实施结构化的软件系统”。这个角色可以是兼职的 (具备能力)， 也可以是全职的（以此谋生）。
从这个定义来看，模块一是讲架构工作中要遵守的原则，模块二是讲“为复杂场景设计和实施结构化的软件系统”的具体工作方法，模块三是讲做好架构工作所必需的能力项。而模块四，则是讲这些能力维度背后的本质能力，即思考力。
而我们当前模块的主要内容，就是梳理架构师工作所必须具备的能力维度，同时帮助架构师找到提升这些能力的办法。也就是为一个复杂系统设计软件的能力，以及引导研发团队实施的能力。有了更高的内在能力，就可以为企业创造更大的价值。
这里我特别要强调一下内在这两个字。所谓内在能力，是你本身具有的能力，而不是所处环境和岗位赋予的权力。最好的例子就是中国古代的儿皇帝。他处在皇帝的位置上，但并不具备管理国家的内在能力。
那么依照刚才对架构师所下的定义，哪些角色可以是一个真正的软件架构师呢？我们来判断一下。
- 刚入职的校招生。
有可能。我们这个定义并没有说复杂到底从哪里开始。或许这个校招生在学校里勤工俭学，已经开发过多个软件系统了呢？是不是够得上一个预备架构师呢？
- 工作两年的职场新人。
很有可能。如果他在一个小公司工作，应该能独立设计一个营销系统了，或许已经迭代一个大版本了。他应该够得上一个兼职架构师吧？
- 大厂的技术专家。
肯定是的。不一定是一个全职的架构师，但至少是个兼职架构师。因为他必须为复杂场景做结构化设计，已经重构了不止一个系统，肯定对“结构化”这个词有着自己的理解。
- 大厂的业务架构师
肯定是的，这不就是他们的工作嘛！
- 某个部门内的总架构师（首席架构师）
当然是的，这不就是他们的工作嘛！而且复杂性也应该更大一些了。
- 一个企业的总架构师（首席架构师）
也应该是的啊，企业的软件系统不就是一个复杂的业务场景吗？
- 一家企业的CTO
也应该是吧，不过CTO亲自做软件设计吗？他会引导实施吗？无论怎么说，小厂的CTO肯定会是一个兼职的架构师吧？
你看，这些大大小小的角色或多或少都满足了软件架构师的定义。
的确是这样的。我们这个模块就是要帮助小白程序员，学习成长到CTO应该具备的核心能力。换句话说，我的目标就是让你尽早具备这种内在能力。
如果你还能回忆起我们开篇词里面的一句话，就会明白我这么说的意图所在了：
“没有战略意图，就无法成为一个优秀的架构师”。
哪怕现在是个小白程序员，也应该具有成为一个优秀CTO的战略意图，让自己成为具有终极软件架构能力的架构师。而这种能力的定义就是：
在一个充分竞争的市场里、在高度不确定性的商业环境中、在有高度的业务复杂度的情况下，引导整个企业的研发团队持续优化一个软件体系并且最终因此而带来企业成功的能力。
如果能做到这一点，可以说是一名相当优秀的CTO了。惭愧地说，我虽然认定这是一个优秀架构师应该具有的战略意图，但我自己还远没有做到这一点。让我们一起往这个方向努力吧！
架构师的能力维度
好的，接下来我们就来描述一下一名优秀架构师应该具备的能力维度。
架构师的成长有五个明显的职业阶段：程序员、兼职架构师、全职架构师、首席架构师和CTO。其实这些阶段的命名并不重要，我们甚至可以称之为软件架构师阶段1到阶段5。因为真正重要的是在这五个阶段里，一个架构师所具备的内在能力发生了什么根本性的变化。如下图所示：
这张图表示的实际上是一个状态机，描述了架构师成长的五个状态，分别对应于我们刚才提到的架构师成长的五个阶段，或者说五种不同的架构师角色。从更深层来看，这张图还给出了架构师每个成长阶段的能力模型，以及需要跨越的具体障碍。在这个模块中，我们会详细描述这些障碍及其对应的能力建设的方法。
需要注意的是，在现实情况中，并不排除一个架构师同时具备多种角色。比如一个创业公司的CTO，往往是五种角色兼备。
也许你会问为什么是五个状态，而不是六个或者四个呢？其实这五个能力维度只是一个建模抽象，是我认为软件架构师成长过程中比较明显的能力项。同时，这五个能力维度又是互相正交的。哪怕你在某个能力维度上做到了极致，也不等于自动获取了另一种能力。也就是说，这五种能力维度具有不连续性，必须主动地、有计划地补足缺失的能力维度，才能获得成长。
所以有没有第六项重要的能力呢？我认为必然会有的，比如算法能力就是下一个强有力的能力项。我们通常认为算法能力不属于软件架构能力的一部分，但是在很多新兴企业中，算法已经和所有业务深度结合了。因而在软件架构设计中如何最大程度地放大算法的作用，我认为在不远的未来，将会成为一个非常重要的架构能力维度。
除此之外，还有没有其他和架构师能力正交的软件研发能力呢？答案是有的，而且非常多。比如数据挖掘能力、系统运维能力、全栈研发能力和技术影响力等。但是这些能力并不是软件架构师最核心的能力，也就是说，它们不是“设计和引导实施结构化软件系统”这个工作的强依赖。虽然这些能力很重要，但在软件架构师成长这个上下文里并没有那么重要。
当然，在技术能力之外，还有其他更广义的职业成长所必需的能力，比如沟通能力、学习能力、项目管理能力和科学决策能力等。同样地，这些能力对于所有互联网从业者来说都非常重要，并不属于我们这个模块的上下文。
你可能会问了，我离CTO还远着呢，现在就花时间为CTO做准备，明智吗？
一方面，我用CTO角色代表了一个高阶的技术架构能力，也就是通过技术带来业务增长的能力。
这个能力是CTO岗位的核心能力，但不是CTO的专属能力。也就是说，并不是要当上CTO才能用到这个能力。因为从一线工程师到各个级别的架构师，对这个能力有着不同程度的需求。而能力的培养非常耗费时间，所以要及早培养。其他的高阶能力也是如此。并不是处在程序员阶段就永远用不到，只是机会少一些罢了。
第二，CTO其实是企业技术职能的一个代表，代表了企业期望技术职能创造的价值。通过对CTO视角的学习，你将认识到自己作为技术团队的一分子，怎样才能最大程度地为企业创造生存优势。关注CTO视角，并根据CTO视角来优化自己在技术团队中的价值定位，才能和其他团队成员形成最大合力，为上下游创造价值，最终放大职业成功的概率。
小结
这节课我们讲了软件架构师的定义，强调架构师是通过“为复杂场景设计和实施结构化的软件系统”为公司创造价值的。同时，也给出了架构师职业成长的五个阶段，从而引出我们整个模块要覆盖的五个核心的能力维度：结构化设计、解决横向问题、解决跨领域冲突、正确的技术决策和创造生存优势。
这节课的内容其实也演示了一个很重要的思维方式，就是深度挖掘并定义一个实体概念，然后从概念的定义推导出内在属性。
我们在模块二统一语义的环节中也介绍过类似的方法。其实定义好一个概念，是我们架构师在职业发展中不断遇到的挑战。我们要确保所有相关方都在使用一个词来表达同样的概念，这个统一过程的第一步，就是对重要概念给出一个准确的定义。
这是架构工作的一个基本功，但却很少有人能完全做对。通过这节课，我希望你能看到定义概念这个看似简单，实则非常锻炼人的强大能力。
短短的一节课，我们通过对软件架构师的定义，准确描述出课程将会给你带来的价值。那么你作为学习者，也对课程的交付目标具有相对完整的理解。未来，你也可以从自己的视角出发，给出学习效果的评价。你看，从一个概念定义出发，就拟定了我们彼此之间的“合同”。
好的，那么下节课开始，我们就正式进入合同履约的过程，开始学习架构师职业成长过程中的主要的能力维度。
思考题
三个课后作业，建议你任选一个认真做一下。目的不是做得全，而是做得深，做得有感触。
- 建议去招聘网站，看看跟你所在行业和背景相关的架构师岗位都有哪些，并判断一下有多少岗位符合我们这节课给出的架构师定义。然后结合课程内容，分享一下你的洞察。
- 请认真看看有多少架构师岗位，是你勉强够得着的。同时，也看看自己的差距在哪里。然后把这些差距总结成几个关键词，分享在留言区。
- 请把你对架构师的定义，延展到我们这节课细分的架构师角色上去，看看有什么不合理的地方？你的改进建议是什么？
欢迎把你的思考和想法分享在留言区，我们下节课再见！
- 金石 👍（10） 💬（3）
架构师应当为架构活动注入灵魂，而这个灵魂就是战略意图，怎样通过架构活动为组织带来持久的核心竞争力。 没有灵魂的架构活动只是照本宣科，被产品经理牵着鼻子走，这样容易让组织过度追求短平快的效益，因而丧失长期的竞争力。 此外，我们厂里很多架构师设计做的很优秀，但最后能落地的设计只有十之一二。不清楚这是不是业界常态。 所以，我认为衡量一个架构师是不是有真本事，除了前面说的战略意图和架构功力，还要看他能不能说服别人赞助项目，能不能利用有限的资源最大化实现战略目标。 毕竟，能画图的嘴炮架构师一抓一大把，但能拿到兵权、能带兵打仗、并战而胜之的架构师却不多。 这主要是因为架构师手上的权力并不多，最多只有架构活动的决策权（即使这个权力，使用起来也要慎之又慎），在其他阶段掣肘颇多。 因此架构师想让项目成功落地，要有足够的影响力，需要各个利益相关者的信任与支持，还要有强大的策划能力。 可能一个成熟的组织就是这样运作的，权力是分散且受到制约的，没有人可以独自下决策。即便是手握实权的决策者和赞助者也不可能脱离架构师去做决定。 但这样也会让决策路径变得很长，让组织的决策效率变得低效。该怎样来平衡呢？ 我这里有两个问题，希望与郭老师以及各位同学探讨一下： 1、不妨设想一下，如果让架构师有足够的权力来调配组织的各种资源，不知道这是好事还是坏事呢？ 2、在我们厂，我还观察到越高级别的架构师，就越容易被架空。很多人虽然看起来位高权重，但实则更像是一个虚职，基本上只出大方案，却指挥不动底下的团队。 越来越像是一个参谋的角色，而不是一个带兵打仗的将领。这难道就是架构师的宿命吗？要怎么才能破局呢？
2022-05-16 - 范飞扬 👍（5） 💬（2）
想请教下老师和同学，文中的“比如算法能力就是下一个强有力的能力项”，这里的算法是指： 1.机器学习算法等类似 还是 2.数据结构与算法的算法？
2022-09-07 - 沈子砚 👍（3） 💬（3）
有没有同是产品经理
2022-05-11 - zangchao 👍（3） 💬（2）
对东白老师提到“CTO 视角来优化自己在技术团队中的价值定位”深有感触，自己公司也提倡拔高层级去做事。作为技术人员为企业创造价值，理解CTO的核心—生存优势至关重要。 自己在一家中小型企业负责工程效率相关工作，致力于为企业提升研发质量和效率，优化研发流程，发掘并开发有价值的研发工具。想请教下东白老师，从架构师或者DevOps角度，如何评估一个项目或者产品需求的价值，如何对这些项目或者需求进行有效协同管理，需要配套什么样的研发流程或工具提升整个研发团队的研发质量和效率，怎么证明自己推广的这套需求管理方法、研发流程或工具确实真正有价值、对公司的生存优势有帮助呢？ 问题有些多，也是困扰了自己好久，期望老师给予解答，多谢东白老师！
2022-05-10 - 罗均 👍（3） 💬（1）
非常感谢东白老师的课程，让自己深刻了解自己方方面面的不足，以及与一名优秀架构师的巨大差距！ 学生去年刚好换新工作，也浏览了很多“架构师”的JD，总结的最大共同点就是：技术专家+行业专家（或领域专家）。 东白老师是极其稀缺的多项技术专家+多行业专家+优秀管理者，因此也是全球顶级的CTO。能够学习老师的课程，真是无比幸运啊！
2022-05-10 - K.Z. 👍（2） 💬（0）
感觉广义地讲，架构师可以从不同维度去区分。横向地看，有建筑架构师，软件架构师，水利工程架构师，等等；也可以垂直地划分为企业架构师，业务架构师，系统架构师，数据库架构师，等。 不管怎么区分，架构师的职责都是解决复杂问题，提供结构化的系统方案。作为一个能够以全局视角规划并实施软件开发的角色，软件架构师需要更多地关注软件或者项目的整体战略目标以及商业价值，同时承担了一些技术管理上的职能。
2022-11-16 - 术子米德 👍（2） 💬（0）
🤔☕️🤔☕️🤔 * 📖：架构师到底干嘛？ * 🤔：每次看到这样的问题，总是很困惑，每次问出这样的问题，那更是在困惑的深渊。一种思考方法，在百般被问，跟百般自问的过程里，逐渐清晰起来，那就是，假设架构师不存在，根本没有，那会怎样？或者说，在一个过程里，什么时候会想到架构师，什么时候非他在不可？ * 🤔：这个思考角度，让我有清晰的思路，可是在思路的末端，往往是在项目出问题后，就开始随口喊到，这是哪个ShaX架构师搞出来的破玩意儿。这样反复出现的思考结果，又让我百思不解。 * 🤔：为了不让架构师在最后拉出来背锅，如何让架构师在一开始就亮相，又是让我抓破耳朵。原因很简单，经常听到，只说不干，眼高手低少来参合。这也没有思考出好的结果。
2022-05-23 - tiny 👍（1） 💬（0）
强调架构师是通过“为复杂场景设计和实施结构化的软件系统”为公司创造价值的！mark，非常明确的软件架构师定义。
2022-07-24 - 徐李 👍（1） 💬（0）
有些岗位对架构师的要求，就是包含对业务的理解规划，甚至开发，就是集产品经理，项目经理，开发，架构师一体
2022-06-28 - spark 👍（1） 💬（0）
郭老师，take away~~~用生活中的例子理解对“架构师”概念的定义。编程范式，"声明式编程范式"的定义和"命令式编程范式"的定义~~~ 声明式编程范式，强调问题是什么，强调抽象和结构是什么，解决数理逻辑问题。例如，CNN等深度学习模型，其中有结构、逻辑、问题的定义、特征的关系、评价成功的标准~~~ 命令式编程范式，强调怎么做，强调流程和状态，不停的写具体指令、if、for、while，解决业务问题。例如，订单状态、物流状态、支付状态~~~
2022-05-10