Conoce las preguntas más valiosas para guiar la construcción de tu arquitectura

Autores: Slin Castro & Tex Albuja

En nuestra experiencia como tecnologistas y desarrolladores de software, nos hemos enfrentado a algunos tipos de arquitectura, desde los ahora llamados monolitos, pasando por microservicios, arquitectura orientada a eventos y otras tantas. Además hemos estado en diferentes etapas de un proyecto, desde una incepción o planificación del proyecto, hasta el soporte y retiro de un sistema.

En un día normal de trabajo, mientras revisamos código y usamos diagramas para resolver algún inconveniente, nos empezamos a hacer estas preguntas : ¿Cómo llegamos aquí? ¿Por qué hicimos esto? ¿Cómo es que se volvió tan complicado?, ¿Por qué no sabíamos que esto iba a pasar al inicio del proyecto? Con esto en mente, quisimos compartir diferentes preguntas desde diferentes enfoques que nos han servido en los últimos proyectos para entender mejor el problema, reducir complejidad innecesaria y entregar lo que el cliente necesita.

Negocio : Apalancando la consecución de un objetivo de negocio.

¿El por qué es más importante que el cómo?
- Fundamentals of Software Architecture

Construir un nuevo sistema o un ecosistema de aplicaciones ocurre porque se necesita conseguir “algo nuevo” que traiga ganancias a la organización. A veces esa ganancia es dinero, otras veces es velocidad o mejora de un proceso. Entonces, el primer paso es responder estas preguntas :

• ¿Cuál es el problema que queremos resolver u objetivo que queremos lograr?
• ¿Por qué es un problema?
• ¿Qué consigue la organización resolviendo ese problema?
• ¿Qué consigue la organización logrando ese objetivo?
• ¿Cómo sabemos que estamos resolviendo estos puntos de dolor?
• ¿Cómo sabemos que estamos consiguiendo este objetivo?

Al entender las motivaciones y el por qué de este problema, evitamos sobredimensionar algunas características de la arquitectura que implican complejidad en el proyecto y un mayor tiempo de entrega, resultando incluso en no llegar a mostrar ese “algo nuevo” que desea la organización. Esto puede provocar que los proyectos no salgan a la luz, como resultado de consumir el presupuesto y provocado por una falta de entrega de valor al negocio.

La finalidad al crear un nuevo sistema es conseguir un objetivo o solucionar un problema, no el implementar una nueva tecnología, arquitectura o metodología: éstas son el camino, no el destino.

Si lo quisiéramos expresar como código sería algo así:

Personas: Facilitando conversaciones de arquitectura en la organización.

El todo por sobre lo específico — El Árbol no te deja ver el bosque

Para proponer una solución técnica, luego de entender el problema debemos contextualizarla dentro del ecosistema y los componentes con los que interactúa. Este diseño base nos da un nivel de abstracción alto que nos permite agregar más detalles conforme construimos la solución.

La información técnica relacionada a la arquitectura de una organización está usualmente dispersa en muchas personas y podemos consolidarla utilizando una pizarra, o en un contexto remoto con herramientas de colaboración digital como Mural y Miro, Estas herramientas nos permiten definir una arquitectura de alto nivel de forma colaborativa y levantar en simultáneo información de múltiples equipos de trabajo en una sola sesión.

Juntar a personas con distintos perfiles y contextos enriquece la conversación en términos de alcance, valor de negocio, factibilidad técnica y proceso. Desarrolladoras, Product Owners, Analistas e incluso usuarios finales agregan su punto de vista en el que el rol del arquitecto de software pasa de ser un observador externo a ser un facilitador en este espacio compartido.

Ahora, el enfoque es mantener los objetivos de la sesión alineados al problema que se busca resolver, sus limitaciones y un posible plan de implementación. Para llegar a este entendimiento no se necesitan todos los artefactos propuestos por UML y BPMN, basta con dibujar cajas, flechas y el contexto del problema.

Podemos apoyarnos en estas preguntas para guiarnos:

• ¿Cómo puedo pasar del porqué al cómo?
• ¿Qué quiero obtener de esta sesión?
• ¿Tengo la información necesaria para empezar a bosquejar la solución?

Tecnología : La arquitectura también es iterativa

“Everything in software architecture is a trade-off, If an architect thinks they have discovered something that isn’t a trade-off, more likely they just haven’t identified the trade-off yet”
Software Architecture fundamentals

Generalmente se piensa en la arquitectura como un objetivo o un fin, que es creada solo por personas técnicas y que será los cimientos del nuevo sistema, por lo que se toman todas las medidas para hacer que esta arquitectura responda a todos los posibles escenarios que se puedan presentar en el futuro, mientras tanto se pierde de vista su principal función que es apalancar la consecución de un objetivo de negocio.

No debemos tratar de predecir todo lo que va a pasar pero debemos crear una base flexible y sólida para adaptarse al cambio en el futuro, además debemos incluir las características / CFRS /ilities necesarias para solucionar el problema Ej.: Si mi sistema tiene 100 usuarios ¿Realmente necesito escalar horizontalmente?. Implementar cambios en la infraestructura son más sencillos ahora que contamos con las capacidades de la nube. El riesgo de cada cambio se ve reducido a aplicar y medir.

Preguntas

• ¿Qué voy a lograr con esta nueva arquitectura que no estoy logrando con la actual?
• ¿Qué features podríamos construir sobre esta arquitectura?
• ¿Cuánto le costará a la organización mantener esta arquitectura cuando esté en producción?
• ¿Cuando terminemos el proyecto, alguien podrá darle mantenimiento?
• ¿Qué características de arquitectura (Escalabilidad, Usabilidad, Testabilidad etc.) debería tener nuestra solución?
• ¿Es este un buen momento para incluir un cambio en la arquitectura?
• ¿Cuáles son los puntos de comparación para comparar nuestra arquitectura con otra posible solución?

Realizar estas preguntas tomando en cuenta las diferentes perspectivas (tecnología, negocio, personas) nos acercarán al problema y nos harán comprender que no todas las soluciones son replicables, dependen del contexto y el problema al que nos enfrentamos.

Es por esto que no quisimos compartir las soluciones que nos sirvieron en otros contextos sino las preguntas y principios que seguimos. Plantearnos estas preguntas nos invita a abrir nuevas e interesantes conversaciones dentro de la organización, ya que nuestro objetivo es implementar un diseño viable que solucione el problema aunque aún no esté perfecto. Entonces, el objetivo no es demostrar lo que sabemos sino empezar a solucionar el problema.

Finalmente queríamos compartir este mapa mental en donde condensamos cómo llegar del porqué al cómo a través de algunas de las preguntas planteadas:

Disclaimer: las declaraciones y opiniones expresadas en este artículo son las de l@s autor@s y no reflejan necesariamente las posturas de Thoughtworks.

¿Quieres formar parte de Thoughtworks Ecuador? Aplica a nuestras vacantes en nuestra página web https://thght.works/3F3T4JA