Follow the LinkedIn discussion
My comment
Your question revives the age-old discussion whether the development of a new application system requires a detailed analysis of the legacy system, and if so, at which stage of the project and to which extent.
For MDM projects as well as for the development of any application, I recommend the following principal steps in this particular order (which is of course only an extract of the actual activities during a software project):
1. Develop the data model structure with the primary metadata (entities, relationships, keys, main attributes including their names and textual definitions) solely based on the requirements for the future application system to avoid being biased by the legacy system (or by any standard software package considered as candidate for the replacement of the legacy system).
2. Once the structure of the new data model is solid, compare the metadata (data model) of the new application with the metadata of the legacy system to add missing attributes including their names and textual definitions to the future data model (i.e. ensure that at least all existing metadata or their semantic correspondences are included in the new data model).
3. Analyze the current data content to complete the attributes’ descriptors (type, length, nullability, permitted range of values, default values) in the future system's data model (i.e. ensure that all values of the legacy system can be mapped / migrated to the new system).
In other words, the current data content does not need to be examined before the structure of the future data model is solid, but certainly before the (logical) data model can be considered being complete and verified.
For MDM projects as well as for the development of any application, I recommend the following principal steps in this particular order (which is of course only an extract of the actual activities during a software project):
1. Develop the data model structure with the primary metadata (entities, relationships, keys, main attributes including their names and textual definitions) solely based on the requirements for the future application system to avoid being biased by the legacy system (or by any standard software package considered as candidate for the replacement of the legacy system).
2. Once the structure of the new data model is solid, compare the metadata (data model) of the new application with the metadata of the legacy system to add missing attributes including their names and textual definitions to the future data model (i.e. ensure that at least all existing metadata or their semantic correspondences are included in the new data model).
3. Analyze the current data content to complete the attributes’ descriptors (type, length, nullability, permitted range of values, default values) in the future system's data model (i.e. ensure that all values of the legacy system can be mapped / migrated to the new system).
In other words, the current data content does not need to be examined before the structure of the future data model is solid, but certainly before the (logical) data model can be considered being complete and verified.
