|
Why Customer Data Integration (CDI) Projects Fail - Data Model Inflexibility
(Continued from Page 1)
|
Spreadsheets have been around since the late 1970s. They were an instant sensation. Over the years, spreadsheets have evolved and matured, but the basic form and substance of spreadsheets has hardly changed. While new features and capabilities continue to be added to spreadsheets, for the most part spreadsheet technology has reached a plateau. This is typical of a highly successful product. However, it is becoming clear that new approaches and paradigms should and are beginning to emerge.
|
|
Ideally, an adaptive CDI solution must offer an initial data model specific to each industry vertical – or allow any proven data model to be imported – that can be further modified to reflect the exact business entities needed to be modeled for the customer hub. In addition, it must supply all the supporting data management services, including extensive metadata management, to facilitate the model’s extension and changes over time. The net result is a relevant, highly specific data model that fits the project needs from inception without forcing an enterprise to standardize on a fixed data model.
Business Services: Customized or Composed?
A CDI solution based on a fixed data model may claim to offer a layer of abstract business services that can be used out-of-the-box for integration. However, these business services are “brittle” and need to be customized if the underlying data model is modified. Therefore, in an implementation, after a fixed data model is customized and de-normalized, there may be only a handful of relevant business services remaining. Worse, even these business services may require customization, and the more such a solution is customized the harder it is to migrate to future product upgrades. Instead, an adaptive architecture must offer a set of granular data integration services, including a full set of APIs, in a services integration framework that may be used to compose only the relevant higher-order business services. These business services and the APIs are maintained for a smooth path to product upgrades. This approach offers a wide variety of methods within a service-oriented architecture for sharing all the data entities based on rules within the hub – at various levels of abstraction–with downstream systems.
Data Types: Which Ones to Model?
Each customer data type – master reference data, relationship data, and transaction data – has separate characteristics and challenges and therefore requires different treatment within the CDI solution. For example, reference data that exists in every system or data repository is often duplicated, conflicting and does not have a system-of-record. On the other hand, transaction data usually does have a system-of-record; consequently, there is little conflict during reconciliation. Also, while reference data is a very small subset of customer data and hence has smaller volume, the volume for transaction data can be very large, requiring a substantial investment in infrastructure to store the replicated data from source systems. Relationship data can only be managed effectively after the underlying conflicts of reference data have been resolved. Further, and for proper management, relationship data and its groupings (like households) also require sophisticated visualization tools to display the complex relationships between entities.
A fixed data model approach offers an enticing, extensive application-level data model whereby all customer attributes – master data, relationship data and transaction data – are fully encapsulated in the model for the hub. This fully persistent approach requires many customer attributes to be duplicated and stored in the customer hub. Conversely, an adaptive approach must permit the data model to be segmented in such a way that only the core master data and relationship data attributes are modeled and stored in the customer master hub. The transaction data is addressed based on where it most appropriately resides given the characteristics of the underlying source system.
|
|
|
Oracle #1 in Business Analytics According to IDC Research
|
The Business Intelligence Search Engine has all the answers.
|
Find all you need on The Business Intelligence Search Engine.
|
|
|
|
|
|
|
|
Other
Articles by this Author
|
|
|
