En el siguiente trabajo se investigará sobre “arquitectura de software y agilidad”, tema designado a nuestro grupo. Este trabajo corresponde a la prueba número dos del curso “Tecnologías Computacionales e Informáticas”.

Nos enfocaremos principalmente en el artículo publicado por el Sr. Rodrigo Salinas, “Una nueva arquitectura”, el cual ha sido trabajo en clases. Trataremos temas como: cuál es la arquitectura correcta que debe tener un software, las buenas prácticas para realizar esto, hacia dónde va el enfoque hoy en día, entre otros. Con el objetivo de conocer y entender un poco más lo que realmente significa el término de “agilidad”, y su relevancia en la arquitectura de software, así como también mejorar nuestras capacidades al momento de enfrentarnos al desarrollo de algún software el día de mañana.

Una nueva arquitectura.

Este es el nombre de un artículo publicado por el Sr. Rodrigo Salinas, en el cual nos enfocamos principalmente para realizar nuestra investigación. Gracias al prestigio que este señor ha ganado con el tiempo está realizando constantemente capacitaciones sobre este tema, en el cual recalca como primer punto que no existe ninguna “nueva arquitectura”.

1- Nombres nuevos, conceptos antiguos.

Como se mencionaba anteriormente, no existe en realidad una “nueva arquitectura, lo que hay es simplemente una mayor claridad respecto de cómo aplicar correctamente conceptos teóricos que llevan por lo menos dos décadas tratando de imponerse en la mente de los profesionales informáticos, desgraciadamente aún no se logra comprender y aceptar de forma esperada estos nuevos conceptos.

Una arquitectura correcta de software debe “gritar” o hacer saltar a la vista su tema principal. El “plano” de cada sistema debe hacer que salte a la vista los elementos más importantes de sus casos de uso. Para lo cual debemos hacer uso de un lenguaje semántico adecuado, como DDD o UML por ejemplo, las principales entidades, junto con sus más importantes operaciones, estarían ubicadas dentro de un modelo que mostrara claramente su relación con el contexto donde existieran.

2- Qué no debería afectar tu arquitectura.

Lo primero que se debe tener claro es que lo más importante en cualquier proyecto de desarrollo de software es poder definirlo a un nivel de abstracción independiente de motores de bases de datos, de sistemas operativos, lenguajes de programación o frameworks. Ninguna de estas cosas debe de importar al momento de definir una arquitectura.

La tendencia natural de las personas que trabajan en el área de la informática es “enamorarse” de los frameworks, lenguajes, tecnologías y paradigmas. Aprendemos un conjuntos de herramientas con las que logramos tener un cierto éxito en algún proyecto, para luego, cuando se nos presenta un nuevo proyecto buscar hacer uso de las mismas herramientas una y otra vez. No obstante este no viene siendo el mayor problema, el problema es que tendemos a diseñar nuestras soluciones en función de dichas herramientas.

El enamoramiento tecnológico se produce principalmente por dos razones:

- Profesionales jóvenes descubren algún framework o herramienta que les permite crear todo aquello que no tenían idea de cómo hacerlo. Se descubren herramientas que nos permiten hacer todo más rápido, de forma más simple y con “buenos” resultados y se hace muy difícil mirar a otro lado.

- Profesionales con más experiencia se preocupan más por el resto del “ciclo de vida” de la aplicación. Se preocupan que vayan a encontrar, en el mercado, profesionales no muy costosos que puedan mantenerlas, de contar con empresas serias que entreguen un buen soporte. Por lo tanto se seleccionan herramientas ya probadas y que llevan más tiempo implementándose, ya que esto las hace más “confiables”

Lo que termina por ocurrir es que algunas de estas dos visiones mencionadas anteriormente terminan interponiéndose en el camino de la elección de la mejor arquitectura para el desarrollo del software.

3- Considera la historia.

La llegada del internet revoluciono a las empresas, estas empezaron a desarrollar una capa de aplicaciones para la web, con esto se llegaron a probar diversas tecnologías y técnicas hasta encontrar aquellas que más les acomodaban. Estas aplicaciones para la Web fueron, durante al menos los últimos 10 años, un mundo aparte dentro de TI en la mayoría de las empresas, no sintieron nunca que la Web en realidad les iba a tocar el core de sus aplicaciones ya existentes. Siguieron coexistiendo ambos mundos y evolucionando por separado.

4- Los nuevos clientes/usuarios y la transmedia.

