La mayoría de los analistas coinciden en afirmar que estamos siendo testigos en los últimos años de la mayor disrupción que hemos vivido en IT en veinticinco años, desde la aparición de Internet y las arquitecturas cliente servidor.

La convergencia entre tecnologías como Cloud (IaaS y PaaS), Big Data, Machine Learning, microservicios, arquitecturas asíncronas, API Management, etc. y metodologías como Scrum, DevOps o continuous delivery, permiten desarrollar productos digitales en formas que hace cinco o diez años, cuando compañías como Google comenzaron a utilizarlas, nos parecían poco menos que magia.

Estas nuevas formas están cambiando radicalmente el ecosistema IT de las grandes compañías en todo el mundo. Es lo que llamamos desarrollo velocity. Ante este nuevo tren tecnológico, muchas compañías siguen basando su core de negocio en hosts con arquitecturas y aplicaciones de más de 30 años de antigüedad. Muchos nos preguntan si es el momento de cambiar y cómo hacerlo.

El mainframe y la resistencia al cambio

A principios de los años noventa ya hubo una transformación tecnológica de calibre similar a la que estamos viviendo ahora y, sin embargo, el mainframe, contra todo pronóstico, la sobrevivió.

Hay una anécdota al respecto que se ha hecho ya famosa: en 1991, Stewart Alsop, un escritor de tecnología conocido, predijo ante las capacidades que veía en Internet y las arquitecturas cliente servidor, que el último mainframe se apagaría el 15 de marzo de 1996.

La realidad es que año arriba o año abajo, en ese momento la predicción parecía tener todo su sentido y, sin embargo, en 2002 Stewart se resignó finalmente a su error y se comió sus palabras (literalmente), haciéndose una foto que ya es historia:

¿Por qué se equivocó Stewart y todavía hoy muchas compañías en todo el mundo mantienen el core de su negocio en una arquitectura obsoleta desde hace más de 25 años? Porque estas compañías dudaron en su momento, decidieron apostar por las nuevas tecnologías de forma tibia y mantenerse en su zona de confort al menos en sus principales aplicaciones.

Las consecuencias han sido años de sobrecoste en licencias, complicación en su arquitectura IT e infrautilización del estado del arte en tecnología.

¿Por qué cambiar ahora, si no lo hemos hecho en 25 años?

Ahora, como decíamos, somos testigos de un cambio parecido, pero la diferencia es que los líderes digitales no están dudando en dar un paso adelante de forma decidida. Hay quien dice que estos líderes juegan con ventaja, porque son nativos digitales, compañías nacidas en la era digital que han podido elegir estas nuevas tecnologías desde cero.

Sin embargo, no es del todo cierto. Compañías como Amazon comenzaron con arquitecturas del siglo XX y han tenido la decisión suficiente para cambiarlas de forma radical. De hecho, es famosa la anécdota de Jeff Bezos, el CEO de Amazon, que hace ya años daba órdenes a toda su compañía a través de una comunicación interna que exigía trabajar en tecnologías de tercera generación. Firmaba esta comunicación diciendo: “Quien no haga esto, será despedido. Gracias, ¡que tengáis un buen día!”.

Ante este escenario, que supone una amenaza clara para las compañías que no sepan avanzar al mismo ritmo que estos líderes digitales, hay todavía compañías que se aferran a su zona de confort con argumentos parecidos a los que se utilizaron hace 25 años, pero que hoy sin embargo tienen aún menos solidez.

Hay quien piensa que el ser líderes, o estar entre los líderes de un sector, demuestra que no hay necesidad de cambiar (“algo estaremos haciendo bien si nos va así de bien”). Sin embargo tenemos ya múltiples ejemplos de compañías como Kodak, Blackberry, Blockbuster, AOL, Marsans o Nokia, entre otras muchas, que han pagado con creces no saber transformarse cuando eran líderes.

