在最近的一项调查中，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 本身并不能解决信息和语义集成挑战。公司需要其他技术方法来解决这些更具挑战性的问题。

　　在启动 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 成熟度模型、知识和日程安排。如果政策安排造成阻碍，就会导致不必要的工作和问题。在很多情况下，这都是导致很多项目失败的根本原因。为了帮助尽量减少这些风险，可以进行以下工作：

• 　　确保获得管理(C 级执行人员和董事会)支持。
• 　　在解决方案和客户团队之间建立强的伙伴关系。
• 　　构建中心知识门户(存储库)。
• 　　建立定义良好的角色和职责。
• 　　管理良好的项目计划。
• 　　建立问题确定/跟踪/解决机制。

　　SOA 让业务用户与 IT 用户的关系更加紧密。弥合这两个组之间的差异和平衡各种动态元素，以确保 IT 交付内容与业务用户请求和需要的完全相符，这对 SOA 项目的成功至关重要。

　　成功的 SOA 实现需要组织对其流程进行实质性的更改，传统的面向功能长期运行开发周期构建后就一成不变，需要将其更改为面向流程的增量式构建与部署流程，构建时需考虑将来的变化。总的说来，传统的开发与应用程序竖井 (Silo) 一致，实现的是紧密耦合，其结构使用组件和对象作为构建块。SOA 开发采用的是经过编排的解决方案，采用的是松散耦合，将服务作为其构建块。务必认识这些差异，并建立流程来支持转换。

　　2003 年 11 月，Gartner 预测(概率为 0.7)，到 2007 年，IT 专业服务将占大型企业应用程序和软件提供商 50% 以上的收益，在软件和 IT 专业服务市场之间形成了一个汇合点。到 2008 年，应用程序面向服务的开发以及面向服务的业务应用程序将使得 A 类企业将程序员的效率提高 100% 以上(概率为 0.8)。2

　　对于很多企业，特别是其 IT 组织具有一定关键作用的大型企业，要讨论的问题不是是否要构建 SOA，而是什么时候 构建的问题。我们几乎已经到了企业中采用 Web 服务的巅峰时期。各个公司现在正在逐渐认识到 Web 服务和 SOA 的战术和战略好处。随着在企业中实现越来越多的有用服务，各个企业将不得不处理更大的体系结构挑战。只要跨过那个模糊点，网络上巨大的服务数量将不得不迫使各个公司采用某种方式处理 SOA。我们并不是到处都需要 SOA，而且它也不能解决所有问题。毫无疑问，很多公司仍然会构建糟糕低效的 SOA，但他们必定要采用 SOA。务必以分阶段的方式 处理流程转换，尤其要从体系结构角度加以考虑。

　　采用多个阶段进行流程转换，理想的情况下应该从分层体系结构到组件体系结构，最终到 SOA。分阶段可尽可能降低风险，并允许对现有体系结构进行重用。初始阶段是通过以下方法建立分层体系结构的：

• 　　创建 SOA 体系结构框架(指导方针、标准等)来指导实现项目
• 　　评估现有体系结构，以支持使用该体系结构框架的 SOA 目标状态
• 　　向正在进行的未采用此体系结构的项目应用组件体系结构框架

　　在组件体系结构阶段，可以将 SOA 应用到小型项目，从而演示组件重用，并同时尽可能降低采用新体系结构的风险。试点项目可帮助“试试水深”。有了这个经验，项目团队然后就可以将 SOA 应用于更大的项目，实现 IT 战略中确定的重用好处。

　　然后可以通过进行以下工作建立 SOA 治理框架：

• 　　定义服务开发生命周期的更改
• 　　定义 IT 组织模型来支持 SOA 环境
• 　　建立面向服务的业务应用程序的指导原则
• 　　确定新技术需求

