De Dónde Salen los Problemas

"Mi país tiene sólo dos tipos de problemas:
aquellos que no se arreglan nunca y
aquellos que se arreglan solos"

(Atribuido a un funcionario sudamericano)
 Arquitectura  implica administrar complejidad, de modo que el desarrollo y la mantenibilidad de una aplicación se maximice. Esta complejidad se distribuye a lo largo de una serie de dominios, y se hace presente en la forma de Problemas de Arquitectura. Veamos algunos
  • Problemas de seguridad (ejemplo, login único)
  • Problemas de acceso a datos (ejemplo, mapeo de objetos a datos relacionales y viceversa)
  • Problemas de modelado o de diseño
  • Problemas de rendimiento (ejemplo, concurrencia en recursos compartidos)
  • Problemas de navegación, de usabilidad de la interfaz de usuario
  • Problemas de integración, incluso interoperabilidad (ejemplo, manejo de contexto transaccional distribuido)
  • Problemas de comunicación (ejemplo, ancho de banda acotado)

Sigo? Mejor no, no? Algún arquitecto se va a querer suicidar de ver tabulados todos los dominios que debe tener en cuenta. El origen de los problemas de arquitectura, no es que sea incierto. No obstante, a efectos del rol del arquitecto, los problemas simplemente están ahí. A la corta o a la larga habrá que enfrentarlos

Es en ese enfrentamiento que el arquitecto debe usar su creatividad para resolver los problemas.O la usa para resolverlos o la usa para buscar eficazmente una solución ya creada para el problema que está enfrentando

Un arquitecto que resuelve por si solo todos los problemas de arquitectura que enfrenta es un arquitecto muy bueno. Pero aquel que resuelve algunos por si solo y el resto mediante la aplicación adecuada de soluciones ya creadas, es mejor. Por qué? Porque no está reinventando la rueda cada vez: reduce los riesgos aplicar soluciones ya probadas a un problema recurrente (conozco más de un arquitecto que no entiende bien este concepto elemental y autosuficientemente lo veo irse a la cascada en cada desafío)

Resolver un problema de arquitectura, es aplicar soluciones normalmente de la siguiente índole

  • Patrones de diseño
  • Paradigmas (orientacion a objetos, a aspectos)
  • Herramientas (sean productos, plataformas –frameworks– o API’s)

Vuelvo atrás, a la duda sobre el origen de los problemas. Acá viene lo interesante: aunque parezca un contrasentido, los problemas se originan en las soluciones que aplicamos a problemas previos. Querés ver que sí? Te muestro algunos ejemplos

  • El patrón de arquitectura en tres capas (vista, negocio y acceso a datos y servicios) resolvió, entre otros, los problemas de los clientes pesados o fat clients (distribución costosa, una licencia de acceso concurrente a la base de datos por cada usuario, etc). Sin embargo, nuevos problemas surgieron, derivados de la solución que el patrón propone: manejo de la sesión (expiración, seguridad para detectar impostores), caching de datos para evitar caídas de rendimiento, pooling de objetos tales como conectores a bases de datos (también por cuestiones de rendimiento), etc
  • La aplicación de un mapeador entre objetos y datos relacionales (object/relational-mapper u O/R-M) resolvió sorprendentemente el problema de discordancia entre ambas representaciones de la información (conocida como impedance mismatch). Sin embargo, aplicar este tipo de soluciones implica definir mapeos que en ocasiones no son triviales. Por ejemplo, la carga perezoza (lazy loading) de relaciones, usada inadecuadamente puede tirar abajo el rendimiento. Dejada de lado inadecuadamente… también puede impactar al rendimiento! Entonces, cómo saber cuál es el punto adecuado en el grafo de relaciones de objetos para detener la carga activa (eager loading) y pasar a la perezoza? He aquí un problema derivado de usar un O/R-M

Que una solución crée nuevos problemas no es necesariamente malo si los nuevos problemas a resolver son más simples, o en algún sentido más manejables que el problema original. Aplicar una solución S para resolver en forma completa un problema P implica aplicar soluciones S1, S2, etc para resolver los problemas P1, P2, etc, derivados de aplicar la solución S. Resolverlos, recursivamente, en forma completa a estos problemas derivados también

Eventualmente se puede pensar en una solución alternativa S’ al problema P, de manera que no introduzca problemas nuevos, o bien que sí los introduzca pero que estos sean más manejables que los introducidos por S. De este modo, el problema P podría tener soluciones S, S’, S”, S”’, etc

Para optar por alguna de estas soluciones posibles, el arquitecto debería tabularlas de modo de comparar sus fortalezas (calidad de la solución en términos de simpleza, efectividad y valor agregado) y debilidades (problemas que quedan a resolver en caso de aplicar cada solución)

Como decía al principio, Arquitectura tiene que ver con administrar la complejidad. Para ello el Arquitecto debe ser un buen administrador, debe saber tomar buenas decisiones y especialmente buenas elecciones. Para elegir adecuadamente, la clave fue, es y será: Objetividad. Los autosuficientes nunca van a ser buenos arquitectos

Hasta pronto

Esta entrada fue publicada en Software Architecture. Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s