El mayor problema con la arquitectura de software
SPOILER: No es algo técnico
Esta edición del newsletter está auspiciada por el “Bootcamp de arquitectura en React Native” que estaré dictando el próximo jueves 9 de Febrero. Aprovecha un 35% de descuento hasta el viernes 3 de Febrero. Más información al final.
En estos 2 últimos años donde he tenido que trabajar en proyectos integrando servicios cloud y una app móvil, me he dado cuenta que a pesar de las dificultades técnicas persistentes, el mayor problema al enfrentar la arquitectura de un sistema tiene que ver con la educación y la creación de espacios para discutir y ahondar en esa materia.
Para explicarlo de mejor forma, deja listarte algunas de las consecuencias de convivir con este problema:
Developers junior o mid-senior intimidados por no poder preguntar o resolver sus dudas respecto a la arquitectura
Falta de estándares para redactar documentación sobre arquitectura
Constante dificultad para mantener actualizada la documentación sobre arquitectura
Inconvenientes para encontrar documentación apropiada para resolver dudas
A continuación, veamos factores que influyen en que este problema progrese y se acelere.
Tamaño de equipo y áreas de negocio
Situémonos en un ejemplo de una app e-commerce. En este tipo de apps con complejidad simple se puede pensar que hay 2 áreas de negocio.
Una donde el usuario navega y explora productos.
Otra donde el usuario hace el checkout y paga por una compra.
En apps más complejas estas áreas puede ser muchas más. Un área de personalización de contenido, una de educación de producto, o donde se le ofrezcan beneficios exclusivos a un equipo.
El número de áreas (y que va en aumento proporcional con el tamaño del equipo), va a impactar en la constante evolución de la arquitectura. Y en casos más difíciles, en los acuerdos que puedan convenir el arquitecto de cada área.
Proceso de “onboarding”
Olvidémonos por un momento del “hiring freeze” post-pandemia. Supongamos que nuestros equipos están creciendo a una velocidad vertiginosa.
Cuando estamos acelerando la contratación y gente nueva en los equipos, es importante saber el proceso y métricas para que ese nuevo miembro se sienta “productivo”.
Que en los procesos formales existan espacios o reuniones frecuentes para enseñar de la arquitectura, va a ser un gran diferenciador en como los nuevos miembros comprendan la arquitectura y tengan el contexto necesario para dar opiniones respecto a ella en el futuro.
La documentación
Si aún no tienes documentación o te falta mucho por escribir para documentar el conocimiento de tu equipo, no te preocupes. Este es un problema recurrente en cualquier tipo de empresa.
Mantener una documentación actualizada, especialmente para la arquitectura es un desafío que requiere de líderes y constancia para hacerlo realidad. Cuando posteriormente se comienza, requiere de definición de estándares y formatos para distintos tipos de documentos.
El no tener acceso ordenado a documentación respecto a la arquitectura va a impactar en las discusiones y decisiones que se tomen sobre esta. Para los arquitectos de software, esta pieza es fundamental ya que les permite explicar las soluciones de arquitectura a su propio equipo y a otros externos.
¿Cuáles son algunos paliativos para solucionar lo anterior?
Los consejos que te voy a dar dependen en que estado estés actualmente con la definición de la arquitectura?
¿Está comenzando de 0 un producto?
Tienes un producto, pero no has comenzando a documentar ni pensar en arquitectura
Tienes arquitectura definida y estás en un proceso de re-arquitectura
Tienes arquitectura definida y el equipo está creciendo con velocidad
Seguro hay más casos pero espero que te hayas podido situar en uno.
Creación de espacios recurrentes de discusión
La palabra comunidad también puede existir dentro de las empresas y se puede formar una de cualquiera tema. Para este caso, no solo basta con educar sobre la arquitectura, si no también tener una comunidad transversal donde se hable de ella y se discutan tópicos sobre: estado actual, estado futuro, optimizaciones, propuestas, entre otros.
Para equipos pequeños, una recurrencia de 1 o 2 semanas sirve para mantener el contacto. Cuando ya existen más de 10 arquitectos en una plataforma, la recurrencia puede variar a 3 o 4 semanas.
Para estas comunidades es vital tener a alguien que las mantenga vivas. Hacer seguimiento a los acuerdos, organizar los encuentros y recabar feedback para mejorarla. Esta persona no necesariamente debe entender en profundidad temas técnicos.
Asignar tiempo en los “sprints”
Como codear, diseñar y hacer QA, diseñar y documentar la arquitectura es un tiempo que debe ser considerado cuando se estima un sprint. Tu “product owner” o “scrum master” debe entender que es un input para la implementación final.
El tiempo que toma diseñar una solución de arquitectura va a depender varias cosas, como: integración con terceros, manejo de data personal, tipo de carga del proceso, y mucho más. En general pienso que el primer borrador de una solución no debería tomar más de 3 semanas.
Lo otro es que el arquitecto generalmente debe estar apoyando y justificando la solución a su mismo equipo, y a otros que de otra plataforma que repliquen la solución. Ese tiempo también se debería estimar en el impacto del sprint.
Contratar y consultar expertos
Cuando son equipos que no tienen mucha experiencia diseñando y enseñando arquitectura, se puede también considerar la opción de contratar ayuda externa. Esto, no solo para ayudar con la solución si no también para establecer estándares mínimos para esa y soluciones futuras.
El experto debe tener ser capaz de mostrar casos donde haya diseñado arquitectura y creado procesos o cultura para exponerla ante distintas audiencias.
Unirse a comunidades externas
Esta en particular me gusta mucho, porque da la señal hacia los equipos, de que la arquitectura es algo importante y que debe ser constantemente desafiada y alineada con estándares de otras empresas o comunidades.
Las acciones para esto van desde ser un miembro pasivo en una comunidad: leyendo, aprendiendo, documentando internamente, etc. O activo: dando charlas, participando de discusiones, creando material, incluso siendo sponsor de comunidades.
Las opciones son variadas: meetups, conferencias, foros y blogs.
Espero haberte dado una arista complementaria o nueva para entender el problema número uno (según mi humilde opinión) respecto a la arquitectura de software.
Pero deja comentarte algo más.
Estoy muy emocionado porque el próximo jueves 9 de Febrero (y 2 otros días posteriormente) estaré dictando un bootcamp sobre arquitectura de apps móviles (escritas usando el framework React Native).
Tengo preparadas muchas estrategias, tips y situaciones donde me ha tocado escalar y re-pensar la arquitectura de esta plataforma.
Sería genial que te unieras. Esta semana, como promoción especial, estoy ofreciendo un 35% de descuento en el ticket hasta el viernes 3.
Te espero para aprender y conversar más de arquitectura.
Eso es todo.
Abrazo.
Felipe
PS: Me ayudas mucho si compartes este artículo a alguien que pueda servirle o interesar. Cambio y fuera.
Cuéntame que te pareció esta edición: