郭东白的架构课37

你好，我是郭东白。我们今天就正式进入模块三的学习了。

我们在开篇词里面介绍了，模块三的目的是向你介绍架构师的能力维度，以及获取这些能力的方法。既然是总结架构师成长的课程，那么“什么是架构师”就是一个绕不过去的话题。

架构师的定义

你肯定会有疑问，为什么课程都过半了才来定义“架构师”呢？再说了，架构师这个岗位不是很普遍嘛，人人都知道啊，用得着定义吗？我先给你三个理由。

第一，业界无标准。“架构师”并不存在一个标准的定义。请你去百度或者Google搜索一下“架构师”这个词，看看能找到一个让人满意的定义吗？你会发现架构师这个角色的定义五花八门，如果说这些定义之间有共性的话，那就是它们两两都不一致！事实上，哪怕是我之前在各类演讲中给出的架构师定义，也有七八种。

第二，语义在漂移。“架构师”是一个正在被滥用的名词。架构师在软件行业原本是一个具有特殊含义的岗位，代表了该岗位人才具有较高的综合能力，于是就成了具有稀缺能力的软件研发人才的代名词。

然而一些不太有节操的公司，却把“架构师”这三个字作为诸多研发岗位的前缀或后缀，让这个岗位看起来至少是个高薪苗子。这种乱蹭热度的现象就把“架构师”这个岗位给污染了，我估计再过十年，说不定还能看到“皇家架构师”这种职位在招聘。

第三，模块所必需。老子有言：“有名万物之始。”没有一个准确的定义，我们就没法锁定“架构师”这个名词的内涵，更无法锁定该岗位角色所必须的能力项。

那么“架构师”的定义是什么呢？如果你读过任何一本关于本体论的哲学论著，就会明白定义一个概念为什么这么难了。

我先给出一些架构师的定义，你可以比较一下：

1. “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
   　
2. “a person holding this position drives all critical decisions about the organization of the software system.”——Indeed
   　
3. “A software architect defines software architecture.”——MSDN
   　
4. 软件架构师是一个复杂软件系统的设计者和规划者。——从架构师（dictionary.com architect）一词引申而来
   　
5. 软件架构师是软件架构活动的定义、规划和实施保障者。
   　
6. 软件架构师是一个以软件架构能力谋生的人。
   　
7. 软件架构师是一个具备软件架构能力的人。
   　
8. 软件架构师是一个主动的软件架构设计者。
   　
9. 架构师是一个具有架构思维的人。

其中，４—９是我在不同场合中曾经使用过的定义。

你如果仔细研究一下，会发现这些定义中还有其他需要解释的概念，比如软件系统、软件架构、架构活动、架构能力、架构思维等。

从另一个角度看，这些定义分别描述的是架构师的工作内容（定义1—5），具备的能力（定义6和7），创造的价值（定义1、2、4、5、8），以及思维方式（定义8和9）。

究竟哪一个是对的呢？似乎每个定义都有一定的道理，不过它们各自覆盖的角度和范围不同，所以也存在一定的差异。事实上，这些定义都与使用的上下文相关。

举个很简单的例子。假设你在观看一个关于狮子和老虎的纪录片，如果开头的文案是“狮子和老虎是地球上两种最大的猫科动物”，那么接下来的内容会是什么呢？如果下一句话是“但是狮子不同于老虎，狮子是群居动物”，你想象到的内容就完全变了。

也就是说，一个名字的定义是为使用它的上下文而服务的。既然我们这个专栏是关于架构师的职业成长，那么我打算使用的定义是：

软件架构师指的是具备软件架构能力的人，或者是以这种能力谋生的人。而所谓的软件架构能力，就是为相对复杂的场景设计并引导一个或多个研发团队，来实施结构化软件系统的能力。

有了这个定义，就可以开始我们这个模块的内容了。模块的主要内容是帮助一名软件行业从业者在架构师这个职业道路上快速成长的，软件架构师的工作职责是“设计和引导实施软件系统”，为公司创造的主要价值是“为复杂场景设计和实施结构化的软件系统”。这个角色可以是兼职的 (具备能力)， 也可以是全职的（以此谋生）。

