SOA绝对不是一个单纯的IT问题，企业必须从业务角度和IT角度两方面出发分析自己的需求，根据自身现状和业务需求确定合适的SOA。如果代码开发人员一直以来都不能为代码使用者提供真正需要的代码开发，那所谓的最佳“企业级架构”将永远无法实现。然而，在现实中，大部分从事代码开发的人并不会把另外一些可能需要到这些代码开发的人当作使用者去对待。这也是面向服务架构(SOA)未能获得成功的原因所在。

　　SOA所能带来的价值已经是清楚的了，在这几年中我们也一直努力创造出SOA软件产品以供使用。我也知道COBOL(面向商业的通用语言，又称为企业管理语言、数据处理语言等，Common Business Oriented Langauge)应用曾经是建立在同样的原则之上。我曾作为一个项目的团队负责人参与了在遵从COBOL 74规范基础之上的超过700个核心功能服务的兴建工作，我们所编写的代码具有着高度的可重用性。当然，这也是我们为金融机构所建立起来的一个竖井中的大型系统。我们以这样的环境需求为基础构建了这一系统，并保证其可以在该企业的其他部门重复使用。

　　对于这份工作我当时是觉得非常自豪的，但是现在回想起来，我们却并不是一个非常好的使用者。我们乐于去试图找到一些非商业定制的应用从而满足我们的主要功能需求，但是却并不是作为自身企业一个好的代码使用者而存在。我们甚至根本没有考虑过从企业现有软件应用的重用方向入手。这个问题直到现在也没有真正改变，因为更多的时候我们只是专注于如何编写代码，并让其实现“可重用”。

　　问题的关键并不是说我们需要从代码的角度去考虑实现可重用。我们必须得明白，这些代码使用者即其他的程序开发人员和架构师。我们必须把自己看作是服务的提供者，为这些使用者创造代码，并准确的提供给他们使用。这些代码必须是易于使用的，必须是很方便就能找到的，必须得到有效推广和准确定位，同时也必须是能够满足使用者需求的，而在做到这一切的前提是我们应该首先成为一个好的使用者，学会如何去使用他们。

　　类似于这样对于使用者的认识以及整个企业和团队中服务的认识可能并不是一个主流的理念。就目前而言，我们对使用者还缺少足够的了解和反馈，仅仅只是感觉上的评断。

　　相对于我们的开发团队，在整个组织范围或者更广的范围内将会有更多的人能够接触到我们所能接触的使用者。如果我和我的团队是为这些使用者的服务提供者，也许在这个领域还有更多的团队是这个使用者的服务提供者，那么我是不是应该提前就问自己一些应该被问到的问题：如果我的使用者能够自主的选择它所需要的服务提供者，那在所有服务提供者都没出错的情况下，我应该怎样做才能确保我会是他唯一的选择，并且能持续不断的赢得这场业务?我应该怎么做才能让我的服务尽可能的便于使用?

　　在当前的市场上有不少杰出的工具可以用来支持这种对遗留应用的再次使用。这些都是资源管理中可以共同使用的内容。对于软件行业而言，这些工具能够有助于度量之前的投资组合在实际消费的可重复使用资产的价值。而这些信息在过去一般来说是不会有的。我试图从这些工具的使用者中整理出一个具有说服力的数字出来，但是，无法避免的是，这个数字绝不会很高。那么，如果我的统计没有出错的话，是什么阻止了我们对可重用代码的重复使用呢?

　　作为软件开发人员我们并不是好的使用者，相比之下我们的同事也许更好的处理好如何去“使用”的工作。当我们要寻找一些有用的东西或者是一些示例的时候我们可能首先想到的是互联网而不是公司内部的资源库。当然，这其中可能的原因是企业内部缺少一个应用能够类似于网络中的搜索工具。但是，更重要的是，当我们在编写代码的时候可能并没有想到会有别的开发人员可以使用这些内容。

　　我们并没有为我们所编写的代码内容创造接口以方便人们能够更好的使用，我们甚至根本就未曾考虑过这个问题。我们不提供设计层次的抽象内容从而有助于其他程序员和架构师能够从我们的解决方案中选出合适的建议整合到他们的方案中去。我们并没有将代码整理给团队中没有参与的人员或者是整个企业范围的其他团队。我们缺乏市场调研，不清楚那么没有使用我们代码的使用者究竟需要什么，无法将我们的代码开发发挥至最大效用。我们没有合理的将代码打包，使得即便选择使用我们的使用者也觉得不易使用。

　　技术支持的工作正是因为我们的这些做法才发展起来并部分的存在于当前的工作之中。我们必须开始将我们的服务提供工作从代码层面转向到人的层面，并更有效的利用这些技术支持。紧接着我们可以利用这些工具更好的辅助市场，并能使我们的代码更广泛的提供给别人。

　　我希望在这些工作之后能够有一些好的度量重用的方式，真正显示出我们艰苦工作后所建立起的可重用软件在重复使用方面的回报。并且使用者的需求将会是真正放在第一的位置。同时，在整个SOA模型当中，服务的有效消费应该是占到一半以上的重要程度。