Semantic Reconciliation
In the latest DM Review an article entitled The Need for Active Metadata Integration: The Hard Boiled Truth, authored by Vickie Farrell, VP of marketing for Cerebra, provides an excellent overview of the issue of semantic reconciliation. Semantic issues - requiring applications and systems agreement on the context and meaning of metadata objects - arise any time you are merging, reconciling and managing metadata from multiple source systems.
I'm reminded of a time when two trading systems I was working on were combined, both of which were metadata driven. The first, which was to be the reference system going forward, reported "Status" and "State" on orders, including values such as Good-Til-Cancelled, Market Order, and Limit Order for status and Open, Executed, Partial Fill, and Confirmed for the state. After combining the metadata, the State field started displaying values such as "Illinois" and "Ohio".
Vickie does an excellent job explaining the issues. Obviously, with Cerebra offering metadata management tools, the article has a marketing spin but the problem is very real and Vickie cites numerous independent research resources to back it up.
The saving grace, if there is one, is that in a customer master environment you are not typically attempting wholesale replacement of the underlying system and a full metadata superset that covers all the descriptors for all the affected systems is not necessary. Instead, as decisions about what data belongs in the customer master are made, the associated metadata must be examined for both meaning and context.
In large deployments with many affected systems - and particularly those in which the metadata must be actively managed: reconciled, combined, split, converted or otherwise massaged - in order to harmonize the meaning across application and enviroments, tools that enable "active metadata management" may indeed be just the ticket.
I highly recommend examining the table provided at the end of the article to help identify key areas of focus and concern early in the planning process.
I'm reminded of a time when two trading systems I was working on were combined, both of which were metadata driven. The first, which was to be the reference system going forward, reported "Status" and "State" on orders, including values such as Good-Til-Cancelled, Market Order, and Limit Order for status and Open, Executed, Partial Fill, and Confirmed for the state. After combining the metadata, the State field started displaying values such as "Illinois" and "Ohio".
Vickie does an excellent job explaining the issues. Obviously, with Cerebra offering metadata management tools, the article has a marketing spin but the problem is very real and Vickie cites numerous independent research resources to back it up.
"As the boundaries between departments break down, and as boundaries between application domains like CRM, supplier relationship management (SRM), enterprise resource planning (ERP) and product lifecycle management (PLM) continue to erode, there is a growing need to create an enterprise-wide information strategy to ensure semantic consistency and persistence for all users, applications and services. This is very different from the current practice of adding a new application stack and merging its reference data definition into the current enterprise model. This practice really only integrates data and does not rationalize semantics." ("Enterprise Information Management Is a Core Element of Your IT Architecture," Gartner, 17 January 2005)And as she points out, while attendees to conferences like DAMA that focus on metadata management are probably among the most sophisticated and knowledgeable on the topic,
... according to a survey (reg. required) that Cerebra ran at the 2005 DAMA/Metadata conference, fewer than 35% of respondents said that they have accurate automated financial reports. And "when integrating data from multiple departments for reporting purposes," 43% said they "must resort to the use of specific code and/or manual processes for cross-functional queries" vs. just querying the data warehouse.The ramifications for Customer Data Integration projects, where metadata from multiple - sometimes dozens - of target systems must be reconciled, is significant. As part of the scope and requirements phase of a CDI project, planning the metadata reconciliation is a key step.
The saving grace, if there is one, is that in a customer master environment you are not typically attempting wholesale replacement of the underlying system and a full metadata superset that covers all the descriptors for all the affected systems is not necessary. Instead, as decisions about what data belongs in the customer master are made, the associated metadata must be examined for both meaning and context.
In large deployments with many affected systems - and particularly those in which the metadata must be actively managed: reconciled, combined, split, converted or otherwise massaged - in order to harmonize the meaning across application and enviroments, tools that enable "active metadata management" may indeed be just the ticket.
I highly recommend examining the table provided at the end of the article to help identify key areas of focus and concern early in the planning process.
0 Comments:
Post a Comment
<< Home