应用5：在 RUP 裁剪过程中，Zachman 作为辅助
在 RUP 裁剪过程中，工作的重点是在开发组织的结构上。角色、时间和职能是每一个这样的活动中要考虑的重要方面，要提出的问题包括：“在这个过程中谁来做构架建模?”“过程建模何时发生?”“什么技术应该用于用途建模?”以及“应该如何基于详细级别划分职责?”。Zachman 具有固定的结构，可能恰恰是回答像这样问题的合适的信息来源。 10
尽管 RUP 中带有对工作流程的指导，但是它可能在真实的项目里并不适用或者只是部分适用。为了帮助过程工程师处理方法上的变化，IBM Rational 已经对 RUP 做了一些专门的扩展，例如“RUP for COTS”(商业现货软件)和“RUP for Systems Engineering”。为了在裁剪工作期间挑选一个合适的 RUP 变量作为基线，过程构架师必须了解组织的企业构架的现有的和未来状态。如果组织已经为企业构架分析/计划使用 Zachman，那么产生的框架可以提供有用的线索来选择正确的 RUP 变量。例如，相应的 Zachman 结构的业务模型(第二行)里的工件集合可能意味着重点是在业务建模上(见图7)并提示密切观注“RUP for Business Modeling”变量，而在网络一栏里的更高的工件密度暗示着 “RUP for SOA”(面向服务的构架)可能的角色。
事实上，因为一些原因没有描述组织系统的工件或者没有与 Zachman 清晰的映射的情况是可能发生的。在这样的情况下，RUP 变量的选择可以围绕预期的辅助项目计划的工件分布来考虑。
应用6：RUP 项目结束后，可以由 Zachman 接替
从项目级到企业级(或者相反)转化系统工件的活动可能是十分痛苦的，因为它不能被很好地理解，也没有被很好的描述。虽然RUP部署规程有很多对将开发的系统移植到产品环境活动的支持，但是它不能涵盖围绕转换项目中创建的构架模型的活动。 11 这对RUP引入方面同样是适用的;在企业级别中，在启始和精化阶段并没有系统地讲述使用可用模型的活动。
既然RUP生命周期不包含企业构架规程，在RUP中就没有关于模型应该如何被项目接收、如何被向后转化至企业和系统被移植生产环境之后如何维护模型方面的指导。如果企业构架在RUP计划和和转化活动中被正式认可(事实不是如此)，那么这将不是上述情况。
有一个企业和项目构架师必须协同合作的局限性，Zachman 在这里要扮演一个角色——使项目构架工作具体化的框架。尽管每个组织将为连接企业和项目级别工件开发其自己独特的方法，但是一个共同的目标是将 Zachman 单元格与 RUP 的工作流和活动连接起来(见图8)。 12 不幸的是这些例子仅代表描述的一部分，因为他们只描述工件到表格的静态映射，通常不提供动态的阶段/迭代/活动事件方面的指导。
当RUP项目计划工作正在进行的时候，需要为连接工件引入一个容易操作的结构。最普遍的做法是复制RUP生命周期结构。我看见过许多设置的例子，其中文件夹相当于迭代，下面的子文件夹通过规程来组织。这种方法有明显的缺点，因为项目结构只在项目存活时有关系，当项目结束后这种关系将立即消失。
Zachman 的例子可以在这一点上产生，因为它的主要结构可能用于在信息来源和文件管理工具里建立项目配置。更简单的实现可以使用文件系统文件夹复制 Zachman 结构。如果在RUP项目完成时，工件被移至已建立的档案中来连接 Zachman 结构，那么以后的企业和项目团队可以很容易得到它们。像这样的一个投资将有益于未来的RUP和企业项目，并使得企业构架更加清晰并具有可持续性。
