3.8 Interoperabilidad y estándares abiertos

Presentación y motivación

La interoperabilidad es la capacidad que tienen dos o más sistemas para intercambiar información y aprovechar la información intercambiada, sin que ninguno de los dos necesite conocer el funcionamiento interno del otro. Un estándar abierto es una especificación de acceso público, desarrollada y mantenida mediante un proceso transparente y de consenso, y cuya implementación es gratuita (o se rige por condiciones justas, razonables y no discriminatorias), de modo que cualquier persona puede construir un sistema conforme sin pedir permiso a un único proveedor. Diseñar con vista a la interoperabilidad significa construir sistemas que se conectan a través de especificaciones compartidas y publicadas, y no mediante integraciones a medida: conectores diseñados de forma singular para enlazar exactamente dos sistemas, y que hay que reconstruir cada vez que uno de los dos cambia.

En una organización de gran envergadura, la interoperabilidad no es un capricho: es el sustrato sobre el que funciona todo lo demás. Las empresas adquieren otras compañías, sustituyen proveedores y articulan decenas de sistemas internos y de terceros, y son los estándares abiertos los que permiten que un nuevo componente se integre sin necesidad de una reescritura. En el sector público las apuestas son aún mayores: los servicios se prestan a través de múltiples organismos, niveles de gobierno y proveedores privados, y ninguna institución controla el conjunto del parque tecnológico. Un ciudadano que solicita una prestación puede interactuar con sistemas de identidad, tributación, salud y bienestar gestionados por distintas consejerías. Esos sistemas deben interoperar; de lo contrario, el servicio falla. Además, las administraciones públicas cambian de proveedor en ciclos de contratación que se miden en años, de modo que cualquier dependencia de interfaces propietarias de un único proveedor se convierte en una trampa larga y costosa.

El fallo recurrente es la antítesis de la interoperabilidad: el cierre de proveedor (vendor lock-in), por el cual los datos y los procesos de una organización quedan tan entrelazados con los formatos y las interfaces no estandarizadas de un solo proveedor que migrar, integrar o incluso leer los datos más adelante se vuelve prohibitivo. Los estándares abiertos son la principal defensa frente a ello. Este capítulo aborda los niveles en los que los sistemas deben interoperar, los estándares que lo hacen posible y cómo diseñar, contratar y certificar esa interoperabilidad. Se vincula estrechamente con las APIs y el diseño de interfaces (capítulo 2.3), los sistemas distribuidos (capítulo 3.3), la estrategia y gobernanza de datos (capítulo 7.1), las compras y el software de código abierto (capítulo 10.3) y el cumplimiento normativo y la gobernanza (capítulo 4.6).

Principios fundamentales

La interoperabilidad se diseña desde el inicio, no se añade a posteriori. Hay que decidir los estándares antes de construir, porque implantarlos después implica reescribir interfaces y migrar datos.
Se prefieren los estándares abiertos a las integraciones a medida. Una interfaz conforme sirve a todos los socios actuales y futuros; un conector a medida sirve a uno solo.
La interoperabilidad tiene niveles. Transmitir datos por la red es inservible si ambas partes no se ponen de acuerdo sobre lo que esos datos significan.
El significado reside en los vocabularios compartidos. Los identificadores, los sistemas de códigos y las terminologías son lo que convierten los datos intercambiados en algo utilizable, no solo transmisible.
Los estándares solo existen si se les da cumplimiento real. Afirmar que un sistema «soporta FHIR」 sin pruebas de conformidad es marketing, no interoperabilidad.
El cierre de proveedor es una decisión de coste total de propiedad. La opción propietaria barata hoy suele ser el parque tecnológico encerrado y caro de mañana.
El sector público multiplica la necesidad. Los servicios públicos trascienden fronteras organizativas que nadie controla de forma unificada, por lo que los estándares abiertos suelen ser un mandato, no una preferencia.

Recomendaciones

Diseñar para los cuatro niveles de interoperabilidad

