Data migration : Data migrations have been present ever since IT solutions were introduced and extensive research has been performed in order to further optimize the migration approach. Nevertheless the data migration phase remains an activity with many challenges which, to be avoided, require appropriate attention. By means of this article i just make a attempt to provide insight and over view, covering the complete process is beyond the scope of the the Data Migration Architect article. Some of the main area to focus by a Data Migration Architect can be briefly covered in the current articles. This can be like a key data points to cover and refrain from any fail over in an on going data migration projects or failure post Data Migration.
In the current business scenario everyone want to move to cloud. IAAS has propelled the data migration market as corporate move from on site infrastructure to cloud . Not just the infrastructure, but even the data needs to be migrated from on site to cloud, cloud based storage as part of optimization of business.
Data Architect : Before we do in depth, lets first understand some of the basics of Data Architecture and its importance.
A Data Migration Architect: very commonly, the word architect for and graduate engineer is quite common as an independent engineering field, Architecture. This is no engineering field or any rocket science, but yes in a lay man language, for those new to this term, yes if we compare to an architect engineer can be Data architect and Data Migration architect to some extent can be Term may not be as commonly seems to be new, but is was always there ever since database started playing an important role of information in business.
Data architecture is a very important aspect of any project metamorphosis. The need of this arises as aging data architectures become ambigous,redundant, intractable, and un organised with the changing business requirements, volatile market. The cycle of this metamorphosis starts with bottom-up extraction, mapping, and redesign of refactored data definitions.
The complete life cycle of the Data Architecture derive and Transformation comprises of following Major roles:
Application Data Definition Extraction: This serves as the baseline step for creating a bottom-up view of existing application data. These data definitions should have been semantically rationalized and standardized as part of the refactoring phase of a project because most systems have highly redundant, cryptic, and inconsistent data definitions.
Logical Data Derivation: Using the existing datya defination, as a source this data models provides the chisled view of a new logical data model. This now is the model that can be further refined or even merged with existing data with business data definitions.
Logical Data Model Validation: Involves a combination of merging the bottom-up data model with a top-down business model or refining the bottom-up model based on business semantics. The approach varies based on availability of business semantics expertise and the target data model as well as the degree of new versus existing data to be incorporated into the target architecture.
Physical Data Architecture Deployment: This complete the metamorphosis cycle as it deploys transformed data into the new target environment. Migration of the physical data would need to be timed by system and within the much bigger context of the project scenario.
Basic activity to be covered by any Data Migration Architecture
Most trivial part in data migration project is when moving data from one application to other, though its all depending on the complexity of the project. As the business needs changes, new application and process are developed, this can even involve BPR ( Business Process Re-Engineering). Most common, company running Legacy System for decades and are replaced or augmented by new applications that will share the same dataset.