第三个问题则是关于架构意图在复杂模式下的效果的。这涉及我们上面讨论的一个核心设问：架构整体需要决策的本质原因是什么呢?①将架构本身作为一个领域，则这些知识是为架构而形成的，与原始的系统目标(例如产品特性等)无关。

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

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

□其一，它是领域集。从领域集的关系来看，它可能涉及的基础构件包括领域/子系统、通信与验证，以及它们的问题与解决方案，例如分布、依赖、消息等。

□其二，从其定义来看，它的抽象必须能容纳上述构件并提供可以讨论的事实基础。

□其三，从系统性的限制上来看，上述事实基础必将涉及全局性的边界约定，以及对非可控因素(包括但不限于风险)的识别与处理。yipindushu.com

□其四，从架构的本质上来看，其范围与联接件的问题，实质上是各领域边界的全集与交集(以及交集间)的关系。

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

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

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

□其一，若架构不谈时间需求与空间需求，而只谈目标需求，那么“架构整体”就必将等效于“各种架构的全集”。然而，若这个全集的元素之间没有关系，也就无法构成整体，进而“全集”这一观念构成了对架构整体性的破坏。

□其二，如前所论，架构是可以通过解决问题来实现需求的，而非单纯对需求的响应。若架构本身只谈上述全集的“目标需求”,那么也就无法触及其背后的“问题”;而时间需求与空间需求背后的问题是清晰的，即系统的规模与复杂性。

□其三，架构本身的价值在于：在保持方向的同时控制成本。而架构在时间需求与空间需求上的考量，构成了“架构全集”到“架构整体”的价值提升。它使得架构可以通过在时间与空间上的分解 一般表达为架构阶段(以及对应的实施阶段)的迭代— 来解决架构规模问题与复杂性问题，进而达到成本控制。

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

①注意决策能力、领袖能力与管理能力并不同一，这里只讨论其中的决策能力部分。而将“架构团队”作为一个组织来看，也存在对“管理者”的需求。但即便如此，也并不表明首席架构师必须担负架构团队的管理责任。

“架构师团队面临的架构整体”是什么?我将它称为系统架构。这缘于这一“架构整体”是对系统整体的抽象。然而需要强调的是，对于系统架构这一指称，其中的“系统”是一个狭义的、表达开发规模的用词，同时它也表达上述规模下的开发活动整体。

针对系统架构的架构意图，我们仍然可以提出如下设问：(1)其一般过程是什么?(2)其可能的演化方向是什么?(3)该系统对于客户战略作何种响应?(4)什么是系统的本质问题?(5)能不能不做?在继续讨论之前我必须再次强调：接下来的讨论并不基于该系统架构之局部(例如子系统/应用的架构),而是面向其本身——系统架构。