Skip to Content
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 image 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 image 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 image 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.

To report this post you need to login first.

4 Comments

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

  1. Nigel James
    Well. I am not going to accuse you of being boring David, but this is pretty heavy stuff and needs a good amount of thought.
    regards,
    Nigel
    (0) 
    1. David Halitsky
      Hi Nigel –

      What’s odd is that the subject is a little complex to talk about in formal prose, but very easy to grasp by anyone who has actually watched more than once as large-scale Legacy->ERP conversions fail for exactly the same reason: a curious over-simplification of the technical issues on the one hand, coupled with an even more curious unwillingness to take even the most rudimentary steps to prevent catastrophe.

      It never ceases to amaze me how top CIO’s of top public/private entities let third-party systems integrators (we know who they are) take them for multi-million dollar conversion expeditions without the kinds of maps and tools that these same CIO’s would require of any relatively unsophisticated guide or bush-pilot that they employ on their fishing and hunting expeditions in Alaska or Canada.

      I only wish SAP was ten times more successful than it currently is, so that it could say to a prospective client wanting to convert to SAP – “Sorry – you’re not ready yet.  Come back and talk to us when you have machine-readable metadata on your business functions, IT processes, and logical/physical persistent/transient data.”

      Of course, I also wish SAP would pay a little more attention to the presentation of its own metadata to external parties.  Having helped re verse engineer SAP’s metadata programs, I know how good a handle SAP has on its own metadata.  But what’s available to SAP’s own engineers is NOT what’s available to engineers working on a legacy conversion to SAP – at least not transparently and directly …

      (0) 
      1. Andre Truong
        from my own recollection, technology or methodology was not so much at fault in failure situations. I’ve seen more trouble due to people or politics. just my 2cents.
        (0) 
        1. David Halitsky
          But I think that there’s a certain amount of escapism and avoidance in chalking up all conversion failures to “people and politics.”

          Here are two examples:

          Example 1:

          A large ERP->Legacy conversion must honor 250-300 external interfaces involving about 2000-2500 different message formats after the conversion is complete.

          The systems integrator assigns a team of 50+ people to work on the interfaces and a team of even more to work on the initial data migration to SAP.

          The two teams are never in communication, i.e. the interface team makes its own guesses about what legacy elements map to what SAP elements, and never considers the guesses the data migration team are simultaneously making.

          Project management sees nothing wrong with this, nor does the customer.

          Is this a “people” problem?  Of course it is.  But as I tried to make clear in Parts 1 and 2 of this blog on a “DMDR”, my basic point is that Legacy->ERP conversions must be based on consensual process-models that not only ensure that “people” will do the right thing, but also have their buy-in up-front.  In the absence of such a consensual process-model, there will continue to be conversions in which one team specs out external interfaces while another team specs out data migration, and neither team ever wonders what will happen when it turns out that the guesses the interface team is making don’t jibe with the guesses the data migration team is making.

          Example 2:

          A large-scale Legacy->ERP conversion is being honcho’d by a systems integrator whose parent company also happens to have its own weapons system design and manufacturing division; in fact, the company’s systems integration division is a “spin-off” from the original weapons system company.

          When the conversion fails, the systems integrator says it’s because the customer refused to freeze development on the legacy system, so the integrator had to keep on hitting a moving target.

          So let’s drop back and think about that excuse for a second.  The company is able to get a lot of systems integration business because it claims that it has the benefit of all the project management techniques which have proved successful in its weapon systems division.

          Uhh – don’t these project management techniques include adequate and successful means for dealing with change management?  Do the colonels in the Pentagon freeze specs on a weapon system when the initial contract for the system is signed?

          I hardly think so.

          And therefore, it’s reasonable to ask how come the integrator’s vaunted change management techniques and experience didn’t help it deal with a legacy system on which management refused to freeze development?

          Is it harder to deal with change on a software system than change on a weapons system?

          ***

          If you’re following this particular blog in enough detail to understand what I’m proposing, I don’t mind at all if you wind up saying “nope – that’s not the right approach” (although I really can’t see how anyone with an ounce of conversion experience and common sense could possibly say this.)

          What I do take exception to is the idea that the process-model which currently drives Legacy->SAP conversions can’t be improved at all – that it’s as good as it’s ever going to be because “people and politics” are what they are.

          To me, this attitude is tantamount to giving a whole lot of people a permanent license to steal.

          Not to mention the fact that this attitude degrades the notion of “engineer” which we’re all so proud to see in titles like “Principle Software Engineer”, etc.

          If we can’t “engineer” a consensual process-model for a Legacy->ERP conversion that will routinely get the job done, we have no business calling ourselves “engineers” because we haven’t learned (or aren’t willing) to “engineer” the “people” side of the software machine.

          There, I feel a lot better now.  That was worth a bottle of Maalox and several Prevacids. 

          Seriously – thanks for taking the time to respond and raise the question which is probably the key question in this whole discussion.

          (0) 

Leave a Reply