El lado oscuro de la integración entre aplicaciones

No hay iniciativa que más guste a los altos directivos que integrar aplicaciones. También gusta mucho la reutilización que está tan de moda ahora, aunque de eso ya hablé en la anterior entrada del Blog. Ligado a la reutilización también está la famosa “nube”. Ya sabéis que vienen tiempos de nubarrones.

El caso es que te encuentras en una reunión, se empieza a hablar sobre alguna aplicación y prácticamente siempre sale a colación el tema de integrarla con “tropecientas” más. Sí que es cierto que en ocasiones integrar es sinónimo de eliminar papel en procedimiento y por tanto necesario, pero estas situaciones normalmente son debidas a un mal diseño previo de las aplicaciones.

Me explico, no hace mucho estuve reunido con un compañero de la IGAE precisamente para eso de integrar aplicaciones y comentábamos que ese proyecto es sin duda el más complicado, tedioso y difícil de obtener buenos resultados en el mundo del desarrollo. Llegamos a la conclusión de que la necesidad imperiosa de integrar en la Administración Pública, es debido al mal planteamiento inicial en donde se construyen aplicaciones basadas únicamente en las competencias del Departamento en cuestión, en vez de abarcar procedimientos globales e íntegros.

A ver, no se trata de hacer desarrollos “mastodónticos” que no haya por donde cogerlos, pero sí de una adecuada gestión de perfiles en las aplicaciones para tratar de tramitar el flujo completo y que cada perfil gestor del procedimiento sólo acceda a aquello que necesite.

Esto debería analizarse en detalle a partir de ahora, si no queremos sufrir con las malditas integraciones que cuestan un gran esfuerzo y que salvo contadas excepciones son fuente inagotable de problemas. Antes de diseñar una aplicación hay que analizar el procedimiento completo, o lo que es lo mismo, mirar al bosque y no al árbol. Aunque el problema parece no estar en los diseñadores de las aplicaciones sino en la distribución y dispersión de competencias y carencia de un CIO, o algo que se le asemeje, que gobierne y organice las decisiones en los proyectos que atañen a varios Departamentos. Pero eso es otro cantar.

El caso es que no queda más remedio que enfrentarse tarde o temprano con la integración de distintas aplicaciones entre sí. Además, el auge de la reutilización implica también hacer mayor uso de integraciones. Si se reutiliza una funcionalidad te permite que no la desarrolles en tu proyecto derivándola en un servicio común. Esto conlleva que tu aplicativo tenga que comunicarse con dicho servicio.

A mayor reutilización mayor integración entre aplicaciones.

Hay que tener mucho cuidado con abusar de estas integraciones, porque si no están debidamente justificadas, lo único que pueden suponer son problemas. Ya no es sólo que el servicio común funcione tal y como debiera, sino también que los servidores donde esté alojado (Servidor de aplicaciones y Base de Datos como mínimo) estén operativos. Ah! Y la red también, por favor no nos olvidemos de la red de comunicaciones.

Y para demostrarlo pongo un ejemplo real:

Los servicios de Intermediación como el servicio de validación del DNI son como su propia palabra indica una pasarela de intermediación. Pues bien, sobre esa pasarela en ocasiones nos empeñamos en añadir otra pasarela más con el fin de que así nos ahorremos temas de autenticación de certificados desde distintas aplicaciones. En mi opinión, esa otra pasarela no tiene ningún sentido y lo que hace es añadir mayor complejidad a la infraestructura. Esto conlleva que cuando falla el servicio, se complica determinar exactamente donde se produce el fallo: si en la aplicación cliente, si en la pasarela nuestra para evitar temas de certificados, si en la plataforma de intermediación o si en la conexión última con la que ofrece el servicio final. Como este ejemplo, existen numeroso más en los que las integraciones no tienen sentido por ser una tarea perfectamente asumible directamente por la aplicación, o lo que es lo mismo, el beneficio de la integración no compense frente al aumento de la complejidad en la infraestructura.

La seguridad también es un tema a tener en cuenta. La belleza esta en la simplicidad y cuando un sistema tiene demasiadas capas de procesamiento, el número de fallos potenciales sobre la seguridad aumenta significativamente.

Concluyo con una frase que resalta el lado oscuro de las integraciones : “Los errores o problemas que se producen dentro de tu código se solucionan muchísimo antes que aquellos ocurridos en tu servicio/aplicativo pero que no dependen de ti como consecuencia de las integraciones con otros servicios”

¿Por qué? Por la sencilla razón de que ya no es tu código, no puedes hacer nada por remediarlo y dependes de un tercero para que lo solucione que probablemente tiene mil historias que atender y seguramente tú no seas su prioridad. Así que mucho cuidado con integraciones innecesarias.

Finalmente ni que decir tiene que si planteas hacer una integración con algún servicio merece la pena informarse si algún otro Organismo/Departamento ya está integrado con él. Si nadie está integrado y te toca ser el conejillo de indias agárrate porque vienen curvas.

En resumen, la integración de aplicaciones es un tema delicado y hay que analizar detenidamente en cada caso la conveniencia o no de efectuarla. Unas veces será necesario y otras quizás convenga más buscar una solución alternativa disminuyendo de ese modo la complejidad final.