El Marco de Interoperabilidad Europeo y modelos afines describen cuatro niveles, y un sistema debe cumplirlos todos para interoperar de verdad. La interoperabilidad técnica es la infraestructura: redes, protocolos y transporte (por ejemplo, HTTPS) que trasladan los datos de un sistema a otro. La interoperabilidad sintáctica es el acuerdo sobre la estructura y el formato, la gramática del mensaje, como JSON (JavaScript Object Notation, un formato de datos en texto ligero) o XML (eXtensible Markup Language). La interoperabilidad semántica es el acuerdo sobre el significado: que un campo etiquetado como gender o un código 250.00 signifique lo mismo para ambas partes. La interoperabilidad organizativa es la alineación de procesos, gobernanza, roles y acuerdos legales: quién puede enviar qué a quién, bajo qué acuerdo de intercambio de datos y con qué finalidad. La mayoría de los proyectos de integración dominan los dos primeros niveles y fracasan en el tercero y el cuarto. Hay que tratar la interoperabilidad semántica y organizativa como un trabajo de diseño de primer orden, no como un detalle pendiente.

Estandarizar la capa de intercambio de datos y de APIs

Adoptar estándares abiertos y de amplio despliegue para describir y exponer las interfaces. En el caso de las APIs web (Application Programming Interfaces, el contrato definido por el que un sistema invoca a otro), utilizar la OpenAPI Specification, una descripción neutra respecto a proveedores y legible por máquina de una API de estilo REST (Representational State Transfer) que no solo documenta la interfaz, sino que genera código de cliente, servidores, pruebas y simuladores. Para los formatos de carga útil, preferir JSON por su ubicuidad y legibilidad humana, y emplear XML cuando el ecosistema ya estandarice sobre él. Cuando se requiera comunicación de alto rendimiento y fuertemente tipada entre servicios, considerar gRPC (un marco de invocación de procedimientos remotos) con Protocol Buffers (Protobuf), un formato binario compacto y definido por esquema, que en sí mismo es una especificación abierta. La clave no es la tecnología concreta, sino que el contrato esté publicado, sea legible por máquina e independientemente implementable. Véase el capítulo 2.3 para un tratamiento más detallado del diseño de interfaces.

Adoptar el estándar reconocido en cada ámbito sectorial

La mayoría de los sectores han convergido en estándares de interoperabilidad propios del dominio. Hay que usarlos en lugar de inventar los propios. La sanidad es el ejemplo paradigmático. HL7 (Health Level Seven, un organismo de normalización y sus antiguos estándares de mensajería) ha sido ampliamente superado en los proyectos nuevos por FHIR (Fast Healthcare Interoperability Resources), un estándar moderno que modela los conceptos clínicos (paciente, observación, medicación) como recursos web intercambiados a través de APIs REST mediante JSON o XML. En finanzas, ISO 20022 es el estándar abierto para la mensajería financiera estructurada y ricamente anotada, ya adoptado por los sistemas de pagos de todo el mundo. En el ámbito geoespacial, el OGC (Consorcio de Geoinformática Abierta) publica estándares como WMS y WFS para servicios de mapas y de objetos geográficos. Otros ejemplos incluyen OASIS y UBL para documentos empresariales, e IFC (BuildingSMART) para la construcción. Elegir el estándar reconocido supone heredar todo un ecosistema de herramientas conformes, proveedores y personal formado.

Anclar el significado en identificadores, sistemas de códigos y ontologías

La interoperabilidad semántica exige vocabularios compartidos. Utilizar identificadores estándar para que lo mismo en el mundo real tenga la misma referencia en todas partes (por ejemplo, un código de país ISO, un LEI para una entidad jurídica o un identificador nacional de paciente). Emplear sistemas de códigos y terminologías publicadas (listas controladas de conceptos codificados con significados definidos) en lugar de texto libre: SNOMED CT y LOINC para términos clínicos, CIE (Clasificación Internacional de Enfermedades) para diagnósticos, Unicode para texto. Cuando las relaciones entre conceptos sean relevantes, emplear una ontología (un modelo formal y legible por máquina de conceptos y sus relaciones) expresada en estándares como RDF y OWL (el Lenguaje de Ontologías de la Web, de la W3C). La gobernanza de estos vocabularios es una responsabilidad de la gobernanza de datos; véase el capítulo 7.1.