　　正如我们所知的，SOA 的主要好处在于，它允许组织实现灵活且响应能力强的业务模型，可以灵活而敏捷地响应快速变化的业务需求。为了实现灵活性和创新，组织需要将其业务流程拆分为可管理的部分。它必须允许应用程序逐渐提高其模块化程度，并能简化管理和支持业务中的变更所需的底层 IT 基础设施。在实现此模型的过程中，务必尽早定义正确的方法，包括用于支持 SOA 的治理结构，并要在此过程中牢记所有业务目标(而不是技术功能)。

　　确定技术与上市时间之间的实际的平衡关系非常重要，因为成本在 SOA 开发过程中扮演非常重要的角色。您还需要对持续灵活性和一次性的效率收益进行权衡，并在各种应用程序投资组合中进行投资(可以的情况下)，以支持资产重用。通过在多样化的应用程序投资组合中投资，而不是仅仅集中在单个打包应用程序或技术上，可以减少风险和创建在很多领域和程度上改进业务的机会。

　　从业务流程的角度而言，建议您：

• 　　将业务流程跨业务单位集中。
• 　　让合作伙伴和重要客户满足服务使用者的需求，如减少手动流程、降低成本和提高性能可见性。
• 　　积极地管理风险，以在竞争优势和系统性能之间求得平衡。
• 　　如果组织有现有企业体系结构，则需要检查其可用性，以确定是否是基于 SOA 和开放标准，并进行必要的修改。
• 　　在可能的情况下，还务必利用目前可用的模式(例如 IBM 的 Patterns for e-Business)，并使用先进的开发工具来简化业务集成项目的开发工作。有关更多信息，请参见基于资产的支持。

　　创建计划

　　SOA 治理和采用计划对 SOA 项目的成功非常关键。需要在考虑企业业务价值的前提下尽快建立流程，采用增量的方式进行实施。组织准备情况扮演着重要的角色，可以通过使用基于服务集成成熟度模型(Service Integration Maturity Model，SIMM)的企业服务成熟度级别进行确定。早期引入过程中使用 SOA 参考体系结构和治理模型将帮助简化和加速此过程，为您的总体 SOA 转换成功带来帮助。

　　SOA 是体系结构，而体系结构是一组最佳实践和模式。或者，可以这样说，SOA 是一个规程。您需要计划，还需要所需的专业知识。构建 SOA 的最佳方法是将自底向上方法(用于构建解决集成问题的服务)和自顶向下体系结构方法结合使用。体系结构方法提供流程驱动的服务(支持业务敏捷性)和目标-服务建模技术(确保考虑了长期业务目标)。

　　基于资产的支持

　　在今天的开发过程中，我们要处理越来越多的异类流程、工具和方法。与五年前或十年前相比，软件开发中的复杂性大幅度增加，而且将来只会进一步提高。作为架构师，您需要时时考虑新变更，并提供足够的解决方案——这些都需要在学习方面进行大量的投资。经常并没有足够的时间在开始项目前进行实际培训。在可能的情况下，请充分利用之前构建的(经过验证和测试)的资产，并尽可能减少从头开发解决方案。

　　基于资产的开发支持包括方法、模式、指导原则、原理、之前构建的项目概要和存储库。在 SOA 领域，这特别重要，因为 SOA 的优势就在于其重用，允许使用者订阅满足其需求的服务。 资产可以包括：行业程序包、标准、最佳实践、原则、模式、开发指南和之前的项目存储库。

　　定义解决方案时利用之前的经验教训(使用已经建立的服务和适用的资产)可帮助：

• 　　实现重用。
• 　　减少开发工作。
• 　　尽可能降低风险。
• 　　提高效率。

　　不幸的是，并非所有项目都利用了资产重用。经常是这样，没有研究现有的内容就开始新项目，因此进行很多重复工作。SOMA 已被视为是支持 SOA 开发的实际 方法(或能力模式)。

