Interoperability

Intención y alcance

Interoperability describe qué tan eficazmente dos o más sistemas o componentes pueden intercambiar información y capacidades y utilizarlas correctamente según significado y contrato acordados. La evaluación identifica participantes, intercambio y resultado esperado. Poder recibir bytes no demuestra que una colaboración produzca el efecto correcto.

ISO/IEC 25010:2011, 4.2.3.2 vincula intercambio y uso de información y ubica interoperability bajo compatibility. Esa referencia terminológica corresponde a la edición 2011, reemplazada por ISO/IEC 25010:2023. Su agrupación no determina la ubicación editorial del Atlas.

Importa arquitectónicamente porque decisiones sobre modelos, fronteras, protocolos y evolución distribuyen conocimiento entre participantes. Una discrepancia puede afectar cobros, envíos o inventario aunque todas las llamadas terminen sin error técnico. quality-attribute-scenarios permite formular el comportamiento que necesitamos; los ejemplos de pagos y Orders de este documento son propios.

Connectivity e Integration

Connectivity significa que existe un camino de comunicación. Que A pueda enviar JSON por HTTP a B demuestra una posibilidad de transporte; todavía falta acordar campos, unidades, identidad, estados del negocio, errores y versiones. «Ambos usan REST» no responde esas preguntas.

Integration designa una realización concreta de colaboración: un flujo, una conexión o una frontera implementada. Interoperability es la calidad con la que evaluamos si los participantes pueden trabajar juntos en el alcance previsto. Una integración puede funcionar para un caso feliz y fallar ante datos o versiones legítimos.

Compartir una base de datos tampoco garantiza interpretación común. Dos componentes pueden leer la misma fila y atribuir significados diferentes a su estado. El acceso compartido puede ocultar un contrato implícito y propagar cambios a consumidores que nadie identificó.

La pregunta necesita una finalidad: ¿intercambiamos información para mostrar seguimiento, reservar inventario o confirmar liquidación? Un formato idéntico puede satisfacer la primera colaboración y resultar insuficiente para la última. No existe interoperabilidad absoluta independiente del uso.

Sintaxis y significado

La interoperabilidad sintáctica permite interpretar estructura, formato y protocolo del intercambio. La semántica permite atribuir significado compatible y actuar conforme a él. El informe SEI: Approaches to Constructive Interoperability, introducción distingue ambas dimensiones y advierte que la capacidad de intercambiar datos no basta.

En un ejemplo propio, un schema acepta amount = 100. Sigue faltando moneda, unidad principal o minor units, importe bruto o neto, y si representa autorización o captura. Un tipo numérico correcto no resuelve esas obligaciones. Tampoco debería inventarse una moneda por defecto cuando el emisor no la especificó y el contrato no autoriza esa inferencia.

Un intercambio HTTP 200 con status = “complete” puede ser válido estructuralmente. Si el emisor lo interpreta como solicitud aceptada y el consumidor como pago liquidado, la colaboración contiene un semantic mismatch. El éxito de transporte no define la transición del negocio.

La evidencia debe cubrir significado, no solamente parsing. Casos con monedas distintas, estados intermedios, identificadores desconocidos y errores permiten contrastar qué hace cada participante. Schema compatibility no equivale a semantic compatibility; cambiar una interpretación conservando tipos y firmas puede romper consumidores silenciosamente.

Qué contiene el contrato

Un contrato puede definir schema y framing, identificación de participantes, operaciones admitidas, precondiciones, efectos, estados, errores, versiones y negociación de capacidades cuando corresponda. También necesita precisar qué resultado se confirma y qué permanece pendiente. Un archivo OpenAPI o JSON Schema puede expresar parte de ese acuerdo, sin agotarlo.

Por ejemplo, ShipmentStatus debe aclarar qué significa entregado, qué autoridad afirma la transición y cómo se identifica el envío. «Mensaje válido» podría significar solamente que parsea, o que el estado tiene sentido para ese envío. El consumidor necesita distinguir ambos resultados y comunicar rechazos explícitos.

Negociar capacidades permite elegir una conversación soportada, si existe esa necesidad. No requiere una plataforma genérica de descubrimiento: versiones declaradas o un acuerdo bilateral pueden ser suficientes. La decisión debe reducir incertidumbre relevante, sin introducir un protocolo adicional sin uso real.

architectural-tactics ayuda a expresar decisiones enfocadas: localizar traducción, hacer explícitas obligaciones o limitar combinaciones soportadas. Son hipótesis sobre la respuesta esperada, no un catálogo normativo de tácticas inventado para este artículo.

Compatibilidad de versiones

Producer v2 y Consumer v1 pueden coexistir si sus obligaciones siguen siendo compatibles. Hay que comprobar si el consumidor ignora campos desconocidos, qué ocurre con valores nuevos y si los defaults conservan significado. Agregar un campo opcional no demuestra seguridad cuando un consumidor rechaza extensiones o necesita ese dato para decidir correctamente.

También puede cambiar semántica sin cambiar estructura: complete ahora implica liquidación definitiva, donde antes solo confirmaba recepción. Un número de versión ayuda a identificar diferencias; no especifica automáticamente cómo migrar ni qué pares pueden comunicarse.

