在发展IT架构时你会逐渐发现到，若要获致真正的业务效益，你必须彻底改变系统架构的思维。本文是关于服务导向架构(SOA)的系列三篇文章中的第一篇，将提供你实用秘诀、深刻剖析和领域模型（Domain Model）以规划和开发一个成功的SOA。

　　SOA：一种新的思维方式

　　爱因斯坦说：「当我们面临重大问题，如果我们没有从引发问题的层次往上提升，从更高的层次观察问题，这些问题将不可能被解决。」这个概念应用到当今的企业运算领域时，如果我们不改变对IT的思维习惯，IT也就无法成功支持商业方面的需求。对于开发人员和企业架构师来说，SOA为这种改变提供一个基础的架构。

　　这里我们要思考的问题是：我们该如何自我提升到新的层次？该如何为这种彻底变革做准备？如何确保以最具成本效益、对组织最没有损害的方式来进行这种变革？所有答案之首在于适当的规划。

　　与其说SOA是一种技术，不如说它是一种思维方式。它是一项大胆的基础架构变革，代表我们在使用技术和相互协同方式上的变革。它的爆红不是业界一时热潮的结果，而是因为IT业已认知到SOA乃是促进业务和IT系统更密切结合的重大革命。这场革命惊天动地，对企业具有深远影响。

　　究竟什么是SOA？

　　服务导向架构是一种IT策略，它把包含在各种企业应用中的功能组织成相互可操作的标准化服务，而这些服务又可以迅速组合和重复使用以满足业务需求。

　　一个服务是一个由服务层次协议（SLA）管理的原始码模块，可经由标准化接口加以存取。每个服务都表示一部分的功能，明确对应到业务流程中的某一步骤。服务可以重新打造或是把现有把各自孤立的应用程序中的系统功能模块公开（expose）出来。

　　慢慢地你就可以建立起服务目录，使业务功能如液体般可以让许多不同系统存取与重复使用。这样，SOA就能同时支持策略变革并在技巧层次上减少重复数据，避免信息重复输入和人为错误。例如，使用SOA能建立一个消费者的单一视图，在此流程中，开启更多交叉销售和向上销售的可能性，进而提供更多服务提升使用者体验。

　　基础架构新典范

　　SOA的典范转移有一部份是从应用基础架构（Application Infrastructure）转换到服务基础架构（Service Infrastructure）。在SOA之前，各种应用程序乃是以点对点的方式连结成相互分离(silos)的系统。SOA也用同样的后端应用引擎和中介软件，但更使用一个聚合的服务基础架构层（Service Infrastructure Layer），如图一所示。

　　图一服务基础架构层

　　SOA实作

　　SOA实作依照以下步骤开始：

　　‧思维需具备策略性，执行需具有战术性：应从简单的、中立的服务来实作，从单一核心流程开始，而不要想横跨多个业务部门。

　　‧从上到下考虑：找出支持这个单一核心流程所需的服务。

　　‧从下到上考虑：找出现有系统中可当成一个服务公开、支持这个流程的功能。

　　‧考虑基础架构服务：找出共通的支持功能需求。

　　‧逐步扩充：最初的项目成功之后，再迈入技术上较具难度挑战性的项目。

　　‧建立应用目录(application catalog)：一个又一个项目下来，逐步累积与重复使用服务模块，长期下来可减少你的成本。

　　‧关注受益：按投资回报率(ROI)切分项目阶段，也要为整合预留一段时间。

　　利用好的模型有效规划

　　SOA若想成功，仰赖IT和业务单位之间新的合作方式。在你开始SOA规划时，你需要在技术性和非技术性要素之间取得有效的平衡。为此BEA发展了Domain Model（如图二所示），可协助指导你规划须等量齐观的六大领域以确保导入的成功。

　　方法论 : BEA SOA Domain Model

　　图二

　　BEA Domain Model

　　最好先从「业务策略与流程」、「架构」以及「成本与效益」三个领域着手规划。

　　业务策略与流程：把SOA对应到业务

　　SOA把IT功能对应到业务流程，使业务随着时间而改善。对应流程如下：

　　‧分析：研究业务流程，找出所需的支持功能。

　　‧开发：从现有的IT资产中搜集功能，开发新功能，确保所有服务都有明确的服务层级协议。

　　‧利用：将服务编排进流程，确保未来措施与策略一致，找出最佳化时机。

　　架构：定义长期需求

　　为IT组织建立参考架构很重要。这种参考架构描述的不是现有状态，而是依据贵公司长远目标的二、三种架构融合而成的长期远景图。你应该花些时间来定义架构的指导原则和策略，但要避免使这些指导原则走入死胡同。SOA系统的弹性和模块化特性是第一考虑。

　　成本和效益：展现立即的业务价值

　　SOA宗旨在于布署底层架构，因此重要的是依据成本效益排定服务开发的优先级，这样SOA从一开始就能有好的ROI。若能仔细规划，你的「启动」成本多半可以为现有预算所吸收。经过一段时间后，服务模块的重复使用可确保以后每个新业务应用程序的启动成本很低。在实作一开始设定好基线(baseline)，确保进度可被测量，同时要避免在过程中临时要回头填补坑洞。

　　使用SOA成熟度模型

　　这牵涉到方法论的问题。BEA的SOA成熟度矩阵（如下图所示）可协助监视SOA布署，以便协助企业依据不同开发阶段检查进度。这个矩阵被划分成三个阶段：探索（Exploring）、延伸（Expanding）和使用（Exploiting）。你可以使用像BEA Online Self-Assessment Tool的工具来评估架构的成熟度。

　　SOA通常不是一种零与一的两极化选择，一般是采取分阶段渐进的模式，我们未来还有其它主题（如定义长期的架构和发现立即的业务价值）来探讨之。

　　结论

　　本文目的在于提供你成功规划SOA的指导方针，我们相信，这个方法最能让你顺利布署SOA，使公司的开发和业务灵活性提升到新的境界。