Integrar mediante patrones basados en estándares, no en conexiones punto a punto

Favorecer los patrones arquitectónicos que mantienen el número de integraciones lineal y no combinatorio. N sistemas conectados de forma punto a punto pueden requerir hasta N×(N−1)/2 conectores a medida. Los mismos N sistemas, cada uno conforme a un estándar compartido, solo necesitan N implementaciones de ese estándar. Utilizar puertas de enlace, contratos de API publicados y modelos de datos canónicos para que un nuevo participante se integre una vez, frente al estándar, en lugar de frente a cada sistema existente. Este es también el antídoto contra el cierre de proveedor: como el contrato es abierto, un proveedor puede sustituirse sin tocar a todos los conectados a él.

Exigir conformidad y certificación

Un estándar solo rinde valor cuando las implementaciones se le ciñen de verdad. Exigir pruebas de conformidad (verificaciones automatizadas de que una implementación cumple la especificación) con suites de pruebas y validadores publicados (por ejemplo, los validadores y las pruebas Touchstone de FHIR, o la validación de esquema OpenAPI en la línea de integración continua). Donde exista un programa formal de certificación (un organismo independiente que atestigua la conformidad, como los esquemas de certificación de tecnologías sanitarias a nivel nacional), preferir los productos certificados e incluir la certificación como requisito contractual. Incorporar los controles de conformidad en la integración continua, de modo que cualquier desviación del estándar provoque el fallo de la construcción y no aparezca en producción.

Compromisos: ventajas e inconvenientes

Enfoque	Ventajas	Inconvenientes / costes
Estándar abierto	Múltiples proveedores, sin cierre, herramientas de ecosistema, integración barata de socios futuros	El estándar puede ser amplio o complejo; adopción más lenta de funcionalidades de nicho; evolución al ritmo del comité
Integración a medida punto a punto	Rápida para la primera conexión, ajuste exacto, mínimo esfuerzo de aprendizaje inicial	El coste crece de forma combinatoria, es frágil, hay que rehacerla con cada cambio y fomenta el cierre de proveedor
Formato o API propietaria	Funcionalidad rica, soporte del proveedor, arranque rápido dentro de un ecosistema	Cierre de proveedor, coste de migración, datos difíciles de extraer después, desplazamiento del poder de fijación de precios hacia el proveedor
Estándar sectorial (FHIR, ISO 20022)	Significado compartido, fuerza de trabajo formada, alineación con el regulador	Curva de aprendizaje, mapeo de datos heredados, sobrecoste de gestión de versiones y perfiles

El compromiso maestro es entre la comodidad a corto plazo y la opcionalidad a largo plazo. Una integración a medida o propietaria casi siempre es más rápida de poner en marcha para la primera conexión, y por eso las organizaciones caen en el cierre de proveedor una decisión razonable a la vez. Los estándares abiertos anticipan el coste (aprender la especificación, mapear los datos existentes, construir pruebas de conformidad) y lo devuelven cada vez que un nuevo socio, proveedor o sistema se incorpora sin necesidad de reescritura. Para un sistema de larga vida y muchos participantes, que es casi toda plataforma empresarial o gubernamental, la vía estandarizada gana con contundencia. Para un enlace de un solo uso, verdaderamente desechable, una integración a medida puede ser racional. El error está en tratar plataformas de larga duración como si fueran enlaces desechables.

Preguntas para debatir con el equipo

