SOA作为一种设计哲学，其核心思想是大规模重用。从技术上，重用一直是软件开发的首要目标之一。在软件技术发展的不同时代，不同的编程思想和语言以不同的方式为重用提供支持。从最早结构化思想下的过程(procedure)或函数(function)，到面向对象思想下的控件(control)或组件(component)，再到现在充斥市场被津津乐道的面向服务架构下的服务(service)，无不试图在计算世界中，寻找一个更加贴近人们在现实世界中思考和解决问题的方式分解软件构造块(buildingblock)，从而构造、执行和管理软件系统，来更好地满足人们在商业活动中的适应性和敏捷性的目标。

　　坦率地说，在大家实际操作过程中，这种努力收获有限。我们能够听到太多来自客户和集成商的声音：

    x服务要能够被共享，需要对未来有一个良好的预测，而这看起来似乎比天气预报的难度差不到哪去。因为业务在不断的调整和变化，谁能够准确地预测未来的应用需要什么？

    x就算我们应用中存在大量的可重用的服务，我们如何能够找到我们需要的？如果没有找到，我们又如何能确定是因为这个服务的确不存在，还是因为我们搜索条件不够充分？

    x或者我们找到了大致我们所需要的服务，但它大部分情况下不是刚好业务需要的。就比如我们有一个客户资料查询的服务，它可能缺了几个我们刚好需要的字段，或者有某个特殊字段因管理或者安全策略需要，只对特定业务人员可见。这使得服务的创建者不得不为这个服务重新包装无数的版本来满足实际业务需要。

　　我相信这些声音对我们大多数人来说并不陌生。很多人乐于将其归结为技术层面的制约，我部分同意。从我个人观点来看，正是这些问题促进了软件工程学和工具厂商的发展和创新，使得大多数的问题，我们可以从方法和工具层面得到答案，比如top-down的EA架构方法，服务总线、服务注册和元数据仓储等工具都能够提供辅助支持。我在这里不打算就此来谈，有时间可以专门拿出一块来和大家探讨。事实上，我们更多地发现，不管架构师和开发者们技术上如何努力，影响重用更深层次的原因，是因为组织文化的障碍。企业缺乏分享的组织文化，是制约重用的最大的绊脚石。

　　在一个企业信息化过程中，有太多这样的故事。我们看到，每个业务线都不愿意开放自己的服务给其它人共享；即使一个某条业务线已经创建了一个服务，能够为其它业务线的应用共享，可以带来成本降低，加快应用的交付，但往往那些业务线的IT经理们很少愿意去使用这个服务，因为他不确认这个服务的质量会给他的应用带来什么样的风险，因为它不被自己控制，而宁愿去选择不断“重新发明轮子”。记得很久前曾经在电视上看过的一个游戏。游戏规则其实很简单，让现场几个人站起来在一分钟之内做出十种以上的穿着变化。我看到有人摘下帽子，有人脱下西服，有人解开扣子，有人摘下手表，有人挽起袖子，有人解开皮带（就差没把裤子脱下来），但很可惜没有一个人能够在规定时间内完成任务。没有一个人想到过从别人手上接过西服，带上别人的帽子或者手表，来帮助自己赢得游戏。人们内心更喜欢自我控制而缺乏分享的精神，在分享面前首先想到的是失去什么，而从未想到能够得到什么，这正是大家失败的地方。Web2.0之所以能够成功，正是在于互联网带来的“参与、共享”的心理变革。而这种变革，正是企业实施SOA不可缺失的重要部分。

　　勿庸置疑，SOA的成功实施和价值体现在于大规模重用。为了重用，企业必须在组织内部推动文化变革，改变传统以项目和应用为基础的IT交付方式，建立一种有益于跨部门的参与和分享的文化、组织和制度。这需要得到来自高层的支持，强烈的认同感和持续不断的努力。不知道有几个CIO能够幸运地同时拥有这三点？