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.
Totalmente de acuerdo, hay que mirar más en global cuando inicia un desarrollo y, sobre todo, pensar en ESTÁNDARES!
ResponderEliminarNos fijamos demasiado en nuestro "pequeño" problema y cómo resolverlo, pero debemos pensar en un principio, qué más puede resolver!
Reutilización e interconexión YA!
Gracias por comentar Javi!
ResponderEliminarEl tema de los estándares tienes razón que es importante para que las integraciones sean exitosas y es un tema muy a tener en cuenta.
Respecto a "Reutilización e interconexión YA!" si lees mis dos últimas entradas yo me posiciono más de esta forma:
Reutilización sí, pero sólo cuando que sea posible. A veces no lo es.
Interconexión sólo en caso de ser necesaria y siempre y cuando las desventajas de la complejidad final (mayor infraestructura) no superen las ventajas de la integración.