¿Quién es el responsable de la interoperabilidad organizativa (los acuerdos de intercambio de datos, los modelos de consentimiento y la alineación de procesos) de la que depende su integración técnica? La mayoría de los proyectos resuelven los niveles técnico y sintáctico y se atascan en el organizativo: los datos llegan y se interpretan, pero no existe ningún acuerdo que regule quién puede enviar qué a quién, con qué finalidad y bajo qué consentimiento. En el sector público, los datos de un ciudadano atraviesan organismos que cada uno gestiona sus propios sistemas y rinde cuentas a bases legales distintas, de modo que una interfaz FHIR impecable es inútil hasta que existe el acuerdo de intercambio y el modelo de consentimiento. Trazar su intercambio transfrontera más importante y nombrar el instrumento legal y el responsable en cada extremo, no solo la API. Si ese responsable no existe, la integración superará todas las pruebas técnicas y quedará bloqueada en producción. Tratar esos acuerdos como artefactos de diseño con el mismo rigor que el esquema de mensajes.
¿En qué medida se apoya en las extensiones propietarias de un estándar, y podría otra implementación conforme comunicarse con el sistema? Los estándares incluyen salidas de emergencia, y su uso excesivo es, de facto, un cierre de proveedor disfrazado de estándar abierto: se declara FHIR o ISO 20022, pero ningún proveedor independiente puede realmente interoperar con el dialecto propio. Se cuela una personalización razonable a la vez, por lo que un parque tecnológico de gran envergadura debería medirlo deliberadamente. Tomar un mensaje real y contar en qué proporción su significado descansa en campos estándar frente a extensiones personalizadas; a mayor peso de lo personalizado, más frágil la portabilidad y mayor el poder de fijación de precios del proveedor incumbe. Preferir la configuración por perfiles dentro de las reglas del estándar, y contribuir con las lagunas al propio estándar, antes que recurrir a extensiones privadas. Todo el punto de la vía abierta es que un proveedor pueda sustituirse sin tocar a todos los conectados, y las extensiones lo erosionan en silencio.
¿Qué versión y perfil de cada estándar se están utilizando, y quién gobierna esa elección en todo el parque tecnológico? «Compatible con el estándar» carece de sentido sin disciplina de versiones y perfiles, porque dos sistemas pueden afirmar ambos que soportan FHIR o ISO 20022 y aun así no poder comunicarse si implementan versiones o perfiles distintos. En una organización grande con muchos proveedores y ciclos de contratación largos, las versiones divergen en silencio hasta que una integración se rompe. Disponer de un inventario de cada interfaz, su estándar, su versión y su perfil, y nombrar a quien sea responsable de mantenerlos alineados y de planear las actualizaciones. Incorporar la versión y el perfil a las pruebas de conformidad en la línea de integración continua, de modo que cualquier desalineación provoque el fallo de la construcción y no surja en producción. Sin esa gobernanza, los sistemas nominalmente conformes siguen sin poder interoperar, que es justo el fallo que los estándares abiertos debían prevenir.
¿Cuando un contrato o un proveedor dice «compatible con el estándar», qué prueba independiente lo acredita y dónde se ejecuta esa prueba? Una afirmación de conformidad sin prueba que la respalde es marketing, y falla donde más duele: en producción, después de que el dinero ya ha cambiado de manos y el sistema está en marcha. En una organización grande que compra a muchos proveedores, la tentación es aceptar una casilla de verificación en un cuestionario, porque exigir la conformidad validada frena la contratación y reduce la cartera de licitadores. Reunir el validador o la suite de pruebas publicada para cada estándar del que se depende (por ejemplo, los validadores y Touchstone de FHIR, o la validación de esquema OpenAPI), una muestra de mensajes reales pasados por él, y la cláusula contractual que vincula la aceptación y el pago a superar la prueba. La tensión es entre la velocidad y la prueba: un producto certificado puede costar más y tardar más en incorporarse, pero un producto no verificado transfiere el fallo al equipo de integración. En el ámbito público y regulado, donde existen esquemas nacionales de certificación de tecnologías sanitarias o de pagos, exigir la certificación en el contrato y conectar el validador en la integración continua para que la desalineación provoque el fallo de la construcción, porque una aserción que nunca se probó es una responsabilidad que se descubrirá durante una auditoría o una avería.
¿Cuántas de las integraciones siguen siendo punto a punto, y cuál es el verdadero coste combinatorio de dejarlas así? Los conectores a medida de uno a uno son lo más rápido de construir para el primer enlace y lo más caro de mantener en un parque tecnológico, porque el número tiende a N×(N−1)/2 mientras un estándar compartido solo requiere N implementaciones. En una organización grande, ese enmarañamiento se acumula una decisión razonable a la vez hasta que el mapa de integraciones resulta inmanejable y cada cambio de sistema se propaga por una docena de conectores frágiles. Presentar un inventario de las integraciones clasificado en punto a punto frente a basado en estándares, el número de conectores afectados por la última gran sustitución de sistema, y una estimación del tiempo de ingeniería dedicado al mantenimiento de vínculos personalizados. La tensión es que migrar un cableado punto a punto en producción detrás de una puerta de enlace o un modelo canónico es trabajo real sin retorno inmediato en funcionalidad, y pierde frente a la hoja de ruta salvo que alguien cuantifique el coste de mantenimiento. Para plataformas empresariales y de administración pública que duran décadas e incorporan participantes de forma continua, la vía punto a punto es un impuesto lento; nombrar un responsable de la arquitectura de integración y un plan para canalizar a los nuevos participantes a través del estándar en lugar de frente a cada sistema ya en marcha.
¿Dónde se transmite significado mediante texto libre que un sistema de códigos o una terminología publicada debería携带, y quién gobierna esos vocabularios? La interoperabilidad semántica es donde la mayoría de las integraciones fallan en silencio: los datos llegan y se interpretan, pero un diagnóstico, una divisa o un país almacenado como una cadena libre significa una cosa para el emisor y otra sutilmente distinta para el receptor. En una organización grande, el coste es invisible hasta que la informes, el análisis o un regulador destapan que el mismo concepto se codificó de tres formas en tres sistemas. Aportar ejemplos de campos actualmente en texto libre, los identificadores y sistemas de códigos estándar que podrían sustituirlos (SNOMED CT y LOINC para datos clínicos, códigos ISO para países y divisas, un LEI para entidades jurídicas), y las tasas de error o el esfuerzo de conciliación que el texto libre está ocultando. La consideración contraria es que el mapeo de datos heredados a vocabularios controlados es laborioso y nunca se demuestra en una presentación, por lo que recibe crónicamente una financiación inferior a la de la capa de transporte. En el sector público, donde el historial de un ciudadano se ensambla a partir de muchos sistemas independientes y un código incorrecto puede denegar una prestación o corromper un registro sanitario, tratar la gobernanza de vocabularios como una responsabilidad nombrada de la gobernanza de datos (capítulo 7.1), no como un detalle de implementación delegado en cada equipo.

