Parts 3 and 4 of this blog: 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 and IT Process tiers in a Diachronic Metadata Repository (DMDR) with a three-tier structure like this: Figure 11 In particular, Part4 emphasized a key difference between the Business Function tier and the IT Process tier – namely the fact that: the DMDR’s mapping from units of AsIs business functionality to units of ToBe business functionality must be hand-constructed by business process experts, business analysts, and re-engineers … … whereas the DMDR’s mapping from units of AsIs IT Process to units of ToBe IT Process can be auto-computed by the DMDR as shown in Figure 11e (repeated here for convenience): Figure 11e Similarly, the mapping among units of AsIs Data and units of ToBe Data in the Data Tier of the DMDR (see Figure 11 above) can and should be “autocomputed” also, as shown in Figure 11f: Figure 11f Or, to put this point another way, if the the mapping among units of AsIs Data and units of ToBe Data in the Data Tier of the DMDR cannot be autocomputed from machine-readable information available to the customer and ERP vendor (after completion of the Business Function intersection table shown in Figure 11f), then neither the customer nor the vendor have any business attempting a LERCON at all. Why do I say this? Well, if one considers Figure 11f in a little more detail, the truth of the following four claims will be immediately obvious to all but the most naive and inexperienced software engineers: (IA) If the customer cannot readily organize metadata about its AsIs Data and get these metadata into a machine-readable hierarchy (the one shown at the bottom left of Figure 11f), then the customer has no business attempting a LERCON; (IB) If the customer or systems integrator does not know how to take this machine-readable AsIs Data hierarchy and map its nodes to the nodes of the AsIs IT Process hierarchy, i.e. does not know how to construct the AsIs Process<>Data Intersection Table shown in Figure 11f, then the customer and integrator should think twice before attempting the LERCON; (IIA) If the ERP vendor does not already have metadata about its “ToBe” data available in a machine-readable hierarchy (the one shown at the bottom right of Figure 11f), then the vendor has no business being in the ERP Business. (SAP’s metadata about its data is “more or less” in this kind of machine-readable hierarchy, but SAP could make significant improvements in this respect, particularly with respect to making the hierachy available to customers without them having to reverse engineer SAP metadata programs.) (IIB) If the ERP vendor has not already cosntructed the ToBe Process<>Data Intersection Table in order to keep its own software engineers from quitting or going crazy, then again, the vendor has no business being in the ERP business. (And again, SAP does have such an intersection table implicitly but not explicitly, i.e. in a form that is transparent to folks who don’t know anything about SAP’s internal metadata programs.) And if IA-B and IIA-B are all inarguably correct, then it follows as a natural consquence that the AsIs<>ToBe Data Intersection Table shown in Figure 11f must be autocomputable once the business process experts, business re-engineers, and business analysts have completed the AsIs<>ToBe Business Function Intersection Table. Before concluding this post, it’s important to note that the three intersection tables shown in Figure 11f are not in the “Staged” slice of the DMDR shown in Figure 11 at the top of the post (although it may appear that way simply due to the similarity between the visual organization of Figure 11f and the visual organization of Figure 11.) As will be discussed in Part 6, the “Staged slice of the DMDR contains three new core tables of its own, plus eleven intersection tables required to relate these tables to themselves and the other six core tables of the DMDR.