在 最近的一项调查中,Saugatuck Technology 发现“SOA 正逐渐在大中型企业中缓慢但稳定地推广开”。1(请参见参考资料。)在此项调查中,他们与在大中型企业工作的高级 IT 管理人员(用户)和应用程序架构师进行了 40 次深入的访谈,注意到“所采访的 37% 的高级 IT 管理人员都表示其公司目前正处于 SOA 部署的有限或完全生产阶段”1。
虽然注意到 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 部门能够感受到其影响的技术优势。
表 1. 涉众对 SOA 的看法 涉众 看法 董事会董事 考虑长期战略与活动的目标;了解政策约束与法律法规。需要在约束范围内满足目标,处理组织的总体运作和战略。SOA 造成的影响是战略性的、长期性的企业级影响。 经理 负责处理日常战术问题。通常希望提高工作效率,而这意味着要应用某种结构,并对其进行推广、监视和测定。业务优势需要以可测定的方式实现。 办 公室工作人员、开发人员、底层开发人员 更为关注战术层和日常事务。他们是进行实际工作的人,需要了解如何创建或交付 SOA。他们所考虑的事情在某方面甚至比经理或公司的高层管理人员更为重要。通常其工作安全性最低,可能不了解或接受其带来的价值,而将 SOA 视为威胁或入侵。
尽管不同的用户对 SOA 有不同的需求,但都在 SOA 转换过程中扮演着重要的角色。务必了解不同的用户,并构建服务生态系统(构建此系统将需要所有组织角色的参与)。就像是食物链,在所有参与者之间存在着相 互依赖的关系,实现了精确的平衡。在 SOA 项目中,架构师需要从高级涉众(董事会董事)获得支持,以便得到项目资金投入和资助,也需要中间的经理的合作,以利用他们的业务支持、资源和专业技能。 SOA 架构师当然还需要办公室工作人员的支持。他们经常是执行操作的人员,具有最详细的业务操作知识,而这些知识对在恰当的粒度级别成功设计和定义相应的服务非 常重要。
不同的用户还需要接受不同的 SOA 培训,以实现其特定的需求,因此务必在项目中考虑用户培训事项。并不一定要大张旗鼓地进行这件事。不同的用户可能在不同的阶段接受不同的 SOA 培训——最好在参与实际的 SOA 工作之前。例如,董事会董事将比其他用户更早接受培训,因为他们需要对总体战略和资金投入提供支持。他们的培训将更注重理论层面的东西。
开发人员应该稍后接受更多的实践方面的培训,以便能在 SOA 开发周期开始时立即应用这些知识。此过程非常重要,应该持续进行。您应该建议客户在开发过程中加入培训活动计划。如果没有进行此工作,将增加沟通难度,导致较差的交付内容。
通 常,任何开发过程中最难的部分都是与人及政策相关的部分,特别是存在多个参与方时,如提供商团队、解决方案团队、现有基础设施支持团队等等。他们具有不同 的 SOA 成熟度模型、知识和日程安排。如果政策安排造成阻碍,就会导致不必要的工作和问题。在很多情况下,这都是导致很多项目失败的根本原因。为了帮助尽量减少这 些风险,可以进行以下工作:
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 应用于更大的项目,实现 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 的最佳方法是将自底向上方法(用于构建解决集成问题的服务)和自顶向下体系结构方法结合使用。体系结构方法提供流程驱动的服务(支持业务敏捷性)和目标- 服务建模技术(确保考虑了长期业务目标)。(有关更多信息,请参见下面的面向服务的建模体系结构(Service-Oriented Modeling Architecture,SOMA)。)
基于资产的开发支持包括方法、模式、指导原则、原 理、之前构建的项目概要和存储库。在 SOA 领域,这特别重要,因为 SOA 的优势就在于其重用,允许使用者订阅满足其需求的服务。 资产可以包括:行业程序包、标准、最佳实践、原则、模式、开发指南和之前的项目存储库。
定义解决方案时利用之前的经验教训(使用已经建立的服务和适用的资产)可帮助:
实现重用。 减少开发工作。 尽可能降低风险。 提高效率。 不幸的是,并非所有项目都利用了资产重用。经常是这样,没有研究现有的内容就开始新项目,因此进行很多重复工作。SOMA 已被视为是支持 SOA 开发的实际 方法(或能力模式)。
面向服务的建模与体系结构包括服务、组件和流(通常是服务的编排)的三个大步骤——标识、规范和实现。有关更多信息,请参见参考资料中的“面向服务的建模和体系结构”。SOMA 的下一版本将进行扩展,以支持从认识到实现的全部 SOA 开发过程。
SOMA 引入了八个新的规程和其他一些功能模式。在这八个规程中,利用现有资产贯穿 SOA 开发过程的整个生命周期,从而满足资产重用的需求。在每个阶段(标识、规范、实现)的最后,都会执行名为“服务构成与合理化”(service factoring and rationalization) 的任务来支持重构流程。此任务确保我们确认拥有什么资产(包括服务)并确定哪些资产可以进入下一个阶段。这是一个迭代的过程,设计用于提供质量检查、降低 风险、尽可能减少浪费和最大化重用。