Parts 3-6 of this blog: 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) 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 In particular, Parts 3-5 outlined the primary core and intersection tables that are critical to the functioning of such a DMDR, namely those shown in Figure 11f (repeated here for convenience): Figure 11f And Part 6 showed how these primary tables must be amplified by additional core and intersection tables in order to store metadata relevant to the “staged” slice of a DMDR: Figure 12 In particular, these additional core and intersection tables include the following: 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 Having sketched out the basic underlying structure of a DMDR in terms of all of the core and intersection tables noted above, we are now in a position to show how this underlying structure facilitates the three most important processes which 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. But before beginning this exposition, it is worth spending a moment talking about the actual physical implementation of the core and intersection tables discussed above, i.e. what kinds of databases and media they should (and should not) be stored in. And as shown in Figure 13, when we talk about this question, what we’re really talking about is what does and does not constitute suitable metadata for a DMDR that will have to support and drive a LERCON of any size and complexity. Figure 13 Perhaps the most important statement in Figure 13 is the one at the bottom of the slide. In all IT undertakings, knowledge is power, but perhaps nowhere is this more true than in the undertaking of a LERCON. How many times have you been working a LERCON and were prevented from finding out something about an AsIs <-> ToBe function, process, or data mapping simply because the metadata you needed was stored in Excel spreadsheets in the desktops of some business process analysts who were not about to share the information that makes them (and their company) valuable to the project? And even if these analysts themselves were willing to share the info, how many times were they told not to by their higher-ups, simply because these higher-ups were involved in some kind of turf-war with your higher-ups? Yes indeed, if you want to bury metadata up to its neck and make it as unavailable/unusable as possible to other folks involved in your conversion, there are few better places to store it than Excel spreads in your own desktop. And equally importantly, even if we assume the existence of something I personally have never seen – namely, a LERCON in which all actors are acting in good-faith with good-will toward all other actors, there is still a very good reason not to store LERCON metadata in Excel spreadsheets: when LERCON metadata are stored in Excel spreadsheets, they do not optimally satisfy the seven criteria stated at the top of Figure 13.. In fact, the only way to ensure that complex LERCON metadata satisfy all seven of these criteria is to place them in sufficiently sophisticated database tables and make sure that everyine can access these tables “nine-ways-to-the-dime” via equally sophisticated web applications such as those that can now be easily written in the SAP NW200nx environment. If you really think I’m wrong about this, just ask yourself the following question: When you bring up SAP’s Repository Information System via transaction SE80, does this transaction access csv’s reformatted from Excel spreads? And if SAP doesn’t think its own Repository Information System can run off csv’s downloaded from Excel spreads, why do you think the metadata repository for a LERCON can? Of course, there are those “rugged individualists” who will say, “Well – our metadata aren’t really stored in Excel spreads – they’re stored in Access databases that drive the Excel spreads.” Oh really? And how many of these Access databases are operative in the kind of LERCON your company usually tackles? And assuming there’s more than one (and there always is), who keeps these in synch as things change during the process of function, process, and data mapping? And where are these Access databases stored and what kind of concurrent access do they support? With what roles, privileges, etc.? With what locking controls? Nope – just think about the seven criteria in Figure 13, and you’ll see why the words “Excel” and “Access” should send shudders down your spine when you find out that they define the “core technology” for storing metadata on the LERCON you’ve just been asked to work on.