antonidavia 19 mayo, 2018

Dentro del proceso de segregación de las actividades de gestión inmobiliaria de las entidades bancarias, una de las acciones es la separación completa de los sistemas informáticos.

Estos proyectos han de permitir que este tipo de compañías, que necesitan una constante evolución de sus sistemas informáticos para adaptarlos a los requerimientos de los clientes (fondos de capital riesgo y otras entidades bancarias), que son muy exigentes en cuanto a seguridad y capacidades de los sistemas, así como en los plazos de entrega.

Las principales dificultades de estos proyectos estan relacionadas con que la tendencia de la matriz es a la copia+segregación de los sistemas, mientras que la necesidad del servicer es un cierto nivel de transformación de los servicios para hacerlos más viables tras el proyecto. En esta línea, los principales retos son:

  • Disponibilidad de recursos por parte del área IT de la empresa matriz. Los servicers al final son empresas filiales, por lo que es difícil que se prioricen los recursos frente a la actividad principal del banco, justo en un momento de transición donde es más necesario que nunca. El hecho de que el servicer pertenezca a la empresa matriz, hace que la capacidad de presión sea muy limitada.
  • Tendencia de la matriz a crear una infraestructura a imagen de la matriz. Los bancos son entidades que por sus características por el momento son más tendientes a arquitecturas on-prem incluso en CPD propio, lo que dificulta que la migración pueda realizarse a arquitecturas actuales que serian nativas en cloud. Los equipos IT de la matriz tienden a priorizar la seguridad de la segregación frente a la necesidad de la nueva empresa de tener unos sistemas flexibles y a un coste razonable. Esto lleva a que tras el carve-out el servicer tenga unos sistemas parecidos en tecnologia a los de un banco, cuando no es lo más adecuado para una empresa de sus características.
  • Resistencia por parte de las áreas de explotación de la matriz a realizar una gestión compartida de los sistemas con las empresas que llevaran el servicio tras el carve-out, lo que hace que una vez finalizado la transferencia del servicio sea muy compleja. Seria mucho más sencillo que la segregación fuera simultánea con el cambio de proveedor.

En un proyecto de este tipo, que en desarrollo puede ser análogo a segregaciones en otros sectores, los principales tracks son los siguientes:

  • Red de comunicaciones – la nueva empresa debe crear una nueva red de comunicaciones independiente, que conecte sus centros. En este momento, nace el nuevo CPD, de momento con los nuevos equipos core de red, conectado con una extensión de LAN con el CPD de la matriz.
  • Nuevo dominio – se crea un nuevo dominio Windows, se establece una relación de confianza con el inicial, y se realiza la migración de todos los servidores en origen hacia este nuevo dominio. Es una buena ocasión para hacer una revisión de las políticas y adaptarlas a las necesidades del servicer, aunque como dije antes esto requeriria que la empresa que se vaya a hacer cargo de la explotación tras el carve-out entrara ya en juego, lo que es punto de conflicto.
  • Migración de la microinformática – es necesario definir una nueva maqueta de los equipos (que buen momento para cambiar a Windows10, o incorporar las funcionalidades de Office365), y hacer el despliegue en todos los PCs, que así pasaran a formar parte del nuevo dominio. Este track es uno de los más costosos en tiempo y recursos, e implica también a los terminales móviles.
  • Nuevos sistemas de gestión IT – incluye la implantación de nuevas herramientas de gestión de tickets (ServiceNow en este caso), de monitorización, antivirus y backup, Las herramientas técnicas no representan demasiado problema, se implantan en el nuevo CPD, y a través de la extensión de LAN se migran los servidores en una operación relativamente sencilla. Lo más problemático es conseguir que la empresa de explotacion IT de la matriz utilice los nuevos sistemas de ticketing en paralelo a los suyos, esto puede ser un problema mayor de lo que pudiera parecer,
  • Migración de servidores – en este track, se implanta la nueva infraestructura destino y a través de maniobras (utilizando los sistemas de contingencia para los sistemas dedicados -AS400, Hana- y las facilidades de VMWare para los virtuaizados) se planifica el traslado de los servidores al nuevo CPD. En estas situaciones, no hay margen para cambiar el direccionamiento IP de los servidores, ni los nombres de equipos, lo que hubiera permitido un paralelo. Demasiado riesgo en plazos. Ni tampoco para una migración a cloud, lo que seria una estrategia más de re-instalación de productos y migración de datos, que es la que yo recomendaría como ideal, aunque el proyecto requiera más tiempo.
  • Nuevos servicios de seguridad – en este track es mucho mayor la definición por parte de la empresa saliente. Incluye el diseño de la seguridad perimetral, la captura de logs, la contratación del SOC, etc..
  • Revisión de las integraciones – una de las principales dificultades puede residir aquí, en la identificación de la comunicación entre sistemas de la filial y la matriz, ya que cuando se encuentren separadas por FW perimetrales es necesario crear las reglas de acceso específicas para tener el control de estos accesos, que son de mucho riesgo. Si no se dispone de un inventario previo, esto puede llevar meses.

Una vez finalizada la migración de servidores, queda la parte final, que es el corte de la comunicación LAN to LAN entre los CPDs, la conexión de la salida a Internet independiente del nuevo CPD, y la ruptura de la relación de confianza entre los dominios Microsoft. Este es el momento crítico, pues es donde veremos si hemos identificado correctamente las integraciones, y si no queda dependencia entre los dos datacenters.

Como conclusión, este tipo de proyectos tiene el riesgo de no cumplir con las expectativas de la dirección, ya que si se desarrollan como hemos comentado como una copia de los sistemas de la matriz, hipotecan el desarrollo de la empresa escindida. Salir de origen con grandes inversiones en HW en sistemas on-prem, dificulta el poder aprovechar la potencia de los entornos cloud, que es donde está actualmente la innovación y la velocidad, que es lo que necesitan empresas de este tipo.

Para evitar riesgo, es necesario establecer de forma clara con la dirección las expectativas, para evitar que la creencia de que al terminar el proyecto todo será mucho más sencillo no se vea frustrada.

Deja un comentario.

Tu dirección de correo electrónico no será visible. Los campos obligatorios están marcados con *