Interoperabilidad: ¿A qué aspiramos cuando hablamos de ella?

El pasado 2 de junio participé en el foro «Software Libre en México, reflexiones y oportunidades», organizado por la Comisión de Ciencia y Tecnología del Senado de la República. En este foro tocamos cuatro temas principales: Educación, gobierno, industria y sociedad.

Si bien el objetivo explícito central del foro fue presentar ante los legisladores y medios interesados tanto los puntos de vista que tenemos los activistas del software libre como las historias de éxito, los avances y problemas con que nos hemos encontrado en los ya más de quince años que llevamos de existencia en nuestro país, posiblemente lo más importante que nos llevamos los participantes fue la reactivación de un grupo de discusión para tratar temas políticos relacionados con la tecnología y con el factor cohesivo de estar interesados en la difusión del software libre.

Este grupo, coordinándose a través de una lista de correo pública[1], está actualmente en proceso de definir los puntos de la agenda digital a presentar; el primero de ellos es el de la interoperabilidad.

El tema coincide con la presentación de la versión preliminar de un acuerdo de la Secretaría de la Función Pública (SFP), a ser discutido y –esperamos– aprobado en las próximas semanas o meses. Nos resulta de gran importancia no sólo analizar y proponer en lo relativo a esta temática hacia el interior de nuestro grupo (y de las instancias gubernamentales involucradas), sino también hacia los demás profesionales en el tema, como lo son los lectores de esta revista.

Dada la imposibilidad de proporcionar referencias a un documento aún inexistente y motivado por el interés que seguramente ésto causará a más de uno de ustedes, coloqué a su disposición una copia de una versión preliminar de este texto en mi sitio Web[2].

¿A qué nos referimos con interoperabilidad?

Al enfrentar un desarrollo, un punto fundamental a considerar desde muy temprano es cuál será su límite o interfaz, sea un sistema, un API sobre la nube, un servicio, un componente o una biblioteca, debemos delimitar por qué mecanismo recibiremos las solicitudes de los usuarios y por cuál le entregaremos los resultados. Del mismo modo, nuestro sistema parte de un contrato con diversos elementos (nuevamente, de cualquiera de los niveles antes descritos) que le brindarán facilidades, por ejemplo, de conectividad a red o de manejo de bases de datos. Hablar de interoperabilidad significa que en cada uno de dichos puntos, en cada una de las interfaces, el intercambio de datos se realice de forma tal que evite imponer dependencia en algún paquete específico, en los designios de algún producto que a futuro pudiera –de cierto modo– mantener como rehén sea al usuario final, al desarrollador o a la entidad que requirió del desarrollo en cuestión.

En palabras del Grupo de Trabajo para la Interoperabilidad, de la Asociación Francófona de Usuarios de Software Libre[3]:
“La interoperabilidad es la capacidad que tiene un producto o un sistema, cuyas interfaces son totalmente conocidas, para funcionar con otros productos o sistemas existentes o futuros y eso sin restricción de acceso o de implementación.”

El borrador de la SFP divide la definición de interoperabilidad en cinco sub-definiciones:

1. Interoperabilidad - Definición del concepto global.
2. Interoperabilidad organizacional - Homologar criterios y procedimientos entre distintas dependencias.
3. Interoperabilidad semántica - Un manejo estandarizado del significado de los diversos conceptos.
4. Interoperabilidad técnica - A las especificaciones técnicas que garantizan que los componentes tecnológicos de los sistemas de información están preparados para interactuar de manera conjunta.
5. Neutralidad tecnológica - Busca que cada dependencia pueda elegir los programas y mecanismos más adecuados para su desarrollo sin que se favorezca o penalice a ninguno por criterios más allá de los puramente técnicos.

Del dicho al hecho

Quien pegue una etiqueta en una página web que diga “esta página se ve mejor con el navegador X” es un nostálgico por los días viejos y malos, antes de la Web, cuando tenías muy pocas probabilidades de leer un documento escrito en otra computadora, otro procesador de textos u otra red. — Tim Berners-Lee, Technology Review, julio 1996.

