ARQUITECTURA ÁGIL

Arquitectura Informática

La arquitectura ágil significa cómo los arquitectos de empresas / sistemas / software aplican la
práctica arquitectónica en el desarrollo de software ágil. Varios comentaristas han identificado
una tensión entre la arquitectura de software tradicional y los métodos ágiles a lo largo del eje
de adaptación (dejando las decisiones arquitectónicas hasta el último momento posible) frente
a la anticipación (planificación por adelantado). (Kruchten, 2010)

Waterman, Nobel y Allan (2015) exploraron las tensiones entre pasar muy poco tiempo
diseñando una arquitectura inicial, aumentando el riesgo y gastando demasiado tiempo, lo que
tiene un impacto negativo en la entrega de valor al cliente. Identifican seis fuerzas que pueden
afectar la arquitectura ágil: inestabilidad de los requisitos, riesgo técnico, valor inicial, cultura
de equipo, agilidad del cliente y experiencia. Estas fuerzas pueden abordarse mediante seis
estrategias; Responda al cambio, aborde el riesgo, la arquitectura emergente, el gran diseño
por adelantado y utilice marcos y arquitecturas de plantillas.

Se han realizado varios intentos para especificar qué constituye un enfoque ágil de la
arquitectura. Según el marco SAFe, los principios de la arquitectura ágil son:

El diseño emerge. La arquitectura es una colaboración. (arquitectura intencional)

Cuanto más grande es el sistema, más larga es la pista (pista arquitectónica)

Construya la arquitectura más simple que pueda funcionar (principios de diseño establecidos)

En caso de duda, codifíquelo o modelélo (picos, prototipo, dominio y modelos de casos de uso)

Lo construyen, lo prueban (diseño para la capacidad de prueba)

No existe el monopolio de la innovación (equipos, hackatones): el botón Me gusta de

Facebook se concibió como parte de un hackathon

Implementar el flujo arquitectónico (epopeyas arquitectónicas y la cartera kanban): la cartera

Kanban pasa por el embudo, la revisión, el análisis, la cartera de pedidos pendientes y la
implementación

En el nivel de Arquitectura Empresarial, Scott Ambler (2016) propone los siguientes principios

Colaboración evolutiva sobre blueprinting

Comunicación sobre la perfección

Participación activa de los interesados

Los arquitectos de la empresa son participantes activos en los equipos de desarrollo

Habilitación sobre inspección (ejemplos)

Modelos de alto nivel (cuanto más complejo, más abstracto)

Capturar detalles con código de trabajo

Orientación y reglas magras, no procedimientos burocráticos

Tener un equipo dedicado de arquitectos empresariales experimentados

Introducción
Desde sus comienzos a esta parte, las metodologías ágiles han logrado una gran conjunto de
adeptos. Hoy en día, una considerable cantidad de proyectos se desarrollan siguiendo algún
tipo de metodología ágil y una proporción muy grande de las que no utilizan una metodología
ágil formal, sigue, al menos, lineamientos e ideas provenientes de éstas. Incluso algunas
metodologías consideradas poco ágiles, como RUP, ensayan nuevas aproximaciones que las
hagan ver “más ágiles”. Varios ejemplos y referencias pueden encontrarse en {28} En este
contexto, la Arquitectura de Software como práctica de diseño no parece ser tratada con el
detenimiento que se merece. Prueba de ello es la escasa información disponible sobre esta
práctica en la documentación de las distintas metodologías ágiles. Otro factor de influencia, es
la falta de documentación estandarizada; hoy por hoy, no existe un lenguaje DDL estándar para
definir arquitecturas. Esto implica que no existe un formalismo estándar, como son los
diagramas de clases de UML, para documentar arquitecturas. En estos momentos, UML aún no
decidió cuál será, de los muchos lenguajes DDL existentes, el que se incluya en sus futuras
versiones. Creemos que el hecho de no tener debidamente en cuenta la Arquitectura de
Software como un proceso en sí mismo, dentro de cualquier proceso de desarrollo de software,
repercute en proyectos más riesgosos, con tareas y asignaciones distribuidas de manera
incorrecta y, por sobre todas las cosas, se evidencia en la calidad final del producto

Metodologías ágiles
¿Qué es desarrollo de software ágil (Agile Software
Development)?
A finales de los 90, varias metodologías comenzaron a atraer la atención del público en
general. Cada una de estas metodologías era una combinación de ideas viejas, ideas nuevas, y
variaciones de ideas viejas. Pero todas tenían algo en común: enfatizaban la colaboración entre
equipos de programadores y expertos de negocio; promovían la comunicación cara a cara
(como una manera más eficiente que la documentación escrita); realizaban entregas frecuentes
de nueva funcionalidad de negocio; contaban con equipos de desarrollo auto organizados;
tenían maneras de estructurar código fuente y equipos de desarrollo con el fin de que los
requerimientos más importantes no entren en crisis. {18} A principios de 2001, los pioneros y
creadores de estas metodologías reunieron, en una figura única, todo lo que sus metodologías
tenían en común, utilizando el término “Ágil” como definición común a todas ellas. De esta
forma, crearon lo que acordaron se en llamar: el manifiesto para desarrollo de software ágil
{19}. Algunos de los principios más importantes definidos en este manifiesto son: {18}

1. Interacción personal de individuos por sobre los procesos y las herramientas

2. Trabajar con el código por sobre documentación escrita
3. Colaboración del cliente por sobre negociación de contratos
4. Responder al cambio antes que seguir y mantener un plan.