Perspectiva por sector

Startup. La velocidad manda, y los estándares abiertos son la forma en que un equipo reducido alcanza a muchos clientes sin construir muchos conectores. Hablar los formatos que cada socio ya soporta (OAuth para el inicio de sesión, iCalendar para la agenda, webhooks para los eventos) de modo que una sola integración alcance a miles de clientes y la sustitución de un proveedor de pagos o de correo toque un solo adaptador. Evitar inventar un formato propio o cablear a mano cada pila de tecnología del cliente: es un mantenimiento futuro que no se puede cubrir. La vía de los estándares cuesta algo más al principio y mantiene la migración barata en un mercado que aún no se puede predecir.

Pequeña y mediana empresa. Sin especialistas en integración y con un presupuesto ajustado, tratar la interoperabilidad como una decisión de compra, no como un proyecto de construcción. Preferir herramientas que ya hablen el estándar abierto del sector y expongan una API documentada, de modo que los datos permanezcan portables si se cambia de proveedor. Preguntar a un candidato a proveedor cómo se extraen los datos y en qué formato antes de firmar, porque la opción propietaria barata de hoy es el parque tecnológico encerrado de mañana. Rara vez se ejecutarán una prueba de conformidad por cuenta propia, por lo que conviene apoyarse en productos certificados o de amplia interoperabilidad.

Gran empresa / corporación. El reto es gobernar la interoperabilidad entre muchos equipos, proveedores y ciclos de contratación largos. Imponer el estándar sectorial (FHIR, ISO 20022, OGC) y un contrato OpenAPI publicado, y mantener un inventario de cada interfaz con su versión y su perfil y un responsable, para que los sistemas nominalmente conformes no diverjan. Canalizar a los nuevos participantes a través de puertas de enlace y modelos canónicos en lugar de conexiones punto a punto, conectar la validación de conformidad en la integración continua y medir en qué proporción del tráfico se apoya en campos estándar frente a extensiones propietarias. Gestionar el cierre de proveedor y la portabilidad como una posición deliberada de coste total de propiedad, no como un accidente.

