Redes abiertas del mundo real. Parte 5: Disonancia entre redes y dominios de software

En nuestro último post terminamos un examen detallado de diferentes aspectos de la Interoperabilidad. En esta publicación, analizaremos las diferentes mentalidades entre los dominios de redes tradicionales y los dominios de desarrollo de software, explicando por qué a menudo existe una disonancia inherente.

Si bien las soluciones de Red Abierta requieren la integración de componentes y prácticas de red y software, actualmente (e históricamente) estas dos áreas son en gran medida incompatibles. Si no se gestiona con cuidado, esta incompatibilidad provoca estrés y deterioro del proyecto.

Debido a que muchas (si no la mayoría) de las soluciones de Red Abierta se originan en el departamento de Ingeniería de Red dentro de una organización de usuarios, esta es una consideración importante para todo el ciclo de vida de la solución; especialmente si el equipo de ingeniería de redes no tiene habilidades y experiencia en software establecidas.

Hay muchos aspectos de los tipos de disonancia que se pueden experimentar en un proyecto de Open Networking debido a diferentes paradigmas o mentalidades. A continuación cubrimos los primeros cuatro aspectos del problema:

En Software Interlude, Parte 6: Paradigmas de desarrollo, describimos que la ingeniería de redes tradicional se alinea más con el modelo de producción del trabajo, lo que significa que los procesos de diseño y producción están en gran medida serializados y separados.

El desarrollo de software, por otro lado, opera según un paradigma diferente, en el que el diseño y la producción se mezclan en gran medida: no sólo en paralelo sino entrelazados dentro del mismo equipo y los mismos recursos.

Las redes (en general) se diseñan utilizando componentes discretos y pueden diseñarse y construirse siguiendo pasos bastante predeterminados y predecibles guiados por principios de ingeniería. Las redes son de naturaleza muy mecánica y matemática y siguen un conjunto de reglas bien establecidas. Incluso los componentes de software de los equipos de red tradicionales (configuración) seguían reglas respaldadas por años de investigación matemática. Los diseños de redes se pueden validar previamente utilizando las mismas técnicas.

En la práctica, vemos las implicaciones de esto en la forma en que se ejecutan los proyectos de red. Formalmente, los proyectos de red son mucho más un modelo de ciclo de vida basado en planes (también conocido como Cascada). Hay muchas razones lógicas por las que el enfoque basado en planes es mejor para este tipo de proyecto.

Informalmente, también vemos esto: es típico que una persona mayor, con más experiencia, diseñe la red y cree una especificación de cómo se debe construir la red. Este diseño de red normalmente se entrega a otro personal técnico para su construcción.

La flexibilidad es un aspecto clave de los proyectos de desarrollo de software: sustenta todo lo que hace y piensa un desarrollador de software. Las redes parecen valorar otras cosas: integridad, seguridad, etc. La diferencia se reduce al tamaño relativo de los Incrementos, prototipos y/o MVP. Nota: el MVP (Producto Mínimo Viable) es el componente más pequeño que se puede implementar en producción y que permite al menos un caso de uso de valor.

Pequeños aumentos en funcionalidad, prototipos y MVP son partes importantes del proceso de desarrollo de soluciones. Todos estos respaldan principios ágiles si inspeccionan y se adaptan.

En el caso del software, estas adiciones pueden ser muy pequeñas y producirse muy rápidamente. Tradicionalmente, en el dominio de la red, crear una pequeña instancia de algún aspecto de una solución presenta un obstáculo mucho mayor. Pueden existir laboratorios modelo o entornos de prueba, pero generalmente son insuficientes para los cambios dinámicos requeridos por la necesidad de iterar; es decir, si están disponibles y/o tienen la cantidad adecuada o suficiente de hardware.

No es raro que los proyectos de red se creen para requisitos muy generales y no para casos de uso específicos de usuarios finales. La consecuencia lógica de esto es que los usuarios finales no participan activamente en el ciclo de vida del desarrollo.

Los proyectos de software, y en particular los proyectos de software ágiles, se basan en el compromiso con los usuarios finales: la expectativa es que los usuarios finales interactúen con los desarrolladores a diario. Esto requiere ciertos conjuntos de habilidades que están bien desarrolladas en los ingenieros de software (bueno, en diversos grados), pero pocos ingenieros de redes tienen esta experiencia.

En general, los desarrolladores de redes tienen expectativas mucho más altas de interoperabilidad inmediata que los desarrolladores de software, a pesar de la softwareización de las redes.

Los desarrolladores de software experimentados suelen tener un alto nivel de escepticismo cuando se trata de afirmaciones de interoperabilidad y, naturalmente, planificarán el proceso de validación para asegurarse de comprender cómo funcionará realmente el producto. Los ingenieros y arquitectos de redes parecen estar más dispuestos a aceptar afirmaciones de operatividad o cumplimiento de estándares y no necesariamente prepararse para los procesos de validación, excepto la primera vez que el equipo se integra en una red.

Pero debido a la diferente naturaleza de los productos, una validación inicial para un producto de software puede tener una vida relativamente corta (ya que las nuevas actualizaciones pueden interrumpir esta funcionalidad probada), mientras que una validación inicial para un producto de hardware tiene una vida mucho más larga.

La existencia de estas fuentes de disonancia, y más, puede fácilmente llevar al deterioro del proyecto si no se anticipa y se gestiona con cuidado.

Tanto en la planificación como en la ejecución de proyectos, surgen problemas cuando una de las partes quiere invertir tiempo en algo (por ejemplo, reservas de riesgo o pruebas de validación) que la otra parte no ve necesario para ella (y en consecuencia cree que es un relleno injustificado de las estimaciones) o simplemente no da lugar a malentendidos y falta de comunicación.

¿Cómo gestionamos esto de forma eficaz? Tratamos todo como un proyecto de software.