Diferencia entre revisiones de «Integración versus Migración»
(Página creada con «Cuando dos entidades deben colaborar entre ellas es necesario integrar los datos de ambas. En la decada de los 90 se hablaba mucho del "master data" que representaba las ta...») |
|||
| (No se muestran 11 ediciones intermedias del mismo usuario) | |||
| Línea 1: | Línea 1: | ||
| − | Cuando dos entidades deben colaborar entre ellas es necesario integrar los datos de ambas. En la | + | Cuando dos entidades deben colaborar entre ellas es necesario integrar los datos de ambas. En la década de los 90 se hablaba mucho del "master data" que representaba las tablas del sistema donde se almacenaban los datos maestros de la empresa, habitualmente clientes, productos y conceptos de negocio. SAP fue de las empresas más conocidas en esa época con este enfoque: todo lo "maestro" estaba en un mismo sitio. |
| − | Con el paso del tiempo se vio que | + | Con el paso del tiempo se vio que esta idea tenia carencias, sobre todo en la integración de sistemas muy dispares que debían existir de forma independiente pero al mismo tiempo dar un servicio "común", por ejemplo cuando una empresa compraba a otra o en lo público cuando las competencias estaban transferidas a diferentes comunidades autónomas. |
| − | Una | + | Una pregunta que siempre hay que responder: ¿es mejor migrar un sistema hacia el otro sistema y olvidarnos del primer sistema o deberíamos mantener ambos sistemas funcionando de forma autónoma e integrar solo lo necesario en tiempo más o menos real?. |
| − | Google es muy conocido por realizar integraciones: como Google compra tantas empresas ya tiene toda una | + | Google es muy conocido por realizar integraciones: como Google compra tantas empresas ya tiene toda una política corporativa de coexistencia, donde cada aplicativo es independiente y se establecen "tuberías de integración" para mantener cohesionado aquello que sea necesario. |
| − | == Proyectos donde la | + | == Proyectos donde la migración dio problemas == |
| − | Hay casos muy conocidos donde el tradicional intento de migrar sistemas fue un desastre | + | Hay casos muy conocidos donde el tradicional intento de migrar sistemas fue un desastre |
| − | [[ | + | === Xing circa 2010 === |
| + | |||
| + | El portal de empleo Xing fue comprando portales de empleo menores y unificando sus datos de forma caótica. Muchos usuarios salían varias veces (como si fueran varias personas) en el buscador de Xing, con el tiempo Xing fue totalmente desplazado por Linkedin que mantenía una estructura mas saludable. | ||
| + | |||
| + | === Sabadell y TSB en 2018 === | ||
| + | |||
| + | Todavía en 2018 seguía ocurriendo este problema, migraciones desastrosas donde realmente una integración síncrona "caso-por-caso" hubiera sido mas recomendable, el TSB británico perdió 60.000 clientes por dejar sin servicio durante varias semanas a cientos de miles de clientes al intentar migrar sus sistemas al Sabadell. De haber sido una integración este caso nunca se hubiera podido dar, sin embargo transformar la estructura de los datos y modificar los sistemas de servicios básicos para adaptarse a ello puede romper cualquier sistema. | ||
| + | |||
| + | === Unicaja y Liberbank en 2022 === | ||
| + | |||
| + | [[Fusión Unicaja-LibreBank|Caso similar al de Sabadell]] | ||
| + | |||
| + | |||
| + | [[Categoría:Conceptos sobre proyectos informáticos]] | ||
Revisión actual - 18:39 30 sep 2022
Cuando dos entidades deben colaborar entre ellas es necesario integrar los datos de ambas. En la década de los 90 se hablaba mucho del "master data" que representaba las tablas del sistema donde se almacenaban los datos maestros de la empresa, habitualmente clientes, productos y conceptos de negocio. SAP fue de las empresas más conocidas en esa época con este enfoque: todo lo "maestro" estaba en un mismo sitio.
Con el paso del tiempo se vio que esta idea tenia carencias, sobre todo en la integración de sistemas muy dispares que debían existir de forma independiente pero al mismo tiempo dar un servicio "común", por ejemplo cuando una empresa compraba a otra o en lo público cuando las competencias estaban transferidas a diferentes comunidades autónomas.
Una pregunta que siempre hay que responder: ¿es mejor migrar un sistema hacia el otro sistema y olvidarnos del primer sistema o deberíamos mantener ambos sistemas funcionando de forma autónoma e integrar solo lo necesario en tiempo más o menos real?.
Google es muy conocido por realizar integraciones: como Google compra tantas empresas ya tiene toda una política corporativa de coexistencia, donde cada aplicativo es independiente y se establecen "tuberías de integración" para mantener cohesionado aquello que sea necesario.
Proyectos donde la migración dio problemas
Hay casos muy conocidos donde el tradicional intento de migrar sistemas fue un desastre
Xing circa 2010
El portal de empleo Xing fue comprando portales de empleo menores y unificando sus datos de forma caótica. Muchos usuarios salían varias veces (como si fueran varias personas) en el buscador de Xing, con el tiempo Xing fue totalmente desplazado por Linkedin que mantenía una estructura mas saludable.
Sabadell y TSB en 2018
Todavía en 2018 seguía ocurriendo este problema, migraciones desastrosas donde realmente una integración síncrona "caso-por-caso" hubiera sido mas recomendable, el TSB británico perdió 60.000 clientes por dejar sin servicio durante varias semanas a cientos de miles de clientes al intentar migrar sus sistemas al Sabadell. De haber sido una integración este caso nunca se hubiera podido dar, sin embargo transformar la estructura de los datos y modificar los sistemas de servicios básicos para adaptarse a ello puede romper cualquier sistema.