Sector público / administración pública. Los estándares abiertos suelen ser un mandato, porque los servicios públicos abarcan organismos que ninguna institución controla de forma unificada y los proveedores cambian en ciclos plurianuales. Exigir pruebas de conformidad y, donde existan esquemas nacionales, la certificación en cada contrato, y demandar la portabilidad de datos para que un proveedor saliente no pueda tomar los datos públicos en rehén. Anclar el significado en identificadores nacionales y terminologías publicadas para que el registro de un ciudadano signifique lo mismo en todas las consejerías, y gestionar la interoperabilidad organizativa mediante acuerdos de intercambio de datos y modelos de consentimiento con responsables nombrados. La transparencia y el dinero público abogan ambos por la vía abierta e independientemente implementable frente a cualquier conveniencia propietaria.

Ejemplos

Startup. Una pequeña startup que desarrolla una aplicación de productividad para equipos se conecta a las herramientas existentes de sus clientes a través de estándares abiertos en lugar de conectores a medida: OAuth para el inicio de sesión, iCalendar para la agenda y webhooks para los eventos. Al hablar formatos que cada proveedor de calendario e identidad ya soporta, una sola integración alcanza a miles de clientes en lugar de uno, y sustituir un proveedor de pagos o de correo solo afecta a un adaptador. De haber construido a mano un enlace personalizado a cada pila de tecnología del cliente, cada nuevo logo habría supuesto otro conector que escribir y mantener.

Gran empresa / corporación. Un banco multinacional moderniza sus pagos transfronterizos migrando de un formato de mensaje propietario heredado a ISO 20022. Como el estándar porta datos estructurados y ricamente anotados (pagador, beneficiario, finalidad, campos regulatorios) en lugar de texto libre, los sistemas downstream de detección de fraude, conciliación e informes consumen un formato canónico único en lugar de una docena de analizadores a medida. Cuando el banco sustituye más tarde a su proveedor de pasarela de pagos, el nuevo proveedor ya habla ISO 20022, de modo que la migración afecta a la pasarela y no a los cien sistemas que hay detrás. El estándar abierto convirtió una migración de proveedor de un proyecto plurianual en una sustitución acotada.

Sector público / administración pública. Un sistema nacional de salud necesita que hospitales, clínicas, laboratorios y una aplicación orientada al paciente (construidos por distintos proveedores a lo largo de dos décadas) compartan registros con seguridad. Se impone FHIR para el intercambio de datos: cada sistema expone los datos de paciente, observación y medicación como recursos FHIR a través de APIs REST, utilizando identificadores estándar (un identificador nacional de paciente) y terminologías clínicas (SNOMED CT para condiciones, LOINC para resultados de laboratorio) de modo que los códigos signifiquen lo mismo en todas partes. Los proveedores deben superar la validación de conformidad FHIR y contar con la certificación nacional de tecnologías sanitarias antes de conectarse. Un nuevo sistema de clínica se integra una vez, frente al estándar FHIR, en lugar de construir enlaces a medida con cada sistema ya en marcha, y un ciudadano puede consultar un registro unificado ensamblado a partir de muchos sistemas independientes. La interoperabilidad organizativa se gestiona mediante acuerdos de intercambio de datos que regulan quién puede acceder a qué y con qué finalidad, satisfaciendo los requisitos de cumplimiento normativo (capítulo 4.6).

Argumento de negocio: motivaciones, rentabilidad y coste total de propiedad

El argumento económico a favor de los estándares abiertos es un argumento sobre el coste total de propiedad a lo largo de la vida de un sistema, no sobre el precio de etiqueta de la primera integración. El coste de una integración a medida crece con el número de conexiones y se paga de nuevo con cada cambio. El coste de una integración basada en estándares se paga una vez por participante y se amortiza en todo el parque. La rentabilidad se manifiesta en la reducción del trabajo de integración, la incorporación más rápida de nuevos socios y proveedores, el menor coste de migración cuando un proveedor no rinde y la evitación del clásico impuesto del cierre de proveedor, cuando un proveedor único sube los precios porque ningún competidor puede licitar.

