客户数据集成项目的成败中枢

　　客户获取成本持续走高，企业留住客户(尤其是高盈利客户)正在变得越来越困难，在这种情况下，了解客户已不单只是一句口号。不过要真正了解客户，就必须整合所有独立数据源，建立统一、全面的客户视角，其中包括客户数据库、客户信息档案、账单和订单管理系统、产品目录，以及外部数据服务等。但是，如果使用现有的技术平台来建立并管理这些跨范围数据、应用和渠道竖井，是一项复杂兼高成本的任务，成功的案例并不多见。

　　导致客户数据集成失败的一大主要原因是缺乏灵活的数据模型，也是一些客户数据集成解决方案的软肋所在。此外，如果缺少灵活的客户数据模型，那么项目就会变得更加臃肿，无形中提高了整体失败的风险。

　　因此，对于任何CDI解决方案的短期或长期成功，评估数据模型的灵活性是重要的一环。专家提出，在衡量一个数据模型是否灵活上，企业可以参照以下几条考虑要素：

　　数据模型的可延伸性

　　好比一家餐馆制定的菜单不一定符合每个人的口味，CDI解决方案也要有允许对数据模型进行自定义修改的宽容度。 大部分CDI解决方案所提供的固定数据模型都是从开发者的角度所设计，一旦要将这些解决方案结合用户企业的真实需求，超出它原有的设计框架范围之外时，就表现为无法提供关系架构，也无法延伸自定义。在这种条件下勉强使用，只会让数据模型难以与现有的应用逻辑融合，导致效率低下。

　　理想中的CDI解决方案应当是针对每个垂直行业的不同而提供一个初始数据模型，或者支持导入某种特定的数据模型，这样才能反应出企业的真实需要。除此之外，它还必须提供所有数据支持管理服务，包括拓展元数据管理，促进模型的弹性，应对企业随着时间推移而产生的要求变化。

　　商业服务的自定义能力

　　一套基于固定数据模型的CDI解决方案或许会宣称自己有一个用于提取商业服务的结构层，可以即买即用进行数据集成。然而，如果数据模型的底层被修改，那么这些商业服务还是需要进行自定义。在具体实施中，只要固定数据模型被修改，那么剩下的相关商业服务可能寥寥无几。而且在这种解决方案上自定义越多，未来就越难升级。因此，理想的可用架构必须有一套粒状数据集成服务，包括一整套API，以求在某个服务集成框架组合高度关联的商业服务。这些商业服务与API可以融为一体，便于维护，也方便未来的产品升级。

　　数据种类的选择建模

　　每一种客户数据种类，不管是参考数据、关系数据还是交易数据，都有自身的特点，因此要求在CDI解决方案中以不同的方式对待。譬如储存在多个系统或数据仓库中的参考数据可能是重复、冲突的。而交易数据在重新调试时的冲突就相对小一些。另外，当参考数据只是客户数据下一个很小的子类时，交易数据就会变得庞大，要求在基础设备上作出持续投资来存储源系统的重复数据。至于关系数据，只有在解决底层冲突和参考数据后，才能被有效管理。另外为了进行恰当的管理，关系数据和分组也同样需要成熟的虚拟化工具来体现不同实体之间的复杂关系。

　　合理的数据模型应当只为核心主数据和关系数据建模并存储在客户主数据库中，而交易数据则应基于底层源系统的特征来选择性地储存。

　　例如源系统是批处理导向，没有实时界面，或有系统载入限制，那么交易数据或许应存储在操作数据仓库中实施动态访问。这种灵活性可以动态减少储存在客户数据中心里的数据量，进而降低总体拥有成本，并提高系统的机动性，按需提供数据。

　　数据模型对可升级性的影响

　　最后，数据模型的灵活性对CDI解决方案的升级性和绩效有着巨大的影响。固定式数据模型解决方案通常优先支持本地应用，而为了增加数据模型的灵活度，一旦模型配置后，所有的调试和标准化工作都要围绕支持指定主数据中心项目的测量和绩效要求，以及相关消费级应用而展开，不单单只是支持单一的厂商应用。此种形式上的不同，会横跨数据生命周期，给建立、使用、管理和拓展主数据中心带来显著的影响。

　　数据模型的灵活性是CDI架构可用性的一个关键组成部分。倘若你想降低CDI实施的风险，那么上述几条要素就应当在数据模型的选择中作出审慎的衡量。错误的决策会导致项目成本徒增，减少可管理能力，甚至会成为整个项目的拦路虎。