Convergencia de Información

En O'Lach vemos la convergencia de información como la única forma válida de propiciar un espacio común para la integración de herramientas desarrolladas por distintos proveedores, unificando la información común a las mismas, por ejemplo, los datos básios de las Organizaciones y sus contactos, en una única base de datos; sin intervenir en el resto de las reglas de negocio específicas de los otros sistemas.

Para ello partimos del concepto que un sistema de estas características debe propender a compartir información y no meras colecciones de datos.

En esta concepción definimos “información” como un conjunto organizado de datos procesados, que constituyen un mensaje, íntimamente relacionado con lo que el usuario o la tarea requieren.

A lo largo de casi dos décadas hemos observado (y tenido que lidiar con) numerosos casos en los que el intercambio de información entre sistemas era dificultado por la arquitectura utilizada en el diseño de las mismas, limitando las operaciones de intercambio a transacciones SQL y procedimientos almacenados, a las que se accedías mediante conectores de datos .

Esta situación obliga a los desarrolladores a un examen exhaustivo de diccionario de datos (cuando este existe) a la vez que exigen al cliente de la aplicación (Capa de presentación) muchos más controles lógicos, de negocio y de consistencia y la habilidad de reinterpretar los conjuntos de datos recibidos para convertirlos en información útil.

Este esquema hace inviable que varias interfaces cliente (capas de presentación) puedan ser desarrolladas y mantenidas a lo largo del tiempo por proveedores independientes entre sí, con un costo total de la propiedad razonable para la organización. Todo ello nos ha llevado, hace ya más de 15 años, a abandonar del paradigma Cliente – Servidor original para pasar a utilizar una arquitectura de n-Capas (n-tier).

Arquitectura n-Capas

Los sistemas de esta aruitectura distinguen al menos 3 capas: Datos, Reglas de Negocio o Intermedia y Capa de presentación (o Cliente o Interfaz de Usuario (UI)).

Las dos primeras capas, Datos y Reglas de negocio se agrupan normalmente en lo que se denomina “Lado Servidor” o “Capas superiores” y, normalmente, se utiliza un único equipo servidor para concentrar estas capas superiores .

Si bien el desarrollo en esta arquitectura parece en principio ser más oneroso , la experiencia demuestra que a partir de un adecuado diseño de la estructura de datos y una buena planificación de la constelación de objetos, pueden lograrse tiempos de primer desarrollo cercanos a los obtenidos con las mejores herramientas para desarrollo en arquitecturas cliente-servidor y que en instancias posteriores (Up-sizing, mejoras y mantenimientos) el costo pasa a ser algo inferior.

Desde el punto de vista de la organización adquirente, los costos totales de propiedad disminuyen significativamente, ya que se requiere menos poder de hardware tanto en el servidor como en los equipos cliente a la vez que posibilita la partición de los proyectos sin que se generen “rastros geológicos”.

Para los equipos de desarrollo también se facilitan las cosas porque en este esquema no necesitan estar al tanto de cada cambio en la capa de datos ya que las devoluciones de los distintos métodos pueden mantenerse a lo largo del tiempo más allá de las modificaciones que se efectúen en la estructura de datos. Dicho de otra forma, la capa intermedia o de reglas de Negocio “absorbe” los impactos de las modificaciones de la capa de datos.

En cuanto a la performance, en un sentido universal y sin tener en cuenta los lenguajes utilizados, el uso de 3-capas debiera ser algo mayor dado que si bien por un lado se agrega una instancia de procesamiento, por otro se simplifican las consultas a la base datos y también la reorganización de los mismos que se efectúa en el equipo cliente . En definitiva se trata de dejar hacer a la base de datos sólo lo que mejor hace, y utilizar un leguaje más competente para las operaciones de conformación de información.