　　面向服务的建模与体系结构包括服务、组件和流(通常是服务的编排)的三个大步骤——标识、规范和实现。有关更多信息，请参见参考资料中的“面向服务的建模和体系结构”。SOMA 的下一版本将进行扩展，以支持从认识到实现的全部 SOA 开发过程。

　　SOMA 引入了八个新的规程和其他一些功能模式。在这八个规程中，利用现有资产贯穿 SOA 开发过程的整个生命周期，从而满足资产重用的需求。在每个阶段(标识、规范、实现)的最后，都会执行名为“服务构成与合理化”(service factoring and rationalization) 的任务来支持重构流程。此任务确保我们确认拥有什么资产(包括服务)并确定哪些资产可以进入下一个阶段。这是一个迭代的过程，设计用于提供质量检查、降低风险、尽可能减少浪费和最大化重用。

　　SOMA 还引入了功能模式，如资产使用 (Asset Consumption)、资产构造 (Asset Construction) 和资产治理 (Asset Governance)，以处理资产开发生命周期需求(请参见图 1)。构造资产之后，将进行认证流程，以确保资产的质量和保证可重用性(属于资产治理的一部分)。认证流程将管理资产开发过程的生命周期。

　　图 1. 资产开发生命周期

　　通常，在创建解决方案之前，应该首先检查可用的内容，充分利用现有资产(方法、最佳实践、指南等等)。应该在项目计划中包括活动和任务(包括全面质量检查)。根据可重用资产的程度，这些工作将一定会帮助减小风险、降低开发成本和提高团队的效率。

　　工具支持：从传统开发到 SOA

　　SOA 还提出了对工具的其他需求，从业务建模、SOA 开发、SOA 测试(互操作性、组合业务服务和 BPEL 测试)、服务测定与监视一直到服务部署。

　　一个工具问题是，大部分第三方供应商工具的空间占有率很高。普通安装流程本身非常复杂，非常耗时，而经常需要大的系统容量才能运行。

　　或许最具挑战的任务就是让来自多个提供商的工具一起工作。各个产品通常与其他产品的集成性能并不好，而这会对开发人员的效率和项目进度造成影响。建议使用客户自动化安装、配置和测试(最低限度)脚本，以加速这些流程的执行，实现可重复性。过程文档还能在此领域提供帮助。

　　工具本身无法满足所有不同用户(业务分析人员、设计人员、架构师、开发人员)的需求。例如，业务需求的建模、业务优化的建模和执行的建模将需要不同的知识和技能，或许还需要其他工具。

　　总之，工具支持需要进行培训，而这应该在项目计划中尽早安排。产品选择通常在开发工作开始前进行。您必须对市场上已有的东西进行研究，并对产品的定价、功能、可支持性、培训和易用性进行比较。您可能需要根据客户的环境、业务需求和长期目标提出建议。最终将由客户作出决策。在任何情况下，最终的决策都要作为体系结构决策加以记录。

　　总结

　　在实现 SOA 解决方案的过程中，架构师会面临各种挑战。务必认识到，SOA 的成功需要进行多个级别的转换，并需要获得组织、人员、流程、资产和工具的支持。设计和管理大型 SOA 项目时，务必配备软件产品专家、处理组织变更管理的战略与变更顾问以及 SOA 解决方案架构师。

　　获得管理人员和所有主要涉众的支持也同样重要。要管理客户期望和范围逐渐扩大的情况，需要专门的项目经理团队，并及时使用流程变更流程。有时候可能还需要采用创造性技术来与客户分担其他工作。　　

　　要制定有效的培训计划，您必须了解客户开发文化和当前可用的流程与技能。人员和机器方面的客户资源可用性对时间较紧的项目至关重要。必须将问题或延迟及时上报给客户的最高执行资助人。

　　要提高效率和缩短开发周期，尽可能多地实现自动化也非常重要。

　　为了降低风险和成本并极大地提高 SOA 成功的几率，请充分利用各种现有资产，包括人员、最佳实践、标准、程序和问题。

查看本文来源