Skip to Content
Author's profile photo David Halitsky

The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 6)

Parts 3-5 of this blog: 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) outlined some key aspects of the Business Function, IT Process, and Data Tiers in a Diachronic Metadata Repository (DMDR) with a three-tier structure like that shown in Figure 11 (repeated here for the reader’s convenience): Figure 11 image In particular, Parts 3-5 outlined the six hierarchy tables and seven intersection tables that are critical to the functioning of such a DMDR, namely those shown in Figure 11f (repeated here for convenience): Figure 11f image But as shown in Figure 11 above, the vertical time-slices of a DMDR include not only the initial As Is Slice and the final ToBe Slice, but also an intermediate Staged Slice, as shown in Figure 12: Figure 12 image And in order to understand why this Staged slice is so critical to the functioning of a DMDR, it is necessary first to explain what Figures 11 and 11f mean by a “Type IV LERCON”. As shown in Figure 7 (repeated here for the reader’s convenience): Figure 7 image a “Type IV LERCON” is the most difficult of all LERCON’s to undertake because of its two salient characteristics: (a) a “Type IV LERCON” is one in which the “powers-that-be” have decided to do the Legacy->ERP converson incrementally, with some units of business functionality being converted first, others second, etc. (b) a “Type IV LERCON” is one in which the ToBe ERP system must continue to honor a large number of external interfaces that pass data into and out of the AsIs legacy system When a LERCON has both of these characteristics, all LERCON actors are confronted with an obvious problem whose nature is sketched out in Figure 12a: Figure 12a image Since the LERCON must honor the External Interface EId after subsystem SS2 has been converted from legacy to its ERP equivalent, the not-yet-converted subsystem SS3 must continue to feed interface IIa to subsystem SS1 (so that SS1 can continue to feed interface IIb and thereby give SS2 what it needs for the interface EId.) But inasmuch as SS1 is now in SAP, the interface IIa will involve data srtuctures that may be quite different in key respects from the data structures involved in interface IIa when subsystem SS2 was still in the legacy environement. Furthermore, since SS3 will eventually be converted to SAP. these data structures are temporary data structures that will go away once SS3 is converted to SAP. And therefore, since these data structures belong neither to the AsIs Legacy Time-Slice of the LERCON nor to the ToBe SAP Time-Slice, their metadata must be recorded within the middle, or “Staged”, time-slice of the DMDR (see item 4 in Figure 12 above.) As this very simple example should make clear, TYPE IV LERCONS require the definition of more temporary data structures than LERCONs which are “big-bang” instead of “incremental” and do not have any external interfaces to honor. But even in the simplest type of “big-bang” LERCON with no external interfaces to honor, the Staged time-slice is necessary to store metadata on temporary data structures needed for initial data migration. The reason why temporary data structures are needed for initial data migration is because any legacy system that is still around in 2006 is more than likely highly heterogeneous – it may use IMS databases, VSAM files for CICS applications, flat sequential files for COBOL applications, as well a the usual more modern culprits (e.g. DB2 and Oracle databases.) And therefore, it happens quite frequently that a file which will be passed to SAP during initial data migration will have data elements from two or more of these disparate systems. In cases such as this, the correct thing to do is to “stage” a temporary database table in which all the different pieces of the final file are stored, and then to write out the file for SAP from this table. But inasmuch as the metadata on this temporary table is neither part of the “AsIs” legacy system nor the “ToBe” ERP system, the metadata on this table must be recorded in the “Staged” time-slice of the DMDR. Turning now from item 4 to items 1-3 in Figure 12 above, it should be clear why a DMDR must be prepared to store metadata on temporary Business Functions and temporary IT Processes, as well as metadata on temporary data structures. In particular, anyone who’s been through even one complex and large-scale LERCON can tell you that: (IA) The need to fine-tune legacy data before passing it to SAP may result in a number of new and temporary Business Functions that will go away once the conversion is complete (see item 2 in Figure 12); (IB) The need to use auxiliary vendor-neutral models such as SCOR during AsIs->ToBe Business Function mapping may require the metadata on such models to be stored in the DMDR (see item 1 in Figure 12); (IIA) In incremental LERCONS, there will be a large number of temporary IT processes needed for bridgework between unconverted processes that are still in the legacy AsIS environment and converted processes that are in the new ERP ToBe environment (see item 3 in Figure 12.) (IIB) Even in a non-incremental (“big-bang”) LERCON, the Staged time-slice of a DMDR must store metadata on all the temporary processes required to create the temporary data tables from which files will be written for the initial migration to SAP (see again item 3 in Figure 12). And therefore, until a LERCON is complete, its DMDR must contain the following core and intersection tables in addition to those shown in Figure 11f: Core: Staged Business Function Hierarchy Table Staged IT Process Hierarchy Table Staged Data Hierarchy Table Intersection: “Horizontal” Intersection Tables: AsIs<->Staged Business Function Intersection Table Staged<->ToBe Business Function Intersection Table AsIs<->Staged IT Process Intersection Table Staged<->ToBe IT Process Intersection Table AsIs<->Staged Data Intersection Table Staged<->ToBe Data Intersection Table “Vertical” Intersection Tables: Staged Business Function <-> IT Process Intersection Table Staged IT Process Intersection Table <-> Data Intersection Table (Figure 11f would get way too complicated if it included these eleven new core and intersection tables, so I’ve simply listed them above. IF SDN allowed for attachement of dynamic gifs, I could do an accordion-file version of Figure 11f that displayed all the core and interseciton tables of the DMDR across all three time-slices.)

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.