Manejar la diversidad tecnológica y las capacidades de migración durante procesos de fusiones y adquisiciones de empresas

Por Bryn Price 

En escenarios de fusiones y adquisiciones, la necesidad de entender y manejar la diversidad tecnológica, así como el estado de preparación para la migración, es imprescindible para asegurar la cohesión y el éxito de forma continua en la organización.  En este artículo se discuten algunas consideraciones sobre el tema y se presentan algunos mecanismos existentes de AWS que pueden ayudar a su organización en el proceso a través de las fases de: Evaluación, Movilización y Migración.

Evaluación

Cuando una organización pone en consideración una migración por cuenta de una adquisición, bien sea desde infraestructura on-premise u otro proveedor de nube, es importante llevar a cabo una evaluación sobre el nivel de preparación de cada organización para afrontar este paso, así como una evaluación general de la diversidad en tecnología. El AWS Migration Readiness Assessment (MRA) es un mecanismo que permite desarrollar un mejor entendimiento de la interdependencia entre los diferentes dominios de negocio y tecnología que se requieran para una migración efectiva. También permite desarrollar recomendaciones para identificar y mitigar riesgos en el proceso. Ejecutar este taller de forma interactiva, permite diseñar una serie de acciones que se necesitan para construir capacidades basadas en el estado actual de la compañía, metas de negocio y objetivos definidos, que posteriormente permitirán crear y conservar el momento en el proceso de migración. El MRA examina el nivel de madurez de la organización a través de los seis pilares del Cloud Adoption Framework (CAF): Negocio, Personas, Gobierno, Plataforma, Seguridad y Operaciones.

Ejecutar el MRA, con cada una de las compañías que se adhieren, ayudar a realizar un diseño para la organización tecnológica resultante basado en la madurez relativa, diversidad tecnológica, así como fortalezas y debilidades de cada una de estas.

Llegar a operar en un solo lugar permite incrementar la eficiencia operacional, reducir costos, mejorar la seguridad y la agilidad. También permite enfocarse en los objetivos principales del negocio y sus usuarios. Remover esos riesgos en la migración ayuda a simplificar el proceso de transición. Es claro que no existe una única solución para todas las migraciones, pero estas son estrategias que pueden ayudar.

Una vez realizado el MRA, su organización debe considerar cuando y cuales partes del stack tecnológico deben ser consolidadas. Hay un gran número de consideraciones, muchas de las cuales hacen parte de la naturaleza de la adquisición y la estrategia de su organización.

En términos de diversidad tecnológica, se pude obtener consecuencias favorables, así como desfavorables. A medida que se crece, se debe ser cauteloso ya que, así como la diversidad tecnológica puede potenciar la productividad, gracias a la libertad de los desolladores para innovar, también puede jugar en contra de las capacidades de la organización para escalar. La carga operacional y el incremento en riesgos de seguridad por manejar una plataforma muy diversa puede sobreponerse sobre los beneficios. “The Paved Road” o la ruta pavimentada es una aproximación acuñada por Netflix y que ha sido adoptada por un gran número de organizaciones para construir un balance de gobierno, mientras se soporta la innovación. Aquí se alinean las expectativas y formaliza una serie de compromisos entre equipos sobre la elección de tecnologías para proveer un marco de trabajo bien integrado y compatible que permita a los desarrolladores enfocarse en entregar valor al negocio. Esta aproximación, permite a tomar diversas formas, sin embargo, frecuentemente incluye uno o más equipos de plataforma que proveen herramientas específicas y abstracciones tecnológicas para eliminar la carga de los demás equipos. Las inversiones realizadas para “pavimentar la ruta” son hechas en conjunto con esos equipos lo que resulta en mejora de la experiencia de los desarrolladores, en vez de la implementación del mínimo común denominador del portafolio. La estandarización provee consistencia, interoperabilidad, seguridad, y confiabilidad, además de soportar el rápido desarrollo y la innovación. A partir del ensamblaje de patrones y componentes que son respaldados por los miembros de la organización, se logra una reducción del desarrollo utilizando copy paste y desvíos entre las versiones, liberando así a los desarrolladores para enfocarse en metas y resultados. Los equipos pueden decidir no usar una “ruta pavimentada”, pero debe ser un proceso de decisión consciente y no una desviación accidental.

A medida que una organización crece, se introducen más procesos, más complejidad, y más mecanismos de gobierno, lo que puede volverse problemático si su respuesta es reactiva. Esto significa forzar el modelo operativo existente para acoplarlo a la demanda sin evolucionar conscientemente la estructura de la organización y sus herramientas. En estos casos, la diversidad tecnológica puede convertirse en un problema, pues obliga la creación de fachadas y planos de control al frente de ambientes dispares, que crean carga operacional. Es importante tener en cuenta este factor, junto con el entrenamiento y rotación del personal, cuando se analiza el costo de la diversidad tecnológica de una organización en el tiempo.

