Por qué el “diseño para operaciones” es esencial para las TI basadas en servicios

Para afrontar la transformación digital y mejorar su rendimiento, las empresas están adoptando una estrategia de “diseño para operaciones” para el desarrollo y distribución de software. Con “diseño para operaciones” queremos decir que el software está diseñado para ejecutarse continuamente, con actualizaciones incrementales frecuentes, que se pueden realizar a escala. Este enfoque tiene en cuenta los costes de distribución y servicios de software de principio a fin, no solo los asociados al desarrollo inicial. Se basa en la aplicación de la automatización inteligente a gran escala y de su conexión con las cambiantes necesidades de los clientes. DevOps es el conjunto de prácticas que hacen esto posible, con el complemento de canales de software que admiten una entrega continuada.

El reto: diseñar para operaciones

Los productos y servicios IT pasan por diversas etapas de evolución:

Diseño en función del propósito (el producto realiza una función concreta)

Diseño para fabricación (el producto puede ser producido en masa)

Diseño para operaciones (el producto abarca su uso continuo y ciclo de vida completo).

Los automóviles son un buen ejemplo: desde el nuevo vehículo de Daimler, hasta el Modelo T de Ford o el Prius de Toyota (en general, cualquier modelo que se venda con un plan de servicio). Incluir el plan de servicio significa que el fabricante de automóviles incurre en costes de mantenimiento del automóvil, una vez vendido, por lo que el fabricante también es responsable del ciclo de vida del producto, de principio a fin. Las tecnologías de la información no son diferentes; vemos ejemplos desde los primeros ordenadores Colossus, hasta el software empaquetado de Oracle, o los servicios basados ​​en software, tipo Netflix.

El punto clave es que las empresas de servicios basados ​​en software, como Netflix, se han dado cuenta de que son responsables del coste total de la distribución del software y han comenzado a mejorarlo, con prácticas que ahora llamamos DevOps.

Hay eficiencias que se pueden lograr solo con software diseñado para operaciones. Esto significa que las compañías que ejecutan software a medida (diseñado para propósitos específicos) y software empaquetado (diseñado para fabricación) tienen  fecha de caducidad, porque la responsabilidad sobre el producto es mayor que el valor del mismo. Si esa brecha se puede cerrar, la distribución será mejor, más rápida y más económica (no es necesario elegir solo dos).

Es esencial cerrar esa brecha, porque si los competidores pueden ofrecer productos mejores, más rápidos y más baratos, tendrán ventaja. Esto incluye hasta al sector público, ya que los departamentos oficiales, ministerios y autoridades locales están todos bajo la presión de ofrecer servicios de mayor calidad a los ciudadanos, con menor impacto en los impuestos.

La razón por la que “nos movemos a la izquierda”

Un resultado típico de una estrategia de diseño para unos fines concretos es que los requisitos funcionales (lo que debería hacer el software) se aplican a los requisitos no funcionales (seguridad, cumplimiento, usabilidad, mantenimiento). Como resultado, aspectos como la seguridad quedan relegados. En muchos casos, esta falta de funcionalidad comienza a aumentar, como si fuera una deuda técnica. Es decir, las decisiones que pueden parecer oportunas a corto plazo se vuelven costosas a largo.

El concepto de “desplazamiento hacia la izquierda” consiste en garantizar que todos los requisitos se incluyan en el proceso de diseño, desde el principio. Piense en un calendario de proyecto y “desplace a la izquierda” aspectos como seguridad y pruebas, para que sucedan antes. En la práctica, eso no tiene por qué significar mucho trabajo de desarrollo adicional, ya que la elección cuidadosa de plataformas y marcos puede garantizar que aspectos como la seguridad se incorporen desde el principio.

Un buen ejemplo de las prácticas de desarrollo moderno se manifiesta cuando preguntamos “¿cómo sabemos que esta aplicación está funcionando acorde a las expectativas del área de producción?” Esto implica mucho más que “¿funciona, o no?” Y se trata de empezar a cuestionarse “¿cómo podría NO funcionar? Y ¿cómo lo sabré?”

Las empresas deben adoptar un modelo de “diseño para operaciones” que incluya un enfoque integral de la automatización inteligente, combinando análisis, técnicas Lean y  capacidades de automatización. Esta estrategia ofrece más información, velocidad y eficiencia y abre la puerta a soluciones basadas en servicios que sean operativas desde el primer día.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: