Interoperabilidad, no negociable

Hoy en día, en cualquier organización medianamente compleja es raro encontrar que el sistema de información se limite a una única solución, por buena y completa que sea. Es normal tener que lidiar con:

• Sistemas anteriores (legacy systems)
• Soluciones de nicho o especializadas, incluso diseñadas y desarrolladas in-house
• Soluciones integradas con maquinaria o línea de logística

Además de esto, es posible que incluso teniendo una buena solución core e incluso ampliable, como Microsoft Dynamics Ax, sea conveniente desarrollar o integrar soluciones satélites, en vez de desarrollarlas dentro del sistema. Esta decisión de arquitectura puede fundamentarse fácilmente en:

• La tecnología a emplear. Puede ser más fácil / rápido / barato hacer cierto tipo de soluciones en plataformas distintas a la proporcionada por el sistema core.
• La ubicación y dispositivo del usuario. Si el usuario trabaja de forma remota, quizás una solución 3 capas con trabajo semi-desconectado sea más conveniente y eficiente. Por otro lado si el usuario no usa sistemas compatibles con nuestro core, no tendremos más remedio que realizar una solución externa. Se podría alegar que con soluciones de tipo Terminal, como Escritorio remoto o Citrix, se podría paliar también el problema, aunque de una forma poco amigable para el usuario.
• Los costes de licenciamiento y mantenimiento. Tampoco hemos de descuidar los costes asociados. Si tenemos cientos de usuarios que realizan tareas puntuales o acceden a información limitada, seguramente nos será más económico una solución externa pero bien relacionada con nuestro core, que la adquisición de esos cientos de licencias.

Por todo lo anterior, la interoperabilidad no es un concepto negociable. Gracias a ella, y con un diseño racional, podremos disponer de un sistema capaz de entenderse y hacerse entender con otros, evitándonos por tanto tener que reescribir lógica de negocio o duplicar datos en distintos sistemas.

Puede haber distintos grados de interoperabilidad, como por ejemplo:

1. Nivel 0. No es posible acceder al sistema ni a su información más que desde el propio sistema. Si te encuentras un sistema así y tienes que integrarlo, prepárate a remangarte, tener ideas muy imaginativas y sudar...no me gustaría estar en tu pellejo!
2. Nivel de datos. Somos capaces de acceder a la información, pero no a la lógica del sistema. Es un primer paso, podremos leer e introducir información, aunque las cautelas deben ser máximas ya que al hacerlo de forma externa podemos estar saltándonos las reglas de negocio de la solución y trabajar con información no coherente.
3. Nivel de librería. Disponemos de una API, DLL o similar que nos facilita el acceso a la lógica. Aquí las dificultades vienen cuando librería no ofrece toda la lógica que necesitamos, o bien la librería no corre sobre la plataforma que necesitamos que corra.
4. Nivel de servicio. Realmente este nivel es muy similar al anterior, salvo la limitación de plataforma. Los servicios están basados en estándares y por tanto debe ser operables desde distintas plataformas. La limitación que podemos seguir teniendo es la de que los servicios expuestos no cubran el 100% de nuestras necesidades.
5. Nivel de servicio extensible. Parte de la anterior, pero además el sistema ofrece la posibilidad de extender los servicios ofrecidos, eliminando por tanto la limitación anterior y haciendo por tanto que este caso sea perfecto de cara a la interoperabilidad.

Comentar, por clarificar, que los niveles anteriores no son excluyentes, y por tanto cuantos más y más altos cumpla nuestro sistema mejor será para comunicarse con posibles "vecinos" que conformen nuestro universo de soluciones empresariales.