El modelo de desarrollo “mete-saca”

Hace unas semanas mantenía una conversación muy interesante con parte del equipo de desarrollo acerca de la importancia de que nuestras aplicaciones fueran algo más que un “mete-saca” de datos. Y es que parece que en muchos ámbitos que siguen siendo totalmente data centric, el objetivo último de nuestras aplicaciones es la inserción o carga masiva de información con el único propósito de ser consultada por el usuario en monstruosos grids de datos o descargados en formatos de intercambio para su posterior gestión ofimática.

Si no tenemos cuidado, esta obsesión casi enfermiza de los usuarios por poseer los datos y tenerlos disponibles siempre en sus discos duros, puede provocar que las decisiones tomadas a nivel de UX y diseño de nuestros aplicativos no sean siempre los más adecuados.

Habitualmente, estas aplicaciones de “mete-saca” están soportadas sobre una base de datos centralizada y con unas dimensiones considerables. Los principales módulos de las aplicaciones interactuan entre ellos consultando directamente la información manejada por el resto de módulos o, en el mejor de los casos, a través de vistas de las mismas.

Es en este entorno clásico en el que, si alguna vez introducimos el concepto de SOA como patrón arquitectónico de diseño de aplicaciones, comienzan los recelos y podemos apreciar cláramente las debilidades del modelo “mete-saca”.

Algunas dudas totalmente lícitas en el ámbito que se producen, que pueden asaltar inicialmente al programador “mete-saca”:

Si el módulo de personas ya no está en la misma base de datos, como va el usuario a poder consultar los miles de registro que le permitimos cargar cuando gestiona sus facturas!!! Con servicios va a ser lento e ineficiente!!!

Otra preocupación similar puede ser:

Si luego necesito exportar todas las personas del sistema en excel, como voy a poderlo hacer el usuario sin que el ORM explote generando ese formato de salida.

Pues bien, todos estos requisitos impuestos por negocio y seguidos sin vacilar por los equipos de desarrollo de aplicaciones orientadas a datos, no son más que el resultado de realizar un esfuerzo titánico por implementar con herramientas del siglo XXI un modelo de hace veinte años.

Patrones como los grids de scroll live en nuestros frameworks SPI o interfaces diseñadas para que el usuario navegue entre miles de registros en este tipo de componentes, hacen que el valor que aporta nuestra aplicación tienda a cero patatero.

En su lugar, es momento de invertir nuestro tiempo de desarrollo en que el usuario pueda explotar búsquedas, generar sus propios filtros, hacer y deshacer acciones, recibir sugerencias o almacenar favoritos. Cualquier ventaja competitiva que implemente nuestra aplicación sobre un CRUD hará que el usuario ame sus herramientas, permitiéndonos dejar así de diseñar aplicativos que implementan modelos anémicos en lugar de estar implementando modelos ricos de interacción que puedan aportar un valor de negocio real.

Si no evolucionamos en nuestros modelos de comprensión del negocio y de sus necesidades, nuestro software nunca aportará un valor extra al mero propósito de la persistencia de datos para su explotación estadística. No solucionará problemas reales teniendo un valor diferenciador, quedando relegado como ahora podemos constatar en muchos casos, a un interfaz de usuario para una base de datos relacional que bien podría ser reemplazado por Microsoft Access.

¿Quieres seguir siendo un promotor del “mete-saca” o vas a comenzar a aportar valor de una vez?