Para la dirección, formular el caso en torno a la opcionalidad y la competencia. Los estándares abiertos mantienen la contratación competitiva (capítulo 10.3): cuando las interfaces están publicadas y sometidas a pruebas de conformidad, múltiples proveedores pueden licitar en términos de igualdad, lo que hace descender los precios y elevar la calidad en contratos sucesivos. También descienden el riesgo de futuro, porque los cambios regulatorios, las fusiones y los programas de modernización se abaratan cuando los datos y las interfaces son portables. El mayor coste oculto de ignorar los estándares es la migración forzada eventual: extraer datos de un formato propietario a posteriori, con el proveedor original ausente o poco colaborativo, suele costar varias veces lo que el diseño basado en estándares habría supuesto en origen. Las administraciones públicas lo reconocen cada vez más e imponen estándares abiertos precisamente para proteger el erario público del cierre de proveedor a lo largo de décadas.

Antipatrones y errores habituales

Confundir la interoperabilidad técnica con el trabajo completo. El mensaje llega y se interpreta, pero las dos partes no se ponen de acuerdo sobre lo que significa un campo, y los datos son erróneos en silencio.
«Basado en estándares» solo en nombre. Un producto afirma soportar un estándar, pero nunca ha superado una prueba de conformidad y en la práctica se desvía.
Texto libre donde existe un sistema de códigos. Almacenar diagnósticos, divisas o países como cadenas sin restricción destruye la interoperabilidad semántica.
Extensiones propietarias que se comen el estándar. Usar las salidas de emergencia de un estándar con tal intensidad que ninguna otra implementación puede interoperar: cierre de proveedor de facto con etiqueta de abierto.
Enmarañamiento punto a punto. Añadir un conector a medida más cada vez, hasta que el mapa de integraciones es un caos combinatorio inmanejable.
Caos de versiones y perfiles. Sin gobernanza de qué versión o perfil de un estándar está en uso, de modo que sistemas nominalmente conformes siguen sin poder comunicarse.
Ignorar la interoperabilidad organizativa. Intercambio técnico impecable bloqueado porque no existe ningún acuerdo de intercambio de datos, modelo de consentimiento o alineación de procesos.
Inventar su propio estándar. Crear un formato a medida cuando ya existe un estándar del dominio maduro y adoptado, y heredar para siempre su mantenimiento.

Modelo de madurez

Nivel 1: Iniciación. La integración es ad hoc y punto a punto. Los formatos son propietarios o no documentados. El significado se transmite mediante texto libre y conocimiento tribal. Sustituir cualquier sistema o proveedor es un proyecto mayúsculo. El cierre de proveedor es generalizado y en gran medida no reconocido.
Nivel 2: Desarrollo. Aparecen formatos comunes como JSON o XML, y algunas APIs están documentadas, pero la práctica varía de un equipo a otro. La interoperabilidad sigue siendo sobre todo sintáctica; el acuerdo semántico es inconsistente y de proyecto a proyecto. Los estándares se eligen de forma reactiva, y la conformidad se afirma pero no se prueba.
Nivel 3: Estandarización. Los estándares abiertos de intercambio de datos (OpenAPI y el estándar sectorial pertinente, como FHIR o ISO 20022) están documentados y son obligatorios a nivel organizativo. Los identificadores, los sistemas de códigos y las terminologías compartidas garantizan la interoperabilidad semántica. Las pruebas de conformidad forman parte de la línea de entrega, y la integración sigue patrones basados en estándares en lugar de conexiones punto a punto.
Nivel 4: Gestión. La interoperabilidad se mide y controla frente a líneas de base. Se siguen y revisan métricas: la proporción de integraciones basadas en estándares frente a punto a punto, la fracción del significado de los mensajes que descansa en campos estándar frente a extensiones propietarias, las tasas de superación de pruebas de conformidad en la línea de integración continua, la desalineación de versiones y perfiles en el parque, y los plazos de integración y las tasas de defectos para incorporar un nuevo participante. Las versiones y los perfiles están gobernados, la certificación es un requisito para los proveedores y se verifica, y el riesgo de cierre de proveedor se cuantifica en lugar de percibirse. Las decisiones de adopción, actualización o retirada de una interfaz se toman sobre esta evidencia.
Nivel 5: Orquestación. La interoperabilidad mejora de forma continua y se integra a lo largo de toda la organización. La interoperabilidad organizativa (acuerdos, consentimiento, alineación de procesos) se gestiona de forma sistemática junto a las capas técnicas, la organización contribuye a los estándares de los que depende, y la portabilidad es una restricción de diseño permanente. El parque se adapta a medida que los estándares evolucionan y los participantes entran o salen, reequilibrando la arquitectura de integración y la gobernanza de vocabularios sobre la evidencia medida y no en reacción a una incidencia.

