成功 SOA 的两个最重要的教训：共享及与其他部分和谐相处。组织中曾经完全不同的团队会发现自己在 SOA 实现中共享服务、成本和资源。事先了解所有相应的关系连接需要出现在哪些地方，是确保大家都获得成功的最好办法。
团队协作
SOA 切实地发生着。采用 SOA 时，将影响整个企业，而不仅是 IT 部门。
企业内不同的组织(可能到目前为止都采用相当独立的方式运作)突然被要求重用其他人的服务，并为创建共享服务提供支持。企业内可能会对这个新的“共享”安排有所顾虑。例如，组织 A 创建了关键型服务 X 来支持他们的某个解决方案。他们并不希望将服务向其他组织的应用程序公开，因为他们并不控制其他应用程序，担心这些应用程序可能会使得此服务崩溃。此外，如果组织 B 的应用程序使此服务崩溃，则可能会导致组织 A 的解决方案也停机。可以这样说，就像将所有人都将鸡蛋放入同一篮子一样。
这个顾虑非常有道理，事实上必须对所需的需要与给定共享服务关联的服务质量进行积极评估，从而对其加以处理。不同的组织可能会依赖于相同共享服务的不同服务质量，如果差异足够大，从财务角度(不是管理角度)来看，认为应该部署该服务两次。
现在，在组织开始对共享服务的最优服务质量吹毛求疵前，可能会希望对共享服务接口的情况达成一致。如果组织 A 和组织 B 均在过去创建了类似的服务，无疑将会就 A 的服务和 B 的服务如何进行组合以形成共享服务的接口进行讨论。此类讨论总是会相当激烈，两个组织都会非常在意其一直依赖的服务的接口中采用所需更改而需要进行的工作。通过部署在之前已经存在的服务与新共享服务间进行转换的 facade 服务，可以简化此转换工作。
很可能在服务调用者和提供者之间存在某个业务实体。谁应该定义实体的表示方式?间接来说，“业务部门”应该负责此工作。应该制订业务术语表，以文字的方式描述“供应商”和“项”之类的业务概念。还应该捕获每个概念的动态方面的信息，类似于如何在业务内对其创建和使用之类。将由“业务部门”在数据架构师的帮助下从术语表中派生出逻辑业务信息模型。可以从逻辑业务信息模型派生出持久性模型(可以采用 DDL 表示)和服务信息模型(可以采用 XSD 表示)。
正如您所看到的，不仅不同组织的 IT 人员必须开始彼此交流，而且其对应的业务人员也将进行类似的沟通。和 IT 一样，这些人员很忙，可能需要让他们确信他们在定义服务接口的过程中扮演着一定的角色(虽然是间接的)，但在业务级别达成此一致前，IT 仅仅是对需求进行猜测而已。
耦合和分离处理新关系
好，现在每个人都在彼此进行交流，而且我们都在扮演着自己的角色，那就可以创建该死的共享服务了，对吧?是的，从技术角度而言的确如此，但由于每个组织目前都负责自己的 IT 支出，那谁将为共享服务提供资金投入呢?共享服务是否可以承载于某个依赖组织的 IT 部门，或者是否将创建某个共享服务组织以某种方式为其提供资金投入呢?如果由现有组织承载，其他组织是否要为服务实现的扩展做出一定的贡献，以便此实现能够支持所有依赖组织的需求?如果服务由共享服务组织承载，该组织是否将采用集中方式提供资金支持，或者从依赖于共享服务的各个组织的预算中提供资金支持?谈到资金投入，共享服务的成本模型是什么样的?如果给定服务需要 IBM® WebSphere® Process Server 之类的新技术，且该服务是驱动对此新技术的需求的第一个服务，则此新技术的全部成本(人员、培训、辅助监视、管理、维护成本等)都归于此新服务，还是采用摊销方式分摊到使用此新技术的后续服务?
可以采用很多方式处理这些事实，虽然“正确”解决方案将会根据组织不同而有所不同，但重要的是要认识到解决此方面问题的需求并加以计划。此组织耦合是由于希望重用服务和更好地保持 IT 与业务的一致性而引起的，可能会从组织变更方面的专家的帮助获益，例如通过 IBM 全球业务服务部提供的专业指导等。
我们已经讨论了 SOA 技术增加耦合的领域，接下来我们将注意力转向组织之间耦合减少的领域。在这种情况下，两个组织都是 IT 部门的下属部门。我将以应用程序开发团队和数据(或信息)管理团队为例。
文章来源于领测软件测试网 https://www.ltesting.net/