Question

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

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

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

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

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

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

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

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

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

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

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

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

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

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