在最近的一项调查中，Saugatuck Technology 发现“SOA 正逐渐在大中型企业中缓慢但稳定地推广开”在此项调查中，他们与在大中型企业工作的高级 IT 管理人员(用户)和应用程序架构师进行了 40 次深入的访谈，注意到“所采访的 37% 的高级 IT 管理人员都表示其公司目前正处于 SOA 部署的有限或完全生产阶段”。
虽然注意到 Gartner 预测在接下来两年中所有新应用程序中将有 80% 将基于 SOA，但 Saugatuck 的调查表明用户的期望非常乐观，指出“到 2008 年，将有接近 67% 的用户将使用有限或完全的 SOA 生产环境”。1其他 Saugatuck 研究数据表明，到 2008 年，会有不到 45% 的大中型企业会采用有限或完全的 SOA 生产环境。在任何情况下，下一年大中型企业中有 45% 到 80% 采用 SOA 都是非常显著的变化了。
随着将 SOA 应用于更为复杂的任务，将会出现更多复杂情况。复杂任务涉及到各种类型的集成模板，用于处理不同的业务挑战和需求，如遗留集成与转换、应用程序、打包应用程序集成、组合业务服务和自定义开发。
作为架构师，您经常在将业务需求和 IT 需求应用到 SOA 项目中扮演着领头雁的角色。本文讨论在从传统开发向 SOA 的过渡中的一些主要成功因素和经验教训。
评估组织准备情况
架构师必须处理 SOA 项目中的很多错误和挑战。一个主要的挑战就是组织准备情况。但是在处理此挑战前，务必确定 SOA 能够给组织带来什么样的价值，并指定恰当的转换计划。
很多 SOA 项目的启动都是仅仅因为客户在长期战略中需要 SOA，不过并没有实际确定 SOA 可能带来的好处有多少，或者确定哪些业务区域可以得到改进。这样将得到定义槽糕的交付计划和范围，而随后会因为没有达到客户的预期而导致客户满意度下降。如果在早期销售周期中参与者没有足够的 SOA 知识来确定工作范围或在签署合同前向客户传递相关知识，则可能会导致预期不当。显然，同样重要的是，交付团队和客户都要全面了解 SOA。
有关 SOA 的观点通常可归为两类：SOA 是最好，或者 SOA 一钱不值。这是两个极端，而 SOA 实际上位于两者之间的位置。不幸的是，作为架构师，您可能需要面对支持这两种观点中的一种的客户和开发团队成员，因此要么过度积极，要么过度消极。克服这些极端思想，需要在 SOA 开发过程中进行大量的理念传递和培训。
“SOA 并不是什么新东西——全是假想，没有实质。”
要克服有负面影响的谬论和驳斥不相信 SOA 的人，您可以指出 SOA 在 20 世纪 90 年代早期就出现了，已经取得了长足的发展。还要务必记住，与其他技术(如 CORBA)相比，今天的 Web 服务标准已经得到了更广泛的行业和用户的接受，而这也对 SOA 的推广起到了促进作用。
“SOA 是革命性的范式变迁，是万能药。”
对于过分乐观的观点，您需要指出，SOA 更多是发展的结果，而不是革命性剧变的结果。在进行类似的事情方面比以前有所改进，只是更好了。这不是范式变迁，不过这是一个重要的转变。SOA 对企业处理分布式计算的方法进行了发展，对其实现进行了改进，但 SOA 并不代表着可以视为革命性的突破性变更。
SOA 在经常受到业务环境的频繁更改影响的异类环境中尤为有用。您需要首先向客户确认其 IT 环境是否是同类环境。如果是，则 SOA 可能并不适合该客户的情况。高性能是否比松散耦合更为重要?客户是否希望对 IT 功能进行严密的控制，以尽可能提高性能?如果是，则 SOA 也不适合他们使用。即使是能够从 SOA 获益的公司，也不要假定他们所需要的唯一体系结构就是 SOA。毕竟，SOA 能很好地与其他体系结构并存，而 SOA 本身并不能解决信息和语义集成挑战。公司需要其他技术方法来解决这些更具挑战性的问题。
可以用于帮助派生出长期和短期战略、热图和 KPI 值的一项技术是组件业务建模(Component Business Modeling，CBM)。我们知道 SOA 的承诺是构建足够灵活的 IT 基础设施，以响应业务的需求。由于具有这么广泛和战略意义的价值主张，因此很容易看到 SOA 是无法回避的趋势。但是，每个组织都需要做到以下几点，仔细地计划从传统开发组织过渡到服务组织的工作：
将组织向服务过渡的过程需要时间、人力、流程、方法和工具支持。这是一项长期的体系结构战略，目的是为了满足业务目标，需要采取渐进的方式才能获得其承诺的好处。在开始项目前，务必了解组织所处的位置和准备情况。要确定项目的范围和所需的工作，应该在做出任何建议前确定组织的准备情况。SOA 路线图能够帮助保持增量计划的战略性。不幸的是，并非所有 SOA 项目都考虑了全局。
获得涉众支持
组织中的不同人员各有自己不同的考虑，而这在 SOA 转换过程中有着非常大的影响。“业务优势”对不同的人员有不同的含义。无论是 SOA 还是非 SOA 项目，架构师在整个开发过程中都经常必须面对各种类型的人。
我们都知道涉众的支持对任何项目的成功都非常重要，但对 SOA 项目尤为重要。SOA 活动应该由业务人员在考虑业务目标的情况推动开展，因此与传统开发项目相比，此类项目需要更多的业务涉众参与。不幸的是，技术人员所支持的 SOA 项目的有些业务优势根本与业务不相关，而是只有 IT 部门能够感受到其影响的技术优势。
哪些能被视为业务优势呢?不同的涉众将以不同的方式看待 SOA，取决于其承担的义务或责任。表 1 给出了一个示例。
表 1. 涉众对 SOA 的看法
尽管不同的用户对 SOA 有不同的需求，但都在 SOA 转换过程中扮演着重要的角色。务必了解不同的用户，并构建服务生态系统(构建此系统将需要所有组织角色的参与)。就像是食物链，在所有参与者之间存在着相互依赖的关系，实现了精确的平衡。在 SOA 项目中，架构师需要从高级涉众(董事会董事)获得支持，以便得到项目资金投入和资助，也需要中间的经理的合作，以利用他们的业务支持、资源和专业技能。SOA 架构师当然还需要办公室工作人员的支持。他们经常是执行操作的人员，具有最详细的业务操作知识，而这些知识对在恰当的粒度级别成功设计和定义相应的服务非常重要。
不同的用户还需要接受不同的 SOA 培训，以实现其特定的需求，因此务必在项目中考虑用户培训事项。并不一定要大张旗鼓地进行这件事。不同的用户可能在不同的阶段接受不同的 SOA 培训——最好在参与实际的 SOA 工作之前。例如，董事会董事将比其他用户更早接受培训，因为他们需要对总体战略和资金投入提供支持。他们的培训将更注重理论层面的东西。
开发人员应该稍后接受更多的实践方面的培训，以便能在 SOA 开发周期开始时立即应用这些知识。此过程非常重要，应该持续进行。您应该建议客户在开发过程中加入培训活动计划。如果没有进行此工作，将增加沟通难度，导致较差的交付内容。
通常，任何开发过程中最难的部分都是与人及政策相关的部分，特别是存在多个参与方时，如提供商团队、解决方案团队、现有基础设施支持团队等等。他们具有不同的 SOA 成熟度模型、知识和日程安排。如果政策安排造成阻碍，就会导致不必要的工作和问题。在很多情况下，这都是导致很多项目失败的根本原因。为了帮助尽量减少这些风险，可以进行以下工作：
SOA 让业务用户与 IT 用户的关系更加紧密。弥合这两个组之间的差异和平衡各种动态元素，以确保 IT 交付内容与业务用户请求和需要的完全相符，这对 SOA 项目的成功至关重要。
