¿Qué ocurre “normalmente”?

Me gustaría empezar aclarando lo que posiblemente muchos hemos vivido en nuestros proyectos. Un sistema se construye con o sin una arquitectura definida. La realidad indica que quieras o no, el sistema se construirá pues así lo determina el negocio. En resumen, tenemos que responder a una necesidad.

Si el sistema ya está en producción y no está claro si hubo un trabajo de arquitectura, más que tomar una posición al respecto, lo que debemos hacer es evaluar y fundamentar con evidencias, el comportamiento del software desde su primera liberación al usuario.

Si el sistema no ha presentado problemas a consecuencia de cambios constantes en el negocio, podremos concluir de que la decisión tomada fue la mejor para esa realidad. Claro está, que eso no implica que dicha formula funcione para otras realidades.

Ahora, si es que está en nuestras manos incluir este tipo de trabajos (es decir, los de arquitectura), pues tenemos que hacerlo sin dudar siquiera un segundo 🙂

¿Cuál es el impacto “mínimo” de una arquitectura?

En este tipo de situaciones considero poco profesional que nos basemos en supuestos, puntos de vista, corazonadas o peor aún en feelings, pues lamentáblemente estos no nos servirán en momentos que llegan gracias a los clásicos y no tan queridos “cambios de última hora”. Es por ello que en vez de feelings, lo mejor es que tengamos a la mano hechos concretos:

1. Impacto en el proyecto: Un caso –muy gráfico– se remonta a un hecho ocurrido en USA en 1940. Si no conocían [la caída del puente Tacoma Narrows], les comento que hay [estudios al respecto] y que todo indica que el diseño inicial omitió consideraciones como por ejemplo, el efecto que tendría el viento sobre la estructura del puente ¿Servirá de algo compartir este tipo de experiencias? Esto lo dejo a su elección, pero vale la pena mencionar que para esa época, USD 6MM fue la cantidad de dinero que literalmente “se fue al agua”

2. Rapidez de implementación: Podría sonar lógico escuchar que una buena práctica incrementa la rapidez del desarrollo, pero es mejor mostrar un caso en el que, por ejemplo, TDD genera una mejora de al menos 30% del tiempo esperado bajo “condiciones normales”

3. Costos de mantenimiento: Si bien es cierto este estudio se hizo hace más de veinte años, estoy seguro de que se han encontrado con problemas que son complicados de resolver, pues la solución implicaba “cambiar muchas cosas”. Aquí un gráfico que refleja lo encontrado luego de analizar proyectos en empresas como HP o IBM, el cual en resumen indica que si hemos avanzado mucho en el trabajo y nos encontramos con un error, corregirlo será muy costoso.

¿Qué consideraciones debe incluir nuestra arquitectura?

La “respuesta corta” es, tenemos que implementar nuestro sistema considerando una arquitectura que soportará las necesidades del negocio.

La “respuesta larga” incluye estas consideraciones:

1. Estamos en la época en la que gracias a la agilidad, podemos confirmar en plazos cortos si nuestro producto (o parte de este) es útil. De aquí es donde se desprende el concepto de valor.

2. El valor se asocia a la utilidad desde el punto de vista el usuario, y eso es bueno, pero lo que no debemos olvidar es que el usuario final no es ni será el único usuario del sistema. Pues de alguna u otra manera, los desarrolladores y resto del equipo técnico son usuarios. Por consiguiente, el valor también se debe visualizar desde una perspectiva técnica.

3. Este “valor técnico” muchas veces es confundido con una necesidad que podría estar en una prioridad distinta a la requerida por el usuario final. Y es lo que comúnmente ocurre, pues “eso es transparente para el usuario”

4. Esta nueva restricción podría basarse en la experiencia del equipo, pero lo recomendable es incluir criterios de calidad probados por el mercado. Para esto hay muchos modelos, pero creo que una base muy entendible es [la propuesta de Jim McCall]:

5. Cubrir los criterios de cada perspectiva, requerirá contar con una arquitectura que las soporte y un conjunto de prácticas que no necesariamente se verán reflejadas en el diseño, pero sí en la implementación del mismo. Es aquí donde entran a tallar el uso de estándares de programación o de prácticas como la de TDD o incluso prácticas de DevOps (y la lista podría ser muy larga)

¿Dónde está el código?

Si bien es cierto soy partidario de hablar con código en mano, este es un caso en que necesitamos aceptar que el código llegará luego de entender con claridad los criterios mencionados por el Modelo de McCall. La mala noticia es que no hay magia en este trabajo, si queremos empezar y no sabemos por dónde, pues podríamos tener en cuenta lo siguiente:

1. Hace poco escribí sobre [10 aspectos a considerar si les interesa la arquitectura]. Si es que ya se sienten listos para empezar con la parte técnica, pues les sugiero revisar los puntos 3 y 7 (Conceptualizar y Estudiar y poner en práctica).

2. Si bien es cierto [mi post] lo menciona, es posible que no esté claro cómo empezar con lo que denomino “conceptualización” ¿Cómo podrían empezar con esto? Pues este gráfico de niveles de diseño, les dará una idea de lo que a algunos les podría parecer obvio, pero que a pesar de ello he notado que muchas veces no se hace bien, debido a la necesidad de escribir código lo más pronto posible.

3. Este tipo de razonamiento se debe complementar con conceptos de diseño como [acoplamiento / cohesión] y claro, de [SOLID]. De este último he encontrado un [video que lo explica muy bien] y que además muestra ejemplos de código.

Conclusiones

Creo que sobran argumentos sobre la importancia de la arquitectura de un sistema, pero esto no sirve de mucho si no aceptamos que la arquitectura es solo una parte del trabajo que debemos realizar.

Líneas arriba mencioné la relación que existe entre la arquitectura y las prácticas como TDD, DevOps y aquí podría agregar los estilos de arquitectura, el uso de patrones de diseño, automatización de pruebas y herramientas que nos permitan acelerar de manera eficiente el trabajo del equipo de desarrollo. Sin olvidar claro, el concepto de valor.

Por otra parte, lo que no debemos hacer es separar el concepto de valor en más de una vertiente. Mi explicación del “valor técnico” fue hecha por la necesidad de demostrar de que el “valor” incluye otros factores, y que en primera instancia estos son transparentes para el usuario, pero con una correcta asesoria este comprenderá la necesidad de incluir estos alcances a lo largo del proyecto.

Me gustaría agregar que la entrega de valor debe estar equibilibrada bajo la premisa de que no hay un solo tipo de usuario. Esta es muchas veces una línea delgada con alto riesgo de ser confundida u omitida.

Un abrazo,