应用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)。

    这一应用在过去已经尝试过很多次，而近期大多是在企业统一过程(EUP)环境中实现的。 10