Skip to Content
In the “trailer” to Part 9 in my blog on the concept of a “Diachronic Metadata Repository(DMDR)”: The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 9) The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 8) The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 7) The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 6) The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 5) The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 4) The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 3) I mentioned that a DMDR can help reveal what aspects of a Legacy -> SAP conversion should be implemented via Enterprise SOA, rather than standard R3 transactions. To see why this is so, consider the major core and intersection tables of a DMDR (Figure 11f below) in relation to the process by which the DMDR “auto-computes” data mapping solution sets for all data mappings required by a Legacy->ERP conversion (Figure 14 below). Figure 11f image Figure 14 image When a DMDR “auto-computes” data mapping solution sets as shown in Figure 14, it does so using only one of the “horizontal” intersection tables shown in Figure 11f and four of the “vertical” intersection tables shown in this figure. In particular, this “auto-computation” takes as input: 1) the “horizontal” intersection table which relates AsIs Legacy Business Function to ToBe ERP Business Functions; 2) the “vertical” intersection table which relates AsIs Legacy Business Function to AsIs Legacy IT Process; 3) the “vertical” intersection table which relates AsIs Legacy IT Process to AsIs Legacy IT Data; 4) the “vertical” intersection table which relates ToBe ERP Business Function to ToBe ERP IT Process; 5) the “vertical” intersection table which relates ToBe ERP IT Process to ToBe ERP Legacy IT Data; and from them, produces the following “horizontal” intersection table as output: 6) the “horizontal” intersection table which relates AsIS Legacy Data to ToBe ERP Data. And inasmuch as the “auto-computation” of (6) from (1-5) does not require the “horizontal” intersection table shown in the middle of Figure 11f (the one relating AsIs Legacy IT Process to ToBe IT Process), the question naturally arises as to why it is necessary to create this table at all. Before answering this question, it is worth reviewing how this horizontal Process intersection table is created. As I have said earlier in this blog, no entity should even consider attempting a LERCON unless: a) it has already built the two vertical intersection tables mentioned above in (2) and (3); b) it is doing the LERCON to convert to an ERP system for which the vendor has already built the two vertical intersection tables mentioned above in (4) and 5). So assuming prerequisites (a-b) have been met, the horizontal Process intersection table can be built in two steps as soon as the horizonal Function intersection table has been built (e.g. using the results of the blue-printing process in the case of a conversion to SAP.) In Step 1, “solution sets” for AsIs Process <-> ToBe Process mappings are auto-computed between AsIs Legacy IT Process and ToBe ERP IT Process using the horizontal Function intersection table mentioned above in (1) and the two vertical Function<->Process intersection tables mentioned above in (2) and (5). In Step 2, these “solution sets” are reviewed (again, iteratively) by AsIs Legacy and ToBe IT Process experts to eliminate “over-” and “under-” computation and arrive at a final Process<->Process intersection table from AsIs to ToBe. Furthermore, when the AsIs and ToBe IT process experts jointly develop this final Process<->Process intersection table between AsIs and ToBe, anyone who’s participated in even one LERCON of any size and complexity knows as well as I do that this final intersection table will contain the following kinds of AsIs -> ToBe Process->Process mappings: 0:1 0:n 1:0 n:0 1:1 1:n n:1 n:n. And I promise you, many opportunities for making use of Enterprise SOA can be found in this table, particularly when this table is examined in conjunction with the AsIs<->ToBe data intersection table discussed in Part 9. Why? Because the 1:n, n:1, and n:n mappings in the process (and data) intersection tables reflect precisely the points at which two different sets of system architects view the proper segmentation of certain IT processes (and data) very differently, i.e. the system architects who designed the ToBe system and the system architects who designed the AsIs system. And you can’t begin to see how Enterprise SOA can help your organization unless you have another view available to help you see beyond your “blind-spots”. Enough said on this point, I think. In Part 11, I’ll present a second reason why the AsIs<->ToBe Process<->Process intersection table must be built during any LERCON which must create permanent external interfaces, temporary internal interfaces, or both.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply