Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member181923
Active Participant
0 Kudos
In the last installment of this blog (Part 8): The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... I presented Figures 14 and 15 in order to try and show diagrammatically how and why a Diachronic Metadata Repository (DMDR) facilitates data mapping in a Legacy -> ERP conversion (LERCON) by auto-computing accurate solution sets from which final data mappings will be selected for initial data migraton, permanent external interfaces, and temporary internal interfaces. Figure 14 Figure 15 Although Figure 14 does present an over-simplified case in which one AsIs Legacy Business Function has been mapped to one ToBe ERP Business Function, it nonetheless makes the basic point that needs to be made: If: a) AsIs Legacy Business Functions have been horizontally mapped to some ToBe ERP Business Functions TBF1; b) AsIs Legacy Business Functions have been vertically mapped to AsIs Legacy IT Processes; c) ToBe ERP Business Functions have also been vertically mapped to ToBe IT Processes (hopefully in the ERP software vendor's own metadata repository) then: a DMDR can use the horizontal mapping in (a) and the two vertical mappings in (b-c) to compute the "solution sets" from which analysts can select the final data mappings needed to support the mapping of each AsIs Legacy Business Function to its corresponding ToBe ERP Business Functions. As shown in Figure 15, moreover, this iterative (function-by function) approach to data mapping differs radically from traditional non-iterative approaches to data mapping which simply try to map AsIs Legacy data elements onto ToBe ERP data elements using nothing more than the logical definitions of these elements that can be found in the AsIs and ToBe data dictionaries. And for this reason, most traditional business analysts, business process re-engineers, and business process experts will scoff at the proposed iterative approach on the grounds that it is a wate of time. The reason why most traditionalists will scoff at an iterative function-by-function approach to data mapping is because this approach insists that each AsIs data element and each ToBe data element must be revisited multiple times: each AsIs data element must be revisited in the context of each AsIs Business Function which it supports, and each ToBe data element must be revisited in the context of each ToBe Business Function which it supports. And to most traditionalists, this iterative revisitation of data elements will seem to be a waste of time. But in fact, nothing could be further from the truth. The iterative function-by-function approach to data mapping is actually the only way to guarantee that nothing important has been overlooked during the data mapping process of a LERCON. Or, to put this point another way, if you don't know how any given AsIs data element is used in each AsIs Business Function which it supports, and how any given ToBe data element is used in each ToBe Business Function which it supports, how can you possibly pretend to know how to map AsIs to ToBe data elements effectively and accurately? But that's OK - just keep on doing it the way you've always done it. You know the drill: i) find an AsIs domain expert and try to get a day of his or her time; ii) find the corresponding ToBe domain expert and try to get the same day of his or her time; iii) have them cross-walk just "their" portions of the AsIS and ToBe data dictionaries together, e.g. if they're vendor experts, have them walk just the vendor portions of the data dictionaries; if they're parts experts, have them walk just the parts portions of the data dictionaries, etc. Yeah - we all know how very effective (i-iii) can be as the basic protocol for LERCON data mappings.

6 Comments