从这个定义来看，模块一是讲架构工作中要遵守的原则，模块二是讲“为复杂场景设计和实施结构化的软件系统”的具体工作方法，模块三是讲做好架构工作所必需的能力项。而模块四，则是讲这些能力维度背后的本质能力，即思考力。

而我们当前模块的主要内容，就是梳理架构师工作所必须具备的能力维度，同时帮助架构师找到提升这些能力的办法。也就是为一个复杂系统设计软件的能力，以及引导研发团队实施的能力。有了更高的内在能力，就可以为企业创造更大的价值。

这里我特别要强调一下内在这两个字。所谓内在能力，是你本身具有的能力，而不是所处环境和岗位赋予的权力。最好的例子就是中国古代的儿皇帝。他处在皇帝的位置上，但并不具备管理国家的内在能力。

那么依照刚才对架构师所下的定义，哪些角色可以是一个真正的软件架构师呢？我们来判断一下。

1. 刚入职的校招生。

有可能。我们这个定义并没有说复杂到底从哪里开始。或许这个校招生在学校里勤工俭学，已经开发过多个软件系统了呢？是不是够得上一个预备架构师呢？

2. 工作两年的职场新人。

很有可能。如果他在一个小公司工作，应该能独立设计一个营销系统了，或许已经迭代一个大版本了。他应该够得上一个兼职架构师吧？

3. 大厂的技术专家。

肯定是的。不一定是一个全职的架构师，但至少是个兼职架构师。因为他必须为复杂场景做结构化设计，已经重构了不止一个系统，肯定对“结构化”这个词有着自己的理解。

4. 大厂的业务架构师

肯定是的，这不就是他们的工作嘛！

5. 某个部门内的总架构师（首席架构师）

当然是的，这不就是他们的工作嘛！而且复杂性也应该更大一些了。

6. 一个企业的总架构师（首席架构师）

也应该是的啊，企业的软件系统不就是一个复杂的业务场景吗？

7. 一家企业的CTO

也应该是吧，不过CTO亲自做软件设计吗？他会引导实施吗？无论怎么说，小厂的CTO肯定会是一个兼职的架构师吧？

你看，这些大大小小的角色或多或少都满足了软件架构师的定义。

的确是这样的。我们这个模块就是要帮助小白程序员，学习成长到CTO应该具备的核心能力。换句话说，我的目标就是让你尽早具备这种内在能力。

如果你还能回忆起我们开篇词里面的一句话，就会明白我这么说的意图所在了：

“没有战略意图，就无法成为一个优秀的架构师”。

哪怕现在是个小白程序员，也应该具有成为一个优秀CTO的战略意图，让自己成为具有终极软件架构能力的架构师。而这种能力的定义就是：

在一个充分竞争的市场里、在高度不确定性的商业环境中、在有高度的业务复杂度的情况下，引导整个企业的研发团队持续优化一个软件体系并且最终因此而带来企业成功的能力。

如果能做到这一点，可以说是一名相当优秀的CTO了。惭愧地说，我虽然认定这是一个优秀架构师应该具有的战略意图，但我自己还远没有做到这一点。让我们一起往这个方向努力吧！

架构师的能力维度

好的，接下来我们就来描述一下一名优秀架构师应该具备的能力维度。

架构师的成长有五个明显的职业阶段：程序员、兼职架构师、全职架构师、首席架构师和CTO。其实这些阶段的命名并不重要，我们甚至可以称之为软件架构师阶段1到阶段5。因为真正重要的是在这五个阶段里，一个架构师所具备的内在能力发生了什么根本性的变化。如下图所示：

这张图表示的实际上是一个状态机，描述了架构师成长的五个状态，分别对应于我们刚才提到的架构师成长的五个阶段，或者说五种不同的架构师角色。从更深层来看，这张图还给出了架构师每个成长阶段的能力模型，以及需要跨越的具体障碍。在这个模块中，我们会详细描述这些障碍及其对应的能力建设的方法。

需要注意的是，在现实情况中，并不排除一个架构师同时具备多种角色。比如一个创业公司的CTO，往往是五种角色兼备。

也许你会问为什么是五个状态，而不是六个或者四个呢？其实这五个能力维度只是一个建模抽象，是我认为软件架构师成长过程中比较明显的能力项。同时，这五个能力维度又是互相正交的。哪怕你在某个能力维度上做到了极致，也不等于自动获取了另一种能力。也就是说，这五种能力维度具有不连续性，必须主动地、有计划地补足缺失的能力维度，才能获得成长。

所以有没有第六项重要的能力呢？我认为必然会有的，比如算法能力就是下一个强有力的能力项。我们通常认为算法能力不属于软件架构能力的一部分，但是在很多新兴企业中，算法已经和所有业务深度结合了。因而在软件架构设计中如何最大程度地放大算法的作用，我认为在不远的未来，将会成为一个非常重要的架构能力维度。

除此之外，还有没有其他和架构师能力正交的软件研发能力呢？答案是有的，而且非常多。比如数据挖掘能力、系统运维能力、全栈研发能力和技术影响力等。但是这些能力并不是软件架构师最核心的能力，也就是说，它们不是“设计和引导实施结构化软件系统”这个工作的强依赖。虽然这些能力很重要，但在软件架构师成长这个上下文里并没有那么重要。

当然，在技术能力之外，还有其他更广义的职业成长所必需的能力，比如沟通能力、学习能力、项目管理能力和科学决策能力等。同样地，这些能力对于所有互联网从业者来说都非常重要，并不属于我们这个模块的上下文。

你可能会问了，我离CTO还远着呢，现在就花时间为CTO做准备，明智吗？

一方面，我用CTO角色代表了一个高阶的技术架构能力，也就是通过技术带来业务增长的能力。

这个能力是CTO岗位的核心能力，但不是CTO的专属能力。也就是说，并不是要当上CTO才能用到这个能力。因为从一线工程师到各个级别的架构师，对这个能力有着不同程度的需求。而能力的培养非常耗费时间，所以要及早培养。其他的高阶能力也是如此。并不是处在程序员阶段就永远用不到，只是机会少一些罢了。

第二，CTO其实是企业技术职能的一个代表，代表了企业期望技术职能创造的价值。通过对CTO视角的学习，你将认识到自己作为技术团队的一分子，怎样才能最大程度地为企业创造生存优势。关注CTO视角，并根据CTO视角来优化自己在技术团队中的价值定位，才能和其他团队成员形成最大合力，为上下游创造价值，最终放大职业成功的概率。

小结

这节课我们讲了软件架构师的定义，强调架构师是通过“为复杂场景设计和实施结构化的软件系统”为公司创造价值的。同时，也给出了架构师职业成长的五个阶段，从而引出我们整个模块要覆盖的五个核心的能力维度：结构化设计、解决横向问题、解决跨领域冲突、正确的技术决策和创造生存优势。

这节课的内容其实也演示了一个很重要的思维方式，就是深度挖掘并定义一个实体概念，然后从概念的定义推导出内在属性。

我们在模块二统一语义的环节中也介绍过类似的方法。其实定义好一个概念，是我们架构师在职业发展中不断遇到的挑战。我们要确保所有相关方都在使用一个词来表达同样的概念，这个统一过程的第一步，就是对重要概念给出一个准确的定义。

这是架构工作的一个基本功，但却很少有人能完全做对。通过这节课，我希望你能看到定义概念这个看似简单，实则非常锻炼人的强大能力。

短短的一节课，我们通过对软件架构师的定义，准确描述出课程将会给你带来的价值。那么你作为学习者，也对课程的交付目标具有相对完整的理解。未来，你也可以从自己的视角出发，给出学习效果的评价。你看，从一个概念定义出发，就拟定了我们彼此之间的“合同”。

好的，那么下节课开始，我们就正式进入合同履约的过程，开始学习架构师职业成长过程中的主要的能力维度。

思考题

三个课后作业，建议你任选一个认真做一下。目的不是做得全，而是做得深，做得有感触。

1. 建议去招聘网站，看看跟你所在行业和背景相关的架构师岗位都有哪些，并判断一下有多少岗位符合我们这节课给出的架构师定义。然后结合课程内容，分享一下你的洞察。
2. 请认真看看有多少架构师岗位，是你勉强够得着的。同时，也看看自己的差距在哪里。然后把这些差距总结成几个关键词，分享在留言区。
3. 请把你对架构师的定义，延展到我们这节课细分的架构师角色上去，看看有什么不合理的地方？你的改进建议是什么？

欢迎把你的思考和想法分享在留言区，我们下节课再见！