回顾VEO这个模型与项目的关系，我们可以将“整个系统”所涉的子系统划分在不同的业务领域中。这时我们会发现，VEO也展示了子系统与系统全局之间在方向上的不一致性。它们既有可能是同向或基本同向的，也有可能是异向的，或者无关的。图0-11部分展示了在Windows操作系统中的“多媒体子系统”可能涉及的一些细分子系统、业务领域。

在将操作系统或“多媒体子系统”的细节投影到VEO模型时，我们会发现：(1)目标跟“规模和细节”之间是一体两面的关系；(2)系统全局的目标，与“不同子项目的规模与细节”又是一体多面的关系；(3)局部目标与全局目标并不存在简单累加关系，因此全局规模与局部规模也不存在累加关系，“细节”轴线也存在相同的问题；(4)目标在不同方向上越分散，子系统在规模与细节上冲突的可能性就越高，系统复杂度(管理成本与实现成本)也越高；(5)不同的方向间产生的内耗极大地增加了系统的代价，而规模与细节的失控只是这个问题在两个轴向上的表现。

①在这里以及后文的讨论中，我是特指Windows中的write.exe这个写字板工具软件。

面对这样复杂的系统分析，架构角色应当要有能力来回顾(review)各个子项目，有意识地放弃掉一些不重要的、投入与产出关系不明朗的，或者对系统全局会有负面影响的子系统。同样，架构角色也可以将部分力量聚焦在一些子项目中，以使战略方向更为明确和落到实处。最后，也是最重要的，架构师要能把握全局力量的投放，对于某些有远见的方向，或暂时不清晰的方向予以持久的关注，这是架构师在系统整体调控能力上的最终体现。

【组织：组织力下的VEO基本模型】yipindushu.com

VEO模型表达了技术、管理之与架构，是一体的两面，这种关系可简单描述为图0-12,但这只是一种理想状况——准确地说，是相对理想的状况当中的一种。

图0-12技术、管理之于架构是一体两面的关系在我们最初做软件开发工作的时候，例如个体开发项目中，所谓技术角色与管理角色是一体的，这是最简洁的开发模式。接下来，当项目规模大到一定程度时，我们发现需要一个管理角色来参与项目的过程，让他通过控制这一过程来限制项目的规模，保障输出质量与投入成本的平衡。这催生了传统的软件工程模型。

传统软件工程模型其实就是一个软件开发方法论在过程与工具上的投影。

然而尽管我们已经基于这样的模式实践了几十年，却仍然在不停地探索管理与技术之间协调工作的方法。从这个角度上，即从实施的视角，对传统的软件工程模型加以审视，

基于实施视角，对传统工程模型的另一种抽象描述这事实上也说明了传统的软件工程为什么都是在某种方法论上的具体实施。然而我们观察实施视角下的软件工程，(基于某种方法论，)它除了引入更复杂的过程/流程，以及更多门类的工具来协助工程的推进之外，并不能解决组织问题。

现在，为了保障更大规模下的目标，我们引入了架构角色。架构这一角色，在组织关系上介于管理与技术二者之间，在工作内容上与二者有所重叠，在职责权力上又难以对当前项目与产品产生直接效果。这三个方面的关系，使架构角色在组织结构上显得尴尬。而与这种尴尬的状况不匹配的，是它可能带来的负面效应。

架构角色对目标投影的失控将不可避免地导致组织规模扩大，以及管理与实施之间失联，图0-14表现了这样一种状态(图中的角度值仅用来与VEO基本模型比较，并非有确切含义的数值)。

所谓组织失联，是指在组织结点之间(例如管理与技术)所工作的方向不一致、沟通成本增加，以及信息不对称——例如架构角色所展示的“目标映射”在其他角色有不同理解。进一步的结果，随着失联愈趋明显，最终有效的工作集变得越来越小。与此同时，组织的规模却在增长，管理边界与成本也增大了。这一过程，其实就是所谓的组织结构调整所带来的内耗。

复杂度增加……管理技术>90°趋向失联图0-14模型8:组织结构调整带来的问题积极的管理或技术角色会趋向于弥补这种内耗，无论是二者谁占据主动(话语权或说服力),其结果无非是图0-15所示的两种情况中的一种。尽管这两种模型从本质上来说是一样的——因为“实际的规模”中的内耗与模型8中是等量的，但是架构失控偏向于某一侧，其结果却可能不同。