In the previous posts of this blog: The Diachronic Metadata Repository (DMDR) as a Tool for Risk Reduction via Conflict-Prevention Durin... The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... I indicated how: ) the initial mapping of AsIs Business Function to ToBe Business Function can be used to project "solution sets" for the mapping of AsIs Data to ToBe Data (see top and bottom rows in Figure 11g); Figure 11g 
b) this projection also automatically determines a mapping from AsIs IT Process to ToBe IT Process (see middle row in Figure 11g); c) this AsIs to ToBe IT Process mapping is an invaluable source of ideas as to how Enterprise SOA can be used to unify and streamline Business Function through IT Processes realized as cross-app service chains (see Part 10) But this AsIS to ToBe IT Process mapping is also critical to the success of a incrementalLERCON for an important reason that have nothing to do with the restructuring of Business Function via new Enterprise SOA IT Processes. (As noted earlier, an incremental LERCON is one which converts a legacy system in phases - some subsystem(s) earlier, some subsystem(s) later - as opposed to a big-bang LERCON in which all subsystems are converted all at once in a "sudden-death" cutover. In particular, consider the kind of situation that typifies an incremental LERCON which must also various interfaces of the original legacy system: Figure 12a 
Anyone familiar with legacy systems knows that "timing" is critical to the operation of the internal interfaces shown on the left-hand side of Figure 12a: there is always some chronological or temporal coordination between the internal interfaces IIa and IIb which results in the interface EId providing data to its external sink at the correct times. But when an incremental LERCON has reached the stage shown on the right-hand side of Figure 12a, the internal interface IIa no longer feeds the AsIs subsystem SS1, but rather the replacement of SS1 in the new ToBe system. Furthermore, this "new" subsytem SS1 must feed the "new" subsystem SS2 via a replacement of the old internal interface IIb, in order that SS2 can feed its external sink via the external interface EId at the correct times. And therefore, it is obviously critical that designers of this incremental LERCON be able to specify the chronology of operations in the new system when it has reached the stage shown on the right-hand side of Figure 12a. That is, the designers must be able to answer the following three questions: a) How does system SS3 know when to feed data to SS1? b) How does system SS1 know when to feed data to SS2? c) How does system SS2 know when to feed data to its external sink? And, they must be able to do so even when the internal interfaces IIa and IIb may no longer really be "interfaces", but rather automatic operations of a sophisticated ERP like SAP, in which multiple tables are simultaneously updated via individual on-line transactions. So now imagine that the situation shown in Figure 12a is multiplied 20 or 50 times, which is often the case in any LERCON dealing with an legacy system that has been built-up gradually over thirty years or so. Do you see why it might be useful to have an explict mapping from AsIS IT Process to ToBe IT Process, as shown in Figure 12a above? And why it might be useful if this mapping also took into account the "Staged" time-slice of an incremental LERCON? Figure 12 
If not, then you've never seen a LERCON crash-and-burn because its architects also didn't see the need for explict AsIs to ToBe IT Process mappings.
b) this projection also automatically determines a mapping from AsIs IT Process to ToBe IT Process (see middle row in Figure 11g); c) this AsIs to ToBe IT Process mapping is an invaluable source of ideas as to how Enterprise SOA can be used to unify and streamline Business Function through IT Processes realized as cross-app service chains (see Part 10) But this AsIS to ToBe IT Process mapping is also critical to the success of a incrementalLERCON for an important reason that have nothing to do with the restructuring of Business Function via new Enterprise SOA IT Processes. (As noted earlier, an incremental LERCON is one which converts a legacy system in phases - some subsystem(s) earlier, some subsystem(s) later - as opposed to a big-bang LERCON in which all subsystems are converted all at once in a "sudden-death" cutover. In particular, consider the kind of situation that typifies an incremental LERCON which must also various interfaces of the original legacy system: Figure 12a Anyone familiar with legacy systems knows that "timing" is critical to the operation of the internal interfaces shown on the left-hand side of Figure 12a: there is always some chronological or temporal coordination between the internal interfaces IIa and IIb which results in the interface EId providing data to its external sink at the correct times. But when an incremental LERCON has reached the stage shown on the right-hand side of Figure 12a, the internal interface IIa no longer feeds the AsIs subsystem SS1, but rather the replacement of SS1 in the new ToBe system. Furthermore, this "new" subsytem SS1 must feed the "new" subsystem SS2 via a replacement of the old internal interface IIb, in order that SS2 can feed its external sink via the external interface EId at the correct times. And therefore, it is obviously critical that designers of this incremental LERCON be able to specify the chronology of operations in the new system when it has reached the stage shown on the right-hand side of Figure 12a. That is, the designers must be able to answer the following three questions: a) How does system SS3 know when to feed data to SS1? b) How does system SS1 know when to feed data to SS2? c) How does system SS2 know when to feed data to its external sink? And, they must be able to do so even when the internal interfaces IIa and IIb may no longer really be "interfaces", but rather automatic operations of a sophisticated ERP like SAP, in which multiple tables are simultaneously updated via individual on-line transactions. So now imagine that the situation shown in Figure 12a is multiplied 20 or 50 times, which is often the case in any LERCON dealing with an legacy system that has been built-up gradually over thirty years or so. Do you see why it might be useful to have an explict mapping from AsIS IT Process to ToBe IT Process, as shown in Figure 12a above? And why it might be useful if this mapping also took into account the "Staged" time-slice of an incremental LERCON? Figure 12 If not, then you've never seen a LERCON crash-and-burn because its architects also didn't see the need for explict AsIs to ToBe IT Process mappings.