主题
企业架构
企业体系结构简介
作者：Gabriel Bechara
归档文章 — 最初于 2006 年 3 月发表在 BEA Arch2Arch 上
企业体系结构 与业务优化实践有关，后者用于解决企业体系结构、绩效管理、组织结构和流程体系结构等问题。它包含对组织的流程、信息系统、人员和组织业务单元的当前及将来的结构和行为的描述，以确保能够符合组织的战略发展方向，可见，企业体系结构的概念超越了信息技术的范畴。
企业体系结构与信息技术紧密相关。在本文中，我将描述 SOA（面向服务的架构）环境中的一种简化的、自上而下的企业体系结构，重点关注旨在更好地协调业务和 IT 的信息技术。
我将介绍：
- 自上而下的企业体系结构方法的不同关注点
- 企业体系结构的目标
- 方法论概述
- 与 BEA SOA 6 域模型的关系
通过本文，您将很好地了解由业务策略驱动的自上而下的企业体系结构方法、该方法的优势以及相关的组织方面的考虑事项。
自上而下的企业体系结构方法的不同关注点
在从业务到 IT 的自上而下的方法中，可以在不同的规划中分离业务和 IT 的不同关注点，进而在二者之间奠定公共基础。与业务相关的规划被称为 业务流程规划，与 IT 相关的规划被称为 应用规划，而二者之间的规划 — 该方法中最重要的部分，因为这种方法旨在更好地协调业务和 IT — 则被称为 功能规划。要描述硬件、网络、操作系统、应用服务器和数据库，可引入 技术规划 的概念。我无意详细描述技术规划，因为我的主要目的是推荐一种方法来通过公共的基础更好地协调 IT 和业务。
图 1 说明了这些规划以及它们之间的相互关系。我将对此详细加以介绍。
图 1. 自上而下的企业体系结构方法的不同关注点
业务流程规划
此规划侧重于业务战略环境中的业务流程。企业架构师从业务战略定义的业务需求入手，与组织中的不同业务线紧密合作，从而为大型企业业务流程建模。例如，企业架构师可以使用 AquaLogic BPM Designer 在设计层面实现这一目的。这将有助于架构师理解企业内全局的主要流程，并将通过让更多的业务代表参与进来以推进这种方法的实施。使用 AquaLogic BPM Designer，业务分析师可以模拟业务流程，从而度量对流程进行反向工程时发生的优化。业务流程规划归业务所有。架构师的主要任务是捕获业务需求并识别可由组织内不同业务线使用的通用业务服务。
以银行业务环境为例，首先要先设计各项银行业务（如贷款、进/出口操作）的流程。这两项银行业务具有完全不同的流程，但会共享一些通用服务。通过在组织层面设计流程识别通用服务。在某种程度上，应该能够在不同的流程中重用授权系统和会计系统，如开具信用证 (LC) 的流程或贷款批准的流程。这两个流程应该使用共同的授权服务和共同的会计服务。
功能规划
设计好组织的重要流程之后，即可确定主要的功能块。其中某些功能块将提供可在不同业务流程中重用的业务服务。这些业务服务是理想的候选 SOA 构建块。这些服务应该具有可重用和重组的必要功能，以便提供业务所需的敏捷性。在选择这些功能块以及需要在功能块间共享的数据时，业务线应该为企业架构师提供个所必需的业务知识，以便整个组织都能重用和理解规范的数据模型、域 UML 模型和数据信息库。这之后，需要在规划中加入业务。
这种通用的做法应该会带来可在整个组织内共享的通用语言和通用分类法。通用实体和通用域模型的定义方式使其在组织内具有统一的含义，并可在不同业务线中重用。这个规划就像是城市规划：将功能构建块组织成与组织内不同业务线相关的区域和地带。
通用语言将有助于重用功能构建块以及在这些块间共享的数据。规范模型应该在 企业信息库 内共享。管理考虑事项应该定义设计、访问、验证和修改这些模型的方式。我将在本文后面的部分对这些考虑事项详加介绍。
回到银行这个例子，在此类机构中，可能有一条业务线用于处理支付、外币兑换和证券，另一条业务线处理贷款，第三条业务线处理进/出口操作（如信用证 (LC) 和托收），以及一条水平的业务线用于处理授权、会计、报表以及风险管理。如果用城市规划做比喻的话，每条业务线都可看作一个区。
进一步观察进/出口这条业务线，会发现分别与 LC 和托收相关的功能块。而代表 LC 的功能块还可以细分为 LC 可能提供的不同服务。这个块应提供开具 LC、修改 LC、使用 LC和 偿还 LC 之类的功能（或服务）。这些都是 LC 块的业务服务。这些服务将依赖于由授权块、会计块和支付块提供的功能。
授权块将基于客户的状态为客户提供授予信贷额度的服务。授权块可能依赖于风险管理块的功能。LC 功能也将使用由会计块和支付块提供的服务，而支付块则将使用会计块和授权块的功能。
对功能规划的描述采用业务术语，并加以细分以使其能够映射到应用内的应用程序和服务。在银行示例这个环境中，在组织层面上重用会计服务和授权服务。
确定了这些功能构建块之后，还需要定义这些块之间的通信，这意味着定义了规范的数据模型。这个规范模型可使用 UML 模型进行描述，这就导致使用 XML 表示数据。这个通用语言应该跨整个组织共享。
在银行示例中，无论是在 LC 块还是贷款块使用，账户都是一样的，客户也是相同的。账户和客户是在组织内共享的业务模型中定义的实体。这些实体由两个规范模型表示，一个用于账户数据，另一个用于客户数据。这些模型将在整个组织内共享。它们可通过作为组织构建块的一部分的通用服务进行访问。这些服务可以是 CRUD（创建、检索、更新和删除）服务，也可以是组合服务。定义规范模型的一个良好开端是参考业界标准。银行系统使用 SWIFT 标准。SWIFT 标准手册中定义的 MT 消息在业务用例使用消息的层面上定义了银行操作。这些消息可以轻松映射成可在整个组织内使用的 XML 消息。最大限度地遵循标准将有助于将单个组织内使用的业务操作扩展到不同个组织间使用的 B2B 操作。
Quinton Wall 撰写的了解 SOA 中的服务生命周期：设计时和了解 SOA 中的服务生命周期：运行时这两篇文章中涵盖了有关服务设计、建模和运行时考虑事项的更多信息。
定义了这些块中使用的功能块和数据模型后，这些资产应该能由企业信息库中的不同业务线访问以便重用。BEA AquaLogic Enterprise Repository 可用于共享企业信息的系统资产。
Printer View