【IT168 技术评论】
　　 就像对于任何其他的新技术或新范例一样，每年的这个时候都照例会出现下面这个问题。今年是X真正腾飞之年吗？而今年的X是面向服务架构（SOA）。
　　 我可以确定地说，这是最近几年反复出现的问题。最初是围绕web services的成熟和人气飙升的讨论，随后就快速过渡到更广义的SOA命题。
　　 那么2006年是SOA真正腾飞之年吗？遗憾的是，很难简单地给出肯定或否定的答案。为了澄清这一困惑并试图回答2006年是否是SOA腾飞之年的问题，我使用了两个著名的模型。

　　 Hype Cycle模型
　　 Adoption Lifecycle模型

　　 Hype Cycle模型

　　 蓝色曲线是Gartner的hype cycle，它以图表方式表现特定技术/范例的成熟度、采用度和业务应用。从1995年起，Gartner使用hype Cycles来表现过热（即“hype”）以及随后的失望现象（这在引入新技术/范例时经常发生）。
　　 在2005年7月，Gartner声称web services的应用正在接近“Plateau of Productivity”（生产力成熟期）阶段。这可归因于一些重要web services标准的发布以及在大量工具和产品中的实现。
　　 对比之下，Gartner声称目前SOA正在接近“Trough of Disillusionment”（幻觉破灭期）阶段。SOA用了相当长的时间达到此状态，人们认为SOA对于新技术/范例来说过热了。我相信这是由于“Peak of Inflated Expectations”（期望膨胀期）阶段随着internet用于大规模营销分发而被延长了，SOA被认为是不连续的创新，因为它要求企业和个人改变其现有行为以获益。
　　 随着SOA进入“Trough of Disillusionment”阶段，我认为这是一件好事而不是坏事，因为现在人们的注意力将从市场方面移开而关注SOA的实际交付。

　　 SOA Adoption Lifecycle（采用生命周期）模型

　　 adoption lifecycle模型有时被称为“Belief curve”，用于描述新技术/范例的接受程度。每种规则都存在例外情况，但是此模型基本上以普适方式描述了任何新技术/范例对于各种类型消费者的市场渗入情况。
　　 使用Geoffrey A. Moore修改后的adoption lifecycle并将其应用于SOA，则每个消费者都有许多问题要解决。这些问题如不解决，新技术/范例就会失去推动力。

　　 革新者

　　 革新者应是技术爱好者，他们往往在还没有考虑新技术对业务或IT的意义时就尽快使用新技术。SOA Adoption lifecycle中的这些“技术爱好者”并不试图理解SOA的意义，而仅将SOA视为纯粹的技术游戏。这些公司仍然需要充分理解SOA带来的机会和影响。
　　 集成开发环境已经成熟到可以毫不费力地从现有组件创建web services的程度。这产生了我称之为“右击”架构的东西。
　　 对于希望解决此问题的革新者来说，他们必须理解面向服务架构与Web Services架构之间的区别。SOA培训不仅对执行官们非常重要，对公司的开发社区来说也是如此。管理层必须理解SOA不只是技术游戏，它包含了IT战略的所有方面；开发人员必须明白仅仅开发JBOWS（Just a bunch of web services，一组web服务）并不是SOA。直到双方都理解了这些，SOA提供的大部分好处才会得以实现。

　　 早期采用者

　　 早期采用者先期体会了新技术/范例所带来的战略业务影响，并利用它赢得竞争优势。这些有远见的人并不只是在单一项目中采用SOA，而是将其视为企业级计划的一部分。
　　 大体上，BEA看到了一种趋势，某些行业中有更多有远见的人正在将SOA作为一种生活方式。其中两个坚持下来的行业是电信和金融业。这并不奇怪，因为这些行业有投资新技术/范例以赢得竞争优势的传统，这是因为他们各自行业内部的发展潜力在不断缩减。紧随这两个行业之后的是政府部门，它们正在考察SOA，以便更好地为政府部门之间的信息共享提供帮助，并将其作为支持民众自我服务自动化的方式。
　　 看得更远的人已经看到SOA所面临的挑战与获益一样多。有远见的人已经在业务线内部署其初始项目的时候看到了许多获益。但是当这些有远见的人在数条业务线上扩展其项目时，却没有获得与在初始项目中所获得的相同等级的好处。这主要是因为额外的人员介入和交互所带来的额外挑战。一些副作用和影响造成了问题，例如服务蔓延（部署了100个服务，却没有消费者，或者存在数十个事实上具有相同功能的服务）的问题。
　　 对于要解决此问题的早期采用者来说，他们必须意识到需要有一个承担所需的决策和责任问题的SOA管理模型。这需要早期采用者具有用于解决SOA的政治和文化转变方面问题的意志力和威信，并意识到工具本身（如服务注册库）只能作为辅助手段而不是最终解决方案。
　　 除非公司拥有综合的SOA管理战略来解决这些风险，否则SOA所提供的获益将无法实现，而早期采用者可能以多个被封杀的SOA解决方案收场。正是由于这个原因，BEA开发了自己的SOA管理框架，它可以帮助公司开发和设计自己的SOA有效管理决策和责任框架。

【IT168 技术评论】
　　 早期的大多数采用者

