Question

第三个问题则是关于架构意图在复杂模式下的效果的。这涉及我们上面讨论的一个核心设问：架构整体需要决策的本质原因是什么呢？

我们所讨论的系统的规模已经扩展到多个领域，因此需要由架构师团队来处理它的架构需求。进而地，多个领域之间的——系统本身的——问题作为一个独立领域仍然有自身的架构需求，因此我们提出了系统架构师或平台架构师等规模来应对之，并（根据其领袖能力、可能性地）赋予其一定的组织责权，例如“首席架构师”或“主架构师”。

这一架构角色面对的并非上述系统各个独立领域内部的问题，而是“架构整体”的问题。将其本身作为系统，综合一下我们此前的讨论：

• 其一，它是领域集。从领域集的关系来看，它可能涉及的基础构件包括领域/子系统、通信与验证，以及它们的问题与解决方案，例如分布、依赖、消息等。
• 其二，从其定义来看，它的抽象必须能容纳上述构件并提供可以讨论的 事实基础 。
• 其三，从系统性的限制上来看，上述事实基础必将涉及全局性的边界约定，以及对非可控因素（包括但不限于风险）的识别与处理。
• 其四，从架构的本质上来看，其范围与联接件的问题，实质上是各领域边界的全集与交集（以及交集间）的关系。

可见，这些内容提出了“系统需要事实基础”，这与架构意图所讨论的问题是一致的。

但这并不能表明“架构本身的架构意图”与领域性的、子系统的架构意图有着一样的源起与价值——我们在这里提到了“价值”，亦即是对“架构本身的架构意图”的效果问题的讨论。

架构有两个效果方面的考量，即它对 时间需求 与 空间需求 的响应与收益。这样的考量依据来源于以下三点。

• 其一，若架构不谈时间需求与空间需求，而只谈目标需求，那么“架构整体”就必将等效于“各种架构的全集”。然而，若这个全集的元素之间没有关系，也就无法构成整体，进而“全集”这一观念构成了对架构整体性的破坏。
• 其二，如前所论，架构是可以通过解决问题来实现需求的，而非单纯对需求的响应。若架构本身只谈上述全集的“目标需求”，那么也就无法触及其背后的“问题”；而时间需求与空间需求背后的问题是清晰的，即系统的规模与复杂性。
• 其三，架构本身的价值在于：在保持方向的同时控制成本。而架构在时间需求与空间需求上的考量，构成了“架构全集”到“架构整体”的价值提升。它使得架构可以通过在时间与空间上的分解——一般表达为架构阶段（以及对应的实施阶段）的迭代——来解决架构规模问题与复杂性问题，进而达到成本控制。

综上，团队模式下的决策与个体决策有很大的不同 16 。团队决策考虑的对象有两点，其一是对架构整体的把握，其二是对团队整体的把握。对前者的思考，仍然可以归于架构意图，是由领悟能力驱动的；而后者则可以视为对架构意图的效果的保障，是由领袖能力所驱动的。

1. 这的确是一种好的开发模式，它确实减少了架构决策过程的复杂性。 ↩
2. 这里的意思是说， 系统 是我们的目标， 项目 是围绕这个目标提出的 解决方案 。作为解决方案，意味着它包括技术、产品、团队、资源等所有有关“实现该系统”所需的方面。而 架构 是整个解决方案中与技术相关的一个部分。仅从规模（的领域相关性）上来看，我们可以把整个 Facebook，或整个 Google 网站作为“系统”的一个参考对象。 ↩
3. 其中，（与计算机无关的）某些领域细节是不需要在这里讨论的。 ↩
4. 参见本书“引言：架构师的思维”。 ↩
5. 如果架构是一个“决策”的过程的话，多样性就是必须的。 ↩
6. 在这里所言的“独特认识”是认识方法论决定的，而不是对象本身的特点所决定的。因此领悟能力是跨架构（或说超越架构）的。脱离具体的架构对象，是我将这一能力称为“领悟”的原因。 ↩
7. 例如，说某人是行业领袖，并不意味着他在行业中担任了类似于联盟主席之类的 领导职务 ，也并不意味着他是行业对口的政府 职能角色 。行业领袖只表明了他在这个领域中的突出表现以及影响力。 ↩
8. 参考本书附录之“附三：超越软件架构——组织与架构”。其一，架构是目标之于规模与细节上的投影，因而其内在就是跨项目组织的管理与实现两个轴向的；其二，架构本身是通过意图来保持与经营者（在领域性、方向性与战略假设等方面）的一致性，因此其外在也是经营者施于系统的影响的一部分——这本质上也是跨组织结构的。 ↩
9. 仅软件开发领域而言，架构师的领域能力与他能应对的开发规模是相关的。参考《程序原本》一书自“第 5 章 从功能到系统”开始论及的四种开发规模：技术架构对应于功能（function) 与程序（program），应用架构对应于应用（application），而系统/平台架构对应于系统（system）。 ↩
10. 分工并不是规模问题。例如，数据架构、前端架构这样的分类法是指分工，而下面讨论的技术架构、系统架构等是指规模。但分工与规模的组合，大致说明了一名架构师在团队中的位置。例如，前端平台架构师，或运维技术架构师。 ↩
11. 现实中我们常常会提及“平台架构师”这样的职务称谓，事实上它是系统架构这一规模下的具体描述，因为平台/平台化是系统的一种实现。因此准确地说，应当将之统一称为系统架构。 ↩
12. 参见本书附录之“附三：超越软件架构——组织与架构”中所讨论的 VEO 模型。 ↩
13. 首席架构师在某一具体领域可能并非最强，这是因为首席架构师所应对的首先是“架构”这一领域，其次才是“目标系统”的具体领域。 ↩
14. 一种可计划的问题解决模型。通过“制定、检验、重构”过程的反复迭代，逐渐拟合问题表征与实施计划，以最终解决问题。参见《认知（第二版)》，Glass 与 Holyoak 著。 ↩
15. 将架构本身作为一个领域，则这些知识是为架构而形成的，与原始的系统目标（例如产品特性等）无关。 ↩
16. 注意决策能力、领袖能力与管理能力并不同一，这里只讨论其中的决策能力部分。而将“架构团队”作为一个组织来看，也存在对“管理者”的需求。但即便如此，也并不表明首席架构师必须担负架构团队的管理责任。 ↩