Limitations on Import/Export Round-Trip

There are an additional considerations when performing what is often referred to as a "round-trip", or importing from tool A, exporting to tool B, editing the model (or not) in tool B, re-import this model in from tool B, and exporting back to tool A. In this case, the 7 points of potential metadata loss identified above are compounded so that there are now 7 additional points of loss:

• They involve methodology changes (e.g., UML back to IDEF1X)
• They may contain "Many to one" or "many to many" type relationships (e.g., data type information and data base definitions many be much narrower in one tool than another)
• They are based upon different levels of information in the import process as opposed to the export process (or vice-versa) used to determine the result (e.g., expressions)
• In addition, the tool's own transformations and metadata coverage (even medium for exchange) will likely be different on import versus export (e.g., import may be using an API with information about the entire tool repository available for the bridge, while export is via an XML file which then must be parsed by the receiving tool itself). Again please refer to the web site for this information Supported Tools(select/click on a bridge to get the full specifications including all the bridge parameters/options and detailed mapping specifications).

The fidelity of some simple types of metadata may be well maintained, where there is a direct, one-to-one, translation from tool A --> MIR's methodology --> tool B and then back again. Examples include tools with the same methodology and metadata coverage (e.g., a data modeling and design tool to another data modeling or design tool), or simple elements like the name, description, layout, etc. This process is referred to as "round-tip migration", and may work successfully given these restrictions.

However, it is never recommended that a combination of import-> export-> edit-> export-> import (i.e., "round-trip engineering") be expected to retain fidelity when there is a migration from tool A to tool B (and vice-versa) of methodology, metadata coverage or any of the known limitations identified above. What round-trip engineering implies is a forward-engineering and then reverse engineering process, which has never been a reality in systems engineering. One should not expect the forward engineering of simple to complex transformations (e.g., forward engineering from a spreadsheet to an ETL tool and then reverse engineering from the ETL tool back to a spreadsheet) would be reversible, or even bear much resemblance to the original.

The proper process is to treat the forward-engineering step as "irreversible", treat the reverse engineering step as a separate process, and not expect to effectively compare the original will the "round-trip" result, nor re-use the result for further engineering of the metadata.

Some examples:

• The process of importing from Informatica PowerCenter and then exporting to Microsoft Excel is in fact a "Mapping Requirement Reporting" exercise consisting of reverse engineering a very complex and large graph of transformations steps into a summary of direct mapping lineage in Excel
• The process of importing an ETL design in Microsoft Excel and exporting it to Informatica PowerCenter is in fact a "Mapping Requirement Forward Engineering" exercise to allow business users to automatically prepare the work for the technical designers of the Informatica design tools

Although each of the above steps can use the same Excel format (MetaMap), the round-trip re-engineering is not recommended and is likely to produce results which are not useful for all of the reasons identified above. Furthermore, like most destination tools, Informatica PowerCenter, as an example, is unable to consume the exported metadata correctly, i.e., it is unable to compare/merge/integrate different versions of complex transformations. (Please see the section on Limitations in the Receiving Environment for Merge/Update of Metadata.)