基于项目的SOA解决方案通常采用自底向上以技术为中心的方式开发。通过这些解决方案，可实现SOA入门，并提供SOA设计和开发工具方面的实践经验，但从企业体系结构的角度而言，这样带来的好处通常很少。缺乏企业级SOA方法的组织仍然可以成功实现SOA，不过却会和SOA的好处失之交臂。

　　企业体系结构与SOA

　　回顾进行过的很多SOA客户合作项目，我发现几乎所有的客户都会想到在其面向服务的体系结构（Service-Oriented Architecture，SOA）解决方案的设计和部署中采用自底向上方法。总的说来，他们在分析现有资产、支持（或仅仅“包装”）相关项（或他们认为相关的项）以及开发服务目录来处理需求方面都做得相当不错。总的说来，通常是业务部门要求使用SOA作为体系结构模型来进行以IT为中心的集成。其积极的一面在于，此方法提供了灵活性和基本的重用，但SOA的最大的回报并非在于此。

　　在企业级实现SOA成功需要将SOA概念与企业体系结构的业务（及技术）战略及治理集成，并要支持自顶向下（及自底向上）SOA解决方案分析和设计。通过关注业务方面，将其作为SOA设计和开发不可或缺的一部分，组织就能更好地从其SOA解决方案获得实际的价值。

　　之所以有这篇文章，我的目的是希望能够增强将SOA设计与以业务为中心相结合的概念。本文并不是要作为企业体系结构或SOA设计方法方面的教程，如果您希望了解更进一步的信息，请参考参考资料部分提供的有关IBM的SOA方法的信息。

　　从项目级到企业级

　　开始之前，让我们澄清一点：在项目级别进行SOA采用工作并没有什么错，事实上，大多数企业SOA活动通常都是从恰当划定了范围的项目开始的。此外，采用企业体系结构的组织会希望通过试验实现来验证SOA解决方案。关键是要通过项目/试验级获得的经验，并将其推广到企业体系结构级别。

　　我在数周前与一家大型企业的首席企业架构师进行了一次有意思的交谈。尽管最初讨论的是SOA的技术方面和SOA设计模式，但我们花了大量时间讨论SOA和企业体系结构。在客户的IT战略中，SOA是按逐个项目的方式实现的。这个以项目为中心的开发方法是目前实现SOA的大部分企业的特征——是由于传统企业文化和基于项目的资金投入模型促成的。尽管以项目为中心的SOA活动提供了一定的好处，但企业级别的SOA支持能够提供更大的灵活性和服务重用，并能促使在业务和IT之间进行更好的相关。除非SOA成为企业体系结构的一部分，并彻底进入组织的开发、设计、部署和治理方法，否则就不能完全实现SOA的最高回报。

　　在企业级别成功实现SOA（及后续的其他成功）能带来更多的好处，包括快速适应市场动向、缩短新解决方案的上市时间、提供与业务需求的联系以及减少长期IT成本。2006年进行的IBM Institute of Business Value调查可为这些结论提供支持。

　　另一方面，项目驱动的SOA实现面临的一个挑战是，对解决方案提升，使其不仅在一个服务调用集合上工作。通过在企业体系结构级别集成SOA，可使其成为业务/IT生态系统的一部分。通过此方法，可将服务作为创建新解决方案的基础，并能够提供业务需求与IT解决方案间的内聚。

　　在图1中，业务和IT战略对企业体系结构的定义和规范起到促进作用。从下游的角度而言，企业体系结构支持在组织级别以信息、应用程序和组织方面为中心进行规划。此框架实现企业级治理，并为IT解决方案设计和交付提供指导和支持。企业级别的SOA设计通常要求SOA成为企业体系结构的战略、规划和执行层的主要支持框架。

　　图1. 关注项目与关注企业的情况对比

 
　　图1 供稿人：Gil Long，IBM杰出工程师来源：IBM Global Services–EA Method Class.

　　对业务进行分解

