Question

第二个问题，复杂模式下的决策过程有什么不同呢？

首先，“架构师个体”的决策过程是简单而粗暴的。但这一过程易于成功的原因在于：架构师总是有足够的时间来推进架构，并有“零机会成本”来修正决策过程。举例来说，架构师在考虑一个决策的时候，总是可以近乎直觉地觉察到“这一架构是否可以在有效时间内完成”。但这既然是他的主观判断，那么也就可能在客观环境中出错。然而当只有“架构师个体”时，他在实施过程中提出“变更某些架构特性”的机会总是存在的。

更特别的情况下，当架构角色、设计角色与开发角色是同一个人的时候，他几乎在任何时候都可以这么做。因为架构特性是关于系统而非关于产品的特性，所以除非产品目标是系统本身（如平台化或系统改造类项目），否则架构师对架构特性的取舍与修改具有足够的发言权。从这个角度来说，这类 变更 （决策过程中的关键行为）在“架构师个体”而言几乎是自由的。

但是在“架构团队”中，变更的成本将会变得无法预期。极端的情况下，一旦项目开始实施，整个架构团队甚至没有机会再来修改架构。因而整个项目基于一个“并不良好的架构”来开发实施的情况，是必然存在的。

种种因素导致对于“架构整体”的决策并不是在讨论学术上正确与否，而将是讨论是否能够基于现有团队实施推进。这涉及团队管理中的几个问题：

1. 对架构师团队与技术团队的评估；
2. 适时地中止讨论并形成架构决议；
3. 对实施过程有效跟踪并适时发起调整过程。

另外，参考格拉斯问题解决模型 14 ，整个架构推进过程还涉及两个时间方面的决策：

4. 何时能确定架构解决了系统的核心问题并可以进入实施推进环节；
5. 一旦实施中发生变更，确定该变更应当在何时予以满足。

上述五点（但不仅限于这五点）提出了在“架构整体 15 ”上所需要的决策过程。其基本模型如图 15 所示。

图 15　在“架构整体”上所需要的决策过程

而图 16 则用于说明将该模型应用于一个开发实施场景中的具体架构决策过程。

图 16　多个实施阶段下的架构决策过程

这一复杂的决策过程是由多个架构师角色参与的，但其决策者必是其中“以架构整体为目标”的架构师。这些决策确定了架构的整体走向与实施规划，以影响架构的整体性为基本目的。但既然参与者众而决策者寡，则必然涉及决策者与众不同的决策能力的问题。