La integración entre sistemas de software siempre ha sido un tema complejo. Hasta el punto que a veces es más difícil integrar dos aplicaciones que desarrollar una aplicación. De hecho la principal idea que sustenta aplicaciones integradas de gestión o ERP, es la complejidad de integrar múltiples sistemas, frente a tener toda la funcionalidad integrada en un sólo paquete.
Las razones son varias, un mismo sistema generalmente tiene en la gran mayoría de los casos, unas necesidades de plataforma tecnológica y software de terceros mucho más sencillas y coherentes. Es por definición menos complejo de mantener, gestionar, aprender y evolucionar. Por eso durante los últimos 30 años, la industria del software corporativo ha tendido hacia suites ERP que intentaban cubrir al máximo número posible de necesidades de una empresa. Aunque como todo siempre ha habido excepciones.
Por un lado han proliferado las soluciones sectoriales que lejos de ser un ERP estándar, incorporaban en mayor o menor grado funcionalidad específica del sector al que se dirigían. Durante muchos han tenido (y siguen teniendo) muy buena acogida, especialmente en sectores que se salen un poco del modelo de negocio más estándar de fabricación, distribución y venta de productos. En sectores como el transporte, la cría de animales, los seguros, la banca y un largo etc. Las soluciones estándar lo han tenido más difícil y gran parte de las empresas del sector cubren sus necesidades con soluciones verticales o desarrollos a medida.
La práctica siempre encuentra maneras de burlar a la teoría y hoy podemos encontrar empresas que trabajan con muchos sistemas integrados y son competitivas. ¿Cómo? Porque son capaces de sacar el trabajo adelante e incluso de llegar más lejos de lo que sería capaz un sistema estándar. Esto es algo perfectamente lógico.
Las limitaciones de las soluciones ERP
Se pueden resumir en un breve y conciso refrán: “Quien mucho abarca, poco aprieta”. Cuando queremos meter tantas cosas en un mismo sistema perdemos foco y concreción. Por necesidades de cohesión y simplicidad muchas cosas tendrán que adaptarse para que la aplicación sea gobernable, tenga una interfaz de usuario uniforme y un modelo de datos y procesos unificado.
El diseñar, desarrollar y mantener aplicaciones tan complejas que abarcan una problemática tan variada es una tarea titánica. Esto aun a costa de hacer sacrificios en muchas aéreas en pos de la solución global. Si no utilizamos elementos comunes de interfaz gráfica, encabezados, herramientas de consulta y manipulación de datos, acabaremos creando un leviatán que acabará por devorar al equipo de desarrolladores más expertos.
El tener un sistema único que integre todas necesidades de aplicaciones de gestión tiene enormes ventajas. Pero también tiene sus inconvenientes. Lo importante es que tanto si optamos por otra opción debemos de conocer las limitaciones de cada una y así podremos tomar medidas evitarlas o paliarlas.
Un modelo compartido de datos
Cuando hablamos de integrar aplicaciones necesitamos además un modelo de datos compartido. Este es un esquema básico de definición y establecimiento del origen de los datos utilizados entre aplicaciones. La información tiene un carácter simbólico y representativo, esto es especialmente aplicable a la información contenida en los sistemas informáticos. Cuando un cliente nos paga 1000€, no los guardamos en nuestros sistema. Cuando trabajamos con sistemas transaccionales esta información ha de compadecerse con la realidad, si además estamos integrando varias soluciones es todavía más importante que cuando estas comparten información, los datos compartidos tengan una integridad, una misma definición y un origen único.
Para que los algoritmos de aplicaciones distintas puedan trabajar con coherencia sobre unos mismos conjuntos de datos es necesario establecer un lenguaje común, definir que es cada dato, que tipo información contiene y en caso de ser modificado como ha de ser actualizado en el resto de sistemas.
Lo más importante es especificar el origen los datos. Este tiene que ser único, por ejemplo una tabla concreta de una determinada base de datos.
Para que en caso de que haya disonancias en datos duplicados siempre prevalezca la versión del origen datos. Luego hay que definir conceptualmente cada elemento dentro de la estructura de de datos. Por ejemplo los clientes, esto puede parecer a priori algo banal o teórico, pero es realmente importante.
A mayor cantidad de integraciones mayor complejidad
Por muy buen diseño estructural que hayamos realizado conforme vaya aumentando la cantidad y el nivel de integración entre nuestras soluciones los problemas irán aumentando. A medida que las integraciones entran en producción van surgiendo problemas de integridad y nuevos casos de uso que difícilmente hubiéramos podido contemplar durante la fase de diseño.
Por ello es muy importante tener bajo control y el número de integraciones y sobre intentar que estas se realicen mediante un canal único. Es decir que las integraciones se realicen en esquemas de 1 a uno. Y que no haya ninguna aplicación que esté cambiando un mismo dato en más de una aplicación.
La era dorada para la integración
En los últimos años hemos asistido a un verdadero apogeo de las integraciones. El fenómeno de las API´s y Web Services ha facilitado mucho las labores de integración, especialmente al haberse asumido unos estándares de facto y a que la experiencia ha permitido mejorar el enfoque con el que se plantean este tipo de proyectos.
Algunos ejemplos como la simplificación del formato de intercambio de datos que ha supuesto el JSON frente al HTML han facilitado enormemente las labores de integración a los desarrolladores, sin que ello suponga ningún avance tecnológico. Sino simplemente un nuevo planteamiento en la forma de hacer las cosas, gracias a la experiencia adquirida.
Sin duda alguna los estándares web han contribuido enormemente a hacer más fácil y sostenible la integración entre aplicaciones. Esperamos que está contribución se mantenga en el futuro y siga ayudándonos a lograr un mundo más integrado.