集成的驱动力

    根据前面的讨论，这三个系统中的每一个都被创建来服务特定的需求， 同时他们也都有缺乏对他们侧重领域之外的更广适应性的缺点。在许多组织里，关于 Zachman 框架我所注意到的一点是，表面上它是一个每个人都称好的巨大海报，但是没有人使用它。我将这一点归结于这样一个事实：与其它任何静态框架一样，Zachman没有说明如何处理工件引入。另一个实用方面的缺点，通常被认为是优点，是框架缺少标准的符号。

    更普遍的是，应用 RUP 的问题在于它作为软件开发过程的主要优势，然而这一点对构架师和开发人员等人是有吸引力的，但来自其他领域的人不会购买它作为主要技术。例如，项目经理会选择其他的方法(比如，RUP 项目管理规程基于的项目管理知识体系(PMBOK))，并将 RUP 作为这些更有利的方法的一个附属物。相反，企业架构师通常选择 Zachman。

    UML 在角色依赖关系上的问题稍微少一些，因为与 RUP 不同，它并不提出角色，因此没有方法映射的需要。尽管如此，过程和框架的独立也限制了UML的有效性。对UML来说幸运的是，尽管许多组织使用其他像实体关系图(ERD)和业务进程建模符号(BPMN) 这样的结构方法和符号，但UML仍得到了普遍认可。

    在尝试表达这些局限性以及为三种方法找到的共同的应用的过程中，要再一次注意的是它们被创建以表示同一个领域的不同的问题(信息系统构架)，而且它们之前的目标设置实际上没有功能重迭(见图4)。对企业和项目构架师来说这都是好消息，因为那意味着 UML、Zachman 和 RUP 可以共同使用以产生更全面的企业价值。

    关于交叉功能适用性的思考

    RUP已经使用UML和其他像ERD这样的可视化建模语言以及像用例、业务角色和验收测试这样的非可视化建模产品。Zachman 框架并不与一个符号或一个过程结合，也不他们的选择加以限制。两种技术可以非常好的使用的情况也是不同的。例如，由于其固有的不适应性，在开发环境中使用 Zachman 是值得置疑的。同样地，使用 RUP 作为一个企业信息构架的基础也未被证明是合理的。

    在各自的生命周期定义之间的相似之处(比较上面的图2和图3十分明显)有助于解释这样一事实：RUP 和 Zachman 都是受工件驱动的并继承源于以构架为中心的设计原理的结构。明显的相似之处意味着假定企业系统和项目的复杂性不断增加，两个过程可能会互相强化。

    这样已经在指出三种方法的不同之处方面进行了相当多的阐述，我将考虑正在探讨的方法在什么地方可以互相补充。