Elegir una herramienta de integración de datos

Hola de nuevo,
Me quiero permitir un paréntesis en la serie de artículos que estaba escribiendo sobre los procesos de migración y fusión para hacer una reflexión sobre los típicos errores, prejuicios y omisiones que se dan a la hora de realizar la elección de una herramienta de integración de datos empresarial.
Cuando hablo de integración de datos empresarial es muy importante remarcar la palabra empresarial como una cualidad indispensable en este tipo de soluciones. La razón es muy sencilla, las necesidades de integración son necesidades que no se encuentran vinculadas a un solo proyecto, sino que son comunes a muchas tipologías de proyecto como pueden ser los proyectos de BI, en la parte de carga del Data Warehouse, los proyectos de M&A, los proyectos de BPM, B2B, ERP, CRM, Visión única de cliente, de producto, etc, por lo tanto es muy importante que este tipo de herramientas se plantean como una solución corporativa para las necesidades de integración de la empresa y no como una solución puntual para cubrir las necesidades de un proyecto específico.
Partiendo de esta aclaración o premisa me gustaría enumerar los 4 errores típicos o los 4 argumentos de resistencia que me he encontrado en el mercado a la hora de plantear soluciones basadas en productos de integración de datos.
La idea es plantearos el requerimiento o la necesidad que deberíamos considerar a la hora de elegir la herramienta y a continuación os explico los errores típicos, situaciones y consecuencias que se planean de una aproximación errónea.

Caso 1:
La herramienta ha de cubrir los requerimientos actuales y asegurar capacidades de crecimiento y adaptación a nuevos requerimientos.

• Error 1: Adquirimos la herramienta que se ajusta a las necesidades actuales sin valorar el crecimiento futuro.
• Posible situación: A los 10 meses aparece un nuevo requerimiento y no podemos hacer frente con la herramienta que escogimos.
• Argumento utilizado por IT: Era la más barata, su coste era reducido, de fácil implantación, etc.
• Punto de vista de dirección: Mala decisión por parte de IT ya que esta herramienta nos saldrá muy cara porque ahora debemos adquirir una nueva para cubrir las necesidades actuales y perdemos la inversión hecha en esa herramienta, el tiempo de implantación, la formación a los administradores y tenemos que volver a pasar por todas esas fases.

Caso 2:

La herramienta ha de tener capacidades de reutilización de procesos.

• Error 2: La herramienta que elegimos NO permite diseñar los procesos de ETL como módulos reutilizables entre los diferentes procesos de carga.
• Posible situación: Nos encontramos que muchos de los procesos de tratamiento de datos son repetitivos y tenemos que volver a generar cada uno de esos procesos.
• Argumento utilizado por IT: Es muy fácil volver a generar el proceso, al final es hacer un copy/paste entre diferentes procesos.
• Punto de vista de dirección: Mala decisión por parte de IT ya que sí mañana cambio la lógica de tratamiento de los datos he de volver a revisar todos los procesos donde se utiliza esa lógica y no dispongo de un punto centralizado donde realizar el cambio.

Caso 3:
La herramienta ha de poder realizar análisis de impacto y dependencia entre orígenes y destinos.

• Error 3: No consideramos esta funcionalidad como algo primordial ya que actualmente sólo tengo una base de datos con unas cuantas tablas y un solo destino.
• Posible situación: Después de varios meses de uso necesitamos cambiar un campo en una tabla, añadir un campo nuevo o cambiar la base de datos de SQL a Oracle ya que nuestro director ha firmado un acuerdo corporativo con Oracle.
• Argumento utilizado por IT: Esta situación era difícil de prever ya que llevamos años utilizando la misma tecnología de DDBB. No contemplamos el cambio en la orientación del negocio o los datos.
• Punto de vista de dirección: Falta de previsión por parte de IT, nuestro negocio es dinámico y siempre se pueden producir cambios en la metodología o lógica que aplicamos, así que las herramientas han de ser capaces de adaptarse a esos cambios.

Caso 4:
Para reducir los costes de integración y anticiparse a los errores de calidad del dato o formato debemos tener capacidades de perfilado.

• Error 4: El perfilado no es necesario ya que conocemos muy bien el modelo de datos de nuestras bases de datos.
• Posible situación: Empiezan a aparecer errores de datos motivados por formatos no esperados o campos con contenido no esperado (Nulls, diferentes formatos de fecha, números no validos, etc).
• Argumento utilizado por IT: El problema reside en el Data Entry ya que las chicas que entran los datos en el Call Center no hacen caso de la normativa de entrada de datos.
• Punto de vista de dirección: Falta de previsión por parte de IT, el personal del call center es subcontratado y rota con mucha frecuencia, no podemos asegurar su formación para entrar los datos perfectos, cada persona escribe las fechas o los teléfonos de forma distinta, algunas no entienden el uso que podemos llegar a hacer de cada dato,…

Otras consideraciones:

• Necesidades de conocimientos de lenguajes de programación específicos (script, java, pl/sql,…)
• Falta de capacidades de autodocumentación de procesos
• Entornos de desarrollo y producción sin capacidades de despliegue guiado, versionado, roll-back, etc.
• Limitadas capacidades de crecimiento vertical, horizontal y optimización del rendimiento (grid computing, alta disponibilidad, particionado, pushdown, etc)
• Imposibilidad de extender el uso de la herramienta a entornos Saas y B2B. (EDI, SEPA, Swift, …)
• Imposibilidad de incorporar datos de formatos no estructurados (excel, pdf, word, etc)

Como resumen de todas estas experiencias que me he ido encontrando a lo largo de todos estos años, me gustaría hacer hincapié en que a la hora de analizar una herramienta de integración de datos no es quedéis sólo en el precio, el fabricante o las capacidades de conexión, porque a la larga pueden aparecer escenarios como los que hemos planteado donde quede claro que la elección no ha sido muy afortunada y en ese momento tendréis un problema sobre la mesa muy difícil de gestionar, creerme que no es grato averiguar al cabo de unos meses que te has equivocado con la elección de la herramienta y que el único argumento que puedes esgrimir ante tus jefes es que “era más barata” o que “para ese proyecto servía”, porque lo único que van a ver tus jefes es que tienes una gran falta de visión global del negocio, de previsión y por lo tanto de gestión de tus presupuestos o proyectos.