　　为了在企业体系结构中将SOA作为战略和规范不可获取的一部分启用，通常需要了解组织的核心竞争力，以确保在业务目标和体系结构需求之间建立紧密的联系。分析企业中的核心功能的流程可以通过各种技术来完成。例如，IBM Global Business Services使用组件业务建模（Component Business Modeling，CBM）来评估组织竞争力。ibm.com提供了有关CBM流程的文献供参考。

　　从较高的抽象级别而言，CBM是相对较为直观的概念。CBM解决方案的基础是组织内核心业务组件的定义。业务组件是提供特定业务价值的人员、技术和资源的分组，能独立进行操作。销售管理和产品管理/营销以及人员、流程和技术方面（进行呈现或执行功能）都是业务组件。业务组件支持从分析和记录所使用的业务服务以及组件提供的服务的角度对业务功能和服务进行标识和设计。例如，“销售管理”业务组件可能会使用来自帐户管理的服务，并可能向其他组件（如“收货”）提供销售订单处理之类的服务。

　　派生出业务组件后，CBM允许我们根据其相对于业务的总体成本对其进行分类，并评估业务部门是否会认为这些功能具有足够的竞争力。通过对竞争力进行分组，可标识有待改进和优化的区域。图2显示了一个示例CBM工作产品，其中突出显示了标识为需要进行持续分析和设计的区域的组件。

　　图2. 示例组件业务模型
 
　　所标识的这些“重点区域”可能成为流程建模之类的SOA设计活动的输入。例如，如果我们决定帐户开立(Account Opening)是有待改进的区域，我们可以通过清楚说明与帐户开立相关的业务远景、业务目标和用户规范来确定初始需求。

　　作为此流程的示例，我们在进行与大型零售银行的合作项目时在内部使用了CBM。在分析期间，我们认识到帐户管理(Account Management)是该银行的一项核心竞争力，同时也是客户满意度和减少客户大量流失方面的一项重要决定因素。CBM活动认为，帐户开立流程可通过转换为跨银行的多个业务部门支持更为简单和标准的流程集（如服务）获益。通过交付这个增强的功能可以减少成本并增加客户满意度。通过将CBM分析与Information Warehouse信息及流程建模结合使用，此银行目前正在积极地开发企业级解决方案来跨各个业务部门对帐户开立流程进行转换。

　　CBM技术提供了一个框架，用于确定组织中的主要竞争力和从后续步骤方面提供有关组织优化的指南。此外，几乎每个主要垂直行业都可以通过IBM Global Business Services合作项目获得的CBM模版。业务组件设计流程会在业务级别定义需要改进的战略区域、将这些目标与业务服务视图进行协调并将此服务视图与IT规划结合使用，从而为企业体系结构提供输入。

　　面向服务的建模与体系结构

　　服务建模方法对获得经过优化的服务模型来实现解决方案设计非常重要。面向服务的建模和体系结构（Service-Oriented Modeling and Architecture，SOMA）技术提供了严格的有相关记录的分析和设计方法，用于确定SOA解决方案。SOMA是IBM的端到端SOA解决方案开发方法。我在此将不会对SOMA进行详细讨论，而将重点讨论以业务为中心进行SOA设计的概念。不过，Ali Arsanjani所撰写的出色文章中对SOMA进行了详细讨论。

　　SOA模型中三个基础构造是服务、服务组件（实现这些服务的实现实体）和编排服务的流（或流程）。之所以提出SOMA，主要是用于处理所有这三个构造的分析和设计工作。正如Rational? Unified Process(RUP)中所述，SOMA实际上由三个主要步骤组成，如图3中所示。

　　·服务标识：派生和定义候选服务。
　　·服务规范工作：建立并验证服务公开决策和高级服务模型的派生物。
　　·服务实现：从整体组件设计的角度确定属性并扩展高级服务模型。

　　图3. SOMA的三个步骤
 
　　尽管SOMA通过多种方式在SOA与业务之间建立联系，但服务标识和Service Litmus Test（服务规范的第一个关键步骤）是我们将重点关注的领域。