作为Zapthink的《Justifying&Fundingyoursoaproject》白皮书的第二部分，此章重点讲述了SOA重用和透明的业务价值。可能我们对这两个概念早已耳熟能详，但是SOA到底是如何做到这些的呢，我想恐怕很少有人能够说的清楚。那就希望本篇能够带领读者深入地洞悉这其中的内涵。
拓展现有应用的价值本质上就是资产重用的一种形式。对大多数企业来说，重用是实施SOA的主要动机。SOA也允许通过增加IT资产的重用来消除冗余，这种方式本质上是一种资产回报(ROA:ReturnOnAsset)而并非简单的投资回报(ROI:ReturnOn Investment)。而这种冗余通常是这样产生的:公司为了不同的目标，每次都花费巨资来建造不同的项目，而这些项目的基础却都完全相同。
|
例如，大多数公司在几十年前就建立了第一个客户数据库，但是今天，在实施CRM、ERP、企业门户和基于Web的系统时仍然需要再建造。只有当我们能够从服务中获取真正的重用性时，才能结束这些多余的、不必要的花费。而SOA能够帮助我们做到这些，使得企业能够建造一次服务，而多次使用。
降低冗余度
通过共享服务来消除冗余或许是SOA重用效益的最明显体现，重用长期以来一直是软件开发界追求的目标，但它的实现却远比人们想象的要困难。或许重用性的真正问题在于超越那些特殊的业务需求，对IT资产进行重新定义。如果定义不够清晰、准确，甚至不断变化，试想开发者如何能够开发出可供重用的资产呢？因此，如果对一个可供重用的资产不能进行具体的、可供操作的定义，重用根本不可能实现，而如果一定要开发者实现这种重用性的话，我想恐怕连他们自己也不知道什么时候能够完成。
在许多方面，重用不仅仅是资产建造者的问题，它也是资产利用者的问题。一个开发者可以为一项资产编出上千个版本，从而满足每一种可能的情况，但是到最后往往发现只有为数不多的几个能够被应用，甚至没有一个可以使用。因为尽管种类繁多，但是他们都无法满足一个特殊的或者特定的需求。所以，关键是让使用者去考虑重用性的问题，而不仅仅是开发者。
面向服务的新的魔咒就是广泛适用性的观念，不再是共享代码，服务使用者最终会共享服务。我们不会通过多次的拷贝和粘贴服务来为不同的目标提供不同的服务，同样我们也不会采取相同的方式来使用一项服务。通过在服务协议中涉及各种不同方面，而不是在底层代码中来这样做，我们可以建造一个共享的服务，它具备广泛的适用性可以应用到众多不同的流程和使用者中。而要实现这样的重用，需要仔细地对资产进行分类，还要在服务实现时对相关性进行分析。
如果一项服务负责提供客户数据，例如，12个不同客户需要此项服务能够用不同的方式来展示后台的数据，我们就会陷入重用的难题中，我们是该建造12项不同的服务和12项服务协议呢，还是利用一个具有可变性的协议来应对这些完全不同的需求。第一种情况违背了重用的目标，但是第二种情况下，一个单独的、过度复杂的协议又不够敏捷。那么一个单独的服务配合12个不同的协议则可以考虑，它既方便管理，又保持了敏捷。在这种方法下，我们只需管理12份协议，而不是12项服务，这就大大简化了管理工作。因此广泛的适用性取决于服务协议的管理。
如果人们不能够找到相应的服务或者不能理解如何使用这些服务，建立具有广泛适用性的服务仍然不能保证重用的实现。要想达到广泛的适用性，服务还必须可消费。可消费意味着人们可以实实在在地重用服务。因此对于可以使用的服务一定要有一个注册中心，这样用户就知道如何在这个中心中找到需要的服务了。可消费还需要对服务有足够多的信息，以便人们知道哪项服务是他们需要的，并且知道如何去使用他们。
SOA为重用提供一个实用的途径。但是，只有当事物是可伸缩的，并且易于发现和使用时，人们才会去重用，这是人类的天性。所以在建造服务时，更多地考虑广泛的适用性和可消费性，将会使重用变得更加简单。
提升客户价值
减少系统的冗余并不是重用的唯一用途，事实上，很多企业一直在努力重用良好的客户体验。可重用的、面向客户的服务结合客户喜爱的服务都有利于改善客户体验，并且有利于提升重要客户的价值。
例如，一家零售银行能够向客户提供存款、信用卡支付、财务管理等业务，同时这个大型银行的操作是在相互隔离的部门中进行的。典型的客户体验就是向银行的呼叫中心打电话，去咨询账户信息。但是在这样一个应用竖井中，客户如果希望通过信用卡号码来查询相应余额时，呼叫中心恐怕不能及时地回答，因为请求系统和处理系统是在不同的竖井中的。
其他大型的企业也会遇到类似的问题，因为他们最良好的客户信息被存在多个竖井当中。所以当服务于这些高端客户时，往往不能让人满意。幸运的是，SOA可以帮助你解决这个问题。
这些大型企业需要做到就是构建核心的共享服务，他们能够贯通那些竖井从而服务客户。这些共享的服务往往是在客户相关的服务领域中，例如呼叫中心、网站。
除了技术困难外，这些共享服务的应用问题也要认真对待。需要处理服务提供者和消费者之间的协作问题。服务域是由一系列共享相同业务语境的服务组成。因此，这个服务域必须服务业务的多个方面，并且能够连接不同的IT竖井。建造和运营服务域需要面临一系列的挑战，而不仅仅是技术难题。
提升业务透明度
今天异构环境的复杂性隐藏了企业一些关键的客户和业务信息。而许多企业利用SOA正是为了提升这种环境下业务的透明性。在有些情况下，这种需求往往成为人们使用SOA最主要的原因，因为提升客户价值依赖于改进业务透明度。
管理一致性
没有哪个企业敢忽视管理一致性，执行人员的自由往往依赖于在财政和业务的其他方面保证充分的透明度。
管理一致性是一个相对特殊的业务诉求。首先它要求管理人员必须不惜一切代价，但是事实却是他们往往不愿花一分钱。其次，一致性要求持续的关注，以及在成本、风险和透明性上的平衡。另外，管理经常是随时可以改变的，因此IT必须对这种改变保持敏捷。正因为这些，企业往往寄希望于SOA来帮助他们面对管理一致性的挑战。
一致性的项目往往面临着严峻的技术挑战。尽管企业对于一致性越来越重视，但是在具体的技术实施上仍然未有突破。在很多情况下，一致性的改造往往相互重叠，即使相互独立的执行团队彼此有一些了解，仍然无法避免。
因此，许多企业发现重叠的应用往往需要在一致性的目标下进行整合。离开SOA来实施这种一致性整合往往产生复杂的、多余的基础架构，而这些又引起了高昂的初期投入和额外的管理麻烦。
通过利用SOA的最佳实践，融合了截然不同的一致性需求，并且提取了服务最核心的部分，这样企业就可以集中于创建具有特定一致性需求的服务。在这种方式下，把现有的SOA项目和与一致性需求进行融合就具备了可能性。同时这样也可以保持IT和业务的目标一致。
事实上，SOA简化了一致性的实现。当IT组织将SOA应用于一致性实施时，他们就能够减少多余的购买量，实现低廉的授权费用，利用服务重用提升生产力。
