Estrategia conservadora

Hace poco, entre un compañero que hace las tareas de asesor técnico de mis proyectos y que además colabora en la dirección de unos cuantos y yo, tuvimos que decidir qué tipo de solución dábamos a un proyecto, si la teóricamente perfecta o si aplicábamos una estrategia más conservadora.

El proyecto tiene como objetivo que a través de una aplicación web se puedan realizar consultas alfanuméricas, cartográficas y documental, en base a la información que se ha generado en diferentes sistemas de información (más de diez), residente dichos datos en organizaciones, formatos y tecnologías distintas, los cuales además pese a tratar una temática similar se han implementado, en la mayoría de los casos, como departamentos estanco.

La mejor solución, en un entorno de desarrollo y explotación de software de software ideal, sería captar la información en línea mediante servicios web de las distintas aplicaciones origen, cada vez que se realice una consulta. Sin embargo en un entorno tan heterogéneo como el que comento, en el que la información a consultar en cada sistema, puede ser abundante en función de la consulta que se realice y según el sistema que se consulta, en el que además es complicado controlar y conocer las modificaciones que pueden producirse en los modelos de datos de los sistemas fuentes de la información y en el que la predicibilidad de la disponibilidad de los sistemas es complicada, así como el comportamiento de la red, pensamos que una solución basada en servicios web, podría ser bastante arriesgada y corríamos el riesgo de que una vez implementada la solución, tal vez la mejor conceptualmente, tuviéramos que volver atrás ya sea por un mal rendimiento del sistema, por no asegurar un mínimo de disponibilidad de la información o por la suma de dichos factores y otros más.

Por este motivo tomamos la decisión de buscar una estrategia conservadora, basada en crear un repositorio central de información que persista la información de los sistemas origen que nos interesa, siendo el proceso de carga de datos orientado a la transacción (la carga de datos se hace completamente o no se hace) y orientado a las características de actualización de la información que se carga, es decir, no todas las fuentes de información cargarán información en el repositorio central en el mismo proceso, sino que las cargas se adaptarán a sus características. De esta forma, la complejidad será la misma que en la solución conceptualmente más aceptable en cuanto a que hay que recopilar la información de los sistemas de información origen, pero la persistencia de la información en una base de datos, reducirá hasta tender a cero los errores por no poder acceder a los datos (en todo caso se accedería a información menos actualizada) y por supuesto el rendimiento mejoraría, ya que la información se almacena en la base de datos central debidamente tratada y dispuesta para su consulta a través de la aplicación.

Ahora toca el proceso de implementación de la solución elegida. Esperamos haber tomado la decisión correcta.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: