La elección del hardware, el software y dónde ejecutarlo sigue siendo muy importante y es objeto de análisis por parte de los responsables de las decisiones informáticas en empresas y organizaciones públicas, pero el concepto de elección ha evolucionado hasta abarcar preguntas más existenciales de las organizaciones de TI:
- ¿A quién elijo para operar mi infraestructura si yo no lo hago?
- ¿Por qué no diseño yo mi propio paquete de soluciones?
Existen dos conceptos que apuntalan estas nuevas preguntas: la nube y el código abierto.
¿Quién la va a operar?
Los servicios gestionados no son precisamente nuevos; han existido a un nivel básico durante décadas con la subcontratación de Datacenters, el correo electrónico y hasta capacidades como los sistemas ERP y CRM. Pero los servicios de 2018 ocuparon otro nivel, siendo diseñados para abstraerse de las complejidades de operar la infraestructura y hasta los servicios —como las bases de datos—, dejando que los equipos de TI se concentren más a menudo en extraer valor de su trabajo sin ocuparse de las nimiedades del mantenimiento.
Olvidémonos de operarla. ¿Por qué no la diseñamos?
El incremento de la nube como eje estructural informático y la disponibilidad inmediata del software de código abierto significa que los líderes de TI pueden adoptar un enfoque “hágalo usted mismo” frente a la TI a fin de crear sus propios paquetes de soluciones personalizados.
Uno de los aspectos más desafiantes es que diseñar su propio paquete de soluciones puede ser muy eficaz y eficiente al comienzo, y en eso consiste su atractivo. Pero esa es la parte sencilla. El futuro del paquete de soluciones requiere:
- Mantenimiento continuo: lo cual puede ser cada vez más complejo, especialmente a medida que la implementación se amplía y aloja cargas de trabajo y sistemas más y más complicados. Esto requiere de un conjunto nuevo y mayor de habilidades cada vez más especializadas para supervisar debidamente facetas que tal vez no existan en una organización determinada.
- Correcciones y parches cuando algo no funcione (y siempre habrá algo que no funcione). Los conocimientos especializados requeridos para comprender y solucionar problemas de la TI moderna van en aumento y existen capas de API que abarcan desde el núcleo hasta el sistema de orquestación. Cuando ocurre una falla se ponen en duda millones de líneas de código en todos los sistemas donde las sutilezas y matices son más complejos que en los sistemas de software de antaño. Puede resultar difícil diagnosticar una falla e incluso más difícil corregirla.
- Provisión de correcciones y parches a la comunidad open sourceEl Open Source o Fuente Abierta hace referencia a todos aquellos programas informáticos que disponen a cualquier usuario el acceso a su código de programación facilitando por parte de otros programadores ajenos la modificación de este. Fuente: opensource.org para ayudar a limitar las posibilidades de que una organización se tope con estos problemas otra vez en una versión futura del código. Éste es un hecho crítico y con frecuencia olvidado en el uso de proyectos de código abierto. Que lo haya corregido una vez no significa que quede corregido en la comunidad, en especial si no está involucrado con el desarrollo.
Lo que he observado es que los paquetes de soluciones “hágalo usted mismo” fallan donde confluyen el mantenimiento, el talento y la influencia open sourceEl Open Source o Fuente Abierta hace referencia a todos aquellos programas informáticos que disponen a cualquier usuario el acceso a su código de programación facilitando por parte de otros programadores ajenos la modificación de este. Fuente: opensource.org.
Los líderes de TI no deberían dejarse abrumar por esta libertad de elección. No obstante, ello, es en esta instancia donde entran en escena los socios de confianza.