Metodologías de migración de datosEscrito por Daniel Aisemberg el 18/06/2019 a las 20:19:336070
(Director EvaluandoERP) La migración de datos es un proceso de una sola vez, es decir que una vez que culmina se detiene. Cada sistema usualmente tiene su propio modelo de datos, lo que plantea la necesidad de realizar mapeo de datos. Raramente una migración se realiza sin transformación de datos. En este artículo presentamos tres metodologías para abordar el proyecto. Metodología libre de plataformas intermedias
Esta metodología de migración de datos se denomina “The Butterfly Methodology: A Gateway Free Approach for Migrating Legacy Information Systems”. Su foco está puesto en lo que sus autores consideran lo más importante: los datos.
Propone eliminar el problema de mantener el sistema legado y el sistema destino corriendo juntos, lo que implica mantenerlos sincronizados para poder tener coherencia entre ellos.
En la práctica, cuando el sistema destino se despliega en producción, el sistema legado debería seguirse utilizando. Sin embargo, es probable que, durante la migración, el sistema destino no se encuentre aún implementado. La razón para elegir esta estrategia se debe a los desafíos técnicos que representa mantener la consistencia entre el legado y el destino, y a la falta de una solución general para este tipo de situaciones.
Con el fin de manejar el proyecto, esta metodología hace que la base de datos del legado se convierta en sólo lectura desde que se inicia el proceso de migración y hace uso de almacenamientos temporales para los datos que necesitan ser guardados antes de que el sistema destino se ponga en producción. A las bases o almacenamientos temporales se accede a través de un componente que redirecciona las peticiones a la base correcta.
La migración es apoyada también por una herramienta de transformación de datos. Durante el proceso, la base se convierte temporalmente a modo sólo lectura y luego se migra de forma incremental hasta que los datos que quedan en el legado son menores a un margen o valor establecido al comienzo del proyecto. Esto significa que el último almacenamiento temporal puede migrar con poco esfuerzo y en un corto espacio de tiempo para que el sistema no sufra de largo tiempo de inactividad y de indisponibilidad. Después de este último paso de la migración, el sistema destino estará listo para ponerse en producción. Fases de la metodología de migración de datos libre de plataformas
Esta metodología es denominada como libre de plataformas intermedias (Gateway-free) y consta de seis fases:
Esta primera metodología, si bien se centra en los datos, no es exclusiva para migración de datos, sino que abarca un contexto más grande que es la migración de sistemas. Metodología iterativa más fases inicial y final
Philip Russom como Senior Manager of Research and Services The Data Warehousing Institute, presenta un modelo de mejores prácticas que se centra en la premisa que la migración de datos es por naturaleza iterativa y consta de cinco fases más una fase preliminar y una final, reconociendo que el desarrollo del proyecto en sí mismo consta de muchos ciclos repetitivos de perfilamiento, análisis, diseño y pruebas.
La imagen a continuación ilustra el proceso de migración de datos propuesto y evidencia la naturaleza cíclica e iterativa mencionada.
Desarrollo de la solución de migración como un proceso cíclico Autor: Russom, Senior Manager of Research and Services The Data Warehousing Institute Fases de la metodología de migración de datos iterativa
Además del marco metodológico propuesto por el autor, se hace referencia a un conjunto de aspectos críticos y buenas prácticas, que resultan relevantes de cara a la investigación planteada. Algunas de ellas son las siguientes:
Migración de datos práctica (Practical Data Migration)
Otro trabajo de interés en el área es el libro Practical Data Migration. En esta obra se propone, en primera instancia, que la migración de datos debe manejarse como un proyecto independiente en sí mismo debido a que tiene sus entregables y reglas específicas, requiere un grado de negociación entre lo funcional y lo técnico en la organización, precisa de habilidades especializadas y no puede encasillarse dentro de la estructura de proyectos estándar.
El modelo de este autor es denominado “Practical Data Migration v2” (en adelante PDM2) y propone un enfoque integral que consta de varios módulos que cubren el alcance completo de la migración de datos, desde sus inicios hasta la desconexión de los sistemas legados. También presenta un resumen de los tipos de tecnología disponibles para soportar la migración de datos.
Representación de PDM2 - Autor de Johny Morris
Los módulos considerados por el autor se encuentran representados en el modelo PDM2 de la figura anterior y se encuentran organizados en dos flujos o streams: el primero es el de negocio y el segundo el de tecnología. La idea es integrar ambas partes del proyecto. Análisis del panorama - Landscape Analysis (LA)
Este módulo usa varias técnicas para descubrir y catalogar almacenamientos de datos legados (legacy data stores - LDS) y su relación entre ellos. Se analizan los sistemas de almacenamiento de datos de los legados para ver cómo funcionan, qué datos tienen y qué “sorpresas” pueden contener. Este perfilamiento de datos se puede realizar mediante el uso de herramientas de software disponibles y de forma manual. Es necesario buscar conscientemente todos los legados
Una importante ventaja de este método es que el análisis del panorama puede comenzar antes del diseño o incluso la selección del sistema de destino. Análisis de brechas y mapeo - Gap analysis and mapping (GAM)
Se realiza el mapeo de datos una vez que el sistema de destino está disponible. El mapeo de datos es la vinculación de campos en los legados con los campos en el destino, además de definir la lógica de transformación que se necesita para dividir datos y fusionar campos. Un ejemplo clásico de esto es reformatear nombre y direcciones donde quizás una base de datos fuente tenga el nombre en un solo campo, pero el destino tiene el nombre y el apellido por separado y solo contiene la primera línea de la dirección, el resto se deriva de un archivo postal nacional basado en un código postal. Diseño y ejecución de migración - Migration Design and Execution (MODE)
Es donde el diseño físico, pruebas y ejecución de la migración se llevan a cabo. La migración de datos es más que simplemente mover bits y bytes. Se debe conocer las limitaciones de negocio, tiempos, requisitos de auditoría, linaje de datos, plan de vuelta atrás (rollback), requisitos de informes, de gestión y control, etc. MODE integra también los requisitos comerciales para la desconexión y retiro de los sistemas legados. Desmontaje del legado - Legacy Decommissioning (LD)
Cubre la eliminación física o lógica de bases de datos legadas, hardware y software. También cubre la entrega de almacenamiento de datos legados para componentes de datos que deben retenerse por algún tiempo pero que no se deben migrar al destino. También hay procesos de cierre del proyecto, incluido el traspaso de problemas de calidad de datos (que no fue posible ajustar dentro del tiempo del proyecto y por restricciones de presupuesto) a los equipos de calidad de datos del día a día (donde existan). Reglas de calidad de datos - Data Quality Rules (DQR)
Es la pieza central que hace único el modelo PDM2. Siguiendo el principio de Super SMART Tasks, este módulo gestiona toda la calidad de los datos.
Integra a los expertos en sistemas técnicos heredados, los especialistas del sistema destino y los expertos en dominios de negocio para priorizar, administrar y completar todos los problemas de datos, incluida la selección y exclusión de fuentes de datos.
Es “Súper Inteligente” porque integra el equipo al hacer que se relacione con los recursos del resto de la empresa, lo que implica la creación de un solo equipo virtual; empodera a los colegas del negocio y les da las habilidades y la oportunidad de hacer una contribución positiva al proyecto. Se completa la tarea al incorporar conocimiento empresarial muy necesario en un marco colaborativo. Gestión de los interesados claves de los datos-Key data stakeholder management (KDSH)
PDM2 tiene sus propias definiciones de roles específicos para cada interesado clave de datos. La gestión de los interesados clave de los datos gestiona el descubrimiento, la información y la gestión de estos individuos. PDM2 está muy centrado en el negocio, por lo que hay tantos roles de negocio como técnicos. Los dos interesados más importantes son los propietarios de los datos y los expertos en el dominio empresarial.
Los propietarios de datos son todas las personas dentro o fuera de una organización que tienen el poder legítimo de detener una migración. Plan de retiro del sistema
El objetivo final de una migración de datos es desactivar los sistemas legados. Es por esta razón que bajo el modelo PDM2 propone iniciar la conversación con el negocio por este tema. Se trata de una serie de preguntas estructuradas para obtener una visión empresarial de la migración, buscando elementos necesarios como requisitos de:
Estrategia de migración y gobernanza - Migration strategy and governance en adelante (MSG)
Cubre todas las funciones de gerencia estándar que se esperan en un proyecto bien gestionado, más algunas actividades exclusivas que PDM2 propone. Se realiza especial énfasis en la creación de una estrategia de migración de datos que debe completarse con la participación de la alta gerencia. Zona desmilitarizada - Demilitarized zone (DMZ)
Hace las veces de interfaz entre el trabajo del proveedor de tecnología y las responsabilidades de sus clientes. La DMZ es un componente clave de PDM2 que, en cierta medida, se definirá formalmente en el contrato con el proveedor. Sin embargo, la DMZ es más amplia que el contrato, y su definición formal ayudará a ambas partes a comprender y gestionar sus dependencias.
El modelo expone además la importancia de la tecnología en el desarrollo de los proyectos de migración de datos, considerando las herramientas subyacentes y de apoyo a procesos como la calidad de datos, el perfilamiento de datos y controladores para la migración. Sugiere además que el uso de software especializado para estos fines reduce el riesgo del proyecto, en lugar de realizar desarrollos propios, pues han sido probadas por más tiempo y con la lógica específica de la migración.
Por la División consultoría de EvaluandoSoftware.com Daniel M. Aisemberg, director de Evaluando Software
|