现今，要有一个可以持续运作的业务，就必须要有能够提供相应支持的架构。这种架构必须具有敏捷和可重用的性质。为了能够支持各种不同的端对端的交易组件，把潜在客户转化为利润，这种架构的业务交流形式必须有充分的自由度。这不管对什么业务都是很重要的一点。这种信息透明度要渗透于企业的各层次之间，从而实现重用的标准化——并将其作为一种优势，而不是成为缺乏准确度的来源。

　　比如一个推广新产品的业务。它不仅代表着外部的市场需求，还表示着内部的基层团队和业务过程应该如何向谁、以什么价位来销售这个新产品。这并不需要对业务部门或者业务线进行改编。它和那些当前被信用危机严重影响的交易一样：要实现利润，唯一的途径就是减少操作成本。

　　这个原则对于那些要采用面向服务架构(SOA)的企业同样适用。SOA改变了企业集成业务系统的方式。这种以“潜在客户到订单、订单到生产、生产要发货、发货到发货单、发货单到支付”为基础的系统使企业能够根据他们的人员情况、生产过程、程序和IT工具(特别是硬件和软件方面)抓住投资机会。并且，他们可以在此同时对系统进行改进，以满足将来电子商务、B2B、全球经济等多样化发展的需求。

　　SOA的独特优势

　　分布式计算已经发展了许多年。对于某些人来说，SOA看起来与其一样只是炒作得厉害。但是SOA作为一种企业开发和架构的范式，它确实有其独特的优势。现在的分布式系统主要是面向服务的、使用松耦合的组件进行操作，对业务事件有很好的响应性，并且对集成的和内部固有的各种方案能提供很好的支持。严格来说，它们是以能够产生利润的交易数据为基础建立起来的，并能有效地应用既有的基础设施和软件。

　　SOA脱离了对平台和物理服务器的依赖，使IT部门可以提高基础设施的效率，并能从既有的网络和系统中提取更多的价值。它可以通过消息传送和认证机制动态地使用当前的服务，系统组件之间的交互方式也很灵活。再加上软件模式的应用——重用服务组件，SOA可以极大地提高系统的可靠性。从服务部署的角度来看，这不仅意味着每一个业务线驱动的新项目都可以减少所购买的硬件和软件基础设施的数量，企业也能从标准化、整合、虚拟化服务器和软件应用环境中受益，并且在不同的技术之间构建交流接口的时候也可以专注于通过技术融合和信息共享获得额外的成本节省。

　　SOA这种范式所带来的最大优势包括管理底层基础设施的操作成本更低、组合应用的构建以及相应更低的风险、可以依据从单一应用接口获取的整个企业的即时数据制定决策。为了达到这个目标，各机构就要整合多个系统和数据源，建立统一的数据分类，实现一致的数据视图–结果就是在整个供应链中形成了由各机构共同组成的面向服务的架构。

　　SOA为走上这条路的企业提供了诸多便利。直接的利益包括灵活而简单的管理、方便各种方案的组合、更少的开发时间、以及能够实现更大的重用性和互通性的标准接口。有一些供应商可以提供整套的SOA平台，但这也会把客户锁死在单一供应商上;因此许多人也把可以从多个供应商选择不同的组件当作SOA的优势之一。还有许多企业虽然并没有明确地决定要发展SOA，但他们也在不经意中增加了某些类型的SOA设施。不管是大型或小型企业，SOA都具有普遍的适应性。

　　SOA还有一个相当大的优势就是能够适应不断变化的客户与市场需求的敏捷性以及由于无需购买和维护新技术所产生的成本节省。同时，由于SOA能够把管理部门和业务部门推向一线，从而减少了客户开发和技术方面的花费。这也保证了SOA能够带来更多的利益和更低的成本。不管是从商业角度或者是从构建一个集成、呈现、修改业务基础数据的企业解决方案的角度，我们都可以说SOA的真正价值是非技术性的。

　　SOA成功的基础

