亲亲宝宝

为何业务体系结构非常重要？

在本系列的第 1 部分中，我们了解了软件体系结构的基础知识。在此部分，我们将了解一种特殊的体系结构类型，即业务体系结构。我们将讨论为何除了 IT 级别的体系结构外还要在业务级别具有体系结构，我们还介绍名为组件业务建模（Component Business Modeling，CBM）的 IBM® 业务体系结构相关技术。

定义业务体系结构

Open Group 体系结构框架（Open Architecture Group Architecture Framework，TOGAF）将业务体系结构视为企业体系结构的一半，而将另一半定义为软件体系结构（后者也称为 IT 体系结构，包括数据、应用程序和技术要素）。（有关“软件体系结构”的 Wikipedia 条目的链接，请参见参考资料。）

业务体系结构的核心组件包括：

* 产品战略
* 治理
* 人员组织
* 业务信息
* 关键业务流程

与软件体系结构类似，业务体系结构遵循所定义的体系结构原则，并使用参考体系结构和体系结构框架。（有关卡耐基梅隆大学对此的更为详细的介绍，请参见参考资料。）

请注意：以下部分描述的活动也可以视为其他规程的一部分，如业务战略或业务建模。

业务体系结构的重要性

业务体系结构之所以重要，有多方面原因：

业务体系结构提供理解透彻的业务路线图。业务体系结构是以业务原则、策略和目标为输入并定义业务流程、人员或信息等要素的规程。企业可通过业务体系结构了解自己目前所处的位置，定义其目标，更为重要的是，定义实现目标的路线图。从这个方面而言，甚至在考虑对 IT 的好处之前，业务体系结构对业务来说已经非常重要了。

图 1. 业务流程更改的顺序

业务体系结构可提高 IT 响应能力。业务需要能够识别更改并快速对其进行响应。所标识的业务更改和所标识、评估和实现的必需的 IT 更改之间经常存在无法接受的延迟。业务体系结构在寻找通过提供业务和 IT 之间的联系来减少此延迟的方法。因此，这样会增强企业的 IT 对业务需求的响应能力，如 IBM 随需应变业务中所述。（有关更多信息，请参见参考资料部分。）

业务体系结构可确保 IT 系统相关。通过首先考虑业务体系结构和描述与软件体系结构的联系，可以确保二者之间不存在差距。也就是说，通过注意软件体系结构如何处理业务需求（战术和战略两个层面上），可以确定两件事：所有 IT 系统功能可追溯到某个业务需求，而所有对 IT 系统自动化的业务需求都得到了满足。业务体系结构的主要目标是展现软件体系结构的业务价值。

业务体系结构可提高 IT 灵活性。或许业务体系结构唯一最重要的元素是，通过在业务体系结构（业务视图）中对软件体系结构（IT 视图）进行分组，可创建更能适应业务变更的 IT 系统，而不会对这些变更起到抑制作用。因此，我们不仅能够更为方便地了解哪些软件组件受到业务变更的影响，而且所产生的变更对总体软件体系结构的影响可能会更小，如图 2 中所示。

图 2. 业务和 IT 之间的映射可提高灵活性

组件业务建模

IBM 组件业务模型（Component Business Model，CBM）是一种战略方法，允许组织将重点放在核心业务竞争力上（使得企业从竞争者中脱颖而出的部分），了解如何使用资源，从而更好地保持业务和 IT 之间的一致性。

组件业务建模对 SOA 非常重要，其中心是与业务保持一致的服务。它允许将企业分解为属于不同可靠性级别（或责任级别）和业务竞争力（业务领域）的业务组件（或功能区域）。每个业务组件提供或使用其他服务使用或提供的业务服务（行为的定义）。CBM 讨论战略业务体系结构元素，如目标、关键绩效指标 (KPI) 和业务流程。（有关 CMB 的更多信息，请参见参考资料。）图 3 以图形的方式说明了其可能的情况，显示了 DVD 出租公司的 CBM。

图 3. DVD 出租公司的 CBM 图
图 3. DVD 出租公司的 CBM 图

将所有模型的好处收入囊中：引入 MDD

模型驱动开发（Model-driven development，MDD）也称为模型驱动的工程（Model-Driven Engineering，MDE），是一种基于模型和转换的软件工程方法。

MDD 使用元数据、元模型、抽象级别、自动化、观点、透视图、统一建模语言（Unified Modeling Language，UML）等建模语言和 Eclipse Modeling Framework (EMF) 等建模框架来提高在软件开发流程中应用的自动化。（请参见参考资料中提供的 SOA 术语指南，以了解关于这些术语的更多信息。）基本理念是，MDD 规定在整个软件开发生命周期中在各个抽象级别使用一组模型作为主要的工程构件，并努力使用这些模型中的精确度来驱动可从较高级别的模型生成较低级别的模型的自动转换流程。图 4 对此转换进行了演示。

