Buscando una arquitectura preparada para hacerse mayor.

Así­ como en el post anterior estuvimos hablando de qué tecnologí­a web debemos elegir a la hora de comenzar un proyecto, hoy vamos a hacer algo similar pero a la hora de elegir una arquitectura.
Vamos a poner varias restricciones al proyecto para hacerlo algo más real y voy a intentaros contar lo que a mi parecer serí­a la mejor solución al problema.
Pongamos que tenemos una aplicación de escritorio la cual queremos migrar a las íºltimas tecnologí­as del momento. Nuestra aplicación se nos ha quedado algo antigua y ya no queremos invertir más pasta en su mantenimiento, así­ que hemos decidido ponernos manos a la obra y buscar una solución arquitectónica adecuada a la información con la que contamos actualmente.
Nuestra aplicación de escritorio sigue al pie de la letra una arquitectura cliente-servidor, donde tenemos una base de datos central, ubicada en un servidor remoto a la cual conectamos para realizar transacciones centralizadas. Además, tenemos la posibilidad de en un momento dado, por una caida del servicio central, trabajar con varios módulos de la aplicación de forma local (almacenamos la información que gestionamos en una base de datos local y al recuperarse la conexión podremos volcar nuestros cambios a la base de datos central). Además, nuestra aplicación contiene toda la lógica de negocio, por lo que ante cualquier necesidad de actualización del mismo, debemos compilar nuevamente y distribuirla a todos nuestros clientes.
Incorporo un pequeño esquema para que os hagáis un poco más a la idea de todo.
Cliente-Servidor
Bien, pues entonces, entre las primeras posibilidades que tenemos para renovar la aplicación es mantener la misma arquitectura, coger su código que estaba programado en Pepito.CHUF versión 2.0 y reprogramar todo internamente mediante la versión 7.0 de Pepito.CHUF. Seguramente nos vamos a dar bastante prisa. Formulario a formulario, despacito y con buena letra al final podemos obtener algo muy similar. Y si encima de paso lavamos la cara un poco a la presentación, pues oye, el cliente más contento que chuflainas porque le da la sensación que tiene una aplicación íºltimo modelo de la tecnologí­a.
El artí­culo parece que se va a quedar aquí­, pero vamos a darle un poco de emoción a la cosa y vamos a pensar que nos llegan ecos de que parte de la aplicación deberí­a ser accesible a través de web. Menudo problema ya que si necesitamos trabajar puntualmente de forma desconectada… vamos a necesitar obligatoriamente tener parte web y parte escritorio. De todas maneras todo esto son rumores, y como nosotros tenemos bastante prisa para desarrollar todo esto, tal vez lo mejor que podamos hacer es tirar todo para escritorio, pero, cubriéndonos un poco las espaldas con la arquitectura, preparándola para hacerse algo mayor si más adelante se requiriera. Además, de paso, vamos a dar otro gran salto de arquitectura, sacando todo el modelo de negocio de la propia aplicación fuera de ella.
A continuación otra foto para que os hagáis un poco más a la idea.
 Extrayendo modelo de negocio
Como véis entre la base de datos y la aplicación cliente hemos colocado un servidor de aplicaciones con servicios web. 
¿Ventajas? Pues unas cuantas, ante cualquier cambio de modelo de negocio no vamos a necesitar actualizar las aplicaciones cliente, haremos el cambio en el servicio web y listo. Pero la ventaja más gorda es que estamos preparados para crecer en cualquier momento y hacer accesible nuestro modelo de negocio a cualquier tipo de dispositivo y/o tecnologí­a.
Por ejemplo, si mañana, o pasado queremos implantar alguno de los módulos de la aplicación a través de web (por ejemplo el módulo de administración), seguramente tendremos ya tres cuartos del trabajo hecho, y íºnicamente deberemos crear una nueva capa de presentación, pero esta vez web.
íšltima foto, esta vez la definitiva.
Arquitectura Orientada a Servicios
Como véis, añadiendo una aplicación web en otro servidor web ya disponemos de una capa de presentación web, la cual conecta con el mismo servidor de servicios web con el que sigue trabajando la aplicación de escritorio. Qué bien, nos hemos evitado tener que duplicar el modelo de negocio para trasladarlo a la web. Y además, por cierto, como podéis ver, la cosa ha evolucionado hasta el punto que alguno de los operadores de la aplicación es capaz también de acceder a la misma a través de un dispositivo móvil. ¿Cuál ha sido el esfuerzo de desarrollo para esto íºltimo? Pues crear la capa de presentación del dispositivo móvil, punto y final.
¿Os hacéis a la idea del esfuerzo que requirirí­a disponer de acceso independientemente del dispositivo si hubiéramos mantenido la misma arquitectura de la aplicación inicial? Y por cierto, por ahora íºnicamente hemos hablado de arquitectura y no de plataforma… mediante esta solución nuestra aplicación web podrí­a estar hecha en JSP+STRUTS, mis servicios web en PHP, mi aplicación de escritorio en .NET y nuestra base de datos… pues la que más os guste. ¿Lo veis posible mediante la primera arquitectura?
Como véis, la idea feliz de todo esto ha sido que en un momento que existí­a cierta incertidumbre hemos invertido algo más en arquitectura, y esto nos ha permitido que la aplicación sepa hacerse mayor con un esfuerzo muy inferior.
Saludos.
Miguel.