Skip to Content
If I had to summarize what’s been said in the previous posts of this blog: The Diachronic Metadata Repository (DMDR) as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 11) The Diachronic Metadata Repository (DMDR) as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 10) 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 would probably say the following: A Legacy -> ERP conversion (LERCON) cannot maintain and take advantage of “Distributed Specification Consistency” unless it is governed and controlled by a centralized Diachronic Metadata Repository (DMDR) which offers distributed access to one set of consistent specs for the LERCON. There are two operative verbs in this summary: maintain and take advantage of. With respect to the first verb (“maintain”), I think I’ve already made it clear that what I mean by specification maintenance is not some fancy version control system for MS Visio, Project, and Excel objects sitting on a shared drive. Rather, it is the storage of an accurate and consistent set of relations among AsIs and ToBe items (functions, processes, data) in a centralized repository which is the only source of technical specifications for initial data migration and all interfaces which must be honored during and after the conversion. (I’ll get to what I mean by “technical specification” in a minute.) With respect to the second verb (“take advantage of”), Figures 16 and 17 show the two major ways in which a LERCON can take advantage of a DMDR which successfully enforces Distributed Specification Consistency across the LERCON. Figure 16 image Figure 17 image As shown diagramatically in Figure 16, virtually all of the code required for a LERCON’s data migration can be auto-generated directly from the LERCON’s DMDR. And as shown diagramatically in Figue 17, virtually all of the code required for a LERCON’s interfaces can also be auto-generated directly from the LERCON’s DMDR. Are you inclined to argue that neither of these claims are true? Then either: 1) you’ve got a vested interest in making sure that migration and interface specs are created manually and inaccurately by as many junior analysts as possible. or 2) you’ve never heard of scripting languages that can access a database when you need to or 3) you’re naive and inexperienced enough to really believe that the sad sad story documented in Figures 18 and 19 is the result of politics and personalities and nothing else. Figure 18 image Figure 19 image Notes: 1) Figures 18 and 19 are reproduced from a presentation given by David Bromlow of Quivira at the SAP/SAP Insider conference “Managing SAP Projects 2006” (Orlando, 16-18 October.) 2) Peter Falk’s actual line from the moview was: “I’m gonna tell you something that’s gonna make you wet all over.”

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