Rational® Unified Process (RUP) 将模型描述为“从特定角度提供完整系统描述的系统抽象表示形式或模拟”。

此外，Object Management Group 的模型驱动的体系结构（Model-Driven Architecture，MDA）将转换定义为“将系统的一个模型转换为同一个系统的另一个模型”。

图 4. 示例 MDD 转换
图 4. 示例 MDD 转换

MDD 的好处

现在我们已经了解了为何软件体系结构和业务体系结构都非常重要，接下来让我们讨论一下通过将 MDD 应用到这些体系结构所带来的进一步的好处：

* 透视图。尽管软件架构师应该全面了解各个领域和模型，但其他大部分角色都更为专门化一些。例如，业务分析人员了解业务流程或用例，但对设计模型并不了解。模型以需要理解此模型的一组用户为目标受众，相同的系统可以表示为完全不同的模型，供不同的人员使用。模型需要准确和完整，而且还需要提供抽象，而正是由于这个原因，我们建议使用图形建模方法。这一点在软件体系结构的设计模型方面特别重要，在此领域建议使用 UML 和专用的 SOA UML 配置文件。
* 自动化与转换。使用 MDD 可在质量和效率上都有所提高，因为较低级别的抽象是从较高抽象级别的模型得到的，而低级别的抽象最终将用于生成代码。例如，SOA 服务模型可以从其 UML 形式转换为 Web 服务描述语言（Web Services Description Language，WSDL）和 XML 模式定义，也可以转换为 Java™ 之类的代码。还存在从较低抽象级别到较高抽象级别的反向转换。例如，从代码到设计的反向转换将允许设计人员验证开发人员对其设计的遵从程度。请注意，此类转换功能应该包括在计算机辅助设计（Computer-Assisted Design，CAD）工具中，如 Rational Software Architect。工具之所以能够对此予以支持，是因为其实现了建模标准，如 OMG 的 UML 和 MDA。
* 可跟踪性。从较低抽象级别到较高抽象级别的可跟踪性可确保较高级别的模型中的“需求”在较低级别模型中得到了处理。例如，对于 SOA，务必能够从概念服务跟踪到从其中标识的元素（如业务活动），或者务必从设计决策跟踪到驱动决策的需求。这样做，还允许分析需求（或更高抽象级别的模型）中的变更对所有低级别抽象模型的影响。

利用现有资产

重用对软件体系结构和 SOA 都非常重要。重用可以有很多形式，包括软件开发构件重用（所有抽象级别）、运行时服务重用和经验及最佳实践重用。

模式

在本系列的后续部分中，我们将更为详细地讨论体系结构风格和模式，更为具体一些，就是作为体系结构风格的 SOA 和处于 SOA 核心的体系结构原则。现在我们将讨论通过模式进行的经验与最佳实践重用。

模式是上下文中给定问题的经过验证的解决方案，通常使用名称、上下文、问题和解决方案描述进行规定。更为重要的是，可以使用在给定平台上实现模式规范的模式实现对模式进行自动化。这就使得使用模式的方法非常具有吸引力，而且非常强大。Rational Software Architect 是对自动化模式和基于模式的工程（Pattern-Based Engineering，PBE）提供了全面支持的工具的一个例子。（请参见参考资料部分提供的指向 IBM developerWorks 的链接，其中提供了一个专门讨论模式解决方案的区域。）

模式与体系结构相关，可能出现在所有抽象级别上。这就意味着您可以获得业务体系结构模式、高级别设计模式、低级别设计模式和实现模式。

所有这些类型的模式的重用都能在整个企业内提高软件质量，减少风险、提高效率和提高互操作性。

设计模式可能是刚刚提到的模式类型中最广为人知的一个。例如，您可能比较熟悉 Gang of Four (GoF) 模式。对于 SOA，在本系列的后续文章中，我们将讨论软件体系结构的一组具体的模式。CBM（前面曾提到）自己就拥有涵盖一些常见行业的业务体系结构模式。

参考体系结构

参考体系结构是特定领域（例如，电信行业的数据中心或呼叫中心参考体系结构或参考体系结构）的经过验证的体系结构。它是已经创建的完整体系结构。参考体系结构遵循一个或多个体系结构风格，通常由体系结构模式组成。例如，分层体系结构、模型-视图-控制器（Model View Controller，MVC）、客户机-服务器甚至 SOA。参考体系结构处理某个领域的功能和非功能需求，涵盖了整个体系结构。例如，电信参考体系结构可能会特别注意消息有效负载。通过参考体系结构，可以重用经过验证的体系结构实践，从而提高您的体系结构质量。一个缺点是，它们非常完整，因此规模很大，可能无法用于较小的项目或系统。

