架构框架解决方案

作者：kaiyun体育官方人口

2009/12/24 17:02:01

本文探究对于当今软件开发组织来说成熟且日益重要的角色，企业架构（enterprise architecture，EA）框架。开始，我们将企业架构规程与解决方案架构和业务架构规程进行对比，在这期间将它们与 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 所示。

图 2：业务架构领域的组件及主题

可以证明过程及信息组件是业务架构活动的焦点，因为（其中）它定义、描述并且把业务过程和组成组织业务模型的支持结构进行分类。该组件还包含了大量相关的主题，例如，可用性和可访问性。当然，每个组织都有不同的业务过程、结构和工作流，等等。同样的，一个组织可能在其业务过程模型中会拥有使其在竞争中具有优势的“额外内容”，而另一个组织将在此领域内挣扎。

组织组件是关于工作实践的结构和设计，以及组织的运作风格。该组件所处理的主题包括组织结构、业务产生的产品和服务，业务单元及其位置，等等。

业务性能是拥有定义并量化组织效率和有效性的主题的面向管理的组件。它关系到生产力、业务风险，及属于此处的其他相关的主题。

企业架构领域

在我讨论企业架构之前，我想要大致描绘一下该规程要解决的问题。大部分现有的实现方法包括创建针对明确的业务需求的解决方案所用的技术。然而，这些方法与业务需求为什么及怎样出现不是直接相关的。相反，相对于组织可能拥有的其他需求，它们关注于对已知需求的响应的相对重要性。举例来说，让我们考虑 RUP。RUP 交付过程想当然地做出开始实施的决策，但没有一个 RUP 工件与评估解决方案的实现是否满足业务需求的紧急性直接相关。

对比 RUP 和其他主要关注于实现的规程，企业架构领域原则上的关注点是企业范围内的业务需求的识别、规范，及优先级划分。企业架构框架环境内所讨论的观点和所绘制的模型解决了大量当前及潜在的问题。

EA 路线图可能比单路线解决方案包含更多内容（如图 3 所示），这可能会形成多个、同时的实现。

图 3：企业架构路线图示例

展望企业的未来

可见，企业架构开发协会（Institute for Enterprise Architecture Development ，IFEAD)概括出了企业架构规程的重要指导原则：“没有战略眼光，就没有 EA。”换句话说，今天的企业架构关系着明天的业务系统。此原则的一个重要方面是企业架构是根据一个战略性的企业眼光结合业务和技术要素的整体规程（参见图 4）。

图 4：企业架构领域的要素

现在正是时候

尽管企业架构概念已经出现了二十多年，但是 EA 规程最近刚获得动力。这可以归因于大多数行业中各种规模的组织中环境变更的加剧。业务灵活性，特别是技术基础架构及时响应变更的能力已经达到决定性的重要程度。

导致人们对企业架构规程更加欣赏的另一个因素是，在美国及其他地方，近年来政府对企业更加严格的遵守某些规章制度的气候，这不仅推动组织提高它们的责任心及报告实践，还适度使组织中的每个业务过程更好的符合遵从性。

作为对 EA 原则更高关注的结果，许多健壮的企业架构框架最近出现了，例如 TOGAF。

相同的主题，不同的观点

企业架构规程实际上与解决方案架构规程涉及同样的主题，但是视点不同，并且所处环境明显不同。EA 环境是全局性的，其视点是组织化的，而解决方案架构是具体到实现的。

同理，企业架构规程大于解决方案架构领域的超集。解决方案架构主题（参见图 1）要应用于解决方案的实现，但 EA 主题（如图 5 所示）主要用于企业分析、计划和架构治理。举例来说，对于解决方案架构师来说，“Applications”主题域涉及到一组链接的组件和类，然而，对于企业架构师来说，就需要一个运行一组业务过程或提供大量服务的节点。

注意，来自解决方案架构规程中的一些主题（低层次的）不含在 EA 的范围内，而许多附加的（大部分是更高层次的）主题加入了。还要注意的是关键的业务架构主题完整地包含于 EA 规程之中了。