Recientemente en un cliente del sector seguros comentaba en que consiste el SOA y como la arquitectura de dicha aseguradora se estaba integrando parcialmente mediante SOA. Como siempre surgieron comentarios que proponen alternativas, siendo la más consistente la de la integracion total, es decir: si voy a “juntar” dos sistemas, vuelco los datos de uno a otro y prescindo de los aplicativos del sistema “donante” de datos.

Bueno, no está mal, es decir, es una opción que puede ser valida en ciertos contextos, por ejemplo si solo quieres volcar unos cientos de polizas a tu sistema informático y las aplicaciones de dicho sistema son irrisorias, prescindibles o sino al menos, sustituibles a bajo coste.

Pero desgraciadamente no suele ser así: en la mayoría de proyectos de integracion corporativos los datos no son pocos y los sistemas de ambas arquitecturas de software suelen ser dispares y heterogeneos. Como muestra un boton: una pareja que tuvo la desdicha de contraer matrimonio durante la integración Bankia-Bancaja se vio obligada a cambiar la cuenta del banco tres veces.

No conozco ese proyecto pero supongo que el equipo de proyecto analizó, argumentó y documentó si la integración de sistemas mediante SOA y la coexistencia de datos no hubiera sido más apropiada que cambiar las cuentas a los clientes.

Puede ser que fuera obligado cambiar el número de cuenta al cambiar el código de entidad, pero ¿se podría haber mantenido el código de entidad y correlacionado los numeros de cuenta  para evitar el cambio de cara al usuario final? o ¿estaban obligados a desterrar el codigo de la entidad descontinuada?,

Pd: Da gusto hablar de proyectos ajenos, sin acuerdos de confidencialidad que te impidan hablar y dando lugar al sano debate ^-^.