当提到SOA项目时，很自然就会联想到各种标准。比如，SOAP如何工作?什么是WSDL?UDDI在哪里装配?我们应该使用XSLT吗?开发人员也很容易只关心某个部门要得非常急得某个项目。

　　但是，Transamerica人寿保险公司养老金产品与服务分部的IT策略主管Jeff Gleason说，只关心标准和技术或者只关心某个应用都会看不到SOA的精髓所在。其中，看不到全景和忘记SOA中最重要的是架构就是这种情况的一种表现。

　　Gleason曾经是一名一线的Java程序员，2003年加入Transamerica公司，参与构建了一个大型远景来观察面向服务架构能够为公司带来什么。而其中主要的一点就是SOA。如果能正确实施的话，会拥有比仅仅开发一个通过XML标准来通讯的应用更有意义的大项目，它和这种技术本身同样重要。

　　他说:“与其说SOA是一种技术，倒不如说它更是一种架构和设计。”而这种需求比编写新的代码要更加重要。

　　当他在Transamerica公司开始工作时，他花费了三个月来研究现有系统以及它们如何支持业务过程，并指出这些系统和过程之间存在的鸿沟。然后，他开始研究SOA能如何弥补这些鸿沟。

　　在从2004年初开始的一个SOA实现中，Gleason和一个由四名架构师组成的团队一起工作，开发出一个全面的考虑独立业务过程的设计，比如接收保单会通过组织与其它过程交互。

　　对于开发人员来说，重要的是不要局限在某个需要特定支出处理系统的部门的需求上。Gleason了解程序员面对的问题。以他作为Java程序员的背景，他说他知道开发人员喜欢赶快写代码，让项目结束，因为这样他们才能得到报酬。

　　这就是为什么他坚持要把SOA不止当作一种商业计算技术，更要当作变更组织行为的一种战略的原因。作为CIO，他让IT管理层接受在更大的框架上构建应用的商业收益。因为在更大的框架上可以获得SOA提供的灵活性和重用性。此外，他还做了一个投资回收期分析，进一步反映对公司的底线收益。

　　他说:“你需要在商业战略和SOA之间建立清晰的关系，否则你就要失败。”

　　他强调在组织中拥有一位有力的SOA推动者的重要性，因为这个推动者能够举例说明重用组建的商业好处，还可以解释如果组织不采用全面SOA框架就无法确定这些组件。在构建不佳的架构中隐藏了可重用的组建，由于无法发现而不能被重用。

　　这名推动者还需要能够从代码中分离业务规则来说明灵活性的好处，这样当市场变化或政府规章改动时，能够不用重写代码来快速修改过程。这里，Gleason警告开发人员不要通过把业务规则硬编码到应用中来加速开发某个项目。

　　最后，推动者成功说服组织采用SOA所带来的远期的业务优势后，他们的工作还没有结束。推动者的工作永远没有终点。还会不可避免的有一些要求涉及到框架之外并要在项目外完成，这样的需求一定要抵制，因为只有这样才能维护架构的完整性，支持整体商业目标。

　　为了让每件事都能完成，Gleason推荐在一个已建好的开发框架中实施SOA。Transamerica公司选择了现在是Sun Microsystems 公司一部分的SeeBeyond公司的Integrated Composite Application Network。

　　他说:“没有框架，我很怀疑你能不能实施SOA。”