El término ‘ágil’ no describe una metodología particular, por el contrario, expresa la existencia
de una familia de metodologías, las cuales comparten las bases y lineamientos entre los que se
encuentran los enumerados anteriormente. Como ejemplo de metodología ágil, podemos citar,
entre muchas otras, a Scrum, ))Feature-Driven Development((, DSDM, Crystal, XP. {29, 30, 31,
32 y 6} respectivamente.

Las técnicas de diseño en las metodologías ágiles

Muchas de las críticas que reciben hoy día las metodologías ágiles tienen relación con la
aparente carencia de prácticas relacionadas con el diseño formal de la aplicación o, en el caso
de las metodologías que contemplan el diseño, su falta de formalismo en la especificación. {13}
Esta falta de formalismo se halla justificada, para algunos de los cultores de metodologías
ágiles, por el siguiente razonamiento: el diseño detallado lleva una inversión de tiempo
considerable en decisiones y aspectos, que son inciertos hasta el momento mismo en que se
presentan. {6} En otras palabras, podríamos decir que, tradicionalmente, el diseño trató de
anticipar al cambio, pero cuanto más tratemos de prever el cambio, más tiempo tomará el
diseño y habrá más clases en el modelo; lo que se traduce en un modelo más complejo para
mantener actualizado, con más líneas de código, y, lo que es peor, el hecho de que, al
producirse un cambio no previsto, quizás tenga que realizarse aún más trabajo que si no se
hubiese diseñado para el cambio. Por tal motivo, muchas de las metodologías ágiles proponen
realizar un diseño informal, en papel si es necesario. El diseño debe ser lo más sencillo posible.
Este estilo de prácticas es parte de algo que, en metodologías ágiles, se conoce con el título
de: “hacer todo lo posible por hacer lo menos posible” {5}

El código NO es el diseño
Debido a las fuertes críticas recibidas por la carencia de diseño formal, se han escrito algunas
contrapropuestas interesantes que defienden la postura de las metodologías ágiles. La mayoría
de las respuestas giran en torno al siguiente planteo, realizado por Fowler, el cual puede
encontrarse en {13}. El planteo dice lo siguiente: “¿Así que ha muerto el diseño? De ninguna
manera, pero la naturaleza del diseño ha cambiado. El diseño ágil busca las siguientes
habilidades:

1. Un deseo constante de mantener el código tan claro y simple como sea posible.
2. Habilidades de refactoración, para que puedas confiadamente hacer mejoras cuando
veas la necesidad.
3. Un buen conocimiento de patrones: no sólo las soluciones, sino también apreciar
cuándo usarlos y cuándo evolucionar hacia ellos.
4. Saber cómo comunicar el diseño a la gente que necesita entenderlo, usando código,
diagramas y, sobre todo, conversación”.

Otra justificación, un poco menos formal, pero aún así de amplia aceptación, es la siguiente: “el
código fuente es el diseño”{20}{21}. En ésta se argumenta lo siguiente: puede verse al código
fuente como el resultado final y visible del diseño, y en dónde quedan plasmados todos los
aspectos de éste. Esta idea, que es tomada de {21}, es llevada al extremo en algunas
metodologías ágiles, en donde el diseño no existe como etapa de desarrollo ni como generador
de algún artefacto formal. Sólo se tiene en cuenta como algo informal, útil para transmitir ideas
entre desarrolladores. La justificación es que con el refactoring continuo, el buen diseño se va
“encontrando” de a poco. Estas ideas definen la opinión sobre el diseño de muchas de las
metodologías ágiles y, sobre todo, de muchos de sus cultores. Si bien estas opiniones son un
tanto controversiales, es interesante rescatar su enfoque evolutivo, en contra de la postura
predictiva que tuvo históricamente el diseño.

Aprehendiendo y tomando ideas

El código no es el diseño, porque solamente nos muestra una vista de éste (la vista de código),
mientras también existe, entre otras, la dinámica. También hay varios modelos, por ejemplo: el
de componentes, el de análisis, el de casos de uso, etc. Decir que el código fuente es el diseño
es como decir que el edificio terminado es su diseño. Hay cosas que no pueden verse. La
sinergia que generan las partes como un todo evita ver ciertos aspectos (vistas y modelos); el
todo hace obtusa la visión, debido a la carencia de abstracción. Así como ver el ala de un ave
en movimiento no hace que se entienda cómo puede volar el ave, tampoco puede analizarse su
estructura interna o esqueleto. Necesitamos abstraernos del ser de plumas que vuela y analizar
su diseño; no se entiende la aerodinámica de las plumas, no se ve cómo están distribuidos los
músculos, no tenemos noción del aparato circulatorio. Es decir, no tenemos vistas. Algo similar
ocurre con el código fuente. Si bien podemos ver la estructura interna del código y extraer
información, no podemos ver la estructura interna de los componentes que usa, así como
tampoco nos es práctico extraer información a partir de la estructura. La abstracción es
necesaria para comprender el todo paulatinamente y de manera efectiva. Si a esto le sumamos
el factor comunicación con los stakeholders del proyecto, tema que será abordado más
adelante, la comunicación se vuelve aún más complicada, en vez de simplificarse. Es complejo
decirle a un gerente que mire el ave en el aire para entender por qué y cómo vuela el ave.

Existen posiciones extremas, en algunos casos extremistas y hasta obtusas, entre las que se
encuentran: por un lado, las metodologías ágiles, diciendo que el código fuente es el diseño y,
por otro, los puristas clásicos pregonando diseñar pensando en el cambio. A pesar de estas
posturas, rescatamos algunas ideas, las cuales serán tenidas en cuenta en lo que resta del
paper. Estas ideas son:

 no diseñar tanto para el cambio y sí tener en cuenta qué es necesario diseñar, cuándo
y en qué nivel de detalle,
 aceptar que los requerimientos cambian y manejarlo de la manera más ágil, siempre
dispuesto al cambio sin reticencia
 utilizar el enfoque iterativo e incremental, del cual se encuentran referencias en la
bibliografía desde el año 1977 (ver {10}).

Las prácticas de Arquitectura de Software, el diseño y

las metodologías ágiles
Definición de arquitectura
Se tomará como definición de Arquitectura de Software la siguiente, ya que consideramos que,
en la práctica, es la más útil de las múltiples definiciones de arquitectura existentes:

“La Arquitectura de Software de un programa o sistema es la estructura

o estructuras del sistema, la cual comprende los componentes de
software, las propiedades externas visibles de estos elementos y las
relaciones entre ellos” {11}. La definición de una arquitectura de software de
manera temprana en un proceso de desarrollo brindará, entre otros, los siguientes beneficios:
{11} Work break down: la separación y asignación de tareas de grupos de trabajo.
Principalmente, esto se debe a que, al identificarse los componentes principales de la
aplicación, se les pueden asignar grupos de trabajo. Facilita la estimación: permite estimar
componentes y conectores por separado, teniendo en cuenta, luego, tiempos de integración,
estabilización, etc. Look ahead: minimizar riesgos: Lidia con los requerimientos no funcionales:

El doble rol de la arquitectura en un desarrollo de software

A nuestro entender, la arquitectura juega un doble rol. Por un lado, contar con una arquitectura
sirve, al desarrollador o grupo de desarrolladores dedicados a un módulo, como contexto y
referencia. A la vez, define los lineamientos básicos del proyecto dando un marco de trabajo
fuerte, permitiendo el intercambio de profesionales entre grupos de trabajo y definiendo
estándares de trabajo, sin una sobrecarga de burocracia. Simultáneamente, lo que podría
considerarse sobrecarga de burocracia, debería quedar plasmado en documentos destinados a
la gerencia del proyecto. Estos documentos son requeridos por la gerencia en la mayoría de los
casos. En este trabajo, se propone realizar estos documentos en las etapas adecuadas del
proyecto y beneficiarse de contar con fuertes (fuerte no implica inflexible) lineamientos
arquitectónicos durante todo el desarrollo. Al tomar en cuenta los lineamientos de arquitectura,
el diseño interno del componente puede manejarse de manera ágil, dejando la especificación
formal (si la complejidad y/o el contexto de éste lo requiere) para el momento en que ésta sea
necesaria.

La arquitectura y su rol actual dentro de las metodologías

ágiles
Resulta difícil encontrar documentación sobre cómo definir una arquitectura en un proyecto de
desarrollo de software guiado por una metodología ágil. La documentación disponible en
muchos casos es sobre algunos lineamientos mínimos, como el caso de la noción de metáfora
de XP {6}. Originalmente, la arquitectura no era tenida en cuenta en las metodologías ágiles y,
si se consideraba, se lo hacía de un modo tangencial y superficial. Como ejemplo, podemos
citar el libro {6} de Kent Beck, en el cual se le dedican a la arquitectura tan sólo dos páginas.
Con el tiempo, el rol de la arquitectura como agente previsor y de orden fue surgiendo, en
varios trabajos, en metodologías ágiles; pero, en muchos casos, con un cierto desdén y amplia
diferenciación de lo que es en la actualidad el perfil de Arquitecto de Software.

Toda decisión en ingeniería de software implica un

compromiso (trade-off)
Los enfoques metodológicos ágiles pueden tender a crear una pequeña trampa. Ésta consiste
en agilizar de tal manera el desarrollo de un proyecto, que el proyecto en sí termina siendo una
suerte de refactoring continuo, en la que el control y estimación del mismo se vuelve caótico.
Podemos ilustrar esto mediante una analogía sencilla: supongamos un algoritmo que trabaja
por fuerza bruta. La lógica de este algoritmo funciona de la siguiente manera: éste va a avanzar
hasta descubrir una solución; chequea si la solución es óptima y, si no lo es, continúa buscando
la siguiente solución. Por otro lado, existen algoritmos que, si bien usan fuerza bruta, le brindan
información de contexto (local) y ofrecen visión a futuro, de manera de poder anticiparse y
llegar antes al objetivo deseado para hacer más ágil la búsqueda. Por ejemplo, teniendo en
cuenta información local, el algoritmo podría darse cuenta, a mitad de camino, que el camino
seleccionado no es el que busca y así comenzar a recorrer un nuevo camino (solución) antes
de llegar al final de ese. En estos casos, si se toma demasiada información de contexto,
pretendiendo saber demasiado sobre el futuro, el algoritmo puede ser más lento aún que el
algoritmo de fuerza bruta.

En la metáfora que planteamos, el camino que supone desarrollar el proyecto es el camino a

descubrir con el algoritmo. De hecho, el camino, en ambos casos, es desconocido, ya que no
sabremos sino hasta el final si las decisiones tomadas fueron las correctas. En eso se basan
buena parte de las suposiciones de las metodologías ágiles y tradicionales. El algoritmo es la
metodología a implementar. El algoritmo de fuerza bruta puro es una metodología ágil mal
aplicada, que no piensa ni mira más allá del módulo y que sólo tiene en cuenta información
local (relativa al módulo de un equipo de personas acotado) El algoritmo que trata de ver muy a
futuro es la típica sobre-especificación, donde se tiende cambiar la documentación de manera
continua y repetitiva, porque la misma documentación se repite.

El algoritmo de fuerza bruta con la heurística justa es el que utiliza información global, local y
que prevé el futuro, aunque sea a corto plazo. La heurística justa, sin duda, depende del
proyecto. Algunas ideas interesantes sobre adaptación de metodologías basadas en el tipo de
proyecto se pueden encontrar en {32}. Este tema tiene relación con la necesidad de brindar un
contexto a los trabajos de ingeniería de software basado en taxonomías de proyectos. {33} Con
la utilización de la arquitectura, buscamos definir una heurística -que debería ser adaptada
según la taxonomía del proyecto- que permita agilizar aún más la metodología en cuestión y
que aporte todos los beneficios, enumerados anteriormente, de la utilización de prácticas de
arquitectura en un proyecto de software.
Hacia un proceso de arquitectura de software ágil
La Arquitectura de Software puede y debe desempeñar un rol fundamental, en un escenario
donde el desarrollo de software tiende hacia formalización y automatización de procesos de
ingeniería, que brinden la seguridad y capacidad de predicción de otras disciplinas, como la
ingeniería civil. Sería de gran importancia contar con un proceso de Arquitectura de Software
capaz de acoplarse a cualquier metodología de desarrollo de software, en el que se distingan
claramente los beneficios de aplicarlo en cada etapa y las consecuencias de no tenerlo en
cuenta. Se plantean aquí algunos lineamientos y prácticas útiles para ser utilizados en
cualquier proceso de desarrollo de software, independientemente de la metodología utilizada.
Algunos de estos lineamientos son tomados de otros autores, en cuyo caso se hace referencia
a la fuente.

No jerarquizar el Rol
Ser arquitecto es sólo un Rol. Este rol puede ser desempeñado por cualquiera que tenga las
habilidades necesarias. Habría que considerar como muy importante no darle una concepción
divina al Rol. Quien lo desempeña no se encuentra en una posición superior, en el
organigrama, a ningún otro miembro del equipo.

Un solo arquitecto para definir la arquitectura

La arquitectura debe ser el producto de un arquitecto solamente, o de un pequeño grupo con
un único líder claramente identificado {11}. La arquitectura macro y en una concepción
abstracta debe, en lo posible, ser realizada por un solo arquitecto. Esto brinda una componente
ágil, evitando largas discusiones. El arquitecto debe, por su parte, compartir, delegar y
comunicar cuestiones de menor abstracción y puede apoyarse en otros integrantes del equipo
de desarrollo para tomar las decisiones. Este Rol puede ser desempeñado por cualquiera de
los arquitectos del proyecto y, al Rol, le daremos el nombre de Arquitecto de Aplicación. Es
importante destacar que menor abstracción no implica, bajo ningún punto de vista, menor
importancia. También es interesante destacar que, en una organización dedicada al desarrollo
de software, el rol de arquitecto puede ser desempeñado por cualquiera de los miembros,
siempre y cuando se encuentre capacitado. Incluso resulta interesante el intercambio de estos
roles en distintos proyectos. {34}

Requerimientos de calidad
Los arquitectos deben tener una lista de requerimientos funcionales para el sistema y una lista
priorizada de atributos de calidad (tales como modularidad, modificabilidad, etc). {11} Los
atributos de calidad pueden estar categorizados y no deberían limitarse solamente a la calidad
del producto final, sino también a los requerimientos de calidad de diseño, de código, de
testing, de performance, etc.

Usar SAAM
Usar el Software Architecture Analysis Method {11} para analizar distintas arquitecturas
candidatas es un método en extremo sencillo y es muy útil para comunicar ideas. Se puede
usar en lugar de métodos más complicados, como ATAM {23}, que deberían ser tenidos en
cuenta sólo para determinados casos.

Requerimientos de calidad tratados como riesgos

Muchos requerimientos de calidad, sobre todo aquellos que tienen que ver con la performance,
la usabilidad, la carga, la disponibilidad, etc. pueden ser tratados como riesgos. Es decir que, el
hecho de que uno de ellos no se cumpla, implica un riesgo. A su vez, estos requerimientos
pueden categorizarse y administrarse de igual manera que un riesgo, utilizando una plantilla
bastante simple, en la que se detallen el impacto, el costo de mitigarlo, la probabilidad, etc.
Esta misma plantilla puede ser tomada de cualquier plantilla de administración de riesgos y
deberá contar con una columna más, que indique la arquitectura seleccionada. Distintas
arquitecturas tendrán impactos diferentes sobre los requerimientos de calidad y éstos deben
ser tenidos en cuenta. La plantilla realizada de esta manera servirá como base para realizar un
SAAM sobre las distintas arquitecturas candidatas.

Utilizar la categorización de riesgos del SEI

El Software Engineering Institute (SEI) {36} ofrece una categorización de riesgos relativos a
proyectos informáticos; la misma se encuentra en {38}. Utilizando esta categorización, pueden
descubrirse riesgos no contemplados, pero también puede ser utilizada para identificar
requerimientos de calidad. Por ejemplo, en la taxonomía, figura “disponibilidad”. Que la
aplicación no cumpla con los requerimientos de disponibilidad que el cliente espera puede
significar un riesgo. Identificar cuál es el requerimiento de calidad que el cliente espera y
escribirlo formalmente, es un requerimiento de calidad. De igual manera, pueden identificarse
requerimientos de calidad relativos a: interfaces, performance, testeabilidad, ambiente,
schedule y staff, entre otros.

Mantenga una adecuada administración de los riesgos del

proyecto
Existen prácticas sencillas, algunas figuran en {40}. También existen varios lineamientos dentro
de muchas metodologías ágiles. Creemos que una de las mejores fuentes sobre administración
de riesgos -y que todo arquitecto debería leer- se encuentra en {37}. Si bien implementar todo
el conjunto de recomendaciones puede resultar muy poco ágil, tener en cuenta su existencia
sin duda ahorrará dolores de cabeza.

Dejar de lado la tentación de la clarividencia (Resuelva el

problema actual)
No intentar predecir el futuro. Realizar solamente la arquitectura de lo que se sabe no va
cambiar en el corto plazo. Hoy día la creación de arquitecturas de aplicación está
evolucionando hacia la especificación de servicios y la creación de arquitecturas transversales
(SOA). Esto plantea la creación de arquitecturas transversales a los servicios y evolutivas en sí
mismas. Querer predecir el futuro de la compañía y cómo será su negocio en el mediano plazo
no es tarea del arquitecto ni de los desarrolladores. Lidiar mediante la adecuada adaptación de
la arquitectura, sí lo es.

Dejar de lado el mito del sentido común

Muchas veces se justifican las decisiones de ingeniería de software bajo el halo del sentido
común. Es claro que resulta necesario el sentido común en la vida en general, pero si bien para
el físico puede ser una cuestión de sentido común que E = MC2, pero para la mayoría de los
mortales no. Sucede que el hecho de entender por qué algo es de una determinada manera no
lo transforma en una cuestión de sentido común. De igual manera, no pertenece al sentido
común la creación de un pattern y tampoco la estimación de proyectos es una cuestión de
sentido común (valga la redundancia); de hecho, requirió años desde que comenzó la
programación, llegar a la noción de pattern y lograr métodos de estimación serios y eso no
quiere decir que los ingenieros de software que precedieron a estos conceptos carecieran de
sentido común. Las sentencias que suelen ser atribuidas al sentido común están basadas en
conocimiento preconcebido y todas las afirmaciones y juicios realizados se basan en ese
conocimiento previamente adquirido. {43}

Plantear la arquitectura como un servicio

La arquitectura puede verse como un servicio que da soporte a los procesos de negocios. Bajo
esta concepción, la arquitectura debería dar soporte al negocio y debería poder evolucionar con
éste. Desde este punto de vista, el carácter evolutivo o no de una arquitectura puede verse
como un requerimiento de calidad.

Armar grupos de arquitectura transversales

Puede resultar una buena práctica armar grupos de arquitectura con gente de distintos
módulos, que se desempeñen en tiempo parcial, haciendo tareas de arquitectura y
compartiendo su opinión respecto a ésta. Este enfoque brinda la oportunidad de dar a conocer
mejor la arquitectura a todo el equipo de desarrollo e involucrar a todos, mejorando la
arquitectura gracias al feedback de los involucrados. {34}

Hablar Patterns
Utilizar como parte del lenguaje cotidiano de trabajo los patterns, aunque sea sólo aquellos más
conocidos. Hoy por hoy, es difícil ver un desarrollador que no haya leído un libro de patterns. La
comunicación es un factor principal en un equipo que pretende utilizar una metodología ágil.
Resulta importante poder subir el nivel de abstracción y saber que todos los miembros del
equipo de desarrollo entienden cuando alguien dice: ‘esto es un composite, un delegate o un
DAO’. Algunas decisiones de diseño pueden tener implicancias sobre los atributos de calidad
del diseño y de la aplicación.{35}

Utilizar ABAS
Un ABAS (Attribute-Based Architectural Style){24} puede pensarse como una parte pre-
analizada de una arquitectura de software. Un ABAS se encuentra conformado por: (1) un
Architectural Pattern (Style); (2) la descripción de los componentes de software y sus
relaciones; (3) atributos de calidad relativos a estos componentes y cómo estos se conectan;
(4) un framework analítico que permita razonar sobre los atributos de calidad. La utilización de
ABAS permite la reutilización de partes de arquitecturas ya definidas. Además, permite dar una
aproximación segura, comprobada y medible a los atributos de calidad relacionados con el
architectural style. Es factible pensar que el correcto uso de architectural styles agilizará y
facilitará la toma de decisiones sobre arquitecturas. El uso de ABAS también facilita la
comunicación, de igual manera que “hablar patterns”.

Crear Tracer Bullets

En la mayoría de los casos en los que hay una interfaz de usuario, suele ser muy útil armar un
prototipo. Este prototipo suele utilizarse para validar los requerimientos junto al usuario. Ahora
bien, en muchas metodologías, el prototipo se tira una vez validados los requerimientos.
Proponemos usar aquí una aproximación como la definida en {40}, en la cual el prototipo
llamado “tracer bullet” sirve para afinar los requerimientos, pero también debe utilizarse para
validar la arquitectura y realizar tests. El “tracer bullet” es parte de la aplicación final, es decir
que no se tira y evoluciona, hasta la forma final de la aplicación.

Definir un leguaje de alto nivel profesional

Utilizar un lenguaje altamente profesional, mediante el conocimiento común de las técnicas y
herramientas utilizadas por el equipo de profesionales. Esta práctica agiliza el proceso de
comunicación entre las partes. Es cierto que existe una decisión de compromiso entre el
lenguaje y el aprendizaje requerido por un nuevo miembro del equipo. Puede considerarse este
aprendizaje como una inversión a mediano plazo.{35}

Compartir las decisiones conflictivas

Contar con un arquitecto que comparta las decisiones conflictivas con los miembros del equipo
de arquitectura e incluso con el resto del equipo, si la decisión es demasiado conflictiva.

Sólo involucrarse en las decisiones de mayor impacto

arquitectónico
Contar o seleccionar un arquitecto que: no disipe la atención de las decisiones que tienen
mayor impacto en la arquitectura; no se transforme en un factor de retraso; no se involucre en
discusiones absurdas que no llevan a ningún lado; deje de lado las discusiones por el uso de
herramientas, IDEs y metodología de trabajo, a menos que éstas tengan algún impacto en la
arquitectura; se mantenga pendiente de las implicancias y validación del uso adecuado de la
arquitectura definida.

Confianza en el equipo
El arquitecto debe conocer a su equipo de trabajo, de manera que pueda generarse en él la
confianza necesaria. De esta manera, el arquitecto podrá y deberá confiar en el equipo, debido
a que éste confía en él para que defina la mejor arquitectura posible dentro del contexto del
proyecto. Los lazos de confianza profesional son difíciles de mantener si no hay un sentimiento
recíproco.

Testear los requerimientos de calidad

La arquitectura debe velar por los requerimientos de calidad. De igual manera que existen los
tests de unidad, puede resultar útil definir baterías de test, que validen los requerimientos de
calidad, por ejemplo, el tiempo de respuesta promedio, cantidad de usuarios concurrentes, etc.
Los tests pueden automatizarse e incluirse dentro del proceso normal de SCM.

Puntos de control y tests de integración

Auditar constantemente la arquitectura y su uso hará que se tengan en cuenta los nuevos
requerimientos. Puede resultar bastante útil y práctico definir puntos de control en los test de
integración. Cada integración plantea la necesidad de correr la batería de test de arquitectura
que valida y certifica los requerimientos de calidad.

No transferir responsabilidades
El desempeño de un profesional en un determinado rol le confiere derechos y obligaciones. El
rol de arquitecto tiene la obligación de no transferir la responsabilidad por las decisiones
tomadas y por el resultado final de la arquitectura. Si la arquitectura no cumple con los
requerimientos especificados, es pura y exclusivamente responsabilidad del arquitecto.

Realizar una arquitectura comprensible

La arquitectura es también un medio de comunicación y el hecho de documentar la arquitectura
de manera clara, sirve como nexo entre perfiles técnicos y no técnicos,. Utilizar stererotypes
{41} de manera conveniente, puede resultar de gran ayuda.

Arquitectura Simple
Mantenga la arquitectura lo más simple posible. Si la simpleza se traduce en facilidad de uso
de la arquitectura, facilidad para entender los conceptos involucrados y está bien documentada,
es muy probable que el nivel de productividad aumente. La simpleza de la arquitectura es
también un requerimiento de calidad.
Defina claramente los requerimientos
Defina claramente los requerimientos de calidad. La arquitectura debe poder medirse sobre la
base de una especificación de requerimientos de calidad bien documentada. El requerimiento
de calidad debe ser testeable. Por ejemplo, decir “el sistema debe ser estable”, relativo al
requerimiento de calidad ‘estabilidad’, no es formal ni testeable; pero un requerimiento de
calidad que diga “el sistema debe tener un 99,99 de disponibilidad”, es un requerimiento
testeable.

Releases Incrementales
Implemente releases incrementales que sean certificadas por el grupo de arquitectura. Cada
release debe ser arquitecturalmente válida. Esto quiere decir que la release debe respetar la
arquitectura actual. Es necesario tener en cuenta que la arquitectura, por estar comprendida
dentro de un entorno ágil, muy posiblemente evolucione y cambie, pero siempre deberá
respetar los requerimientos de calidad.

Busque mejorar sus habilidades constantemente.

Es un buen ejercicio suponer, por un momento, que nuestra profesión no está relacionada con
el desarrollo de software, sino con la medicina. Si tuviéramos que realizar una operación, ¿qué
métodos, técnicas y herramientas utilizaría? ¿Sometería a una persona a una cirugía que le
produzca una cicatriz por el resto de su vida, si ésta es tratable mediante alguna técnica
moderna, como por ejemplo láser? Si usted fuera el paciente, ¿le gustaría que lo opere un
cirujano actualizado o esto no tendría importancia?

El desarrollo de software, al igual que la medicina, es una profesión basada en el conocimiento

actualizado. Las habilidades de ambos deberían medirse por su conocimiento y el buen uso de
éste. Por lo tanto, es factible pensar que mantenernos en constante aprendizaje y conocer
cuáles son nuestras debilidades para mejorarlas nos permitirá desempeñar mejor nuestra
tarea. Algunas de las buenas características personales a buscar en un arquitecto de software
ágil podrían ser: (1) Conocer el dominio del problema a resolver (2) Ser un buen comunicador
(implica saber escuchar) (3) Saber persuadir (si se tiene razón) (4) Tener habilidades de Project
Manager, pero no enredarse con estas tareas en su desempeño diario (5) Pensar que siempre
se puede mejorar, tanto en los aspectos técnicos como en los humanos.{43}

Aportes
En el presente artículo, se muestra la necesidad de implementar prácticas tradicionales de
Arquitectura de Software con un enfoque ágil, en proyectos que implementen cualquier tipo de
metodologías. Se aportan lineamientos útiles para la implementación de las prácticas de
arquitectura de manera ágil. En este trabajo no se discute cómo deben aplicarse estos
lineamientos, ni en qué estadio del proceso. Se sientan las bases para desarrollar un proceso
de arquitectura ágil, que sea posible implementar dentro del contexto de cualquier metodología
y/o proceso de desarrollo.

Trabajo Futuro
Como extensión al trabajo realizado, podemos plantear la definición de un proceso de
desarrollo y especificación de arquitecturas de software ágil que pueda implementarse en el
contexto de cualquier metodología. Muchos de los lineamientos expuestos aquí pueden ser
extendidos, mostrando ejemplos de uso, contextualizándolos en un dominio de problema
adecuado.

Conclusiones
En este artículo se plantea la necesidad de definir un proceso de Arquitectura de Software que
sea capaz de asociarse con cualquier metodología de desarrollo existente. Se buscó también,
cubrir la necesidad de que este proceso sea ágil, de manera tal que pueda ser utilizado tanto
en procesos ágiles como tradicionales. Como una primera aproximación a la resolución de este
problema, se plantean algunos lineamientos que deberían ser tenidos en cuenta al momento de
realizar una arquitectura para cualquier proyecto de desarrollo de software. Algunos de los
lineamientos fueron recopilados de la bibliografía existente sobre el tema y algunos otros son
aportes originales del presente trabajo. Todos los lineamientos propuestos están basados en
estándares aceptados del mercado o de trabajos de reconocido nivel académico. La
originalidad del planteo no sólo radica en su utilización para agilizar un proceso arquitectónico,
sino también en la propuesta de varios lineamientos.

Qué son los sistemas reactivos y cómo

aprovecharlos en las empresas
17 octubre 2017 on Sistemas reactivos, software, desarrollo de software, programación
Es probable que hayas oído hablar de sistemas reactivos, una tendencia en la
arquitectura de software de la que mucho se habla, pero de la que poco se entiende. A
continuación, te contamos qué son y cómo pueden ayudar a las organizaciones
modernas.

Su historia

Los tiempos cambian y la tecnología evoluciona. Hace apenas unos años, lo corriente
era que las grandes aplicaciones necesitaran decenas de servidores, tardaran muchos
segundos en dar una respuesta y requirieran de constante mantenimiento. Estas
limitaciones, impuestas por sistemas de programación obsoletos, se convirtieron en
obstáculos para empresas que crecían vertiginosamente y que necesitaban soluciones
de software ágiles. Ante este problema, un grupo de ingenieros, liderados por Jonas
Bonér, publicó en el 2013 un documento denominado Reactive Manifesto, en el que se
sugiere darle un nuevo enfoque a la arquitectura de sistemas, con el fin de que los
programas y aplicaciones informáticos sean más flexibles, independientes y escalables.

El cambio

Lo que entonces parecía ser una mera tendencia en el diseño de arquitectura

de software, se está convirtiendo en un modelo estándar en el desarrollo de sistemas.
Así se puede inferir de los resultados de una reciente encuesta a desarrolladores. Según
el estudio, denominado Going Reactive 2016, el 80 por ciento de los encuestados cree
que las empresas con mayor éxito van a adoptar los sistemas reactivos para el 2018.
Esto significa que, dentro de la industria, existe la firme convicción de que el desarrollo
exitoso de software empresarial está estrechamente vinculado con los principios del
diseño reactivo. Pero, ¿en qué consisten los sistemas reactivos y cuáles son sus
fundamentos?

La definición

De acuerdo con el manifiesto, los sistemas reactivos son una serie de principios de
diseño, cuyo propósito es construir sistemas modernos, preparados para satisfacer las
exigencias, cada vez mayores, de las aplicaciones actuales. Su flexibilidad y
escalabilidad los hace más fáciles de desarrollar y modificar. También toleran mejor las
fallas, y cuando estas ocurren, se corrigen automáticamente antes de que se
desencadenen problemas mayores. Un sistema reactivo es en esencia:

-Responsivo: el sistema responde oportunamente al usuario. Detecta los problemas a

tiempo y los resuelve efectivamente.
-Resiliente: el sistema permanece responsivo ante las fallas, conteniéndolas dentro de
cada componente. Al aislar los componentes entre sí, previene que varios resulten
afectados, evitando comprometer todo el sistema.
-Elástico: ante diferentes cargas de trabajo, el sistema permanece responsivo, lo que
significa que su rendimiento aumenta o disminuye automáticamente para satisfacer la
demanda variable, a medida que los recursos se agregan o eliminan proporcionalmente.
-Impulsado por mensajes: los sistemas reactivos se basan en la transmisión asíncrona
de mensajes entre los distintos componentes, asegurando un bajo acoplamiento entre
estos y una ubicación independiente.

Las ventajas

Para cualquier organización, contar con sistemas basados en una arquitectura reactiva
representa grandes ventajas. En un mundo en el que tecnologías como la computación
en la nube y el Internet de las cosas exigen una mayor capacidad de las aplicaciones
actuales, asegurar un menor tiempo de respuesta a los usuarios finales significa ir un
paso adelante de la competencia. Asimismo, un sistema eficiente consume menos
recursos (tiempo, energía, memoria), es más amigable con el medio ambiente, y resulta
más rentable para la empresa, al igual que asequible para los consumidores.

Con el tiempo, la mayoría de organizaciones terminará migrando a este tipo de sistemas,

sin embargo, startups y empresas orientadas a ofrecer soluciones en la nube parecen ser
las que más necesitan hoy en día de los sistemas reactivos. No adoptarlos implica
atascarse en las limitaciones de lenguajes y arquitecturas obsoletos.

¿Utiliza tu empresa programas basados en sistemas reactivos? ¡Déjanos tus comentarios

y comparte este artículo!

Manifiesto de Sistemas Reactivos

Empresas que trabajan en dominios diferentes están descubriendo de manera

independiente patrones similares para construir software. Estos sistemas son más robustos,
más flexibles y están mejor posicionados para cumplir demandas modernas.

Estos cambios están sucediendo porque los requerimientos de las aplicaciones han cambiado
drásticamente en los últimos años. Sólo unos pocos años atrás, una aplicación grande tenía
decenas de servidores, segundos de tiempo de respuesta, horas de mantenimiento fuera de
línea y gigabytes en datos. Hoy, las aplicaciones se desplegan en cualquier cosa, desde
dispositivos móviles hasta clusters en la nube corriendo en miles de procesadores multi-core.
Los usuarios esperan que los tiempos de respuesta sean de milisegundos y que sus sistemas
estén operativos el 100% del tiempo. Los datos son medidos en Petabytes. Las demandas de
hoy simplemente no están siendo satisfechas por las arquitecturas software de ayer.

Se necesita un enfoque coherente para la arquitectura de sistemas, y se cree que todos los
aspectos necesarios ya han sido identificados por separado: queremos sistemas Responsivos,
Resilientes, Elásticos y Orientados a Mensajes. Se les llama Sistemas Reactivos.

Los sistemas construidos como Sistemas Reactivos son más flexibles, con bajo acoplamiento
y escalables. Esto hace que sean más fáciles de desarrollar y abiertos al cambio. Son
significativamente más tolerantes a fallos y cuando fallan responden con elegancia y no con un
desastre. Los Sistemas Reactivos son altamente responsivos, dando a los usuarios un feedback
efectivo e interactivo.

Los Sistemas Reactivos

 
 
Responsivos
El sistema responde a tiempo en la medida de lo posible. La responsividad es la piedra angular
de la usabilidad y la utilidad, pero más que esto, responsividad significa que los problemas
pueden ser detectados rápidamente y tratados efectivamente. Los sistemas responsivos se
enfocan en proveer tiempos de respuesta rápidos y consistentes, estableciendo límites
superiores confiables para así proporcionar una calidad de servicio consistente. Este
comportamiento consistente, a su vez, simplifica el tratamiento de errores, aporta seguridad al
usuario final y fomenta una mayor interacción.

Basicamente un sistema que siempre responde de acuerdo a las exigencias del negocio.

Resilientes
El sistema permanece responsivo frente a fallos. Esto es aplicable no sólo a sistemas de alta
disponibilidad o de misión crítica - cualquier sistema que no sea resiliente dejará de ser
responsivo después de un fallo. La resiliencia es alcanzada con replicación,
contención, aislamiento y delegación. Los fallos son manejados dentro de cada componente,
aislando cada componente de los demás, y asegurando así que cualquier parte del sistema
pueda fallar y recuperarse sin comprometer el sistema como un todo. La recuperación de cada
componente se delega en otro componente (externo) y la alta disponibilidad se asegura con
replicación allí donde sea necesario. El cliente de un componente no tiene que
responsabilizarse del manejo sus fallos.

Tratar de parar la propagacion de errores por todo el sistema y manejarlos individualmente,

junto con tecnicas como cluster hacen que el sistema pueda seguir trabajando a pesar de tener
problemas internos, es decir el fallo se lo toma como parte del ciclo de produccion.

  

Elásticos

El sistema se mantiene responsivo bajo variaciones en la carga de trabajo. Los Sistemas

Reactivos pueden reaccionar a cambios en la frecuencia de peticiones incrementando o
reduciendo los recursos asignados para servir dichas peticiones. Esto implica diseños que no
tengan puntos de contención o cuellos de botella centralizados, resultando en la capacidad de
dividir o replicar componentes y distribuir las peticiones entre ellos. Los Sistemas Reactivos
soportan algoritmos de escalado predictivos, así como Reactivos, al proporcionar relevantes
medidas de rendimiento en tiempo real. La elasticidad se consigue de forma rentable haciendo
uso de plataformas con hardware y software genéricos.

Poder variar sus capacidades de respuesta de acuerdo a condiciones temporales a veces

creciendo y otras decreciendo en infraestructura puede significar ahorros en costos y poder
responder al negocio de forma optima.

Orientados a Mensajes 
Los Sistemas Reactivos confían en el intercambio de mensajes asíncrono para establecer
fronteras entre componentes, lo que asegura bajo acoplamiento, aislamiento y transparencia
de ubicación. Estas fronteras también proporcionan los medios para delegar fallos como
mensajes. El uso del intercambio de mensajes explícito posibilita la gestión de la carga, la
elasticidad, y el control de flujo, gracias al modelado y monitorización de las colas de mensajes
en el sistema, y la aplicación de back-pressure cuando sea necesario. La mensajería basada en
ubicaciones transparentes como medio de comunicación permite que la gestión de fallos
pueda trabajar con los mismos bloques y semánticas a través de un cluster o dentro de un solo
nodo. La comunicación No-bloqueante permite a los destinatarios consumir recursos sólo
mientras estén activos, llevando a una menor sobrecarga del sistema.

Trabajar de forma asincrona y delimitando los contextos de cada componente a traves de

fronteras, este tipo de mensajeria puede ser implementada de diferentes formas una de ella es
un ESB (Bus de Servicios Empresariales) donde la transparencia de ubicacion, conversion de
protocolos y tecnologias es crucial, sin embargo existen otras formas APIs, gateways, brokers
de mensajeria

Conclusiones
Los sistemas grandes están compuestos de otros más pequeños y por lo tanto dependen de las
propiedades Reactivas de sus partes. Esto significa que los Sistemas Reactivos aplican
principios de diseño para que estas propiedades sean válidas a cualquier escala, haciéndolas
componibles. Los sistemas más grandes del mundo confían en arquitecturas basadas en estas
propiedades y atienden las necesidades de miles de millones de personas diariamente. Es
tiempo de aplicar estos principios de diseño conscientemente desde el inicio, en vez de
redescubrirlos cada vez.

Aunque el manifiesto no habla específicamente de microservicios, al decir

que los grandes sistemas estarán compuestos de otros más pequeños con
las mismas características ya dejan entrever la constitución de un sistema a
través de pequeños elementos o unidades que se mantengan aislados y
operantes, responsivos, resilientes y elásticos de forma individual para
conseguir un sistema como un conjunto igualmente responsivo, resiliente y
elástico e igualmente orientado a mensajes asíncronos en toda su
interacción.

No olvidemos que la premisa de este tipo de arquitecturas es responder a las necesidades del
dominio o negocio por lo que por ejemplo "tiempos de respuesta optimos" van acorde a lo que
se espera dentro del negocio, y lo principal es tener disponibilidad, poder crecer o decrecer de
acuerdo a la carga, aislar la propagacion de errores y tener bajo acoplamiento en cada uno de
los componentes por todo lo anterior, el diseño, desarrollo e implantacion de este tipo de
sistemas puede parecer costoso pero si es de una ayuda para el negocio podria convertirse en
nuevas oportunidades y modelos de negocio que apoyarian la gestion empresarial.

Arquitectura emergente ó arquitectura de emergencia

Humberto González Ortiz
 
 
La cubierta del Mercado de Santa Catarina en Barcelona, del estudio del
desaparecido arquitecto Enric Miralles (1955-2000), con gran colorido y evidente
“exceso de estructura”
Foto Humberto González Ortiz
Afirma Luis Fernández-Galiano en su editorial: “dos publicaciones recientes
dan cuenta de este paisaje de mutación: The Economist, bajo el titulo “Africa
Rising”, asegura que África tiene hoy la oportunidad de seguir los pasos de
Asia; y nuestro Atlas arquitectónico de África y Oriente Medio documenta
exhaustivamente la zona, mostrando abundantes ejemplos de la transformación de
su entorno construido” (1). Después de leer esta visión “algo” colonialista
del hecho arquitectónico (2) quiero defender una visión que mira desde la
periferia y que quiere aportar “otras” posibles respuestas a nuestras
incógnitas acerca de la incongruencia arquitectónica actual.
Las desigualdades entre norte-sur o desarrollo-subdesarrollo agudizan sus
diferencias de manera casi exponencial. Actualmente más de 1.200 millones de
personas (una de cada cinco del mundo) sobrevive con menos de un dólar al día.
A día de hoy, puedo afirmar que cerca 5.000 millones de habitantes viven en
condiciones de pobreza y marginados de los planes sociales y de los beneficios
de la globalización financiera del mundo actual, hablamos de casi el 83% de la
población mundial. En 1989 el 20% más rico recibía el 82.7% de la producción
económica mundial, mientras el 20% más pobre recibía solo el 1.4%. En este
proceso podemos afirmar que actualmente la renta de las 350 personas más ricas
del Planeta equivale a la del 45% de la población mundial.

Los países del Tercer Mundo no pueden hacer frente en el marco político actual
al cúmulo de necesidades de sus pobladores, igualmente los pobladores pobres
del llamado 4º mundo, que intentan ferozmente acceder a una vivienda digna y a
un precio accesible. Por ello debemos inevitablemente re-fundar también,
nuestra visión y posición “arquitectónica” desde la Urgencia y la Necesidad,
dejando de lado esta visión mediocre y frustrante, en la que se maneja la
arquitectura de autor, actual.

Las formas esculturales de la arquitectura de hoy son impresionantes, la

espectacularidad de la arquitectura actual que utiliza la tecnología para
crear formas imposibles, es innegable, y sería tristísimo que “con los
presupuestos” con que cuentan los “grandes” arquitectos, no hicieran lo mejor
que su lápiz y su imaginación pudieran recrear.

Sin embargo, yo no puedo quitar el ojo de la realidad que nos envuelve, y que
muchas veces, los arquitectos la obviamos, o definitivamente “no nos
interesa”.

Y preferimos hablar de arte, de diseño, de la forma, de la tecnología, de

los renders, de las relaciones con alcaldes, o del último software de dibujo
que “facilitará” el trabajo a los dibujantes del despacho. Y en muchas
ocasiones pasamos por alto, que la arquitectura: “es un arte práctico
destinado a construir espacios utilizables por el ser humano y que desde hace
siglos, quien posee el encargo de la sociedad para llevar a cabo la
construcción de estos espacios es el arquitecto” (3).
Considero que la arquitectura de autor actual deja de lado la “realidad” real,
es decir, al potencial usuario-cliente que vive, recorre, utiliza, se
enfrenta, y también, padece de espacios “escultórico-artísticos”, más que su
referente de espacios “habitables”.

Si bien es cierto que el arquitecto es quien resuelve con arte las necesidades
del cliente, el arquitecto con el uso ético de su oficio puede persuadir al
cliente de utilizar inadecuadamente el arte en la construcción, pero “la
acción persistente de una artisticidad mal entendida, mezclada con la
doctrinaria creencia en una misión pedagógico-social de la arquitectura, y
unas gotas de “libertad creadora” fundamentalista, lleva a ciertos arquitectos
a proferir simplezas de tal calibre que hacen tambalear gravemente el
prestigio social de la profesión” (4).
La arquitectura globalizada aparta de su “hacer proyectual” a la pobreza
mundial, es decir, ese 80% del mundo que no puede detenerse a “admirar” las
últimas tendencias en “esculturas arquitectónicas”... simplemente porque
necesita “urgentemente” de un techo y cuatro paredes para guarecerse del mundo
que lo ignora (5). La modernidad sigue siendo una deuda pendiente cada vez más
“evidente” y “urgente” y que el movimiento moderno prometió, “como posible”.

Va siendo hora de que nosotros los arquitectos también comencemos a

cuestionarnos a nosotros mismos y nuestras actuaciones como “constructores de
las ciudades modernas”. Es necesario que renovemos nuestro oficio para
adecuarlo a la realidad de pobreza de nuestro planeta, es necesario que
reduzcamos drásticamente el consumo de recursos y energía que se emplean, en
la construcción de la arquitectura actual como desde hace décadas viene
afirmando Serge Latouche (6) cuando afirma “el decrecimiento que, a diferencia
del crecimiento negativo o de la crisis, consiste precisamente en salir de esa
lógica que condena, de forma obligatoria, a destruir el planeta para crear
empleos. A través del decrecimiento, al contrario, crearíamos empleos salvando
al planeta” (7).
Es necesario que giremos la cara, aprendamos, y expongamos la experiencia de
arquitectos que se han comprometido desde la arquitectura sí, pero también
desde el compromiso social (8) que el oficio del arquitecto, sin duda, tiene.

Los intelectuales y creadores debemos de poner en duda este sistema

excluyente, los arquitectos deberíamos cuestionar nuestro papel en la
globalización del diseño high tech de última generación. Los arquitectos
debemos “urgentemente”, encontrar “otra arquitectura” que responda a todos los
intereses que la sociedad moderna requiere. Nos referimos a la necesidad de
una arquitectura “pobre” de calidad, de necesidad y de urgencia.
Una arquitectura que democratice claramente esta moderna arquitectura de
pasarela, que vende sus exclusivos diseños y los expone, como símbolo de la
globalización, la riqueza, y el poder.

La construcción de la ciudad informal (9) se produce (y reproduce) con una

lógica que no es improvisada, ni caótica, es simplemente “otra lógica”, la que
se afirma coherente desde las perspectivas de la necesidad y las posibilidades
concretas de los pobladores que están al margen de la ciudad de los ricos
(10).

Don Carmelo, habitante de un asentamiento irregular de la Ciudad de México en

una entrevista con universitarios explicó su rechazo respecto a la reubicación
que le ofrecían con una vivienda “de interés social” y un crédito accesible y
pagadero, a veinte años, porque: “la casa que nos dan, es muy pequeña, de solo
dos recámaras, un solo baño, con una salita. Y además solo tiene una
azotehuela, mejor nos quedamos aquí. Esto es mucho más grande, porque en el
futuro esto va acrecer, y con muchos cuartos para todos los hijos, y con un
jardín y hasta garaje; y ¡además!, sin tener que pagar por el resto de mi vida
una parte significativa de mis ingresos. ¡Vean muchachos, como esto es más
grande, como la esperanza, y en cambio, lo que el gobierno nos ofrece es como
“un féretro”, es “así” para siempre y además, nunca cabríamos allí, de lo
chiquito que es” (11).

Esta reflexión debe llevarnos necesariamente a pensar, proyectar y hablar de

Arquitectura apropiada. La acción directa de lo que denominamos arquitectura
apropiada tiene que ver con la creación de tecnologías, proyectos e
investigaciones asequibles para el mejoramiento del hábitat “también”, entre
los pobladores más pobres del planeta.
En este campo, encontramos avances significativos en la tecnología de “techos”
al ser un elemento estructural básico para la construcción de una vivienda;
también hay trabajos excelentes en la investigación y construcción sobre la
vivienda semilla con futuros crecimientos en Latinoamérica (12); o programas
universitarios que promueven la investigación en la acción, analizando la
problemática del hábitat latinoamericano, interactuando con los pobladores y
proponiendo soluciones concretas a problemas directos de los ciudadanos
pobres(13).

Todo este esfuerzo encaminado a la asistencia técnica directa con usuarios

pobres y hacedores de ciudad, tiene que ver con nuestra apuesta por lo que
denominamos arquitectura apropiada, la que se aleja definitivamente del
marketing, y se acerca definitivamente a los principios del CIAM de 1929 (14),
que buscaba afanosamente la funcionalidad arquitectónica, la adecuación de los
recursos y la divulgación de la investigación de lo que podemos denominar
ciudad de masas.

Sin embargo, estas actuaciones desde el ámbito meramente arquitectónico, no

afectan decididamente a la base estructural del problema ya que “Los datos
estadísticos sobre la pobreza en el mundo dan muestra del incremento de las
desigualdades interpersonales e interrelacionales. No sólo hay un mayor número
de personas que se ven afectadas por estos procesos de desequilibrios y
asimetrías, sino que también hay un incremento de la intensidad de las
carencias de bastantes personas” (15).

Las propia Organización de las Naciones Unidas en 2005 afirmó que 4 de cada 5
seres humanos sufren procesos de desigualdad, por ello debemos recocer que la
pobreza es el desafío más grave para los derechos humanos en el mundo, tanto
si se mide por el número de personas afectadas (16) como por el efecto
acumulado sobre toda una gama de derechos humanos. Y añadimos a la
arquitectura, ya que los ciudadanos tienen derecho a la vivienda y derecho a
la ciudad.

Este análisis nos lleva a pensar en un proceso de comprensión y aprendizaje de

la pobreza, para incidir sobre el fenómeno de la “exclusión arquitectónica” de
una franja mayoritaria de pobladores en el mundo y así convertirnos en
“actores” que aporten soluciones arquitectónicas que hablen de tecnologías
sobre una manera diferente (apropiada) para construir, de una manera
proyectual novedosa (apropiada) que nos permita desarrollar proyectos de
viviendas semillas que crezcan en el futuro, según los recursos de las propias
familias constructoras, con tecnologías asequibles (apropiadas) para que los
usuarios las aprendan y las empleen en colectividad en la construcción de su
hábitat, de su historia; y con investigaciones que aporten una visión “otra”
(apropiada), para divulgar las necesidades, pero que también aporte
directrices sobre las cuales, podamos hablar de Arquitectura Apropiada sin
tapujos.

Esta realidad globalizada neoliberal (17) nos lleva necesariamente a repensar

la relación entre arquitectura y sociedad, producto de la reflexión sobre el
nuevo papel del arquitecto frente al creciente deterioro del tejido social, de
la calidad de vida de la población, que se refleja en el deterioro constante
del estado del bienestar: trabajo, ingreso, salud, educación, seguridad,
vivienda. Y que se expresa en términos de un desmedido crecimiento de la
ciudad precaria, como reflejo evidente del constate incremento de la pobreza,
y concretamente en la pobreza arquitectónica, que mira hacia otra parte, y no
se inmiscuye en el día a día, del “hábitat humano”.
Necesitamos de “necios” que sigan haciendo lo necesario para revolucionar la
arquitectura, porque esta realidad cruda y tajante nos conduce a tomar partido
por una fórmula igual de tajante, donde el arquitecto mediante su actividad
crítica, docente y proyectual, ayude a encontrar alternativas culturales y
humanamente más apropiadas, no ya para transformar las estructuras sociales,
pero sí, para que la modernidad incumplida que nos ofreció el movimiento
moderno, llegue con propuestas arquitectónicas que ayuden a construir la
ciudad de masas y decir, junto a los pobladores, y potenciales usuarios, que
es posible construir mediante nuestro esfuerzo, y la organización solidaria de
los técnicos, una ciudad “otra”, y una arquitectura apropiada que ayude a
construir, o reconstruir, la necesidad del habitar humano.

A modo de conclusión
Este ensayo partió de la inquietud del autor al leer, por ejemplo: “Aunque el
crecimiento de África es impresionante, la mayor parte de sus mil millones de
habitantes viven aún en la pobreza, asediados por sequías, hambrunas y
enfermedades como la malaria y el sida...()... Y en este magma cambiante
aparecen de cuando en cuando obras de arquitectura de valor singular, que
reconcilian tradición y modernidad para transmitir un mensaje de confianza en
el futuro de un continente que sin duda se la merece” (18).

¡Dónde ven “ellos” la oportunidad!... ¿En los mil millones de habitantes

africanos que viven en la pobreza?, ¿en Norman Foster y su “green desert
utopía”en Abu Dhabi?, ¿en las falsas islas que se construyen a base de
petrodólares en Dubai?, ¿en las masacres de Siria, Libia, Argelia?, ¿en los 30
dólares a la semana que gana un trabajador congolés de Coltan para enriquecer
a las multinacionales de las telecomunicaciones?, ¿en la pobreza y la hambruna
que la guerra ha ocasionado?, ¿en la indiscriminada caza de elefantes y
gorilas que “para comer” realizan rebeldes y mineros poniendo ambas especies
en peligro? (19), ¿en esta “necia” huida hacia adelante para que “nosotros”
grupos de arquitectos europeos vayamos a conquistar las tierras vírgenes de
África ahora que por la crisis (nuestra) estamos todos sin trabajo? (20)

Dicen los autores Mireia Belil y Jordi Borja: “La ciudad es el horizonte
humano del siglo XXI. A inicios de este siglo, haciendo un cálculo optimista
apenas un 25% de la población mundial vive en ciudades y no siempre en
condiciones de ejercer sus teóricos derechos ciudadanos. Otro 25% puede
considerarse población rural, mayoritariamente agrícola o ganadera. ¿Y el otro
50%? En muchos casos las estadísticas globalizadas nos dirán que es gran parte
población urbana. Puede ser, si entendemos que viven en áreas consideradas
administrativamente como urbanizadas, o mejor dicho suburbanas o periurbanas,
o radicalmente marginales. Unas áreas que por la “exclusión territorial” y por
su carácter de ghetto que las caracteriza difícilmente pueden considerarse
“ciudad”. Ni dar por sentado que su población vive en ciudades y menos aun que
sus habitantes disfrutan de status de ciudadanos” (21).
¿Cómo enfrentar de manera eficiente el creciente deterioro de la estructura
social de la pobreza en el mundo?; ¿cómo intervenir desde la arquitectura,
para incluir “también” a ese 60% de la población excluida de los planes
urbanísticos?; ¿cómo aglutinar a los grupos de población y comunidades que
viven en condiciones de vulnerabilidad social desde la investigación
arquitectónica?

Ante lo aquí expuesto podemos concluir que debemos re-pensar el modelo

arquitectónico actual, ya que no responde eficientemente a la demanda
de habitabilidad en el mundo pobre que crece exponencialmente y día con día.
Debemos cambiar el ideal colectivo de consumir por el de evaluar-decidir-
transformar, a partir de la herencia cultural propia; debemos entender la
arquitectura también, desde nuestra diversidad y no hablar como nos lo sugiere
en stablishment arquitectónico actual, por ejemplo; tengo sed: coca-cola. Ya
que sobre esta premisa obvia, pero arraigada culturalmente por el sistema
económico que nos rige, hemos construido nuestras ciudades, y nos ha impedido
descubrir un mundo “otro”, del que hemos expuesto aquí algunas pinceladas y
que nos ofrece un modo “otro” de planificar la ciudad, el barrio, la casa, en
definitiva, nos conduce necesariamente hacia una Arquitectura Apropiada
incluyente, que propone una tecnología asequible, que propone un urbanismo
dialogal, que propone la investigación en la acción que apuesta por un espacio
público y una ciudad, que incorpora a la ciudadanía también, en su Derecho a
la Ciudad.
En principio, la apertura tecnológica de nuestro tiempo, nos conduciría a
pensar en una supuesta “democratización” del conocimiento, y por ende, una
democratización del derecho a la ciudad, sin embargo la segregación social de
lo que podríamos llamar espacio público, nunca ha sido tan grande, las
desigualdades de ingresos aumentan, la precariedad laboral se agudiza, las
ofertas y el acceso real a las ofertas urbanas entre la población, se
difuminan, exponiendo a los colectivos más vulnerables y débiles, en un estado
de marginación y vulnerabilidad impensables hace algunos años, el paso del
huracán Mitch por la ciudad norteamericana de Nueva Orleáns, es un ejemplo
claro de marginalidad técnica, política y humana por el que trascurre el
devenir de las mayorías empobrecidas del planeta, incluso en los llamados
países desarrollados.

Por ello, o usamos nuestra energía creativa enfocada hacia esta arquitectura
autoritaria y díscola, o nos esforzamos y apostamos por la creación de una
arquitectura autogestiva, poética, alegre, democrática… En definitiva, una
arquitectura apropiada.

Dejo aquí mi colaboración de crítico e investigador en la acción, construyendo

la obra arquitectónica que está a mi alcance, la de las palabras. Y que
considero imprescindible ante esta realidad “enajenada” y “levemente”
reaccionaria en que nos movemos en el tiempo presente.

Una arquitectura emergente es aquella que nos permite realizar una

arquitectura de software reemplazable, el modelo de 3 capas, es un claro
ejemplo de esto, ya que el nos permite poder actualizar o realizar cambios en
una capa sin necesidad de realizar mas cambios en las demás capas.
El modelo sashimi es una alteración del modelo en cascada: A veces se hace
referencia a él como el modelo en cascada con fases superpuestas o el modelo
en cascada con retroalimentación. Ya que las fases en el modelo sashimi se
superponen, lo que implica que se puede actuar durante las etapas anteriores.
Por ejemplo, ya que las fases de diseño e implementación se superpondrán en
el modelo sashimi, los problemas de implementación se pueden descubrir
durante las fases de diseño e implementación del proceso de desarrollo. Esto
ayuda a aliviar muchos de los problemas asociadas con la filosofía del modelo
en cascada.
Ya que sus capas se superponen entonces nos evita el hacer cambios despues
en el sistema, se los puede hacer durante alguna etapa del mismo.
Se debe de mantener una inspección constante durante y despues del
desarrollo de software de a siguiente manera:

En la visión técnica: se debe realizar una validación a nivel de Atributos, calidad

y ciclo de vida del software. Se debe realizar una descomposición en módulos
del sistemas para exista aceptación y no se obtenga un bajo rendimiento. Se
debe validar las diferentes dependencias entre la capa lógica y física.
Y finalmente se realiza una prueba individual o estática de cada una de las
funciones o clases del sistema.

ntroducción a la
Arquitectura reactiva:
qué es, principios y
lenguajes, plataformas…
PUBLICADO EN 06/08/2018

Como decíamos en la entrada anterior sobre arquitecturas

reactivas, las demandas de hoy en las empresas
requieren tiempos de respuesta cortos, con la necesidad
de tener que procesar ingentes cantidades de
datos, desplegarse en cualquier cosa y que los sistemas
estén operativos el 100% del tiempo. Para ellos, distintos
tipos de organizaciones están dando de manera
independiente con patrones similares con los que construir
software que haga frente a estas demandas.

Este conjunto de patrones y técnicas es el que se conoce

como Arquitecturas Reactivas y se utilizan para construir
sistemas que:

 Son más amigables, robustos y flexibles

 Son capaces de responder a las limitaciones
de escalado
 Pueden resistir mejor a los fallos y responder con
elegancia a ellos
 Dan un feedback efectivo e interactivo al usuario
 Están más abiertos a los cambios.
 Son escalables y con bajo acoplamiento.
 Reaccionan a los eventos

Principios de la programación
reactiva
Dirigida por datos
En el modelo de actores, uno de los patrones más utilizados
en programación reactiva, se definen cadenas de
transformación funcional. Estas son atravesadas por flujos
de datos para su procesamiento. Se podría decir que este
tipo de soluciones están dirigidas por los datos porque en
ellos descansa, además de gran parte de la lógica de la
aplicación, el propio comportamiento reactivo del sistema.

Centrada en la composición
Las operaciones que forman parte del procesamiento de datos
en programación reactiva, que normalmente se
implementan en actores distintos, se encadenan de forma
compositiva. De este modo, el resultado de cada
transformación es la entrada para la siguiente. Para poder
articular esta composición adecuadamente, debemos tener en
cuenta tres reglas fundamentales en la programación
funcional:

Idempotencia de las funciones

Las funciones siempre deben devolver los mismos resultados
para los mismos valores de entrada.

Transparencia referencial
El valor de retorno de las funciones depende de los
parámetros de entrada, nunca de condiciones ambientales
(parámetros externos o contexto).

Inmutabilidad de los datos

Los datos de entrada que manejan las funciones son
inmutables, es decir, las funciones nunca deben alterar los
parámetros de entrada.

Principales lenguajes y
plataformas de la programación
reactiva:
Como ya se ha dicho antes, la programación reactiva implica
el conocimiento y la integración de varios lenguajes de
programación y plataformas, como podrían ser:

 Scala es un lenguaje multi-paradigma. Expresa

patrones comunes de programación en forma concisa,
elegante y con tipos seguros. Integra características
de lenguajes funcionales y de los orientados a objetos.
  Akka es una plataforma que busca desarrollar de
forma simple aplicaciones escalables y multihilo. Su
método de concurrencia se basa en actores (objetos
con los que puedes interactuar enviándoles mensajes)
y se puede desarrollar con diferentes APIs,
generalmente Scala.
 Kubernetes es un sistema para automatizar el
despliegue, autoajustar el escalado y manejo de
aplicaciones en contenedores.
 Kafka es un proyecto que permite publicar mensajes
de datos procedentes de las aplicaciones en un flujo,
suscribirse a los mensajes generados,  almacenarlos
en un sistema tolerante a fallos y consumir los
streams de mensajes por aplicaciones en cuanto se
produzcan.
 Docker es un proyecto que automatiza el despliegue
de aplicaciones dentro de contenedores de software.
Proporciona una capa adicional de abstracción y
automatización de virtualización de aplicaciones en
múltiples sistemas operativos. Además, permite que
los “contenedores” independientes se ejecuten en una
sola instancia de Linux, evitando sobrecargar
las máquinas virtuales.
 Elasticsearch es un servidor de búsqueda de texto
completo, distribuido y con capacidad de multi-tenant.
 Cassandra es un almacén de datos NoSQL de gran
rendimiento. Como es distribuida y basada en un
modelo de almacenamiento de «clave-valor», permite
grandes volúmenes de datos en forma distribuida, con
escalabilidad lineal y disponibilidad.

Se puede resumir el rumbo que están siguiendo las empresas

en la segunda década del siglo XXI en dos
palabras: transformación digital.
La nueva economía digital plantea nuevos desafíos a las
empresas y sus líderes. La integración de herramientas
digitalesha penetrado al negocio. Además, esto está
provocando cambios importantes en la forma en que
trabajan, se comunican y venden. La digitalización de los
procesos y actividades del negocio amplía el alcance de las
organizaciones, tanto para mejorar las decisiones que toma
la dirección y acelerar el desarrollo de nuevos productos
y servicios como para transformar radicalmente los
modelos de negocio tradicionales. De este modo, todas las
empresas se han convertido en tecnológicas y sus
plataformas digitales son un elemento vital para el negocio.

Evolución de Arquitecturas y
aplicaciones Empresariales
Los requerimientos de las aplicaciones han cambiado
drásticamente en los últimos años. Solo unos pocos años
atrás, una aplicación grande tenía decenas de servidores,
segundos de tiempo de respuesta, horas de mantenimiento
fuera de línea y gigabytes en datos, lo que hacía necesario su
procesamiento. Luego se incorporaron los ERP y CRM a las
webs con arquitecturas cliente/servidor y finalmente a las
aplicaciones modernas actuales, basadas en
los microservicios, los contenedores virtuales y el Big
Data. Estos últimos basados en componentes de código
abierto y/o software libre.

Aplicaciones Empresariales Modernas:

arquitecturas reactivas y microservicios
Hoy, las aplicaciones se despliegan en casi “cualquier
cosa”, desde dispositivos móviles, dispositivos industriales,
hasta clústeres en la nube corriendo en miles de
procesadores multi-core. Esto se debe a que los usuarios
“digitales” esperamos que los tiempos de respuesta sean
de milisegundos y que nuestros sistemas estén operativos
el 100% del tiempo. Las demandas de hoy simplemente no
están siendo satisfechas por las arquitecturas software de
ayer.

Las arquitecturas reactivas surgen como un nuevo patrón

para construir unos sistemas más robustos,
más flexibles y que están mejor posicionados para cumplir
demandas modernas. Las aplicaciones monolíticas se
descomponen en micro-aplicaciones o microservicios, que
se despliegan en diferentes contenedores. En muchas
ocasiones, estos microservicios utilizan motores de cálculo
basados en tecnologías Big Data, Machine Learning y
de Inteligencia Artificial. Estos motores proporcionan
capacidades de analítica avanzada en tiempo real,
procesando grandes cantidades de información. Los
microservicios se integran entre ellos utilizando APIs
asíncronos, muy robustos, con un bajo acoplamiento y
con grandes capacidades para escalar según las
demandas.

De esta forma, logran responder a las limitaciones de

escalado de los modelos de desarrollo anteriores, que se
caracterizan por su desaprovechamiento del uso de la CPU, el
sobreuso de memoria y la ineficiencia de las interacciones
bloqueantes.