Today, the CDI market has attracted several technology vendors from areas like ERP, CRM, data quality, and master data management. Unfortunately, while there is consensus that a CDI hub is critical for tying distributed customer data into unified views, there is rampant confusion on how best to implement such a hub. Currently, there are four “styles” of CDI implementations and before committing to a specific CDI style, organizations need to consider the fundamental business purpose of their current/future CDI hub.
Before committing to a specific CDI style, organizations need to consider the fundamental business purpose of their current/future CDI hub, including: frequency of business change, scope/latency of unified views, legacy IT environment, operational versus analytical applications need, types of data sources and data governance policies. Beyond these characteristics, an organization should choose a CDI style that is future-proof, i.e., it can adapt to merger & acquisitions, re-organizations and other systemic organizational changes. This involves four critical factors. First, the CDI hub architecture must adapt easily to changes over time, such as adding new business processes, data sources and applications. Second, it must allow for ongoing data stewardship/governance by both business and IT teams. Third, it must be an extensible IT platform in order to build new data views and services. Finally, it should be able to deliver these views in multiple modes – real-time and batch – to other systems at the performance and scaling requirements of the business.
The Four CDI Styles
Today, there are four different CDI styles which include:
- Custom-built data hub
- Fixed transaction hub
- Match & link cross-reference hub
- Adaptive transaction hub
Custom-Built Data Hub
This style reflects the historical way of building customer hubs using software tools and custom-coded rules. Building such a hub requires the use of an Extract-Transform-Load (ETL) tool to bring data into the hub’s data model from multiple sources and Data Quality (DQ) tools to cleanse & match similar records within the hub. These matched records are then merged based on simple, custom-coded rules, which generally results in the system choosing one record over another. Typically, ongoing code development is needed to integrate this custom hub to downstream systems, to make changes to match & merge rules and to add new data sources.
This tools-based approach is the least adaptable to business changes and has severely limited extensibility to new data sources.
Figure 1 – Custom-Built Data Hub
|