Debemos ser capaces de entender que hoy en día los clientes ya se sienten usuarios y no solo simples clientes. Del mismo modo que años atrás se hizo evidente la necesidad de cada empresa por poseer un sitio en la Web, hoy es mal mirado el que alguna empresa no tenga aplicaciones de auto atención disponibles en la Web. Los clientes lo que quieren es ser usuarios de estas aplicaciones, quieren contar con funcionalidades de consulta de precios o de contratación de servicios o productos, quieren consultar estados de cuenta, quieren ver sus detalles de consumo, quieren pagar sus cuentas, quieren comprar y vender, quieren opinar, quieren consultar bases de datos de conocimiento para descubrir cómo resolver posibles problemas con los productos o servicios contratados. Estos nuevos clientes/usuarios quieren todos estos nuevos servicios disponibles en sus PC’s del trabajo, en sus casas, en sus plasmas y en sus dispositivos móviles. Lo quieren ahora y lo quieren ya.

La transmedia, según Martin Fowler, se refiere a la experiencia del usuario que hace uso de distintos dispositivos, en diferentes contextos, de una misma aplicaciones, ya sea un su escritorio, como en su Tablet o su Smartphone, estos deben ser capaces de proporcionar una experiencia similar con la aplicación, obviamente propias del contexto en el que se encuentre el usuario.

Tenemos hoy en día un cliente/usuario que quiere funcionalidad sobre la Web, que se le proporcione la sensación de “yo tengo el control”. Y en esto tiene razón, vivimos en un mundo globalizado y tecnológico, por lo tanto es justo esperar que los proveedores tradicionales se pongan a la altura de los tiempos modernos.

5- La arquitectura correcta.

Hoy en día podemos ver sitios Web con funcionalidad pobre e insuficiente, son lentos y a menudo se caen de las maneras menos elegantes posibles, esto debido a que si bien son conscientes de que necesitan de estas funcionalidades en sus Web, sucede que en ambiente de producción han descubierto de que no son capaces de ofrecer un nivel de desempeño aceptable.

Esto se debe a que su arquitectura modular se interpone como una gran limitante, se estima que durante los últimos 15 años se han venido desarrollando el software de negocios bajo premisas y prioridades equivocadas. Se han descuidado dos principios básicos para que una arquitectura sea verdaderamente escalable, fácilmente mantenible y altamente extensible.

a) Arquitectura armada a partir de bloques de abstracción adecuados: Hasta hoy en día la abstracción que más se maneja en la mayoría de las empresas es la DATA, y es un error que la DATA sea el centro del universo.

Ni muy cerca de la DATA: La lógica de negocios muchas veces se ejecuta en el lugar más rápido pero a su vez el menos escalable de todos, el servidor de la Base de Datos. El gran problema de estas BD relacionales es que estas no son capaces de sacarle provecho a la escalabilidad horizontal, y hoy en día se sufren las consecuencias, de toda esa cantidad de información que se ha almacenado por años en las maquinas encargadas de las BD, constantemente se tiene que estar invirtiendo en servidores capaces de atender un nivel de demanda altísimo, y en ocasiones, con poco éxito.

Si sabemos que nuestros servidores de BD son limitados, deberíamos estar preocupados de quitarles responsabilidad, pero ¿qué hacemos entonces con la lógica de negocios?, ¿Dónde la llevamos? Debemos llevarlas a modelos de dominio que pueden ser ejecutados en forma distribuida y replicada en granjas de servidores o Clouds de máquinas baratas y fácilmente administrables.

Ni muy cerca del usuario: No debemos de situar la lógica del negocio en el mismo frontend de las aplicaciones, ni tampoco repetir una y otra vez la lógica del dominio en incontables lugares. Esto puede llevar a la sobre exigencia de una máquina y, en otros casos, se dificulta la mantenibilidad de las reglas del negocio. Cuando TI teme realizar cambios debido a que no conoce los reales impactos, quien sufre es el negocio directamente ya que no cuenta con la versatilidad necesaria para mantenerse en el mundo competitivo en el que nos encontramos hoy.

Entonces ¿Cuál debería ser nuestro centro del universo? Existe un nivel de abstracción mucho más útil, escalable, extensible y reutilizable que tan solo tablas y procedimientos almacenados. Es la abstracción de entidades junto a la lógica encapsulada en ellas, el conjunto de estas abstracciones se conoce como “Modelo del Dominio”, este es un concepto antiguo, pero aun no nos acostumbramos realmente a trabajar a este nivel de abstracción a escala corporativa.