El documento presentado por la SFP nos parece muy esperanzador, está escrito de forma clara y bastante exhaustiva. El cuidado que debemos ahora poner va principalmente para que el acuerdo no quede en letra muerta, debe ser del conocimiento de las diversas dependencias y ser tomado en serio para beneficio no sólo de toda la población, sino que de cada una de dichas dependencias. Además, debe ser conocido y comprendido por la industria nacional de desarrolladores de software, dado que interoperar sin restricciones no únicamente beneficia al sector público, sino que, a fin de cuentas, a todos los implicados.

Escribir software que no dependa de implementaciones específicas es sencillamente escribir mejor software.

Al día de hoy, como usuarios, tristemente nos resulta muy común encontrar, una y otra vez, ejemplos de cosas que podrían trivialmente ser interoperables, pero resultan no serlo y lo que es peor: sin razón alguna.

Ejemplos de lo que digo son demasiado comunes. Desde la aplicación desarrollada por el SAT para presentar la declaración de impuestos (desarrollada en Java, plataforma que se popularizó al ser la primera en impulsar explícitamente la interoperabilidad como su principal promesa), que sencillamente se niega a operar al ser llamada con cualquier navegador que no sea Internet Explorer, hasta el SUA del IMSS, única manera en que una empresa puede dar de alta y administrar a su plantilla de trabajadores ante IMSS e INFONAVIT, que requiere ser ejecutada en computadoras corriendo Windows. Y al igual que estos dos casos de altísima visibilidad, seguramente ustedes podrán citar a ejemplos adicionales que obligan a sus usuarios a emplear tecnologías específicas, sin justificación técnica alguna para hacerlo.

El pretexto más frecuente que encontramos ante cualquier solicitud de que algún sistema sea utilizable desde una plataforma distinta es el ya sabido “eso es lo que hay y no podemos hacer nada al respecto” donde modificar la base de software ya desarrollado e instalado significaría una tarea titánica. Sin embargo, los servicios fundamentales que deben estar disponibles para toda la población deben ser priorizados. Resulta inaceptable que a la población en general se le imponga el requisito de emplear una tecnología específica (independientemente del papel dominante que ésta tenga actualmente en el mercado), especialmente dado el desarrollo y rápida adopción de estándares como HTML5, que permiten un despliegue extensivo de interfaces de usuario ricas y completamente multiplataforma.

Las múltiples facetas de la interoperabilidad

Hablar de interoperabilidad no se limita a permitir que usuarios con configuraciones diversas puedan usar los sistemas de gobierno, como lo mencionamos en el primer apartado, parte importante de la interoperabilidad se refiere a cómo facilitar el intercambio de información entre entidades del mismo gobierno, a la creación de modelos estandarizados (la ya citada interoperabilidad semántica) con los que puedan representarse e intercambiarse datos acerca de las estructuras más comúnmente encontradas y repetidas, las cuales posiblemente faciliten que paulatinamente se vaya creando, en vez de una colección de sistemas que conforman al e-gobierno, una nube de información con un mínimo de duplicación de información.

¿Y cómo elegir entre tantos estándares disponibles? ¿Qué formatos, protocolos y lenguajes son los más adecuados? ¿Cómo podemos determinar cuál es un estándar abierto? Este es un tema que da para largas discusiones, y motivo de los diferentes foros referidos. Si nos basamos en lo que dice el Proyecto de Acuerdo al respecto, tenemos que los estándares abiertos deberán tener, como mínimo, las características siguientes:

• Disponibilidad.
• Que los derechos de autor estén disponibles, libres de regalías y condiciones.
• Maduros.
• Internacionalmente aceptados.
• De fácil distribución.
• Con amplio soporte en el mercado.

El sólo hecho de reducir la cantidad de datos redundantes (y por consiguiente avanzar en la larga lucha contra los peregrinares a mil ventanillas para cualquier trámite trivial) ya por sí sólo lo valdría. Agreguemos a esto que reducirá fuertemente la dependencia de proveedores únicos y de la permanencia en el mercado de productos específicos, fomentando el crecimiento de una verdadera industria de desarrollo de software.

Sigamos entonces, la discusión que se presentará sobre estos temas en los próximos meses. Este es un tema que indudablemente impactará el trabajo de todos nosotros y en el que todos tendremos algo que aportar.