【TechTarget中国原创】几乎以前你所知道的每一件关于商业计算的事情都随着SOA而改变了……

　　对象管理组织(OMG)的SOA社区，一个由BEA系统有限公司、思科系统有限公司、IBM以及SAP AG所成立的，专注于SOA并把它作为商业策略的社区公布了从最近CIOs和CTOs行政首脑会议上所收集的五大启示，这是来自于CIOs和CTOs启示的高度总结。

　　不是所有的实际简介对SOA架构和开发者周期都有着非常具体和准确的定义，来自于行政人员的观点预示了一个正在酝酿中的商业计算和软件上从上至下的解决方案。被邀请参加该社区高级会议，并承诺对个人的观点采用匿名的形式的CIOs和CTOs，也了解到面向服务架构的变化以及IT将如何与企业的业务更好的合作，并准备重组各个部门从而在之后的实验阶段完全实施SOA。

　　就这个SOA社区本身而言，它所推崇的是“SOA意味着商业”，所以它并没有像其他大多数SOA组织那样，把重点放在了技术实现上，相反，整个社区对如何实施SOA所应该使用的技术不是特别感兴趣。Richard Mark Soley，这个SOA社区的执行董事，OMG的主席兼CEO说到。

　　“现在已经存在很多关于面向服务架构以及它是如何影响你的技术基础设施的信息，但对于我们来说SOA意味着商业。SOA不是等同于技术。它是一个商业策略，专注于业务的敏捷性。”在圣地亚哥举行社区就职会议之前，他在一个网络采访中表述了如下的五大启示。

　　根据改社区对外宣传负责人，同时也是搜集和提炼建议研究专员Brenda Michelson的观点，在前五大启示中所展示的，也是CIOs和CTOs最想谈到的。

　　1. 不要人工分离SOA和BPM

　　“CIOs和CTOs不会人工的将SOA和业务流程管理(BPM)分离。” Michelson说到。

　　她想起一位CTO曾告诉她，“你知道，SOA、BPM、精益生产、六西格玛基本上是一样东西。它们都是关于商业策略和结构的。都是关于商业转换。而且它们都必须同时工作。”

　　SOA供应商的营销人员也许会提倡将SOA和BPM分成特殊的产品类别，Michelson说到，但是“我们所提到的CIOs和CTO是中没有人打算做这个。”

　　“当他们想到SOA时，”她解释到，“他们考虑的是一种自上而下的商业观点。他们首先看他们的业务流程。他们开始发现并讨论他们的业务单元，在那个业务流程中包括了哪些业务活动。这个业务活动是怎样与他们的资产负债表相关的？为了实现这些活动需要哪些服务？”

　　在定义他们的术语时，她说，经理人开始于商业服务，而不是Web服务。

　　“当他们谈论服务时，他们已不再是谈论我们能在面向服务架构中实现的那些离散的服务，” Michelson说到。“他们在说存在由人来实现的服务以及由机器来实现的服务。”

　　在SOA高层会议中，根据经理人的观点，服务的建模起始于商业。

　　“预期执行系统，他们更想能执行他们的商业模型，” Michelson说到。“其中一位CTOs谈到在未来仅仅将“system”这个词语从其商业伙伴的语言中消除的将是多么的重要。所有他们想要讨论不过就是业务流程、活动以及服务。当你开始谈论系统时，你就潜在的约束了自己，因为你一开始思考的就是你已经拥有了系统A和系统B，以及他们所能做的事，而不是我想尽力实现的东西。“

　　2. 成功，需要业务和IT的协作

　　统一业务和IT的话题已经在SOA的讨论中谈的很多，但是Michelson指出这是社区的一个基本前提，并且也是高层会议中经理人所谈论的热门话题。

　　“当我们讨论这个前提时，我们说今天在一个企业所发生的一个商业策略或许会或许不会影响IT策略，”她说到。“商业策略影响商业需求。但是我们所重复看见的是IT解决方案的失败，不管你是购买的，或是自己建造的，IT解决方案实际上都最终都将影响业务流程。接着将发生变化的是你的商业架构，结构、流程、政策都将变为IT解决方案的结果，这与IT解决方案的驱动因素相对立。”

　　Michelson说经理人首先想将旧的IT方法导向业务。SOA使旧的实践过时了，那时IT能购买或开发软件，然后向商业人员解释这个软件是如何帮助他们的。

