Redes abiertas en el mundo real. Parte 2 – Interoperabilidad: El Santo Grial

En nuestra última publicación describimos los atributos de una solución de red abierta. En este post desgranamos lo que seguramente es el «Santo Grial» de las Redes Abiertas: la Interoperabilidad. La interoperabilidad se define como:

Finalmente, la interoperabilidad significa que puedo reemplazar componentes libremente, es decir, si tengo el Componente X en mi solución de Red Abierta, en el futuro puedo reemplazarlo libremente con el Componente Y.

Hoy en día, los componentes varían ampliamente en esa capacidad, en cada uno de los «factores de forma» de los componentes que hemos descrito en esta publicación. Pero no son sólo los componentes tecnológicos los que entran en nuestro concepto de interoperabilidad.

Por definición, ser muy-interoperableNoNecesitamos poder reemplazar libremente los componentes. a lo largo de cada una de las dimensiones de apertura que describimos aquí.

Veamos brevemente cada uno de estos por separado.

Probablemente la estrategia más obvia utilizada para impulsar la interoperabilidad haya sido la definición y/o adopción de estándares. Esto abarca tanto las normas establecidas formalmente por organismos de normalización («normas de jure») como las establecidas informalmente por dominio del mercado o uso generalizado («normas de facto»).

La idea de Estándares Abiertos no significa realmente reemplazar diferentes Estándares entre sí (aunque los diseñadores de soluciones probablemente deberían considerar los costos de cambiar un Estándar en su fase de diseño). El uso de Estándares Abiertos significa la selección de un estándar para un área funcional determinada de la solución y la gestión del nivel de conformidad con este estándar para permitir el libre cambio de componentes en esa área funcional de la solución.

Este es un tema complejo que revisaremos en el próximo post.

Desde una perspectiva de integración de software, las interfaces de programación de aplicaciones (API) son una forma fundamental de lograr la interoperabilidad. Hay varias perspectivas para «abrir» una API:

Los problemas de API e interoperabilidad también son un tema bastante complejo, y lo exploraremos con más detalle en la próxima publicación junto con uno.

Poder cambiar de socio libremente es esencial para los sistemas abiertos, pero hay varios factores a considerar:

Desafortunadamente, hubo muchos casos de vendedores que intentaron (y lograron) asegurarse clientes a largo plazo. Esta forma de «búsqueda de rentas» genera mala voluntad y da lugar a numerosas medidas de protección, algunas de ellas extremas y que van en contra de la idea de «ganar-ganar».

Hemos hablado del código abierto antes, pero no lo hemos examinado desde una perspectiva de interoperabilidad. El código abierto aborda el requisito de transparencia tecnológica de los Open Partners: es accesible para todos y, por lo tanto, transparente. Aunque puede requerir algún esfuerzo generar conciencia sobre un nuevo proveedor, los componentes de código abierto a menudo tienen múltiples fuentes de soporte, conocimiento y recursos que pueden ayudar en este proceso.

Como se mencionó en la última publicación, Operaciones Abiertas significa que los procesos operativos son flexibles y abiertos al cambio, abiertos a la participación y transparentes. En resumen, esto resume DevOps.

Revisamos el paradigma DevOps en un artículo anterior. Las prácticas están abiertas cuando nuevos proveedores pueden ingresar sin fricciones ni gastos generales significativos. Existe un flujo limpio desde el negocio hasta el desarrollo y las operaciones que permite a los nuevos proveedores acelerar rápidamente el ritmo del valor agregado. El uso de conceptos, herramientas y prácticas comunes permite a los nuevos vendedores comprender rápidamente dónde encajan.

Podemos ver desde arriba que todos los atributos de las soluciones abiertas impulsan la interoperabilidad. La mayoría de los casos de negocios y planes de proyectos contienen evaluaciones de riesgos y, a veces, disposiciones financieras para hacer frente a los costos de cambio que pueden ocurrir durante un proyecto: la falla de un socio, de una pieza de tecnología o de algún otro aspecto de la solución generará costos y demoras. a medida que los nuevos componentes se seleccionan, validan e integran en la solución.

La única prueba real de interoperabilidad es que estos eventos de riesgo, si ocurren, son órdenes de magnitud menos difíciles y costosos, de modo que las provisiones de riesgo pueden reducirse o eliminarse. Sabemos cuál es nuestro objetivo, pero lamentablemente estamos lejos de esa etapa. En esta publicación hemos cubierto algunos de los problemas que causan esta suposición fallida. Cubriremos más en nuestra próxima publicación.

Manténganse al tanto.