Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member181923
Active Participant
0 Kudos
As noted in Part 7 of this blog: The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... a Diachronic Metadata Repository (DMDR) with the overall structure outlined in Parts 3-6: 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... greatly reduces the risk and increases the accuracy of the three most important processes that must take place in any Type IV Legacy -> ERP Conversion (LERCON): i) AsIs -> ToBe persistent data mapping (for data migration) ii) AsIs -> ToBe transient data mapping (for specification of permanent external interfaces that must be honored); iii) AsIs ->Staged -> ToBe transient data mapping (for specification of temporary interfaces that must be used in a Type IV "incremental" LERCON until all legacy components have been converted to ERP. There are many reasons why a DMDR facilitates processes (i-iii), and the first of these can readily be seen by considering Figures 14 and 15: Figure 14 Figure 15 Although Figure 14 is over-simplified to the point where it actually is telling two different lies simultaneously, it is nonetheless useful for discussing how a DMDR facilitates the AsIs<->ToBe mapping of persistent data for initial data migration. The first reason Figure 14 lies is because it depicts a "symmetric" AsIs<->ToBe situation which virtually never occurs in real life. In particular, Figure 14 depicts a situation in which: There is an AsIs Business Function that is implemented via two AsIs IT Processes; The LERCON business re-engineers/analysts/process experts have mapped this AsIS Business Function to exactly one ToBe Business Function; This ToBe Business Function also happens to be implemented by exactly two AsIs IT Processes. And as anyone familiar with LERCON's can tell you, it is much more common for a LERCON's business re-engineers/analysts/process experts to create asymmetric mappings in which: One AsIs Business Function is mapped to more than one ToBe Business Function or More than one AsIs Business Function is mapped to one ToBe Business Function But although Figure 14 "lies" by portraying a preternaturally symmetric AsIs<->ToBe mapping situation, it tells the truth in the following key respect: The decision to map any particular AsIs business function F(a) onto a particular ToBe business function F(t) implies a decision to map a certain set D(a) of AsIs data elements to a certain set D(t)of ToBe data elements - namely: the set D(a) of data elements utilized by the AsIs IT process(es) which implement the AsIs function F(a) and the set D(t) of data elements utiilzed by the ToBe IT process(es) which implement the ToBe Function F(t). Which brings us to the second lie told by Figure 14. Although the DMDR can auto-define the "boundaries" of the desired data mapping D(a)-->D(t), it can't really define this data mapping exactly. All the DMDR can do is to tell AsIs and ToBe SME's/DE's (subject matter experts/domain experts) what pools of AsIs and ToBe data elements they should be looking at in order to create a data mapping that will support the conversion of the AsIs function F(a) to the ToBe function F(t). It still requires SME's/DE's to decide the specifics of the desired mapping, i.e. that element s(a) of S(a) will map to element s(b) of S(b). But here's the first point that needs to be made about the initial "mapping" D(a) --> D(t) that is "auto-computed" by the DMDR. Anyone who has worked with legacy functionals (SME's/DE's) know that they are excellent at answering narrow and specific questions but terrible at answering broad and open-ended questions. So if you really think that you can ask a bunch of AsIs SME's/DE's to sit down with a bunch of ToBe SME's/De's and figure out what data elements have to be mapped to what data elements in order to support the conversion of AsIs function F(a) to ToBe function F(t), then all I can do is wish you good luck and hope your LERCON schedule has allotted an infinite amount of time to wait for the answer. On the other hand, if you give the same bunch of AsIS and ToBe SME's/DE's the inital data mapping D(a) --> D(t) auto-computed by the DMDR, and tell them that they must choose a final data mapping from among the elements in D(a) and D(t), then I promise you will be amazed at the speed with which these SME's/DE's arrive at the answer. Why? Because you've sufficiently delimited the solution set so that they can actually find a reasonable solution within it. More tomorrow on Figure 15, and how the DMDR makes optimally effective data mappings possible via the iterative provision of delimited solution sets, i.e. provision of provisional initial mappings D(a)-->D9t) for each AsIs Business Function F(a) within the scope of the LERCON.