viernes, 16 de noviembre de 2012

Arquitectura - ¿Afectada por la tecnología?

¿La arquitectura se ve afectada por la tecnología de implementación?

"Lo mas importante es satisfacer al negocio por encima de la tecnología pero esto depende del entendimiento de la tecnología que se pretende poner al servicio del negocio.".

El rol de arquitecto de software ha cobrado mucha fuerza en los últimos años y al día de hoy no podría encontrar una frase que lo defina unívocamente. De hecho con el tiempo se ha desvirtuado poco a poco hasta convertirse en un simple punto mas de toma de decisiones burocráticas alejadas de la realidad y difíciles de implementar. He aquí el nacimiento del Ivory Tower Architect.

Es difícil no dejarse contaminar con el ambiente y por esto les comparto mi experiencia como Ivory Tower Architect en un proyecto de la vida real. Afortunadamente evidenciamos el gran error a tiempo y por eso no fue tan costoso.

Mi experiencia en desarollo de software se sustentaba solo en aplicaciones WEB, JAVA y JEE.

El reto ahora era diferente. Necesitábamos construir una aplicación que sería ejecutada en el computador de escritorio de cada persona. Adicional a esto se requería un nivel gráfico muy alto porque uno de los objetivos era generar una muy buena experiencia al usuario.

Mi responsabilidad inicialmente era realizar una investigación sobre las tecnologías existentes en el mercado y que nos pudiesen apoyar en la realización de este trabajo. Pasé por muchas herramientas RIA: Silverligth de Microsoft, Java Fx de Oracle, y Flex de Adobe. Después de discutir las ventajas y desventajas de cada una de ellas la seleccionada fue Flex.

Decidimos entonces realizar una prueba de concepto de modo que pudiésemos determinar que tantas facilidades ofrecía la plataforma en torno a incrementar la velocidad de programación. Las conclusiones fueron bastante positivas de modo que finalmente esta fue la opción seleccionada para el proyecto.

Acto seguido se realizó el diseño de la arquitectura. Decidimos tener un híbrido: JEE para la Back End y Flex para el Front End. El mecanismo de integración sería a través de servicios web. El diseño para el Front End fue el siguiente:


Diseño inicial de la aplicación FLEX.
La idea era que las pantallas estuvieran en el componente "forms", los cuales accederían a los servicios de datos a través de las interfaces definidas en el componente "datarepositories" (Estos actuarían de forma similar a como lo hacen los Delegate en JEE), cualquier evento que se ejecutara en el formulario se realizaría a través de una acción definida dentro del componente "actions", las validaciones en pantalla se realizarían a través de "validations" y en caso de que se requiriera consultar información para completarla, se debería usar un data repository.

Hasta aquí todo perfecto. Una arquitectura que aparentemente satisface las necesidades y en teoría fácil de implementar.

Tiempo después llegó el desarollo de la primera funcionalidad. Como asumimos que los data repository nos abstraerían de los servicios de datos decidimos Mockearlos y trabajar sin la implementación de estos. El desarrollo en el Front end se completó e inició la construcción de los servicios de datos y la integración.


No contamos con que la ejecución de los servicios web en Flex se realiza de forma asíncrona. Esto significa que desde los componentes "actions", "forms" o "validations", no podríamos obtener una respuesta haciendo el llamado a un método de un data repository puesto que la arquitectura de esta tecnología plantea que la respuesta se reciba en un método a través de callBack.

En este punto fue necesario re diseñar y cambiar la implementación de todo lo construido en el Front End. Ahora tenemos el siguiente diseño. 

Nuevo diseño de aplicación FLEX

Los formularios realizan el llamado directo a los servicios y reciben el callback con la respuesta. Si se requieren validaciones que usen servicios de datos entonces primero se llama al servicio y luego se ejecuta la validación (En el callback).

La alternativa inicial de diseño fue radicalmente diferente. De hecho durante varias horas intentamos implementar tal y como se había definido al inicio pero la especificación de Flex lo hacía imposible, en todos los foros muchas personas preguntaban cosas similares y la respuesta siempre era la misma. Flex es asíncrono en la ejecución de servicios de datos y no hay nada que hacer.

Siempre he defendido mi posición en torno a que la tecnología es lo menos importante en el diseño de una arquitectura. Hoy replanteo esta afirmación de la siguiente manera: 

"Lo mas importante es satisfacer al negocio por encima de la tecnología pero esto depende del entendimiento de la tecnología que se pretende poner al servicio del negocio.".

Ahora valoro mucho uno de los principios que plantean las metodologías ágiles: "Los mejores diseños salen de equipos auto dirigidos"

Y un concejo: Si no sabe mejor reserve su opinión, investigue, implemente, aprenda y luego hable.



1 comentario:

Yeison R dijo...

Me parece que muchas veces nos equivocamos al escoger un tipo de tecnología y creo que es mas por desconocimiento de las características propias de los que elegimos, en este caso el haber desconocido algo esencial en como trabaja Flex.

Saludos buen articulo