　　“在SOA中，我们正看到业务和商业之间更多的前台协，”Michelson说到，总结经理人的观点，“你使一个商业策略影响了你实际上计划的业务架构。这个商业策略和IT策略统一在一起，并为对方服务，因为存在很多技术进步将影响你的商业策略的样子，而你的IT策略影响你的企业架构。你的商业架构和你的企业架构相关度很搞。”

　　3. 从IT的方面来说，SOA必须渗透到组织内部

　　SOA也许开始于特殊工程工作组，或以经理人团队的官方正确说法——一个“科研中心，”但是它并不就此停止。然而经理人也许不会持怀疑的态度来看待试点项目，因为他们鼓励创新，他们确是将科研中心视为一个可能的瓶颈。

　　“你开始于科研中心，以及作为建筑根基的一部分人，” Michelson在解释来自高层的观点时说到。“他们启动你的SOA计划以及你的蓝图。他们定义出示的基础服务。他们做一些早期的商业服务。他们做一些试点项目。”

　　尽管如此，一旦试点项目完成，科研中心的角色需要变化，否则SOA也许会在中途夭折。

　　“你不能和科研中心共处，” Michelson说到。“几乎从一开始，你的科研中心就是一个瓶颈。你确实需要移动并将SOA扩散到你的整个组织。”

　　一些CIOs告诉Michelson，他们已经将科研中心从试点开发过渡到了企业开发团队的培训和协作。

　　“CIOs告诉我们科研工作中心与开发项目团队相协作，并且告诉他们关于SOA的标准和时间，”她说到。“从开发项目来说，你一开始将SOA扩散到开发组织。最后，科研中心再一次重组，而它的工作变为治理和协作。到时开发组织负责SOA的执行。”

　　4. 重大的业务影响，极少的行业重点

　　如果CIOs和CTOs有关于SOA的主要控制权，也就是说软件产业是不公平的，也不会提供转换为SOA时对业务影响的支持。

　　比如说，Michelson说到，“CIOs所面临的挑战就是服务版本，而且现在没有能够确实的掌握操作服务版本的方法。他们所知道的只是如果你仅仅打算生产一个服务版本，是相当幼稚的。和我们进行谈话的人都拥有140-250个服务，这些服务被用于9-95个组合应用中。只要你开始引进变化，就会进入一个绝对漂亮而复杂的环境中。”

　　测试和治理供应商的营销人员也许会承诺帮助解决这个问题，但是在执行团队中可能会重复Edward Deming的老说法，“除非你是上帝，否则任何人都必须依据事实说话。”尽管倾尽全力，他们也无法确定那些推销的技术中哪个更适合自己的工作。他们有一大堆问题，他们需要答案。

　　“他们谈论很多关于测试的话题，以及你实际上应如何测试你的服务客户和服务供应商，” Michelson说到。“你如何使这些测试同步?以及你如何开展测试?你如何能在同一时间将每一件事情都测试了?这又回到关于测试对你的版本实践有何影响的问题上了。”

　　她说当讨论转向变化管理时，尤其是他们在何处进行敏捷开发，他们没有发现技术所能处理的情况，在该种情况下“你每两周引进一些东西，而且你拥有该项服务的95个顾客。”

　　CIOs告诉Michelson，他们想发现更多的产业重点技术来支持一个大的SOA环境的运作。

　　5. SOA对应用软件提供商而言是游戏规则的改变

　　这个其实也许能给推销产品的供应商一些不眠之夜以支持SOA。

　　“一个CIO告诉我们，SOA从根本上改变了市场，” Michelson回忆到。“他们购买软件的方式在改变。”

　　一些经理人不打算“将来购买软件。”很多正认购将软件作为一项服务(SaaS)的方式，或是他们希望能获得免费的开放源软件。Michelson发现对旧的购买单独的软件包——在营销化的概念中被称为系列产品的方式几乎未获得任何支持。

　　Michelson回忆说：“当我们询问集团：这些服务来自于何处?他们告诉我们，它们实际上可能来自于任何地方。一些可能是内部构造。它们将会扩展已有的功能和数据。实际上，一位CTO告诉我们‘我所需要的用来运转我的业务的95%的功能和数据都是已经存在的。我们只是无法获得它们。它们在业务流程中并没有被统筹安排以使其对我产生作用。’”

　　供应商的唯一亮点可能是为那些销售平台所预留的。

　　在与CIOs和CTOs谈话之后，Michelson总结到：“他们所采取的方式是他们将购买应用平台，接着获得免费的服务。”