一般情况下，SOA呼声最高的是各种技术平台下的应用集成，似乎快速搭建应用的各种技术把人们的眼球全部都吸引光了，而在数据方面却很少有人会静下心来好好思索，为什么一定要等到发现集成过程中因为数据的原因才回头来关注它呢？毕竟，人的精力有限，但抓问题主要矛盾的同时要先将基础性工作搞好，否则就事倍功半了。 采用了SOA架构允诺通过将业务功能和流程分解成离散的服务来进一步解耦全局应用。同时，它使得企业计算的“资产”可以得到更多的复用，SOA实现模式成为前一种应用开发模型的主要的迭岱。象大多少应用开发的演进一样，SOA方法在应用层注入了更多的层和灵活性，但经常是忽略了所有应用最基础的内容：低层数据。

　　我们先来看看大多少IT组织当前的数据环境吧。可以说，一个典型的组织数据环境就是数据总是不在其应该待在的地方，从企业视角来看，就是经常对于存储和处理数据缺乏一个统一的来源以及技术。一般说来，没有一个单一的系统可以提供组织核心业务对象的完整视图，因为大多数大型IT组织都把他们核心的企业数据分布得到处都是，跨越多个竖井式系统。企业中每个系统都有其各自的上下文环境，而没有整个企业的上下文的概念，来维护他们各自的数据。数据质量以及互操作性问题很多，特别是当数据消费系统访问各种数据产生系统时，每个数据产生系统都有对企业数据的独立视图。这些不同导致了业务流程的不一致和不精确描述。下图给出了这些数据访问与管理方面的挑战，影响了SOA变革的进程。

　　SOA变革放大或说是恶化了组织存在的数据问题。因为基于SOA应用的可集成性，组织将搭建在薄落的基础之上，除非一开始就涉及到当前数据环境的问题。这在很多方面都类似于在垃圾堆积物上搭建高层建筑。

　　这里假设一个企业的供应链系统，有５个独立的系统。每个系统在其各自的部门都认为是提供者数据合理的来源。当构建一个共享供应者数据的服务时，哪里才应该是供应者数据的来源呢？

　　１）５个当前系统中的１个？如果是这样，那么是哪个呢？

　　２）为此创建一个新的数据库，那么这个数据源与已存在的数据源如何关联呢？

　　３）数据必须并行地来源于这５个数据？

　　以上解决方案的每个都有各自的好处和劣势，不存在对与错的问题。现在的关键点就在于这些数据问题必须在实现团队开工之前解决掉。到实现团队接管并开始构建服务和基础架构，组织必须在业务层面解决了。否则，这些数据问题将一直存在并阻碍创建服务共享数据的好处。换句话说，一个服务可能会因为共享一个不完整的数据集而结束，或更糟糕的情况是，功能性错误，因为它没有正确的数据。

　　问题摆在这，至于如何应对，请看下回分解。

　　待续…………