Domain-Driven Desing: Hoy en día es el approach a la Ingeniería de Software que mejor guía ofrece respecto de cómo representar el conjunto completo de sistemas computacionales en una empresa, bajo un modelo de abstracción orientado a las principales entidades y contextos de un dominio.

b) Conceptual y tecnológicamente independiente: Ya vimos que una arquitectura correcta se arma a partir de bloques de abstracción adecuados. El segundo principio básico a cumplir es el desacoplamiento conceptual y tecnológico de nuestra Arquitectura. Los aspectos fundamentales que debe proporcionar un estilo de arquitectura son los siguientes:

- Independiente de frameworks.

- Testeable.

-Independiente de la interfaz de usuario.

-Independiente de la base de datos.

Cabe recalcar de entre todos estos aspectos fundamentales, la importancia de diseñar y construir unidades de software en conjunto con test unitarios automatizados que las ejecuten.

Arquitectura orientada a servicio de cliente (SOA).

Primero que todo ¿Qué es SOA?: Es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio.

Permite la creación de sistemas de información altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma bien definida de exposición e invocación de servicios (comúnmente pero no exclusivamente servicios web), lo cual facilita la interacción entre diferentes sistemas propios o de terceros.

Al contrario de las arquitecturas orientado a objetos, las SOAs están formadas por servicios de aplicación débilmente acoplados y altamente interoperables. Para comunicarse entre sí, estos servicios se basan en una definición formal independiente de la plataforma subyacente y del lenguaje de programación. La definición de la interfaz encapsula (oculta) las particularidades de una implementación, lo que la hace independiente del fabricante, del lenguaje de programación o de la tecnología de desarrollo (como Plataforma Java o Microsoft .NET). Con esta arquitectura, se pretende que los componentes de software desarrollados sean muy reutilizables, ya que la interfaz se define siguiendo un estándar; así, un servicio C# podría ser usado por una aplicación Java. En este sentido, ciertos autores definen SOA como una Súper-Abstracción.

Cuando los profesionales de la informática se dieron cuenta de que los mundos del Backoffice y la Web debían comunicarse, empezó la fiebre de SOA. De hecho casi todo el mundo vivió prácticamente lo mismo:

Partieron implementando los populares Web Services SOAP (Simple Object Access Protocol). Esta tecnología les permitió a todos rápidamente hacer que sus mundos interoperaran. Como suele pasar a toda solución simple y económica, evidentemente abusamos de ella. Al poco tiempo pulularon por todas partes estor servicio y se perdió su control. Muchos ya no sabían que realmente hacia un determinado servicio o como reutilizarlo.

La preocupación general ahora paso a ser la gubernabilidad de los servicios (SOA Governance). Como administrar sus ciclos de vida desde un único lugar. Todos empezaron a mirar a los Enterprise Service Buses de IBM, Oracle y en unos cuantos casos a Microsoft como la solución a todos sus problemas, de alguna u otra manera las empresas lograron controlar sus Web Services.

No obstante superados estos problemas, apareció uno mucho mayor, que las demandas de los clientes estaban en alza respecto a este tema, lo que tratamos anteriormente en el punto “Los nuevos clientes/usuarios y la transmedia”.

Arquitectura y agilidad.

No podemos hablar de Arquitectura de Software Corporativo hoy en día sin explicar su relación con el Movimiento Ágil. Una de las personas no informáticas que más ha influenciado el actual pensar de la Ingeniería de Software, o del diseño en general, es Christopher Alexander. Él ha propuesta teorías originales aplicables al diseño y a la arquitectura. Las ideas de este arquitecto civil austriaco han proporcionado un fundamento teórico potente para nuevas prácticas relacionadas con la construcción de software. A diferencia de las metodologías tradicionales donde el software es diseñado completo al principio, para luego ser construido a partir de la documentación del diseño, estas nuevas prácticas apuntan a ciclos incrementales, orgánicos y coherentes de construcción de software, con una fase de diseño por cada una de estas iteraciones. Debemos ser capaces de diferenciar entre un diseño incremental versus uno iterativo.

El movimiento ágil ha transformado completamente la manera de hacer Arquitectura de Software, este movimiento no ha eliminado el diseño, lo que ha eliminado es la ilusión de que es posible diseñar completamente un sistema antes de empezar su construcción. La arquitectura ya no es una especificación a priori, sino una visión de un estado futuro del sistema.

