BLOG

La automatización de TI es estratégica

Miniatura de Lori MacVittie
Lori MacVittie
Publicado el 17 de mayo de 2018

¿Qué pasaría si te dijera que «los mainframes alojan más transacciones diarias que Google (1,3 millones/segundo en CICS frente a 68.542/segundo en Google), incluido el 55 % de todas las transacciones empresariales»? ( Forbes )

¿Te sorprenderías? No deberías. Si bien las empresas de hiperescala como Facebook, Netflix y Google suelen ocupar el escenario principal cuando hablamos de transformación digital y la economía de las aplicaciones, la realidad es que la economía de las aplicaciones depende tanto (o quizás más) de las miles y miles de aplicações que nadie ve ni escucha nunca. No son sólo los mainframes los que pasan desapercibidos. También son los servicios de aplicação , la infraestructura, el middleware y las fuentes de datos inteligentemente ocultos debajo de la brillante interfaz de la última aplicación o dispositivo.

Verá, la transformación digital tiene más que ver con cómo interactuamos con la tecnología que con una transformación espectacular de la tecnología en sí. No hay nada nuevo en cuanto a API, sensores y dispositivos. No hay nada particularmente sorprendente en las pantallas táctiles y el control por voz. Toda esta tecnología ha existido de una forma u otra durante bastante tiempo. Y en algunos casos, realmente es solo lápiz labial en un cerdo.

No es posible escalar sin un servicio de equilibrio de carga. No se pueden proteger las aplicaciones sin servicios de aplicação de seguridad. No se pueden conectar aplicaciones sin middleware y API. Y ninguno de ellos es muy interesante sin los datos que manejan.

La economía de las aplicaciones depende más de lo que no vemos que de lo que vemos. Y eso hace que sea imperativo que la TI tenga un lugar, y una voz, en la mesa digital. Ese asiento es importante independientemente de si las aplicaciones se implementan en una nube pública o en las instalaciones de una nube privada. Ese asiento es importante independientemente de si las aplicaciones siguen siendo monolíticas o microservicios en contenedores. Ese asiento es importante. Período.

Ese asiento es representativo de la colaboración y los cambios culturales necesarios para transformar la TI de un rol de apoyo a uno estratégico.

La naturaleza estratégica de la automatización de TI


Una de las decisiones más estratégicas que un CIO puede tomar hoy en día se centra en la automatización. Dado que el 55% de las organizaciones emplean la automatización como resultado de la transformación digital , su impacto estratégico no puede pasarse por alto. Así como la elección de lenguajes y plataformas de programación para el desarrollo de aplicaciones es estratégica, también lo son los conjuntos de herramientas, lenguajes y plataformas que se seleccionan para respaldar los esfuerzos de automatización.

Sería una locura desestimar estas decisiones considerándolas sin importancia. La deuda técnica y arquitectónica se acumula rápidamente y es tan difícil de eliminar del presupuesto como los kilos que subimos en Acción de Gracias. La deuda arquitectónica se basa en el principio de “deuda técnica” en el desarrollo de software. Es una metáfora: La complejidad y las decisiones arquitectónicas le impiden realizar nuevos trabajos porque pasa todo su tiempo lidiando con sistemas existentes (roturas/reparaciones, mantenimiento, etc.). Si tiene muchas deudas, esto le impide usar su dinero en otras cosas, porque lo gasta todo en intereses. Esta deuda es la que aumenta los costos de los nuevos servicios y reduce la velocidad del servicio necesaria para aprovechar las oportunidades de mejorar el resultado final, ya sea medido en productividad o ganancias.

Eso es lo que hace que la automatización de TI sea una inversión estratégica. En la empresa, las decisiones que tome ahora con respecto a la implementación de la automatización resonarán tan fuerte como las que tomó en el desarrollo de aplicaciones hace años.

Por ejemplo, en nuestra encuesta del año pasado, el 65 % de los DevOps mencionaron que la habilitación de autoservicio influyó en su decisión de "eludir" a TI y buscar soluciones en la nube o de código abierto. Evitar la TI significa eludir la seguridad, lo que pone en riesgo el negocio y otros sistemas. 

Elegir el lenguaje equivocado puede generar su propia deuda porque con el tiempo no es posible sostener sistemas sin el talento adecuado. No elegir un lenguaje puede causar caos y convertir los scripts y sistemas de automatización en mascotas que necesitan atención y cuidado constantes. Esto desplaza el presupuesto hacia reparaciones y mantenimiento en lugar de hacia la innovación.

La automatización de TI es un esfuerzo estratégico que debe abordarse teniendo cuidadosamente en cuenta factores similares a los de las arquitecturas de aplicação empresariales:

  1. Soporte en toda la cadena de herramientas
    Hoy en día, casi todos los proveedores de TI respaldan la automatización y la integración con otros actores del proceso de producción. El soporte, ya sea tradicional o comunitario, es imprescindible dada la complejidad de las redes actuales y la variedad de proveedores que conforman el canal de distribución. La documentación, los ejemplos de código y una comunidad activa son de gran ayuda.
  2. Disponibilidad de talento y/o formación
    Si no puede capacitar a su personal o contratar talento para trabajar con las plataformas, sistemas e idiomas que desea utilizar, vuelva al paso uno y comience nuevamente el proceso de selección. Si no tiene la capacidad de mantener los sistemas que va a construir, es mejor continuar con el proceso manual hasta que pueda.
  3. Preparación para múltiples nubes
    El soporte para empresas multicloud es un requisito relativamente nuevo, pero es un requisito. La automatización no se limitará a un centro de datos local. Los esfuerzos de automatización deberán incluir al menos una nube pública y casi con certeza más de una nube pública. Esto significa considerar cuidadosamente la compatibilidad de la plataforma y la portabilidad de políticas en diferentes entornos como parte de su iniciativa de automatización. 
  4. Imperativo o declarativo
    Sé que probablemente estés cansado de oír hablar de esto, pero la elección es bastante importante. Los métodos imperativos (basados puramente en API) son más rápidos de desarrollar y requieren menos adaptación por parte de TI, pero generan una deuda técnica significativa al vincular la automatización a dispositivos y proveedores específicos. Los métodos declarativos (basados en artefactos) pueden requerir más tiempo (y arquitectura) al principio, pero alivian el estrecho acoplamiento del proceso con los productos y reducen la deuda técnica. 

La automatización de TI es una de las decisiones tecnológicas más estratégicas que un CIO puede tomar. Y dado que la mayor parte de la economía de las aplicaciones depende de sistemas bajo la supervisión de TI, también es una de las decisiones comerciales más estratégicas que un CIO puede tomar hoy. 

Elige sabiamente