SOA的这种理念在上世纪70/80年代就有了，其原型是CORBA(Common Object Request Broker Architecture，通用对象请求代理架构)，限于软件技术和产品的局限性，一直处于被谈论的境态。
在1996年，有Gartner给出了SOA的具体定义。2002年12月份，又是Gartner给出了“指导性意见”说SOA是“现代应用开发领域最重要的课题”。2005年前后，各IT厂商风起潮涌般的争相提出自己的SOA理念、产品，以及所谓的解决方案。可是，企业接受这些东西吗？曾经采访过的国内一家大型企业的CIO直言：不采用SOA，也把企业内部的IT架构搭建和管理的很好很完美。
现在，是SOA落地的时候，但它似乎是“遇土而入”，企业找不到成功的案例。SOA似乎成了IT界的一个“圣杯”，人们现在明白喝了“圣杯”里的水可以使自己的IT架构驱除病魔，永葆健壮，可是有谁喝到过“圣水”，或者说，有谁真正看到过“圣杯”?
对于部分企业来说，试着实践SOA已经是刻不容缓的事情。但是对于有的企业来说，仍有许多还要再等等的理由。一方面是因为还看不到成功案例，另一方面则是因为市场过于混乱，以致于有意愿尝试的企业，决定凭借自己的经验来实践SOA，而意愿相对低落的企业则选择持续观望。除此之外，包括SOA实施顾问还需要时间来养成、SOA成效难以评估，以及SOA方法论还在演变都是影响市场发展的关键因素。
先期导入者必须对系统架构有充分的掌握度
事实上，SOA在市场的发展，过去几年都还是处于市场“教育”阶段，一直到去年下半那年才逐渐有概念验证的项目出现。目前为止，仍旧没有任何一家IT服务厂商真正拿得出成功案例。关键在于先期实践者对于IT服务厂商的不信赖，而IT服务厂商的顾问又必须仰赖项目经验得以养成。
对此，IBM、BEA(已经被甲骨文收购)、微软以及甲骨文(Oracle)等都纷纷表示，顾问的养成固然需要依赖项目经验累积，但是在此之前，各个公司内部都有一套培养的方法，其中，除了来自国外的项目经验技术转移之外，各个IT服务厂商也会定期把顾问送到国外培训。
然而，即便如此，市场调查机构IDC企业应用研究经理曹永晖毫不讳言地指出：“SOA顾问的养成会比ERP还要难”，因为SOA的复杂度不仅具有产业差异，甚至就连每一个公司的SOA都会有所不同，相关的顾问除了需要产业经验以外，也必须经过多个项目的历练，才能针对不同企业的系统与流程做出适当的判断。
除此之外，SOA成效难以评估也是另一个让企业迟疑的原因。根据目前已经投入SOA的企业来看，大多是因为已经有具体的目标想要改善，例如：缩短应用系统的开发时间，进而达到实时响应市场需求(Time to Market)的目的等，因此这些企业大多是亟想验证SOA可行性的一群。一般来说，验证之后就会进入真正的实践阶段，其中甚至很少看到企业具体评估SOA的效益。
从局部开始慢慢扩大导入范围，才能快速展现SOA效益
企业为了快速掌握SOA的经验与效益，现阶段大多会采取局部导入的做法，这样不仅可以降低风险，也可以快速展现SOA所带来的效益。对于许多大型企业来说，即使非常认同SOA、也有实作经验，都不可能因为要SOA就大幅翻新系统架构，除非正好有这个计划。
值得一提的是，有一些大型企业过去为了加速系统开发的时间，对于不熟悉的应用或是超过既有人力负担的需求，都会透过外包开发的方式完成。长期下来，这些企业的IT人员可能会逐渐偏重业务分析，进而无法充分掌握系统架构。而类似于这样的情况，也会影响到该企业对于SOA的实践能力，所需要的摸索时间也会变得更长，因为SOA不只是应用开发层面的问题，更深的意义在于系统架构的转变。
如果企业本身无法充分掌握相关技术或是系统架构，不仅容易被IT服务厂商牵着鼻子走，也容易陷入产品面的功能比较。然而，SOA并非一定要透过新的工具才能实践出来，重要的是，系统的沟通接口要遵循开放标准，才能真正达到SOA松散耦合的诉求。
关于SOA不可不知的8件事
1. 不要只是为了SOA而SOA，进而陷入追寻新科技的无限循环。
2. 实践SOA的人力与时间成本，将会随着应用范围扩大而增加，一般来说可能会增加20％～30％左右。
3. 对于才刚刚在市场迈入实践阶段的SOA，概念验证仍是必要的做法。
4. 不是每一种应用系统都适合SOA，衡量的关键在于系统与业务之间的关连性。
5. 为了避免业务模式改变，共享业务模块的建模时间，最好不要超过6～8周。
6. 共享业务模块切割出来之后，必须保持后续调整的弹性，才能针对不同阶段的需求，达到共享业务模块最佳化。
7. 开始实践SOA之前，最好先厘清系统架构，才能避免被牵着走的情况发生。
8. 从局部开始慢慢扩大SOA的范围，除了可以降低风险，也可以快速展现效果。