几乎以前你所知道的每一件关于商业计算的事情都随着SOA而改变了……
3. 从IT的方面来说，SOA必须渗透到组织内部
SOA也许开始于特殊工程工作组，或以经理人团队的官方正确说法——一个“科研中心，”但是它并不就此停止。然而经理人也许不会持怀疑的态度来看待试点项目，因为他们鼓励创新，他们确是将科研中心视为一个可能的瓶颈。
“你开始于科研中心，以及作为建筑根基的一部分人，” Michelson在解释来自高层的观点时说到。“他们启动你的SOA计划以及你的蓝图。他们定义出示的基础服务。他们做一些早期的商业服务。他们做一些试点项目。”
尽管如此，一旦试点项目完成，科研中心的角色需要变化，否则SOA也许会在中途夭折。
“你不能和科研中心共处，”BPMichelson说到。“几乎从一开始，你的科研中心就是一个瓶颈。你确实需要移动并将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从根本上改变了市场，”BPMichelson回忆到。“他们购买软件的方式在改变。”
一些经理人不打算“将来购买软件。”很多正认购将软件作为一项服务(SaaS)的方式，或是他们希望能获得免费的开放源软件。Michelson发现对旧的购买单独的软件包——在营销化的概念中被称为系列产品的方式几乎未获得任何支持。
Michelson回忆说：“当我们询问集团：这些服务来自于何处?他们告诉我们，它们实际上可能来自于任何地方。一些可能是内部构造。它们将会扩展已有的功能和数据。实际上，一位CTO告诉我们‘我所需要的用来运转我的业务的95%的功能和数据都是已经存在的。我们只是无法获得它们。它们在业务流程中并没有被统筹安排以使其对我产生作用。’”
供应商的唯一亮点可能是为那些销售平台所预留的。
在与CIOs和CTOs谈话之后，Michelson总结到：“他们所采取的方式是他们将购买应用平台，接着获得免费的服务。”
网友评论