Esta nueva visión sirve de guía para cada iteración de diseño-construcción-entrega. Se habla de iteración porque, especialmente en un sistema complejo, no es práctico pretender realizar un único salto desde el estado inicial hacia el estado final deseado. Debe haber pasos o estados intermedios pequeños pero completos a la vez. En cada uno de estos pasos o ciclos se añade al sistema funcionalidad útil y verificable por el usuario, al empezar el siguiente ciclo, diseñaremos a partir de lo anterior que construimos, tomando en consideración las lecciones aprendidas, realizando los ajustes necesarios, pero jamás olvidando la visión que nos proporciona la Arquitectura del Sistema que nos dice hacia donde nos dirigimos.

El diseño evolutivo, cuando es enmarcado en una estricta disciplina y es realizado por todo el equipo de desarrollo e conjunto con testers y usuarios, produce éxito.

Agilidad en las empresas.

Los críticos del desarrollo ágil suelen tener la opinión que enfoques iterativos como Scrum no pueden ser aplicados a grandes empresas, pues consideran que los proyectos de software de estas requieren de cientos de personas que sólo pueden gestionarse en una estructura jerárquica centralizada.

Sin embargo, a pesar de esta opinión existen ejemplos de grandes empresas que han aplicado con éxito la agilidad, uno de esos casos es el de Amazon.com

Amazon comenzó como una sola aplicación comunicándose con un Backend, pero eventualmente creció hasta convertirse en una plataforma de servicios totalmente distribuida y centralizada, prestando servicios a diferentes aplicaciones.

Hoy en día, la arquitectura de Amazon tiene bajo grado de acoplamiento y está construida alrededor de servicios. Está arquitectura orientada a servicios es la que les permite construir muchos componentes de software, de forma rápida e independiente.

La arquitectura de Amazon ha crecido hasta tener cientos de servicios y múltiples servidores de aplicaciones. Estos servidores de aplicaciones son los que proporcionan estos servicios. Por ejemplo, la aplicación que presenta la página Amazon.com es uno de esos servidores de aplicaciones. Asimismo, existen otros servidores, específicamente: Servidores para interfaces de servicios web (Web Servers), la aplicación de servicio al cliente y la interfaz para vendedores.

Conclusiones.

Para todo lo que tenga que ver con el Software Estratégico de una compañía, aquel que soporta las funciones de negocio que la diferencian de su competencia, es imprescindible que desde ya esa empresa, si pretende ser líder en su rubro de aquí a 5 años, esté invirtiendo en evolucionar su Arquitectura actual hacia lo que hemos definido en este post como una Arquitectura Correcta.

Correcta no desde el punto de vista académico solamente, no por moda o por capricho, sino por los evidentes beneficios prácticos que he intentado explicar brevemente en este post: mejorar el desempeño al aprovechar el escalamiento horizontal (más máquinas pero a la vez más económicas), reducir costos al desarrollar y mantener los sistemas (modelos de dominio centralizados más simples de modificar y extender) y facilitar la implementación de nueva funcionalidad al separar responsabilidades en el software a nivel corporativo.

Todo esto sin olvidar que la Arquitectura no es una especificación congelada sino una Visión que evoluciona en el tiempo, con la participación colectiva de todas las personas involucradas en los procesos del negocio: desarrolladores, testers, ejecutivos y usuarios. Todos trabajando para la felicidad de estos últimos.

Propuestas de Preguntas.

1) ¿Cuál es el rol del arquitecto de software, en agilidad?

R: Dentro de la agilidad este rol se pierde un poco, ya que el equipo completo debe estar integrado dentro de este proceso, aportando ideas y mejoras en la App. Deben aportar con nuevas tecnologías que permiten la escalabilidad de la aplicación y la fácil integración de nuevos cambios dentro del software, sin la necesidad de hacer refactorización, lo que puede resultar costoso.

2) ¿Es necesario “inventar” una arquitectura de software nueva para cada sistema de información?

R: No, lo habitual es adoptar una arquitectura conocida en función de sus ventajas e inconvenientes para cada caso en concreto. Dado esto existen ciertas arquitecturas universales como: Cliente-servidor, modelo vista y controlador, arquitectura de tres niveles, entre otras.

3) ¿SOA es lo mismo que Cloud Computing?

R: Aunque hay algunas ideas que subyacen en la definición de ambos términos, como el uso del concepto de servicio o la idea de la independencia de localización de los mismos, queda claro que los ámbitos de aplicación son distintos, relacionándose SOA con el ámbito del desarrollo de aplicaciones TI con claro significado de negocio, mientras que Cloud se refiere más a la forma de ofertar recursos TI a cliente final, a su entrega, provisión, y posterior gestión y operación.