在 RUP 之上扩展企业架构

 当运用 IBM Rational 统一过程®（RUP®）的项目团队拥有了问题陈述，或者确定了具体的用户需求时，团队会创建业务案例、愿景描述（Vision statement），以及其他工件中的软件需求规格（Software Requirements Specification）来生成解决方案。技术和业务团体对这些工作产品以及生成它们的活动有很好的了解。然而，我们概念化、划分优先级，并且选择哪些业务问题和用户需求需要在软件中实现所采取的方法在我们的行业中仍旧是非常有价值的过程。

    本文探究对于当今软件开发组织来说成熟且日益重要的角色，企业架构（enterprise architecture，EA）框架。开始，我们将企业架构规程与解决方案架构和业务架构规程进行对比，在这期间将它们与 RUP 进行联系。然后，我们将解释 Open Group Architecture Framework (TOGAF) 如何利用 RUP 有利地扩展企业架构集的边界，从而包含企业业务和 IT 计划、实现治理，以及其他活动。最后，我们将提出把 TOGAF 与一些其他 EA 框架结合的方法。

    对比不同的架构框架

    就企业、解决方案和业务架构框架的范围而言，就像大家普遍了解的那样，在它们之间有很多重叠。那么，它们是如何相关联的呢？

    解决方案架构

    解决方案架构框架有各种各样的形式。IT 专家们已经习惯于在信息系统开发和维护项目中处理应用、数据、技术和其他解决方案架构形式（这些常称为领域）。新的（以及全部更加专门的）解决方案架构形式，例如安全及测试，也快速地成为主流。图 1 中展示了最为广泛公认的解决方案架构领域、其主要主题和它们之间的依赖性。

 
    图 1：解决方案架构规程的领域及主题

    图 1 中展示的所有解决方案架构领域被看作是“技术性的”，因为它们的范围内包括各种技术元素，例如，软件、数据和 IT 基础架构。这些领域都是由技术人员来处理 —— 也就是那些具有系统工程、软件工程或 IT 管理背景的人。

    业务架构

    业务架构在 90 年代作为单独的领域出现了，当时许多组织接受了业务架构师角色，因为它们试图优化它们的业务过程。

    业务架构规程是关于业务的“工作范围”，并且描述它是如何运作的。虽然不是每个人都赞成在业务架构框架中应该包含的组件的内容，但是一般的共识是，过程及信息、组织和性能方面是相关联的。实质上，每个组件都相当重要，并且结合了多个主题领域，如图 2 所示。

原文转自：http://www.ltesting.net