archivo

Archivo de la etiqueta: sistemas configurables

Si un usuario tiene dudas sobre el comportamiento de una funcionalidad y prevé la evolución de la misma en un futuro y no se sabe a ciencia cierta si se van a disponer de recursos en un futuro para poder realizar los cambios, nos encontramos ante una situación candidata a aplicar una solución configurable (teniendo en cuenta que tampoco podemos hacer magia y que el número de opciones de configuración serán limitadas).

Por ejemplo, recuerdo hace tiempo un sistema donde a una entidad se le podían asociar determinados tipos de características. Cada vez que repasábamos con el usuario la pantalla principal en la que se trabajaba con esa entidad incluía y eliminaba nuevas características, lo que provocaba que continuamente se tuviera que estar modificando el modelo de datos. También nos comentó que independientemente de las características que se terminaran incluyendo en un futuro les podría resultar interesante incluir nuevas relaciones. ¿Qué solución le dimos? Implementar las características asociada a la entidad como un casilla/valor. En ese momento terminaron los problemas. ¿Es la solución más elegante? No, ¿es la más académica? No, pero fue realmente práctica y efectiva.

Tenemos los extremos de tener sistemas absolutamente cerrados y tener sistemas totalmente configurables. ¿Qué extremo es el más válido? Dependerá, como es lógico, del sistema de información que se desarrolla.

Si hablamos en términos generales, un sistema totalmente cerrado, sin posibilidad de configurar nada, requiere cambios en el código para realizar cualquier tipo de modificación. En mi opinión, este comportamiento no es deseable.

Por otro lado, un sistema totalmente configurable requiere un nivel muy importante de su abstracción en su desarrollo y la definición de modelos de datos generalistas. Esto requiere un coste adicional y puede dar lugar a dificultades con la explotación de la información y el rendimiento. También, si son muchas las opciones de configuración el usuario puede perderse en ellas.

Configurable es que el comportamiento de determinadas funcionalidades, la realización de determinados cálculos o la aplicación de determinadas restricciones varíe en tiempo de ejecución (o en tiempo de arranque del servidor) pero va más allá de eso, ya que configurable también es la posibilidad de poder actualizar manualmente (sin entrar directamente en las tablas de la base de datos) los valores de las tablas maestras o de determinados parámetros. Esto que parece obvio no lo es tanto cuando ves incrustados en el código determinados dominios de datos o se le impide al usuario modificar valores de una tabla maestra.

Pese a que los generadores de código prácticamente te ahorran el tiempo de desarrollo (o buena parte de él) de la gestión CRUD existe mucha pereza en los desarrolladores a dedicarle tiempo a esto: “Total, siempre existe la posibilidad de hacerlo directamente a través de base de datos”. ¿Qué pasa después? Pues que podemos tener un sistema con doscientas tablas y un montón de ficheros de configuración y a ver quién mantiene eso. Desde luego el usuario no, por lo que la responsabilidad recaerá en el departamento TIC, debiendo dedicar unos recursos a realizar estas tareas que con el paso del tiempo suponen un mayor coste del que hubieran tenido si las cosas se hubieran hecho bien desde un principio.