Construyendo un modelo de la cadena de suministro de software

La descripción estándar de un flujo de valor de desarrollo de software comienza con la codificación y termina con el código en producción. A menudo, ve diagramas de DevOps que comienzan con "la empresa" y terminan con "el cliente". Sin embargo, esta descripción no refleja con precisión la complejidad de la entrega de software a escala empresarial.

Dando un paso atrás, verá muchas más actividades involucradas en el suministro de software a los clientes, pero los enfoques actuales para administrar estas actividades tienen sus raíces en los marcos de prestación de servicios y no en los modelos de producción. Como tal, no conectan todas las actividades involucradas como un único sistema de extremo a extremo.

El modelo utilizado en otras industrias de productos es el modelo de cadena de suministro, y al aplicar ese modelo a la entrega de software, puede ampliar su comprensión del “sistema” de entrega de software más allá de devops, brindándole una nueva perspectiva sobre cómo optimizarlo.

¿Qué es la cadena de suministro?

La cadena de suministro comienza con la idea de que puede coordinar todas las actividades de producción y no producción como un solo sistema. La gestión de la cadena de suministro a menudo se malinterpreta como simplemente "gestión de proveedores", cuando en realidad ese es solo un aspecto de la gestión de la cadena de suministro (aunque es fundamental).

Todas las empresas de productos y servicios tienen una cadena de suministro, y las actividades involucradas y su importancia relativa para el sistema de la cadena de suministro variarán. La idea central, sin embargo, es que al coordinar estas actividades como un solo sistema, se obtiene un valor mayor que la suma de las partes y fluye la entrega eficiente de ese valor a las partes interesadas.

Las siguientes actividades son solo algunos de los aspectos importantes de todas las cadenas de suministro, pero para el software se ejecutan de forma única:

Planificación

En la cadena de suministro tradicional, las actividades de planificación implican la coordinación de activos y la optimización del flujo de procesos para equilibrar el suministro de materiales con la demanda de productos. En la cadena de suministro de software, esa coordinación implica asegurarse de que se desarrolle el código correcto para las características del producto que más se necesitan. A gran escala, con cientos de aplicaciones y miles de desarrolladores de software, este es un esfuerzo monumental.

El alcance de las actividades de planificación a menudo se minimiza con los modelos devops existentes. Es un tanto irónico, entonces, que las grandes empresas que más necesitan devops tengan que lidiar con obligaciones legales, regulatorias, contractuales y de los clientes que hacen que la planificación sea larga y compleja. Un enfoque de la cadena de suministro para la planificación implica optimizar las interfaces entre los diferentes roles y disciplinas de planificación involucradas, y un factor clave de éxito es poder integrarlos de manera efectiva.

Por un lado, las metodologías ágiles que guían el desarrollo en la empresa a menudo se expresan dentro de los procesos en cascada. Pocas empresas pueden escapar de los ciclos de planificación fiscal y los procesos ágiles pueden contener abstracciones que entren en conflicto con esos ciclos; por ejemplo, los sprints pueden no alinearse con los límites de los trimestres fiscales. La falta de comunicación y conexiones entre los procesos de desarrollo que usan actividades ágiles y de no producción que usan cascada puede generar desperdicio e ineficiencia en toda la empresa.

Por otro lado, la planificación de productos empresariales siempre ha implicado amplios sistemas de trazabilidad y gestión de requisitos, y esto no es diferente para los productos de software. La gestión de requisitos es especialmente crítica en industrias altamente reguladas, como la atención médica, donde se puede desarrollar software para dispositivos médicos que pueden significar la vida o la muerte de los usuarios. La gestión de requisitos implica herramientas y metodologías especializadas, y la capacidad de rastrear la fidelidad y la calidad de su implementación a lo largo del ciclo de vida del desarrollo puede ser fundamental para los productos de software empresarial.   

Abastecimiento

En la cadena de suministro tradicional, los componentes de abastecimiento implican la gestión de las relaciones con los proveedores y el desarrollo de estrategias de adquisición de piezas y materiales. El software también depende en gran medida de componentes de origen; según una investigación reciente de Sonatype, el código abierto ahora forma la mayoría de los productos de software: entre el 80 y el 90 por ciento del código en las aplicaciones modernas proviene de componentes de código abierto. Y estos componentes crean desafíos de gestión únicos.