　　 早期的大多数采用者代表主流市场的前半部分，并以实用主义出名。这些实用主义者并不希望被视为先驱，而是会采取有计划的方法。他们理解SOA的业务获益，但是对他们认为存在高风险的事情采取反对冒险的态度。
　　 当涉及到SOA时，早期的大多数采用者希望确保所有SOA产品都经历了多个发布版本，而且发布的web服务标准已经成熟到一定程度（受大多数主流产品的支持）。实用主义者倾向于从财务状况稳定的、具有提供优质、稳定和成熟产品名声的知名专业供应商处购买产品。他们倾向于等到供应商市场成熟，存在2－3个专攻其SOA需求的主要供应商的时候，这样有助于降低成本，并具有迁移到替代方案的安全保障。
　　 实用主义者看重同行的经验，并希望从早期采用者那里学习最优方法并从业内其他公司处获得详细的案例分析和参考。
　　 对于要解决此问题的大多数早期采用者来说，他们选择的供应商必须具有可靠的案例分析和参考，以及一套使他们确信SOA计划不是高风险活动且可通过递增和可度量的方法以不断发展的方式交付SOA的SOA方法学。最近许多小型SOA供应商的合并表明，SOA供应商市场正在逐渐发展到存在2－3个能够提供期望稳定性的主要供应商的成熟程度。
　　 BEA一直是革新者，因此吸引了电信和金融业中的大部分早期采用者，因此BEA具有大多数早期采用者所要求的大量案例分析和参考。此外，BEA具有已经验证的递增SOA方法和专业的SOA产品线。

　　 后期的大多数采用者

　　 后期的大多数采用者代表主流市场的后半部分，并以保守主义出名。大多数后期采用者往往犹豫不决，因为SOA被列入不连续的技术/范例，这是保守主义者所不赞同的，因为它需要在企业内进行政治和文化转变。保守主义者更原意解决当年的目标，而不愿将注意力放在影响企业多年惯例文化的技术/范例上。
　　 保守主义者将等到SOA不只在本行业内而且在多个行业都成为确定标准的时候。最后，在进行大量投资之前，这些大多数后期采用者会要求许多跨行业SOA参考以及非常详细的ROI业务案例。
　　 这些保守主义者倾向于拖延任何重大技术决策并往往成为追随者。因此对于要解决此问题的大多数后期采用者来说，他们将等待SOA到达hype curve的末期并达到“Plateau of Productivity”阶段的时候。

　　 落后者

　　 落后者和SOA的怀疑论者或者没有全面理解SOA，或者认为存在更好的获得SOA所提供获益的不冒险的方式。
　　 怀疑论者认为SOA仅是营销和宣传手段，而SOA的获益和方法与之前吹捧的组件重用方法没有区别。既然组件重用并没有交付获益，SOA又凭什么能做到呢？这次的区别是市场已经发展并成熟了，现在我们有成熟的开发人员产品、用于互操作的web services标准以及知识和经验，这足以使我们认识到SOA不仅仅是技术游戏，它还需要有其它的IT规程（如管理、产品组件管理和灵活的方法学）才能成功。
　　 一些落后者意识到了SOA试图解决的问题，但认为采取单一供应商针对业务应用程序的方法会解决此问题。具有讽刺意味的是，这些ERP供应商需要中间件产品来融合这些独立的业务应用程序。在这个瞬息万变的时代，公司需要及时部署新产品、新服务并改善客户关系。但是过去的事实显示，ERP倾向于减弱公司的竞争优势，因为公司只能根据ERP标准流程调整公司流程而不是根据公司流程调整ERP流程。
　　 一些落后者会等到SOA达到其采用高峰，然后尝试跟上他们的竞争者。这可能会付出巨大的代价，并会引起混乱，因为SOA需要进行文化转变，而后者需要时间来获得一些学习经验。因为时间对于落后者来说极其重要，所以当落后者尝试加速文化转变过程时，这就会给他们施加更大压力。所以落后者事实上更可能失败。

　　 SOA成熟度

　　 即使公司决定使用SOA作为构建系统的方法，还是不足以回答关于SOA是否是主流以及2006年是否是SOA真正腾飞之年的问题。
　　 随着SOA市场的成熟，需要新的和改进的方法和软件。SOA的主要优点是，它通过允许对不同服务的访问，使得业务流程的创建和更改更快、更轻松。实现复杂流程本身就具有挑战性，而新的专门用于构建、部署和度量这些业务流程的平台看上去就像是面向未来的技术。
　　 回头再看hype curve，您会发现，BPP业务流程平台仍处于“Peak of Inflated Expectations”阶段的底部。这意味着一家公司需要承诺在多条业务线上交付多个系统/业务流程才能被视为SOA主流的一部分。此外，公司必须意识到SOA是一个过程，需要多年多阶段的集中计划以引导公司走过此历程。

　　 这就提出了以下的问题：
　　 “一家公司的SOA计划必须达到什么水平的成熟度才能被视为主流的一部分？”

　　 “如何度量一家公司的SOA成熟度以及这家公司的IT规范的成熟度？”

　　 为此，BEA开发了SOA Maturity Matrix（成熟度矩阵），它涵盖了成功的多年多阶段SOA计划所需的6个领域。