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是要满足业务需求的，而不能仅仅作为应用开发团队的工具而存在。因此，首先建立一个可以方便地了解底层技术的清晰的业务服务视图，才是合理的第一步。