Una política situada declara versiones y combinaciones soportadas, criterios de incorporación y retiro, y comportamiento ante incompatibilidad. Las pruebas deberían ejercitar esos pares con datos representativos y resultados esperados. Probar únicamente la última versión de ambos participantes deja sin evidencia la coexistencia real.

Compatibilidad puede favorecer deployability al permitir que productor y consumidor se entreguen en momentos distintos. Interoperability pregunta por interpretación y colaboración durante esa convivencia; Deployability examina el proceso de llevar las versiones a ejecución. Su autonomía necesita ambas respuestas, no solo un pipeline independiente.

Estándares y perfiles

Un estándar puede reducir decisiones particulares sobre formatos y conversaciones. No garantiza por sí solo acuerdo sobre significado, extensiones, perfiles, opciones o lifecycle. Dos implementaciones que declaran el mismo estándar pueden soportar subconjuntos distintos o interpretar detalles opcionales de forma incompatible.

Por eso conviene identificar versión y perfil utilizado, acuerdos adicionales y evidencia de conformidad relevante para la colaboración. La afirmación «usa un estándar» queda incompleta si no sabemos qué acepta cada participante y cómo responde fuera de ese alcance.

Esto tampoco implica que los estándares carezcan de valor. Permiten reutilizar acuerdos y herramientas de validación; las obligaciones específicas del negocio y las pruebas entre participantes siguen siendo necesarias. No hay que convertir cada integración en un protocolo propio por reconocer esos límites.

Adaptadores y límites semánticos

adapter-pattern presenta una interfaz esperada sobre otra incompatible. ports-and-adapters organiza fronteras arquitectónicas entre aplicación y exterior. Un componente puede cumplir ambos papeles, pero nombrarlo adapter no demuestra ninguna traducción correcta ni convierte ambos patrones en sinónimos.

Un adaptador puede convertir nombres, unidades, estados y errores. Si el proveedor no distingue aceptado de liquidado, no puede fabricar esa certeza. Debe exponer la limitación o rechazar un caso no representable, en lugar de completar un mapping que falsea el contrato.

Una frontera semántica protege el modelo interno frente a diferencias exteriores. Esa motivación puede aparecer en una Anti-Corruption Layer, sin exigirla universalmente ni desarrollar aquí otro patrón. La evidencia relevante comprueba preservación de significado y localización de cambios, no solo que existe una interfaz.

En microservices, muchas conversaciones internas pueden aumentar obligaciones de interoperabilidad aunque los equipos pertenezcan a la misma organización. Ownership separado y contratos explícitos pueden ayudar; numerosas versiones y dependencias también amplían coordinación. Ningún profile resuelve por nombre esa tensión.

Entrega, operación y costos

reliable-messaging organiza responsabilidades de entrega y procesamiento. Un mensaje entregado con las garantías previstas todavía puede interpretarse incorrectamente. A la inversa, un contrato perfectamente compartido no asegura que el mensaje llegue o que sobreviva una intención pendiente. Las pruebas de transporte y significado necesitan fronteras propias.

Soportar más partners, protocolos y versiones puede ampliar colaboración útil y agregar mappings, caminos de código, pruebas, conocimiento operacional y superficie de ataque. La interoperabilidad debe ser suficiente para participantes relevantes, no maximizarse aceptando cualquier entrada con una traducción aproximada.

quality-attribute-trade-offs permite comparar ese alcance con simplicidad, costo y operability. Rechazos claros facilitan diagnóstico; compatibilidad silenciosa puede ocultar pérdida de significado. Retirar una versión también requiere saber quién depende de ella y cómo observar la transición.

Escenario: interpretar estados de envío

Campo	Escenario propio
Source	Partner logístico externo autorizado.
Stimulus	Envía una actualización ShipmentStatus conforme al contrato de integración acordado.
Artifact	Frontera de integración de envíos y su traducción al modelo interno de Orders.
Environment	Producción normal con dos versiones soportadas del contrato coexistiendo.
Response	Acepta mensajes soportados, interpreta su significado en el modelo interno, rechaza semántica inválida explícitamente y expone un resultado compatible a capacidades consumidoras.
Response Measure	Todos los casos acordados de las versiones soportadas producen transiciones equivalentes; mensajes no soportados o semánticamente inválidos obtienen el rechazo previsto; incorporar una versión compatible no cambia componentes fuera de la frontera acordada.

Faltan catálogo de versiones, equivalencias de estados, fixtures representativos, política de errores y definición de la frontera. Deben fijarse antes de evaluar, incluyendo casos negativos y quién acepta que el modelo interno expresa fielmente el contrato. «Todos» refiere a ese corpus y alcance, no demuestra cualquier intercambio futuro.

La evidencia combina pruebas de contrato con el partner, inspección de cambios y comprobación del efecto interno. Si una versión incorpora un estado que el modelo no puede representar, cambió el supuesto de compatibilidad: corresponde revisar el escenario, no esconder la diferencia para mantener localidad.