Ideas para el debate

En su intercambio de datos más crítico, ¿en cuál de los cuatro niveles (técnico, sintáctico, semántico, organizativo) es más débil hoy?
Si su proveedor principal duplicara su precio en la renovación, ¿cuánto tardaría y cuánto costaría migrar, y qué es lo que lo hace tan difícil?
¿Cuáles de sus integraciones son punto a punto, y qué haría falta para trasladarlas detrás de un estándar abierto compartido?
¿Dónde almacena en texto libre lo que un sistema de códigos o una terminología publicada debería portar, y qué errores oculta ese texto libre?
¿Cuando sus contratos dicen «compatible con el estándar», exige superar una prueba de conformidad o certificación independiente, o es solo una aserción?
¿Qué mandatos de estándares abiertos (nacionales o sectoriales) ya le aplican, y los está realmente cumpliendo o solo afirmando que los cumple?

Puntos clave

La interoperabilidad significa usar la información intercambiada, no solo transmitirla; diseñar para los cuatro niveles: técnico, sintáctico, semántico y organizativo.
Preferir estándares abiertos, publicados e independientemente implementables frente a integraciones a medida y formatos propietarios, que generan cierre de proveedor y coste combinatorio.
Estandarizar la capa de API y de intercambio de datos (OpenAPI, JSON/XML, gRPC/Protobuf) y adoptar el estándar reconocido del sector (FHIR en sanidad, ISO 20022 en finanzas, OGC en geoespacial).
Anclar el significado en identificadores, sistemas de códigos, terminologías y ontologías compartidos; la interoperabilidad semántica es donde la mayoría de las integraciones fallan en silencio.
Exigir pruebas de conformidad y, cuando existan, certificación; un estándar solo es real cuando las implementaciones se le ciñen de forma demostrable.
Juzgar la elección por el coste total de propiedad y la opcionalidad a lo largo de la vida del sistema; para plataformas de larga vida y con múltiples participantes (casi todas las plataformas empresariales y de administración pública), los estándares abiertos ganan, y el sector público los impone cada vez más.

Referencias y lecturas complementarias

HL7 International, Especificación FHIR (Fast Healthcare Interoperability Resources) (hl7.org/fhir)
ISO 20022, Esquema de mensajes universales de la industria financiera (iso20022.org)
OpenAPI Initiative, Especificación OpenAPI (Linux Foundation)
Consorcio de Geoinformática Abierta (OGC), estándares (WMS, WFS y sucesores)
Comisión Europea, Marco de Interoperabilidad Europeo (EIF) y la Ley de Interoperabilidad en Europa
Gobierno del Reino Unido, Principios de Estándares Abiertos y el Código de Práctica Tecnológica (GOV.UK)
W3C, RDF, OWL (Lenguaje de Ontologías de la Web) y estándares de la Web Semántica
Terminologías de SNOMED International (SNOMED CT), del Instituto Regenstrief (LOINC) y de la OMS (CIE)
Especificaciones de gRPC y Protocol Buffers (Cloud Native Computing Foundation / software de código abierto)
Literatura de NIST e IEEE sobre interoperabilidad de sistemas y pruebas de conformidad