在第 1 部分中，我们介绍了 SOA 参考模型 SOA 解决方案堆栈 (SOA Solution Stack)，其中定义了正确地确定面向服务的解决方案的体系结构所需的层次和构建块。

现有软件资产

SOA 的一个关键成功因素是能够在体系结构中重用现有资产。在此上下文中，现有资产指在生产环境中运行的并未采用面向服务的方式的现有软件（遗留应用程序，下一部分将讨论现有软件开发构件）。SOA 转换项目允许企业踏上 SOA 之旅，并逐渐转换为服务扮演重要角色的企业。其中通常涉及位于企业核心位置的主要软件资产（遗留应用程序）的面向服务化。对于 SOA 转换项目，在进行转换前，有必要对可能在体系结构中扮演重要角色的资产进行标识，而这是在现有资产分析（Existing Asset Analysis，EAA）期间进行的。现有资产可以包括 IBM CICS® 或 IMS® 事务，或者 COBOL 程序。这些资产可能已经运行了多年，属于企业的主要优势。应该在 SOA 中对其利用。例如，它们可以作为体系结构中的服务公开（包装）。分析级别技术（也称为自底向上方法）可用于发现对特定 SOA 项目有意义的资产。例如，如果 SOA 项目所处理的是保险索赔业务流程，则可能有以索赔数据为中心的程序或事务可利用。请注意，在此区域中 IBM WebSphere® Studio Asset Analyzer 之类的分析工具可帮助从巨大的生产环境中发现相关信息。还要注意，您不应该盲目地将现有资产作为服务公开，而应该在标识服务时遵循经过验证的流程，如 RUP 面向服务的建模与体系结构（Service-Oriented Modeling and Architecture，SOMA）。

软件资产管理和基于资产的开发

基于资产的开发（Asset-Based Development，ABD）是一个大概念，本身就足以用一系列文章予以讨论。不过，在此部分中我们将仅仅介绍其背后的理念。

ABD 是一种基于使用软件资产构建解决方案的软件工程方法。在此上下文中，资产不是上面所定义的现有资产，而是任意抽象级别的任何类型的软件开发资产，包括设计模型、模式和代码实现。尽管人们已经讨论了 ABD 多年，咨询公司一直梦想能够成功采用基于资产的模型来替代基于重复工作的模型，但成功采用 ABD 的组织并不多见。这不仅是因为文化和人们习惯于自己重新做而不愿重用他人的工作，但更多的是因为缺乏治理和平台支持。幸运的是，IBM 等公司正在通过新产品和流程处理此问题，如 IBM Rational Asset Manager 和 IBM Rational 资产治理与基于资产的开发 (Governance and Asset-Based Development) 流程。资产支持人们仅仅创建需要创建的内容，而尽可能重用在其他地方经过了验证的东西。

ABD 提供了整个组织内的一致性（由于使用了相同的资产，因此相同的需求导致相同的设计决策）。ABD 和 MDD 并不是互斥的。完全相反：将模型打包为资产供其他人重用的做法是非常有效的。（有关 Rational Asset Manager 产品的更多信息，请参见参考资料。）

服务注册中心与存储库

SOA 环境的两个主要组件，服务注册中心和存储库通过在整个生命周期中支持服务来执行所配备的治理。

其主要特征之一是，它们支持服务重用。尽管大部分公司都没有实施很多 SOA 项目，但 SOA 的承诺只能在之前开发的服务能供将来的项目重用的情况下实现。通过前瞻性体系结构风格的应用，将需要进行大量的工作来确保这些服务可重用。

软件架构师、设计人员和实现人员应该考虑在确定体系结构、设计或实现 SOA 解决方案时探索服务注册中心的使用（开发时）。服务注册中心提供服务规范与描述、使用策略、依赖关系和交互等信息。如果必须开发服务（如果不存在），则软件架构师应考虑将其提交（发布）到企业的服务注册中心。另外，面向服务的体系结构可以在运行时使用注册中心和存储库，因为它们可支持与端点选择、可用性管理和策略执行等的有效动态服务交互。存储库还提供了管理组件，以帮助进行服务版本控制，确保以最优的方式使用服务和满足服务级别协议。（有关 IBM WebSphere Service Registry and Repository 的更多信息，请参见参考资料。）

分享这篇文章……

digg 提交到 Digg
del.icio.u 发布到 del.icio.u
Slashdot Slashdot 一下!

总结

在本文中，我们了解了业务体系结构、模型驱动开发和可重用资产。我们了解了业务体系结构如何提供路线图，提高 IT 响应能力和灵活性，以及帮助确保 IT 系统与业务保持一致。另外，我们还了解了 IBM Component Business Modeling (CBM) 技术和模型驱动开发，并讨论了其在透视图、自动化和可跟踪性方面的好处。最后，我们了解了 SOA 和体系结构上下文中的可重用资产，包括模式、参考体系结构、现有资产以及资产与服务注册中心。