Las migraciones de datos a menudo fallan porque se usan métodos tradicionales #
Los programas personalizados y las soluciones de enlatadas de ETL (Extract- Transform-Load, por sus siglas en inglés) son los métodos más comunes utilizados para migrar grandes volúmenes de datos. Ambos esfuerzos requieren cierto grado de desarrollo.
En el caso de un programa personalizado, toda la solución se desarrolla desde cero. En el caso de una solución ETL, se debe crear varias interfaces y luego se debe agregar la lógica de transformación. Ambas actividades generalmente se completan utilizando metodologías tradicionales de desarrollo de software. Pero los métodos tradicionales a menudo fallan cuando se aplican a las migraciones de datos. ¿Por qué?
Dependen de requisitos iniciales muy precisos que no se pueden alcanzar #
A menudo, el sistema fuente es antiguo, grande y complejo y los conjuntos de habilidades necesarios para el análisis de requisitos son escasos. Es común que la documentación del sistema sea pobre, desactualizada o no exista. Algunos requisitos simplemente provienen de personas con conocimientos que han realizado migraciones antes, pero debido a que las migraciones de datos son eventos poco comunes, los recursos con estas habilidades no están disponibles para contribuir con los requisitos críticos. Debido a estas cosas, la mayor parte de los requisitos se descubren a mitad del camino.
Todo termina en un ciclo interminable de requisitos refinados que son impredecibles y difíciles de manejar #
Esto ocurre porque cuando se descubren nuevos requisitos en la mitad del ciclo, los métodos tradicionales no se pueden acomodar fácilmente. Los nuevos requisitos afectan el diseño y la implementación. Los nuevos cambios en la implementación y las pruebas adicionales también descubren más requisitos. Los nuevos requisitos afectan la implementación, etc.
Este ciclo es costoso y difícil de administrar con las metodologías tradicionales.
No permiten que los requisitos de migración de datos se desarrollen al mismo tiempo que las modificaciones funcionales del sistema destino #
Existe una codependencia natural entre la migración de datos y las modificaciones funcionales del sistema destino. Los datos de producción real, que solo están disponibles a partir de los esfuerzos de migración de datos, exponen nuevos requisitos que afectan las modificaciones del sistema destino. Las modificaciones del sistema destino exponen nuevos requisitos que afectan la migración de datos. Esto da como resultado que cada grupo espere que el otro se complete para que puedan avanzar (a menudo con muchos dedos apuntando).
No proporcionan herramientas o métodos para identificar o medir el éxito #
Cada intento de migrar datos tiene algunas cosas que son buenas y otras que no. Cuando se tienen datos muy grandes y no hay herramientas, es difícil identificar qué es bueno y qué no.
La documentación de diseño de migración de datos no se puede usar para respaldar los repasos que son una parte común del proceso #
Se necesita mucho trabajo manual para mantener la documentación en sincronía con los requisitos emergentes. Como resultado, la documentación generalmente se vuelve cada vez más imprecisa a medida que avanza el ciclo de vida del proceso. La documentación creada automáticamente, por otro lado, a menudo contiene código sin formato o algún otro contenido inutilizable o se presenta en un formato que no es utilizable. La documentación inexacta o inutilizable reduce la efectividad de los recorridos.
Las soluciones ETL tienen problemas adicionales #
Dado que las interfaces ETL se desarrollan utilizando las mismas técnicas que impulsan el desarrollo de programas personalizados, fallan por los mismos motivos. Pero las soluciones ETL se ven afectadas por otros problemas que también contribuyen al fracaso. ¿Por qué fallan las soluciones ETL cuando se aplica a migración de datos?
Sus diversas interfaces se desarrollan utilizando las mismas metodologías tradicionales propensas a fallar #
Esto lo discutimos anteriormente. Cuando estas técnicas se aplican en la migración de datos, incluso aquellas que se intentaron con herramientas ETL, pueden provocar fallas.
No adoptan tecnologías legadas #
Las soluciones ETL no pueden utilizar la funcionalidad legada, como las rutinas de sistemas I/O que extraen o cargan datos o las rutinas de conversión de datos, como funciones que realizan cálculos de fecha de creación. Además, no manejan formatos de almacenamiento de datos legados o propietarios que son comunes en aplicaciones más antiguas.
Requieren infraestructura costosa adicional #
Hay varios tipos de productos de «middleware» disponibles que permiten que las plataformas legadas se comuniquen perfectamente con las plataformas más nuevas. Este tipo de middleware a menudo requiere habilitar una solución ETL para acceder a archivos y bases de datos legados. Pero este es un componente costoso para agregar a un sistema que puede estar en proceso de desmantelamiento y requiere una experiencia particular para su uso.
Resultan en una mezcla de componentes legados y modernos con componentes manuales intermedios #
Incluso cuando el middleware correcto está disponible, los tipos de archivos más antiguos y los formatos de datos propietarios a menudo requieren que los componentes del lado heredado se desarrollen con un lenguaje y tecnología diferentes para extraer datos. La combinación de tecnologías es una solución compleja que requiere múltiples conjuntos de habilidades, múltiples entornos de desarrollo y más o más equipos grandes. Esto aumenta las vías de comunicación, las horas de implementación, el costo y la probabilidad de falla.
