在开发IT架构时显而易见的是，要真正实现商业利益就要从根本上改变关于系统设计的思维方法。本文是三篇关于面向服务的架构(SOA)的系列文章中的第一篇，BEA提供了有用的技巧、洞察力和一个域模型，以帮助您规划和开发一个成功的SOA实施。
SOA：一种新的思维方式
Albert Einstein曾说过，“假如我们面临的重大问题在思维熟悉水平与我们创建它们时处于同一水平上，我们不可能解决这些问题。”把这个概念应用到当今的企业计算领域，假如我们不改变关于IT的思维习惯，就不可能解决IT界所面临的提供成功商业解决方案的挑战。对于开发人员和企业架构师，SOA为这种变革提供一种结构。要考虑的问题是：我们如何迁移到这种新水平呢？我们如何为这种根本变革做预备呢？我们如何确保证以成本最低、企业创伤最少的方式实现这种变革呢？全部答案始于正确的规划。
SOA与其说是一种技术，不如说是一种的思维方式。它是一项大胆的基础架构变革议程，表达我们如何通过技术和协同工作来实现文化变迁。它的忽然普及不是大规模宣传的结果，而是对SOA作为一种使业务和IT系统更密切结合的演化的认知。这种演化是震撼的，必将为企业的成功带来深远的影响。
SOA 是真正什么?
面向服务的架构是一种IT战略，它把包含在各种企业应用中的分散的功能组织为可互操作的、基于标准的服务，而这些服务可以再被迅速组合和重用以满足业务需求。
一个服务就是一个代码模块，它由可通过基于标准的接口访问的服务水平协议治理。每个服务表示一部分功能，它明确地映射到业务流程中的一个步骤。服务可以从头开始编写，或通过公开原有孤立的应用程序中现有系统功能模块挖掘出来。
经过一段时间后，可以建立起服务目录，答应跨许多不同系统流畅地访问和重用业务功能。这样，在支持战略变革的同时，SOA能消除数据冗余，避免信息重新录入和技巧层面的人为错误。例如，使用SOA能创建一个消费者的单一视图，在此过程中，开启了交叉销售和往上销售的新的可能性，因此提供更有吸引力的用户体验的服务。
新的基础架构范例
SOA的部分范例转移是一个从应用基础架构（application InfrastrUCture）迁移到服务基础架构（Service Infrastructure）的过程。在SOA之前，各种应用程序用点对点的连接方式孤立地组织在一起。除了利用一个聚合的服务基础架构层（Service Infrastructure Layer）之外，SOA使用同样的后端应用引擎和中间件，如图1所示。
图1. 服务基础架构层
实施SOA
按以下步骤开始实施SOA：
从战略上考虑，从战术上实施：首先，用简单的、跨越多个业务单元的不可知服务来实现单一的核心过程。
从上到下考虑：找出支持这个单一核心过程所需的服务。
从下到上考虑：找出现有系统中能作为服务公开以支持这个过程的功能。
考虑基础架构服务：找出公共的支持功能需求。
缓慢扩展：在最初的项目证实成功之后，可以同时承担技术上富有挑战性的项目。
建立一个应用目录：在逐个项目的基础上，经过一段时间后，获取和重用服务模块，降低成本。
关注受益：按投资回报率(ROI)分阶段实施项目，在每一阶段要巩固原有的水平。
使用BEA域模型有效地规划
为了保证成功，SOA以一种新的方式要求IT和业务协同工作。开始SOA规划时，需要在技术性和非技术性要素之间进行有效的平衡。为此BEA开发了一个域模型（如图2所示），帮助指导您规划必须同等重视的六个要害方面，以确保成功实施。
图2. BEA域模型
最好从业务战略与过程、架构以及成本与受益三个方面开始规划。
业务战略与过程：把SOA映射到业务
SOA把IT功能映射到业务流程，使业务随着时间而改善。这个映射过程的最佳表达如下：
分析：研究业务流程，找出所需的支持功能。
开发：从现有的IT资产中获取功能，开发新的功能，确保所有服务都有清楚的服务水平协议。
利用：将服务编排进流程，让其与战略保持一致，识别最佳机会。
架构: 定义长期需求
为IT组织建立参考架构很重要。这种参考架构不是当前的状态图，而是一个长远视图，合并了未来2到3年架构上的发展需要。花些时间来定义架构的指导原则和策略，但要避免使这些指导原则走入死胡同。优先考虑SOA系统的灵活性和模块化。
成本和受益：直接证实业务价值
SOA反对四处出击，重要的是按成本受益顺序确定服务开发的优先级，这样SOA从一开始就显示出ROI。通过仔细的规划，启动成本要限制在现有预算内。经过一段时间后，服务模块的重用会确保以后每个新业务应用程序的启动成本很低。在实施开始时设置好基线，确保可测量性，避免临时修路的效果。
使用SOA成熟度模型
BEA的SOA成熟度矩阵（如图3所示）帮助监视SOA效果，这样您可以检查不同开发阶段的进度。这个矩阵被划分成三个阶段：探索（EXPloring）、扩展（Expanding）和开拓（Exploiting）。可以使用像BEA Online Self-Assessment Tool这样的工具来评估架构的成熟度。
图3：BEA的SOA成熟度矩阵
如图所示，采纳通常不是一种要么全有要么全无的方法。典型的采纳是一种分阶段的方法，这就是为什么在本文里其他题目（比如定义长期的架构和发现直接的业务价值）是很重要的。
结束语 本文的目的是为您提供成功组织SOA规划的指导方针，我们相信，采用这个方法能使您最平稳地实施SOA，使您的企业发展和业务灵敏性达到一个新的高度。
