奥本海默基金公司从其面向服务架构部署中吸取至少两个经验教训：一是业务驱动技术而非技术驱动业务，二是尽早切换到敏捷开发过程中去。
奥本海默基金公司曾经有过数据接入问题。客户在其网站上更改的地址信息须要手工的再次录入到不同的后端系统中才能生效。
公司的架构助理副总裁Geoff Youell 说：“好消息则是从这些问题中能够看到我们的业务在增长”。但由于整合问题，记录与业务保持的测量却不是很好。他说：“同一条信息需要重复好几次输入到之前的遗留系统里边。”
摆在该公司面前的选择就是：要么立即解决这个问题或者是投入一些时间和资金做好长远打算。该公司请了一位顾问考虑了一下在未来五年内真正想要做的事情。Youell说主要的任务就是瓦解筒仓(Silos)并且消除冗余流程。
这个战略的基石是一个能将各个业务组件组合成面向服务架构(SOA)的企业服务总线(ESB)。该项目在内部被称为"巅峰"(Capstone)。
其实单一的门户就可以满足这个公司迫切的需求，它能将面向单一用户的应用程序与需要连接的数据库整合起来，但不会有测量功能。
Progress软件的首席技术官Hub Vandervoort 认为Sonic ESB允许开发人员位整合建模而不是为每一个连接进行编码。Vandervoort 说：“实际上这更容易为商业分析师所理解，同时也更容易进行改动并且不需要同等复杂程度的Java代码编写与测试。”
他指出奥本海默基金公司当时已经为自己的网站接口使用了一个WebLogic门户服务器，辐射状(hub and spoke)整合工作。他说：“对于小型的整合来讲这也许是足够的。但当地理上分散的信息、筒仓式组织以政治组织的形式联合时，你就要问问自己谁才是这其中的主宰。你需要一个高度分布式环境，因为不仅仅拓扑布局需要，业务本身也需要这样的环境。”
他说企业服务总线(ESB)从本质上说是分布式平台，能够接入不同的遗留系统合前端系统。接着，兼容性、管理与安全特性才适当的建入ESB里。
奥本海默基金公司的Youell说：“对于我们来说这是一次后端整合与对于遗留系统的暴露。”
初步研究涉及到参考Forrester 和 Gartner研究报告作为背景资料。近期才加入该公司的Youell还聘请了几名架构师。这个团队很快就得出了短短的一个厂商列表，包括Tibco, BEA以及它最终选择的公司Bedford――麻省的一家软件开发公司，Sonic ESB的制造商。
Youell 指出Sonic ESB是建立在高可用性的容器中的，他说：“他们的部署模型和定价战略尺度非常好。我们有许多个部门和地区办事处，他们的容器定级却没有额外费用产生的方式对于我们来说很重要。并且它的工具箱已经相当成熟――一年半以前就已经发布了，而其他的厂商在这方面没有这么成熟。”
Youell说这是一个很好的决定，他们成为了我们很好的战略伙伴。
他们从事的第一个项目是更换面向客户地址的Web应用程序。Youell说“尽管我们在此之前已经获得了一些技巧，但我们在这个领域还是相当的不成熟。我们决定为持股人和顾问建立网站的Web开发团队应该是变革最好的开始。”
以前，当客户使用网络更新地址时需要一个奥本海默基金公司员工5到7分钟来处理更新。结果，该公司并没有特别的推行网络为基础的功能。后端流程一经自动化，该公司就开始大力推广自助服务功能，于是所有地址的70%通过网络需要更新。
他说：“这是一个巨大的市场胜利，为建立SOA项目创造了动力。我们成功的一个因素在于刚一开始就得到了一些合理的投资回报。”
由于地址变更只能是以服务的形式编写的，因此它能在多个渠道进行重新利用。例如，下个月公司将把客户电话服务中心应用程序将新的地址变更功能连接起来。
Youell说要把地址变更功能由代码变成一个SOA服务还需要一些额外的工作。他指出：“但好处是可重复利用，突然之间，你可以在整个内部渠道中重新利用这个服务。”
在地址变更之后，下一个服务就是更新银行信息。
以这两个小服务试水之后，巅峰小组开始追求更大的目标：纸质文档。Youell说：“我们工作的主要内容都是通过电子方式传递的，但仍然有40%的工作是以纸质文档的方式。人们将应用或交易以邮件发送进来，我们使之成形，然后就能在屏幕上得以体现，人们可以将之输入他们的应用程序。”
该项目旨在部署一个新的成像应用程序，以更为有效、更自动化的方式将工作在公司内传递。也就是说，如果一个客户发送进来一个采购单，在以前会有人去确定它的路径，如果需要税务号码会有人去查找然后录入。
Youell说：“ESB事实上覆盖了8个不同的遗留系统。如果你已经拥有了客户的信息，ESB会在工作传递过程中将该信息拖入以丰富工作项目。”
这需要将ESB和这些应用程序进行整合。AS/400的和Sybase有遗留系统可用的网关产品。甲骨文数据库也可以通过JDBC(Java数据库连接)服务电话来访问。
Youell说作为巅峰项目的一部分，奥本海默基金公司计划建立一个数据仓库，但即使是没有数据仓库，ESB也知道从哪里获取并抽取数据并得出同样的结果。
他补充说成像项目7月上线，目前为内部大约1000名呼叫中心、处理和管理小组的员工所使用。
Youell说：“我们将巅峰项目的第一阶段作为基础，在整个企业范围内安装了坚实的ESB和成像产品。在此基础上，我们决定要向全面变革模式转换。”
在现实中这意味着要整理一个SOA项目的期望列表，根据业务价值对其进行优先排序。那么哪一项应该排在第一位呢?简化内部应用程序界面的项目。目前，我们拥有22个还在使用的遗留应用程序，被服务代理人员为客户提供不同的组合。任何一个相关的雇员都可能需要了解其中十几个服务。
最新整合的界面将使用Adobe Flex建立，Web服务使用ReST接口。ReST(代表性状态传输)是支持Web2.0的SOAP(简单对象访问协议)的替代选择，在富网络应用中使用很多。
Youell表示这个项目的工作从8月开始，首次展示定于今年年底，整个项目计划于2009年底结束。
另一个应予最优先考虑的是新的工作流系统。Youell说：“我们有许多遗留应用程序，设计大量手工操作。因此你可以以许多种方式来服务客户。我们目标的之一就是标准化流程。”
工作流项目启动于9月，需要几年时间来完成。总共有25名员工在为这个项目工作，其中10个从事用户界面的工作而另外15位员工致力于工作流。
巅峰项目不仅仅改变了奥本海默基金公司应用程序整合的方式，还为该公司编程流程本身带来了影响。在巅峰项目开始之前，奥本海默基金公司使用的是传统的“瀑布”式软件开发模型。Youell说：“SOA驱使我们从事敏捷开发。当你考虑服务粒度时，敏捷开发也采取了同样的方式。业务需求帮助你将大的功能分解为更小的粒度。SOA和敏捷发挥了彼此的效用，并使得我们的SOA战略更为轻松。”
由于切换到敏捷开发，巅峰项目计划也随之改变。他说道：“我们开始的时候部署了一个多年的商业战略，适合于瀑布式计划。但现在有了敏捷流程，我们将继续使用这些团队直到从他们身上再也得不到任何价值回报。我们将开发小组保留在这些任务上，一旦我们不能从中获取价值回报，我们就可以随时停止。”
就目前的情况来说，这将花上几年的时间来完成订单。
Youell指出这项技术为开发小组带来了意义重大的理念上的转变，那就是开发小组开始更多的考虑商业价值。
向着开发离散服务而非大型软件开发的切换为该公司诸如了活力和兴奋。他说：“这个项目允许引进新的技术，创建新的氛围。”结果技术小组就须要更新他们的技能，这并不像学习新的编程语言或开发方法一样简单。
他说：“我跟所有将这个项目以技术为主的人一样有罪恶感，但还是要找到业务问题并加以解决。因为我们是以商业战略为主的，也了解自己的价值主张。这对于高层管理人员也是很大的帮助。”
Youell说公司的下一个步骤就是着眼于政策的执行，建立更为充沛的安全模型和注册表存贮器。他补充道：“我认为我们目前得到了更多的信息来做出那些决定了。”
他说重要的一点是要确保模型在文档和问题跟踪方面的成熟度，不然你将以蛮荒混乱而告终。公司将在2008年底至2009年间做出关于治理的决定。
Youell表示：如果公司还要从头再来一次，只会有一点不同：那就是直接切入敏捷开发。他说：“我们在最后三个月的时间才转换到敏捷开发。最初的几个项目是瀑布式开发，不能分解成更易执行的更小的组件。”