Por ejemplo, la contratación de nuevos desarrolladores pude ser retadora, pues deben ser capacitados en una capa de abstracción sobre múltiples nubes, causando una inhabilidad para los equipos de TI de prestar buen servicio en una fase de crecimiento del negocio. Adicionalmente, abstraer a los desarrolladores de la nube puede reducir su capacidad de experimentación e impedir la utilización de nuevos servicios y funcionalidades hasta que estos sean adoptados por la tecnología que se encuentra sobre estos. Esto puede sofocar la innovación e impactar retención de talento ya que sus habilidades de nube son diluidas.

Movilización

Un proceso de descubrimiento detallado durante la fase de Movilización es vital para entender el estado de cada una de las cargas de trabajo que van a ser migradas a la nube. Una herramienta que puede ayudar en este proceso es el Well-Architected Framework, ya que este no se ajusta únicamente a las cargas de trabajo nativas de AWS. Esta herramienta puede utilizarse para cargas de trabajo existentes que no corren en recursos de AWS actualmente. El Well-Architected Framework evalúa las cargas de trabajo en seis pilares:

• Excelencia Operacional: La habilidad de soportar el desarrollo y ejecución de cargas de trabajo de forma efectiva. Además de tener hallazgos de las operaciones, mejorar los procesos de soporte de forma continua y los procedimientos para agregar valor al negocio.
• Seguridad: Tomar ventaja de las tecnologías de la nube para mejorar las habilidades para proteger los datos, sistemas y otros activos tecnológicos.
• Confiabilidad: La confiabilidad en las cargas de trabajo para ejecutar sus funciones correctamente. Esto incluye la capcidad de operarlas y probarlas durante su ciclo de vida completo.
• Rendimiento eficiente: Es la habilidad de usar los recursos de cómputo para cumplir con los requerimientos del sistema y mantener la eficiencia a medida que la demanda cambia y las tecnologías evolucionan.
• Optimización de costos: Es la habilidad de correr las cargas de trabajo con una visión consciente sobre el gasto para cumplir con los objetivos de negocio mientras se minimizan los costos.
• Sostenibilidad: Es la habilidad de medir y establecer metas de sostenibilidad para reducir el impacto ambiental ocasionado por las cargas de trabajo.

Entender las cargas de trabajo bajo estos pilares provee una alineación con las mejores prácticas de arquitectura.

AWS ha publicado un blog sobre este tema, sin embargo, a pesar de que este hable más sobre cambios de AWS a AWS, el proceso de pensamiento es el mismo sin importar el origen de las cargas.

El Well-Architected Framework también puede ayudarlo a mantenerse informado de la evolución de la plataforma y prepararse para la fase de crecimiento. A la vez que se define la huella arquitectónica y operacional de su infraestructura en AWS, se debe pensar continuamente en como su ambiente puede soportar nuevas adquisiciones. Los arquitectos deben construir un ambiente ágil y sin fricción que pueda acomodarse a los picos en la adopción de nuevas cargas sin generar sobrecarga operacional. La idea aquí es permitir una migración rápida de las nuevas entidades adquiridas para reducir los riegos de seguridad, los costos asociados a la doble burbuja y la carga operacional de correr múltiples y diversos ambientes de tecnología.

Migración

Para cargas de trabajo individuales, el AWS Prescriptive Guidance provee estrategias, guías y patrones probados en el tiempo por AWS y sus socios de negocio para acelerar proyectos. Por ejemplo, en el caso de migrar de Azure a AWS, hay un gran numero de patrones y herramientas para mover y convertir los recursos. Por ejemplo: un Azure VM a un Amazon EC2, un Azure Service Bus a un Amazon SQS o una portación de .NET a .NET Core para permitir las aplicaciones existentes correr en Linux o en contenedores basados en Linux.

Conclusión

Los procesos de fusiones y adquisiciones pueden ser un punto de inflexión para el crecimiento de una organización. Por medio de la utilización de mecanismos como el Migration Readiness Assessment, Well-Architected Framework y el AWS Prescriptive Guidance la diversidad en tecnología puede ser entendida y considerada de forma correcta para soportar el crecimiento organizacional. Es crucial reconocer las herramientas y los mecanismos para navegar este proceso de forma exitosa.

Este artículo provee una visión sobre los aspectos más desafiantes a los que se enfrentan las organizaciones durante sus procesos de crecimiento, sin embargo, resalta las soluciones que pueden ayudar a superarlos. Al adoptar una actitud proactiva y estos recursos las organizaciones pueden prepararse para los procesos de fusión, adquisición y más.