在从EHM模型推进到图0-8所示模型的过程中，我们让经营角色介入进来，又渐渐地将这个角色分离出去，代之以“系统架构”这样的领域与角色。以下我们把工程视图模型简称为VEO模型(View of Engineering Organization)。在开始后续的讨论之前，我们需要再次强调引入架构角色的本意与背景。

(1)目标。架构角色围绕一个阶段目标，以及该目标在规模与细节上的投影工作。这是能将架构角色与其他两个角色纳人同一个系统(具体的工程实施)来讨论的前提。

(2)方向。架构角色在方向领域上与经营者(或更宽泛地称为架构需求的提出者)保持一致，了解阶段目标与方向之间的关系，并通过架构产出、指导、推进和实施等一系列工作来把握这种关系。

(3)范围与联接件。架构的主要产出是对范围进行的约束，对目标的关键构件之间的联接件的设定。并且还需要在实施过程中调适架构最初的约束与设定，平衡由时间、信息等因素带来的目标与方向之间的衍变。

我曾经说“记事本○这样的软件不需要架构”,这句话并不对，因为彼时我不能将记事本作为一个系统来看待。事实上“系统”这个词并没有“大小”的限定条件，就如同说“人”这个概念本身没有“群体”的限定条件一样：并不是说一群人是人，一个人就不是人。

从组织的视角来看一个系统各个独立的部分，这些部分都可称为角色。yipindushu.com

【系统中的不同角色】

在(系统)架构角色的眼中，目标是一个系统。所以记事本既然是一个系统，则也可以有工作在该系统上的架构角色。记事本系统与整个桌面操作系统之间仅存在复杂性的区别，这在VEO模型上体现得尤其明显(就我们这里要讨论的话题来说，图0-9中规模的绝对大小是没有数值意义的)。

【模型6:不同规模的系统在VEO模型上的映像】

现实的工作中，我们没有为记事本的开发指派一个“系统架构师”的原因是：它的规模与技术复杂度一个人就可以控制?。但这并不是说，这个“个人”在软件开发过程中就没有过规模、细节、方向这三个领域上的思考。简单地说，我们在很小规模①在这里以及后文的讨论中，我是特指Windows中的notepad.exe这个记事本工具软件。

②我并不清楚在Windows开发团队中，记事本软件是不是由“一个人”来开发的。但大多数人认为类似这样规模的产品，是可以由一个人完成的。

的软件开发中，可能是由一两个开发人员同时负担了管理、架构、实现三类职责而已。所以——我们要讨论的是“角色”,而非某个职务或具体的人。

以架构为例，我们讨论的不是“谁来做架构师”的问题，而是“架构这个角色应该起到什么作用”的问题。首先，最迫切的问题是要弄清楚项目目标，这是必然的。在这个目标被作为一个产品指派到某个项目组之前，架构师就应该清楚在更大范围的“系统”中，当前这个目标的真实意图。例如记事本从Windows 1.0开始就在系统中存在，有着诸如此类的原始设定：□作为对DOS等早期命令行系统中的行文本编辑器的替代；□是操作系统缺省的文本处理工具。

而在这个目标之下，规模问题是项目管理这个角色所主要关注的，更确切地说：规模问题的核心是项目目标的投入与产出。

所谓投入，包括时间、人力、资金、设施等，项目管理者必须考虑项目在各个阶段的投入情况并确保它在一个可控的规模。所谓产出，是指项目目标(例如产品)的特性及其细节，项目经理必须保证这些特性是在一定边界上增减的，是可测试与交付的。

这看起来与质量的三要素，以及软件工程的体系层次等模型有隐约的相似，这些用来阐述软件项目或软件工程的传统模型，是从工程质量保障或实现方法的视角来考察工程的。然而关注质量平衡或关注实现层次，仅是在规模控制中的手法，是部分的要件而非其全部，例如在《大道至简》第三版中，就将做得“更多”或“更好”等等都作为规模失控的一种形式来看待。