　　但是大多企业在进行SOA的时候却从数据模型——企业的元数据——以及企业将来所需的各种元数据视图着手。比如，各个机构都有客户数据，但是在不同的业务过程中，所需要的各个客户的数据属性却是不同的。在从“发货单到支付”的过程中我们希望看到的是可能是客户的付款记录，而“潜在客户到下定单”过程中我们可能会对客户的定单记录更感兴趣。如果产业不同，这种差异就会变得更大。因此，许多企业甚至在着手企业范围的集成之前就先陷入了为各业务部门之间建立一致、及时的信息传输架构的困境之中。

　　然后，各机构开始考虑各种SOA技术、定义以及各种海量选择的不同优势：中间件、基于模式的软件架构、远程处理、后期连接、消息/信息、容器、J2EE与。NET组件、服务标准、通过注册中心验证服务、与分散的外部世界同步、业务规则及适应性、服务层以及一个真正的面向服务的技术框架的意义。

　　在这整个过程中，许多公司都忘了一个基本点：在他们开始SOA的旅程之前，他们首先要了解当前既有的架构，保证他们能够利用一些可重用的敏捷组件。在起步SOA和企业集成之前还有大量的基础性工作要做。IT技术人员的一个重要的出发点就是了解他们当前的基础设施如何(以及是否)支持业务关键的系统和过程–以及在哪些地方可以有效地利用成本进行安全的改变、集成系统，从而从互通的服务中受益。作为第一步，为既有的SOA相关的技术和这些技术在企业中应有的位置制作一个完整的列表并保持更新是很有必要的。

　　对于那些希望通过SOA转型实现节省成本、提高效率的目标的公司来说，他们完全可以使用与供应商无关的发现和制图工具对他们IT设施的所有组件进行鉴别，并得到硬件、软件和应用之间的依赖性的准确而全面的数据。这些数据的质量以及从系统中提取、聚合、处理这些数据所使用的方法是SOA成功的重要因素。这些发现和制图工具是IT团队继续开发分布式、高性能的架构(比如SOA)的主要工具–而且它们还可以协助管理SOA框架中的应用程序的性能和依赖关系。它们还能跟踪一些架构中的活动组件(比如虚拟机)，标志这些活动组件之间的依赖关系并在整体SOA环境下对这些个体进行检测–这可以将投资回报周期从以年为单位缩短为以天或周为单位。通过对当前架构的理解，确定原始设计的偏移，就能为公司实现一个安全、快速、有效的转换打下坚实的基础。

　　放到实际操作中，这意味着架构、开发和基础设施支持团队要协作一致地研究当前的环境。他们需要共同的语言来描述当前的IT状态，包括所有的组件关系和依赖关系。对于SOA的成功来说，这比仅仅依靠数据模型和中间件更有意义。

　　自动化的发现和制图工作可以更容易地寻找适合SOA的业务服务，当然也可以找出那些不适合的服务。比如，SOA并不适合那些非分布式的对组件集成没有需求的系统、使用由服务递交的数据会降低性能的应用、需要严格匹配的异步通信的应用、已在通用的通信环境中运行的应用和短期的过渡性方案。

　　这些制图工具能够描述软件组件之间的关系，让我们更清楚地了解业务应用或服务的底层组件，同时还可以让我们更容易地发现当前的支持SOA范式的应用组件。这些信息可能会在实验性进行SOA部署的时候派上用场，但是这只是其中一步。然后还要对这些信息进行治理方面的补充，因为治理是SOA成功的进一步要求。伴随着SOA的灵活性和其它优势，需要管理的组件也变得越来越多——同时这些组件之间的关系也越来越复杂。

　　SOA就是IT企业架构可以使用什么方式根据企业的、客户的、合作伙伴的数据分类对分散的系统进行松散整合。在实际操作中，这需要对当前的架构有深刻的了解、能够在企业范围内实现SOA的治理、成熟的数据模型设计、以及随时注意对任何能够支持敏捷和重用已建立的软件服务的方案的需求。技术是一个重要的考虑因素，而技术结构将根据当前各系统是否适合转化为SOA应用而调整。利用发现和依赖关系制图工具，公司可以对当前的架构进行评估，建立一个已经实现SOA的企业环境，确定可用于集成的组件，并对部署成功率做出评测。SOA是要满足业务需求的，而不能仅仅作为应用开发团队的工具而存在。因此，首先建立一个可以方便地了解底层技术的清晰的业务服务视图，才是合理的第一步。