首先，我们明确了模型阐述的主题。整个模型被称为“组织视角下的工程视图”(请留意这仅仅是该视图的一个“过渡版本”),意在将这张图的整体视为对“工程”的描述。

其次，我们将纵向轴称为“项目管理"。这个领域中的角色围绕一个“明确的目标”的投影工作，主要职责在于管理其规模(scope),包括对团队组织、产品特性、项目质量、消耗成本等进行明确的或可预期的管理。以现实的工程角色为例，可能包括团队负责人、项目经理、产品经理、市场经理等①。

最后，我们将横向轴称为“技术实现"。这个领域中的角色围绕“与‘项目管理’角色相同目标”的投影工作，主要职责在于实现其细节(specific)。以现实的工程角色为例，可能包括工程师、设计师、分析师等。

上述“技术实现"与“项目管理”二者所关注投影的原始目标“应当”是同一的。在现实的工程中，我们通常称之为“产品”②。

①这并不是说项目经理要“管辖或替代”产品经理的职责，而是说在“范围”这个领域中，事实上(在现实中)是并存着这些角色的。“项目管理”作为一个现实职务时，它管理的具体内容是与组织的授权有关的，这在后面的内容中将会讨论到(例如，“调适：变化中的VEO模型”)。

②对于“方向”这个轴线上的“目标”来说，项目所管理与实现的，是阶段目标下的“阶段性产品”。同样，以纯粹的“产品视角”来说，“方向”轴线上的目标/产品系列，即是“产品线”。更进一步，经营角色同时关注的是多个产品线上的方向问题，于是一系列产品线所构成的某一个方向上的“方向簇”,通常可以作为一个“战略”的战术实施。在本书中，并不对模型4中所隐含的“产品视角”作深入讨论。yipindushu.com

对于一个小型的组织，或一个较短期的目标/方向来说，若要求“经营者”来保证两个投影的原始目标同一，并在实施过程中持续稳定，是有可能做到的。这也是一些小公司或小型团队能有良好的组织与合作的根本原因：经营者直接参与规模与细节的平衡。但是，在以下时候：□规模持续扩大、技术渐趋复杂；□经营者的方向与阶段目标间的距离越来越远；口方向由多个方向簇构成。

经营者将难以通过亲历亲为的形式来实现上述的平衡。这些情况下，经营者通常需要通过组织调整来保证其战略推进的有效性。

“组织”既是一种经营工具，也是一种管理工具。所以无论经营者还是管理者，都有可能使用这一工具带来系统整体或局部的变化。换一个角度，管理者其实也可能参与或直接行使经营职责。因此《大道至简》中所述的：你可以更直接地观察到“经营者”与“组织者”之间的差异。例如公司的大小股东是“经营者”,董事会通常是解决经营问题的地方；而总经理、执行经理及各个部门经理则是各级的“组织者”,经理办公会则是解决组织问题的地方。

这样来将“组织者”作为角色讨论是并不适当的——“组织”,是管理职能的一种工具而非其全部。所以《大道至简》其实是用一种极端情况来区分出了“经营角色”,使我们在EHM中的模型可以被讨论而已。

经营者选择组织工具而非其他，是有一定合理性的。首先，模型4在“方向”轴上的缺失是局部问题而非全局问题，因此通过组织工具来调适不会带来全局性的风险。其次，经营者可能并不期望颠覆正在进行中的阶段性目标，因此选择组织工具而非战术手段(例如裁撤项目)相对会更为温和。

经营者需要在模型4中解决的问题是规模与细节的平衡，以使得工程角色的实施与目标、方向的设定一致。正是这一需求导致架构角色的引入，因为“架构”角色本质责任与这一需求不谋而合。

所谓架构，包含了“范围”与“联接件”两个方面。“架构”一词源于建筑学，中文所说的架构，意指“间架结构”。其中的间、架，在建筑中是对房屋规模的度量用词；结、构则是指建筑的关键位置上的技术构件。

但是，如果我们将架构角色锁定在“某种描述范围与联接件的文书”这样的产出上，无异于将架构角色当成技术工人：使用某些工具，生产某种产品。我在这里讨论"架构"一词的本义，是强调应从本质特性上来看清架构角色所关注的方面。而这些方面，又与在现今软件工程中经营角色对软件系统的关注，例如问题的识别与控制等等存在一致性。正是因为这种一致性，由架构角色来介入模型4中的“方向”这个轴线所指代的领域，才会成为一种组织选择的必然，