Otros, ante la perspectiva de un cambio tan importante, simplemente echan la piedra hacia adelante (“seguro que no necesito abordar esto ahora mismo”). A estos les encaja perfectamente una de las ideas más acertadas del famoso manifiesto Cluetrain: “Las empresas inteligentes harán lo que sea necesario para lograr que lo inevitable suceda cuanto antes”.

hbspt.cta.load(2189055, '7317a215-fbd1-4cc3-a54d-afee694a88f7', {});

Y ahora, ¿cómo nos enfrentamos al monstruo?

Como en tantas cosas de la vida, el primer paso (y el más importante) es decidirse a hacerlo. A partir de ahí, hay que asumir dos premisas fundamentales:

• Un proceso de apagado de host no es un proyecto únicamente tecnológico. Debe estar acompañado de una reinvención de los procesos de negocio para sacar partido de las nuevas capacidades técnicas.
• El proceso va a ser largo y, por tanto, es necesario abordarlo gradualmente y garantizando que no hay impacto en el día a día operacional.

A partir de aquí, basándonos en nuestra experiencia, proponemos un modelo basado en cuatro grandes etapas:

1. Trocear al monstruo: No en operaciones, ni por antigüedad, ni en departamentos, ni en aplicaciones, sino en negocios verticales que nos permitan poder hacer un cambio controlado en fases. Se pretende obtener retorno de la inversión lo antes posible; para ello identificaremos las principales áreas y prioridades mediante dinámicas específicas de negocio. Esta etapa nos permite crear un lenguaje común de comunicación entre negocio y tecnología.
2. Acorralar al monstruo: Abordamos los trozos uno por uno, y los acorralamos mediante herramientas intermedias basadas en acceso a datos. Trataremos de evitar acercarnos al monstruo mediante APIs o cualquier otro tipo de contacto directo con las aplicaciones. Estas herramientas intermedias de convivencia generan aproximadamente un 20% de código extra que al final del proceso se tirará.
3. Comerse el monstruo a bocados: Minimizar el riesgo garantizando la sustitución sin interrupción del servicio. Se desarrollan herramientas de soporte al paralelo de producción y nunca se aborda una sustitución big bang.
4. Innovar libres del monstruo: Es habitual encontrarse procesos muy mejorables, cuya única justificación es "esto siempre se ha hecho así". Es el momento de aprovechar para mejorarlos, simplificarlos y dotar a Negocio de nuevas capacidades: tiempo real, inteligencia de datos, omnicanalidad, customer centric, etc. sin servidumbres ni restricciones.

¿Es así de fácil?

Evidentemente, aunque en este post hayamos tratado de simplificar, en lo posible nuestra visión sobre los procesos de migración y apagado de host. “El diablo está en los detalles”, y no podemos pensar que va a ser sencillo sustituir de forma no traumática aplicaciones que en muchos casos han llevado decenas de años de desarrollo, y lo que es peor, a día de hoy ni siquiera queda nadie en la organización que conozca cómo funcionan.

Nuestro modelo detallado de un proceso de migración, que hemos elaborado a partir de experiencias en diferentes clientes y resumimos en la siguiente imagen, es un proceso que puede durar en grandes compañías meses de planificación y años de ejecución:

Nuestra experiencia en clientes reales es que no hay dos procesos iguales, y la primera fase de análisis y contexto es fundamental para trazar un modelo de migración a medida, completamente adaptado a la realidad y a los objetivos de cada organización.

Somos conscientes de que es un proceso difícil y costoso para la mayoría de las compañías, de ahí la importancia de contar con un socio tecnológico especializado que ayude a hacerlo lo más práctico, lo más fácil y lo menos traumático posible.

Conclusión

El reto es importante, pero la recompensa al final del camino es inmensa: un futuro libre de cadenas tecnológicas que nos permita abordar un proceso real de transformación digital, y estar así en condiciones de competir en el siglo XXI. Desde aquí os animamos a seguir la máxima aplicable a casi todos los ámbitos de la vida: si tienes dudas entre hacer algo y no hacerlo, HAZLO*.*