Redes abiertas en el mundo real. Parte 3 – Interoperabilidad: Problemas con los estándares

En nuestra última publicación publicamos Interoperabilidad, incluidos los Estándares Abiertos. Continuando con este tema, veremos cómo los desarrolladores de soluciones implementan el cumplimiento de los estándares y los problemas que surgen.

Exigir a los proveedores (y a los sistemas internos) que cumplan con los Estándares Abiertos es una estrategia utilizada por las organizaciones para impulsar la interoperabilidad. Se supone que los componentes que cumplan con los Estándares Abiertos serán interoperables.

En esta publicación examinamos las muchas razones por las que esa suposición no siempre es cierta en situaciones del mundo real. Este análisis se realizará desde una perspectiva de software, ya que los equipos de red generalmente hacen un mejor trabajo de interoperabilidad de componentes que el software. Esta publicación también cubrirá aspectos generales del cumplimiento de estándares en esta publicación y aspectos específicos de API en la próxima publicación.

Ya sea que el estándar sea «de jure» o «de facto», existen tres enfoques básicos para implementar el cumplimiento del software con los estándares:

Este enfoque consta de dos partes:

A «Implementación de referencia» es un componente de software que está garantizado para cumplirlo el estándar y es referencia conocida que en contra valida desarrollado componente. Thes él tiene también incluir un conjunto de casos de prueba estándar que verifican el cumplimiento y/o resaltan problemas.

Vendedores a menudo Proporcionar resultados de pruebas como evidencia y caracterización del nivel de cumplimiento.

Beneficios de este enfoque

Este es el nivel más alto posible de cumplimiento de una norma. Dos componentes que hayan sido validados según el estándar serán interoperables en el nivel común más bajo para el que ambos hayan pasado la prueba.

Problemas con este enfoque

Debe existir y estar disponible una implementación de referencia; sin embargo, este no es siempre el caso. La implementación de referencia debe desarrollarse y certificarse de forma independiente, a menudo por el propio organismo de normalización.

Este enfoque es similar al enfoque de implementación de referencia. En primer lugar, el estándar documentado es un elemento de control del diseño. Sin embargo, la segunda parte (validación según la norma) es opcional y muy variable. En el nivel más básico, el cumplimiento puede ser simplemente que el proveedor afirme que el componente cumple con el estándar. Alternativamente, la conformidad se puede validar comparando el componente desarrollado y la documentación, y hay muchas maneras de hacerlo con distintos niveles de precisión y costo.

Beneficios de este enfoque

Los principales beneficios de este enfoque es que el diseño se orienta hacia el estándar y, en este nivel, es equivalente al enfoque de implementación de Referencia.

Problemas con este enfoque

La validación sin una implementación de referencia es muy manual y potencialmente sujeta a interpretación. Este tipo de validación es costosa y crea una presión de costos para que los proveedores validen solo parcialmente, especialmente en actualizaciones y actualizaciones repetidas de la versión.

En este caso, la norma se utiliza como entrada para el diseño, pero no como entrada de control. La intención no es conformidad sino alineación. El producto puede utilizar tecnologías subyacentes iguales o similares definidas en los estándares (por ejemplo, interfaces REST o los mismos estándares de representación de datos subyacentes, como XML o JSON). El proveedor puede adoptar una arquitectura de componentes similar (por ejemplo, microservicios) al estándar.

Beneficios de este enfoque

En el mejor de los casos, este enfoque puede proporcionar una base para el cumplimiento futuro.

Problemas con este enfoque

En general, el proveedor diseña su producto para que «no sea incompatible» con el estándar, sin asumir el costo de su cumplimiento total.

El cumplimiento de las normas es costoso de implementar, independientemente del enfoque adoptado. Por lo tanto, cada vendedor adoptará su propio enfoque, en función de sus propias situaciones y contexto. Un vendedor puede:

Existe una amplia gama de implementaciones y los resultados son muy variables. Lo importante que hay que recordar es que una afirmación de «cumplimiento de normas» puede significar muchas cosas.

Partiendo del punto de partida de la intención de cumplir (o al menos exigir el cumplimiento), y utilizando cualquiera de las estrategias anteriores, un vendedor puede incumplir de muchas maneras:

No se puede asumir nada sobre el cumplimiento de las normas, excepto que se deben validar las afirmaciones de cada vendedor. La otra parte de este problema es la interoperabilidad de las interfaces de programas de aplicaciones (API). Cubriremos esto en la próxima publicación. Manténganse al tanto.