"One problem area for refactoring is databases. Most business applications are tightly coupled to the database schema that supports them. That's one reason that the database is difficult to change. Another reason is data migration. Even if you have carefully layered your system to minimize the dependencies between the database schema and the object model, changing the database schema forces you to migrate the data, which can be a long and fraught task." (Martin Fowler et al, "Refactoring: Improving the Design of Existing Code", 2002)
"Data migration is not just about moving data from one place
to another; it should be focused on: realizing all the benefits promised by the
new system when you entertained the concept of new software in the first place;
creating the improved enterprise performance that was the driver for the
project; importing the best, the most appropriate and the cleanest data you can
so that you enhance business intelligence; maintaining all your regulatory,
legal and governance compliance criteria; staying securely in control of the
project."
"The key to a successful migration is to remember that data migration is a business not a technical problem and data quality is a business not a technical issue. It is for the enterprise to dictate how and where data comes from and goes and what constitutes sufficient data quality. It is our jobs, as handmaidens of progress, to assist with the technical issues of moving data from one place to another, identifying referential integrity and other technical issues, and facilitating the process. But we are the servants not the masters." (John Morris, "Practical Data Migration", 2009)
"Data migration is indeed a complex project. It is common for companies to underestimate the amount of time it takes to complete the data conversion successfully. Data quality usually suffers because it is the first thing to be dropped once the project is behind schedule. Make sure to allocate enough time to complete the task maintaining the highest standards of quality necessary. Migrate now, clean later typically leads to another source of mistrusted data, defeating the whole purpose of MDM." (Dalton Cervo & Mark Allen, "Master Data Management in Practice: Achieving true customer MDM", 2011)
"Data migration, in simple terms, is about physically copying data from one repository into another. The need for a data migration effort is highly dependent on the MDM architecture chosen [...] The goal of MDM is to eliminate redundant systems and have a single system-of-record. Therefore, it seems contradictory to have a temporary ongoing data migration, which is, in essence, maintaining multiple systems and having to write additional software to keep them synchronized." (Dalton Cervo & Mark Allen, "Master Data Management in Practice: Achieving true customer MDM", 2011)
"Companies typically underestimate the importance of metadata management in general, and more specifically during data migration projects. Metadata management is normally postponed when data migration projects are behind schedule because it doesn’t necessarily provide immediate benefit. However, in the long run, it becomes critical. It is common to see data issues later, and without proper metadata or data lineage it becomes difficult to assess the root cause of the problem." (Dalton Cervo & Mark Allen, "Master Data Management in Practice: Achieving true customer MDM", 2011)
"For a metadata management program to be successful, it needs to be accessible to everybody that needs it, either from a creation or a consumption perspective. It should also be readily available to be used as a byproduct of other activities, such as data migration and data cleansing. Remember, metadata is documentation, and the closer it is generated to the activity affecting it, the better." (Dalton Cervo & Mark Allen, "Master Data Management in Practice: Achieving true customer MDM", 2011)
No comments:
Post a Comment