En primer lugar, puede resultar difícil decidir cómo determinar la calidad de los componentes, ya que muchos factores influyen en las decisiones, como el consumo, las pruebas, la documentación, la comunidad, el soporte y las tendencias tecnológicas. Es imperativo tener una estrategia y un enfoque claros para seleccionar componentes.

En segundo lugar, a medida que aumenta la cantidad de componentes de código abierto, incluso saber cuáles son y administrarlos de manera efectiva es un desafío. Los gerentes e ingenieros de productos deben prestar mucha atención a los problemas de licencia y seguridad. El estado de sus componentes de código abierto puede cambiar a diario a medida que se descubren nuevas vulnerabilidades y los encargados de mantenimiento cambian sus estrategias de propiedad intelectual. Y los clientes quieren saber exactamente lo que están recibiendo; muchas grandes empresas no comprarán software sin una lista de productos que describa lo que hay en la caja. La gestión de todos estos problemas de código abierto es un aspecto fundamental del desarrollo de productos de software.

Distribución

Poner el software en manos de los clientes puede implicar una red compleja de socios de todo tipo: implementación, distribución, integración, revendedor; acuerdos de todo tipo: OEM, licencias, NDA, RFP; reuniones de todo tipo: demostraciones, PoCs, presentaciones; y mucho más.

Estas relaciones sirven como entradas, salidas e incluso pasos en el proceso de entrega de software. El estado de cualquiera de estas relaciones puede afectar directamente las actividades de desarrollo. Sin gestionarlos de cerca y conectarlos con el trabajo que se está realizando, se producen desperdicios muy tangibles.

Imagínese ofrecer una experiencia épica para un cliente potencial que silenciosamente se convirtió en una oportunidad perdida, o implementar una función para un socio que canceló su contrato hace un mes. Esto sucede con regularidad cuando el software se entrega independientemente del flujo de valor del negocio, cuando la función de entrega de software no está vinculada a la cadena de suministro.

La tubería de DevOps debe estar estrechamente relacionada con las asociaciones, los acuerdos y los objetivos para los que se está realizando el trabajo. El código se puede rastrear y vincular desde la historia hasta el requisito hasta el registro del cliente en su CRM, todo al tratar su entrega de software como una cadena de suministro y seguir con una estrategia de integración.

Imagine, en cambio, poder mostrar todas las actividades en curso que se realizan para un contrato específico o todas las funciones planificadas para un nuevo cliente; este es el resultado de la gestión de la cadena de suministro de software, la visibilidad y la trazabilidad a lo largo de todo el ciclo de vida.

Herramientas

Si bien sus herramientas de fabricación clásicas pueden consistir en máquinas troqueladoras y hornos de tratamiento térmico, la cadena de suministro de software incluye una clase de herramientas (también llamadas herramientas ALM, herramientas de ciclo de vida o herramientas devops) que se utilizan para administrar las diversas etapas de la entrega de software. .

La estrategia para administrar estas herramientas es muy diferente del enfoque clásico porque la inversión técnica e intelectual en herramientas de desarrollo de software es enorme y de gran impacto. Este tipo de herramienta también está evolucionando rápidamente y muy fragmentado: el Jenkins de hoy será el Hudson de antaño. Una organización debe estar posicionada para tener una pila de herramientas flexible pero modular, una que proporcione a los equipos lo que necesitan, al tiempo que conserva la flexibilidad para adaptarse.

Además, la cadena de herramientas no se puede desconectar; debe fluir información de regreso a la cadena de valor para obtener conocimiento donde se necesita. También es fundamental examinar esta área desde el punto de vista de la integración: ¿cómo se pueden conectar las actividades en una capa determinada con las actividades de gestión de la cadena de suministro circundantes y de apoyo?

Conclusión

Históricamente, la empresa ha separado la gestión de la tecnología de las líneas de negocio generadoras de ingresos, tratándola como un conjunto de actividades de apoyo impulsadas por valores y objetivos alineados con la prestación de servicios. En un mundo definido por software, sin embargo, ese modelo de negocio ya no encaja.

La capacidad de entrega de software ha salido del espacio de soporte definido clásicamente y ha llegado a definir todas las actividades primarias generadoras de ingresos.

Por lo tanto, debe repensar su modelo como un sistema de producción y avanzar hacia uno que capture las relaciones de complejidad entre las actividades de la cadena de valor. La cadena de suministro encarna ese pensamiento y, a medida que evolucionó la producción de productos de software, seguramente veremos madurar este modelo.