我的架构思想(二十):架构是过程,而非结果——架构师的能力结构(架构师的能力模型)

阅读数:31 2019 年 10 月 12 日 16:58

我的架构思想(二十):架构是过程,而非结果——架构师的能力结构(架构师的能力模型)

我们接下来要讨论的是三个问题:其一,是否需要更加复杂的模式(如架构师团队)来推进架构;其二,复杂模式下的决策过程有何不同;其三,架构意图在复杂模式下的效果。

第一个问题的关键在于我们对“系统”的规模的设定。我们此前讨论过:作为一个“规模”的用词,系统是一个“领域集”;即使将这一领域聚焦到“数据 + 算法”这样的软件开发本质工作中,(在大型系统中)也被具体分成多个领域了。一旦在系统中出现跨领域和领域细分,也或者说这样的背景就是我们将“系统”作为一个规模设定的本质,那么架构也就通常是一个人无法完成的了。

因此,在这个系统的解决方案——某个具体的项目中2,团队中需要一个架构团队来处理架构方面的具体实作:实施与推进。但是进一步的问题是:这个架构团队应该由怎样的一些成员组成呢?对此,我认为他们——架构师应当具备的能力包括图 11 所示三个方面3

2 这里的意思是说,系统是我们的目标,项目是围绕这个目标提出的解决方案。作为解决方案,意味着它包括技术、产品、团队、资源等所有有关“实现该系统”所需的方面。而架构是整个解决方案中与技术相关的一个部分。仅从规模(的领域相关性)上来看,我们可以把整个 Facebook,或整个 Google 网站作为“系统”的一个参考对象。

3 其中,(与计算机无关的)某些领域细节是不需要在这里讨论的。

图 11 架构师能力的三个方面

我的架构思想(二十):架构是过程,而非结果——架构师的能力结构(架构师的能力模型)

所谓领悟,主要包括架构思维的三个核心能力4:概念抽象能力、概念表达能力和基于概念的逻辑表达能力。架构师的思维方式,决定了他在架构团队中的独特价值5。而这一思维方式的基点必然源自他的概念抽象能力,亦即他对“架构对象”的独特认识6——正是因为对其认识不同,进而才决定了对其抽象不同。

4 参见本书“引言:架构师的思维”。

5 如果架构是一个“决策”的过程的话,多样性就是必须的。

6 在这里所言的“独特认识”是认识方法论决定的,而不是对象本身的特点所决定的。因此领悟能力是跨架构(或说超越架构)的。脱离具体的架构对象,是我将这一能力称为“领悟”的原因。

所谓领域,是架构师在目标系统中的背景知识。架构师需要相当的背景知识,才“能够”对目标系统进行恰当的概念抽象,也才“能够”准确把握系统的内在动律整体动向。因此,领域能力也是架构意图能够作为抽象概念与决策条件被提出的基础。

所谓领袖,是架构师在领域内和团队内的影响力。领袖能力与领导能力略有区别。后者(即领导能力)主要是在组织视角下对管理者(manager)这样的角色,在其职能、责权与实施能力上的说明;尤其重要的是,就组织的必要性来说,是希望限制领导角色的影响力范围的,跨责权范围的影响力是对领导职权的一个质问。而前者,即我们这里讨论的领袖并非是一个组织角色7,而是指架构角色所形成的、超出组织结构的影响力8,其主要表达为方向、决策和对团队向心力的把握。

7 例如,说某人是行业领袖,并不意味着他在行业中担任了类似于联盟主席之类的领导职务,也并不意味着他是行业对口的政府职能角色。行业领袖只表明了他在这个领域中的突出表现以及影响力。

8 参考本书附录之“附三:超越软件架构——组织与架构”。其一,架构是目标之于规模与细节上的投影,因而其内在就是跨项目组织的管理与实现两个轴向的;其二,架构本身是通过意图来保持与经营者(在领域性、方向性与战略假设等方面)的一致性,因此其外在也是经营者施于系统的影响的一部分——这本质上也是跨组织结构的。

事实上我们所讨论的这一模型由思维、知识、行动三个方向的能力构成。总的来说,个人能力的不同取向决定了他在组织中的职业倾向,而架构师所需的是在三者中相对平衡的一种整体能力,如图 12 所示。

图 12 个人能力取向与职业倾向的对比

我的架构思想(二十):架构是过程,而非结果——架构师的能力结构(架构师的能力模型)

当从领域专家这一方向上衡量时,在领域方面的背景知识(一定程度上)反映了他可以应对的架构的规模——之所以选择从领域方面进行考察,是因为“领域”是在架构师团队中进行分工的一般标准9 10,如图 13 所示。

9 仅软件开发领域而言,架构师的领域能力与他能应对的开发规模是相关的。参考《程序原本》一书自“第 5 章 从功能到系统”开始论及的四种开发规模:技术架构对应于功能(function) 与程序(program),应用架构对应于应用(application),而系统 / 平台架构对应于系统(system)。

10 分工并不是规模问题。例如,数据架构、前端架构这样的分类法是指分工,而下面讨论的技术架构、系统架构等是指规模。但分工与规模的组合,大致说明了一名架构师在团队中的位置。例如,前端平台架构师,或运维技术架构师。

图 13 领域背景知识与可应对的架构规模的关系

我的架构思想(二十):架构是过程,而非结果——架构师的能力结构(架构师的能力模型)

但就这三个方面总体而言,(在应对同一事件时)应当是相互支撑的,亦即是要求三个方向上的能力在整体上是平衡的。举例来说,如果架构师偏向于强化领悟能力而弱化其他,则由于在领域能力上的缺失,其架构思维趋向于理想化,偏于学术;又由于领袖能力的缺失,导致他在决策过程中丧失发言权,或有言无行,疏于实作。类似的,片面强调领域能力,则与工程师无异;片面强调领袖能力,则必将碌碌而难有所为。因而团队成员仅仅符合图 13 中对“领域”这一方面的要求,是不足以承担相应规模的架构师职责的。以“系统架构 / 平台架构”11为例,他应当具备与之平衡的领悟与领袖能力(如图 14 所示),从而避免因领域能力过强而滞于领域专家的角色。

11 现实中我们常常会提及“平台架构师”这样的职务称谓,事实上它是系统架构这一规模下的具体描述,因为平台 / 平台化是系统的一种实现。因此准确地说,应当将之统一称为系统架构。

图 14 架构师能力是对三方面能力的平衡性的要求

我的架构思想(二十):架构是过程,而非结果——架构师的能力结构(架构师的能力模型)

当“架构”被作为计算机系统的一个领域时,该领域也必然具有自己特定的知识,也必然具有自身的系统性需求。因此,“架构整体”作为一个系统性的目标,仍然是存在自身在“目标、规模与实现”三方面的需求12,仍然需要架构角色。这一角色通常被称为“首席架构师”,负责“架构整体”的决策,其能力结构仍然是我们谈到的这三个方面:在“架构”这一领域中有着丰富的知识,具有强大而独特的领悟能力,是团队中的领袖人物13

12 参见本书附录之“附三:超越软件架构——组织与架构”中所讨论的 VEO 模型。

13 首席架构师在某一具体领域可能并非最强,这是因为首席架构师所应对的首先是“架构”这一领域,其次才是“目标系统”的具体领域。

评论

发布