集成的驱动力
　　根据前面的讨论，这三个系统中的每一个都被创建来服务特定的需求， 同时他们也都有缺乏对他们侧重领域之外的更广适应性的缺点。在许多组织里，关于 Zachman 框架我所注意到的一点是，表面上它是一个每个人都称好的巨大海报，但是没有人使用它。我将这一点归结于这样一个事实：与其它任何静态框架一样，Zachman没有说明如何处理工件引入。另一个实用方面的缺点，通常被认为是优点，是框架缺少标准的符号。
　　更普遍的是，应用 RUP 的问题在于它作为软件开发过程的主要优势，然而这一点对构架师和开发人员等人是有吸引力的，但来自其他领域的人不会购买它作为主要技术。例如，项目经理会选择其他的方法(比如，RUP 项目管理规程基于的项目管理知识体系(PMBOK))，并将 RUP 作为这些更有利的方法的一个附属物。相反，企业架构师通常选择 Zachman。
　　UML 在角色依赖关系上的问题稍微少一些，因为与 RUP 不同，它并不提出角色，因此没有方法映射的需要。尽管如此，过程和框架的独立也限制了UML的有效性。对UML来说幸运的是，尽管许多组织使用其他像实体关系图(ERD)和业务进程建模符号(BPMN) 这样的结构方法和符号，但UML仍得到了普遍认可。
　　在尝试表达这些局限性以及为三种方法找到的共同的应用的过程中，要再一次注意的是它们被创建以表示同一个领域的不同的问题(信息系统构架)，而且它们之前的目标设置实际上没有功能重迭(见图4)。对企业和项目构架师来说这都是好消息，因为那意味着 UML、Zachman 和 RUP 可以共同使用以产生更全面的企业价值。

　　图4：UML、RUP 和 Zachman 框架的功能重迭    

    关于交叉功能适用性的思考
　　RUP已经使用UML和其他像ERD这样的可视化建模语言以及像用例、业务角色和验收测试这样的非可视化建模产品。Zachman 框架并不与一个符号或一个过程结合，也不他们的选择加以限制。两种技术可以最佳使用的情况也是不同的。例如，由于其固有的不适应性，在开发环境中使用 Zachman 是值得置疑的。同样地，使用 RUP 作为一个企业信息构架的基础也未被证明是合理的。
　　在各自的生命周期定义之间的相似之处(比较上面的图2和图3十分明显)有助于解释这样一事实：RUP 和 Zachman 都是受工件驱动的并继承源于以构架为中心的设计原理的结构。明显的相似之处意味着假定企业系统和项目的复杂性不断增加，两个过程可能会互相强化。
　　这样已经在指出三种方法的不同之处方面进行了相当多的阐述，我将考虑正在探讨的方法在什么地方可以互相补充。
　　应用1：要为企业提供通用的符号，可以考虑 UML
　　通常情况下，为响应在管理上的“call for action”，组织直接将注意力投向 Zachman 来为企业的IT系统驱动“未来的”模型，或者针对一个非同小可的业务转型项目。在类似这样的场景中，架构师们将分散在跨越储存库的系统知识资产汇集起来(这实际上是件正确的事情)只是为了了解到他们的前辈们生产出的工件并不能很好的适合 Zachman 结构。不适合的普遍原因是大多数现有的工件是至少几个不同方面的混合(还记得 Zachman 的列吗?)，另外一个原因是工件总是被使用不同的符号进行创建。而在大多数情况下，对工件进行式样翻新是不可行的，这些“经验教训”是与通用符号的重要性相关的。您是否也正在思考我所考虑的事情?那好—— UML 也许能够帮助您解决这一难题。
　　Zachman 不限定也不推荐使用 UML 或者其他任何符号。然而， RUP 要求使用 UML。既然应该避免使用多样的符号，那么后面的论述将着重展示一个利用 UML 作为企业和项目架构的通用符号的情况。
　　应用2：使用 UML 将 Zachman 和 RUP 结合起来
　　在大多数组织里，当系统可能以某种形式存在很长时间的时候，例如 UML 起码已经有大约十年的时间，缺少标准的符号是可以理解的。即使在相对现代化的系统环境里，UML 也可能由于文档设计的时间限制和缺少必要的技巧设置等 原因没有被使用。
　　除了对于分析和设计需要良好的建模语言外，两个因素中任何一个都可能引发组织——一个RUP项目或者企业架构现代化成果——对 UML 的需要。任何一个理由都很好，因为它允许组织启用 UML。尽管如此，RUP 项目产生的结果可能要比从未来重用的角度而由构架现代化工作产生的结果更重要，因为RUP项目趋向于产生更加细化而且更加容易跟踪的工件。RUP方法的另一个优点是，通常只生产真正有价值的工件。从另一方面来看，构架现代化成果可能会产生很多实用价值很小，而且带有不确定性的UML图。事实上，这种情况可能会影响组织对UML的认可以及它在组织中的未来。
　　通过RUP驱动系统交付项目将UML应用到组织之后，它的用途可以扩展到以 Zachman 为基础的企业构架，没有减少它的需求的风险(见图5)。

　　图5：UML 连接 RUP 和 Zachman 框架

　　这一应用在过去已经尝试过很多次，而近期大多是在企业统一过程(EUP)环境中实现的。
　　应用3：从一开始就使用 UML
　　以我的经验来看，无论是为组织引入 RUP 还是 Zachman ，如果 UML 已经在组织中被使用，成功的可能性更大。图6 试图通过描述三个技术之间的依赖关系解释这一点。

　　图6：UML、RUP 和 Zachman 框架之间的依赖关系   

    正如我上面所陈述的，Zachman 和 RUP 都依赖 UML。RUP 专门由 UML 驱动，而符号未知的 Zachman 依赖其实现符号。UML可被证明是 Zachman 使用的最好符号，因为它不依赖其他方法，因此可以作为 RUP 和 Zachman 的出发点。此外，即使以后您决定不使用 RUP 或者 Zachman，UML 仍是一个十分有用而且易于理解的可视化语言，可用于全面分析、解决方案的分析和设计以及提高团队交流。
　　应用4：和 Zachman 一起学习 RUP(或者相反)可能更加容易

　　学习RUP需要理解它的结构和规程是如何服务于管理项目团队的。因此，学习RUP最好的办法是通过相关的项目经验或在有指导的环境中进行。为了获得这一经验，有必要在贯穿RUP生命周期的活动中扮演一定的角色。
　　正如在 RUP 实践中可以有许多 Zachman 方面可以与之并行，这样一个方法也的确帮助 Zachman 增加价值。例如，用RUP业务过程建模、用例和序列图来表示 Zachman“功能”，同样地，使用用例和UI设计来处理“人机交互”，使用类和对象图来处理“数据”。Zachman 结构的某些行与RUP 的需求驱动、递增和以构架为中心的原则是相通的，而列相当于一些UML模型和最佳实践的目标设置。例如，“如何实现”这一列重点强调处理过程，并可以与UML活动图相比较。
　　可以证明，了解 Zachman 比了解 RUP 和 UML 更简单，因为 Zachman 处理的是企业系统构架的静态视图，而不是动态模型和过程。尽管如此，学习 Zachman 的方法可能主要受益于一些 RUP 主要原则——例如，“需求驱动”、“以构架为中心”、“模型驱动”和“迭代”——的应用。我的看法是当这些原则加入到学习过程和它的实际应用时，Zachman 框架更容易掌握。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。