Thinking Like an Architect

En el desarrollo de software moderno, cambiamos la forma en que solíamos diseñar software. Pero el verdadero desafío ahora es que los desarrolladores tienen muchas más cosas en qué pensar. Piensa en la parte de DevOps, la arquitectura, la seguridad, y así sucesivamente. Este movimiento de shift left comenzó a entrar de manera muy agresiva hacia los desarrolladores, y ahora necesitan cubrir una variedad de tareas.

El desafío con la arquitectura es que muy a menudo la gente piensa que la arquitectura no es más que seleccionar la pila tecnológica adecuada o la pila tecnológica más avanzada. Desafortunadamente, esto es incorrecto. Porque la realidad es que la arquitectura se compone de tres cosas simples. Tomas algunas decisiones basadas en el contexto y la información que tienes, luego necesitas equilibrar las compensaciones respecto a la decisión que necesitas tomar, y finalmente, lidiar con las consecuencias. Porque la realidad es que la arquitectura no es algo que decides y luego olvidas eso. Necesitas vivir con eso durante un largo período de tiempo muy a menudo.

Por lo tanto, la arquitectura no se define como un título, en mi opinión, sino como una mentalidad. Si tienes el rol de arquitecto dentro de tu título de trabajo, podrías o no representar a un buen arquitecto. Durante esta masterclass, quiero compartir contigo 11 consejos que aprendí en las trincheras en los últimos 22 años. Mi nombre es Luca y actualmente trabajo para AWS. Pero en el pasado, como puedes ver, he desempeñado varios roles que van desde un simple desarrollador hasta un CTO y todo lo que hay en medio. Tuve el placer de trabajar con una gran organización, Unicorn, empresas que pasan de cero a millones de clientes y cosas por el estilo.

Creo que estas 11 ideas te ayudarán a repensar cómo debería ser la arquitectura dentro de tu sistema. Comencemos primero con el espacio del problema. Necesitamos entender eso. En la arquitectura moderna, una cosa que cambia es la parte de descentralización porque ya no estamos descentralizando solo las prácticas, las prácticas de ingeniería a múltiples equipos que están trabajando en un área específica del sistema, sino también la organización. Pero durante la gran mayoría del tiempo, la organización es un pensamiento posterior. Pensamos que con una arquitectura simple como microservicios o una arquitectura basada en autoservicio, lo que sea, resolvemos todos nuestros problemas. Ese no es el caso. El segundo problema es que nos enfocamos mucho en la tecnología. Ignoramos las necesidades del negocio y nos enfocamos en lo que nos apasiona, escribir código o construir con el último servicio en la nube. Y por último, ignoramos nuestro contexto, lo que el negocio necesita. Entonces, ¿cuáles son las habilidades técnicas dentro de nuestra organización y cómo está estructurada nuestra organización y así sucesivamente? Nuestro contexto es el rey aquí porque si diseñamos algo que ayuda a nuestro contexto a prosperar, entonces estamos en una buena situación.

Así que déjame comenzar con algunos consejos que aprendí en las trincheras en los últimos 22 años. Así que, primero que todo, necesitas recordar que la arquitectura está vinculada, directamente vinculada a la cultura de ingeniería y la organización.

Algo tan simple como seleccionar un enfoque de monorepo versus un polyrepo dará forma a la forma en que tus equipos se comunican entre sí. Y eso no es algo que puedas subestimar. Muy a menudo, la gente piensa que es solo una decisión técnica. La realidad es que básicamente estás definiendo cómo deberían trabajar tus equipos, tal vez utilizando desarrollo basado en trunk. ¿Tienen la habilidad para hacerlo o cuánta fricción crearás dentro de las trincheras y también cómo van a comunicarse? Porque compartir con el monorepo es diferente de compartir con el enfoque de polyrepo y así sucesivamente.

Así que nunca subestimes una decisión técnica pensando que solo vive en ese ámbito. La otra cosa en la que necesitas pensar es en entender qué necesita tu producto o negocio. Este es el primer punto para mí. Y muy a menudo, ya sea que estés trabajando en un proyecto Greenfield o en un proyecto Brownfield se subestima. Es extremadamente importante que entendamos qué tipo de KPIs necesitamos rastrear. ¿Cuál es el beneficio de esta característica para nuestros usuarios? ¿Por qué estamos haciendo eso? ¿Cuál es el producto mínimo valioso que pueden entregar lo antes posible para recopilar información de los usuarios?

Hay dos técnicas que suelo usar con los clientes ahora con AWS, pero antes también en mi empresa. Una es una masterclass colaborativa llamada event storming que reúne a un grupo de personas dentro de la misma sala y comienza a dar un paso atrás de la tecnología y mirar hacia el negocio y cómo se comportarán tus usuarios dentro del sistema. La otra es domain storytelling, muy similar pero con un enfoque diferente donde contamos una historia y explicamos cómo nuestros usuarios van a interactuar con nuestro sistema. Pero ambos tienen algo en común. No necesitan hablar de tecnología que al principio no es necesaria. Necesitas entender qué necesitas expresar dentro de tu sistema.

Y eso nos lleva al segundo consejo. Así que comienza con los límites. Cuando entiendes cómo funciona el sistema, entonces comienzas a pensar en cómo se ven tus límites. El diseño impulsado por el dominio es fenomenal en eso porque generalmente ayuda a crear un vocabulario común entre producto e ingeniería. Pero más importante aún, cuando identificas a través de event storming o domain storytelling los diferentes límites de los que está compuesto tu sistema o tu característica, puedes comenzar a categorizarlos. Puedes definir qué es central, así que las cosas más importantes dentro de tu sistema. Qué es de apoyo que ayuda al núcleo a prosperar y qué es genérico. Déjame darte un ejemplo. Así que si tomamos Netflix, por ejemplo, un dominio central para Netflix, así que la razón por la que Netflix existe es permitirte ver tus series favoritas en cualquier dispositivo y en cualquier momento del día. El dominio de apoyo, por ejemplo, podría ser la personalización. Y la personalización significa que si tengo un catálogo que es el dominio central y tengo una personalización, sí, puedo tener una mejor experiencia. Pero la realidad es que si el servicio de personalización está caído, aún puedo ver el catálogo, aún puedo buscar. Así que no está tan mal. Así que puedo comenzar a aplicar características a los dominios de apoyo.

Eso es lo mismo para genérico. Para consumir video en Netflix, necesitas suscribirte. Y para suscribirte, necesitas pagar una tarifa con, no sé, PayPal, mi tarjeta de crédito o cualquier otro método de pago que desees. Netflix no es una pasarela de pago, pero aprovechan una integración para hacer eso. Ese es un dominio genérico que no agrega ningún valor a Netflix en sí, pero la realidad es que se necesita para tener el servicio de Netflix disponible para ti.

Además, recuerda, si estás trabajando en un proyecto brownfield, también necesitas revisar regularmente tus límites, porque tu negocio está evolucionando así como tu arquitectura. Porque la realidad es que si ignoras que el negocio está tomando una dirección y luego comienzas a generar fricción en las trincheras, no puedes culpar a la arquitectura. Así que solo necesitas revalidar que los límites siguen siendo válidos de la manera y la forma que la empresa quiere seguir. La otra cosa es que necesitas, como tercer punto, identificar tus características arquitectónicas.

Porque muy a menudo, hablo con empresas y equipos que están comenzando a preguntar, oh, mira, ¿qué piensas sobre esto? Es como, perfecto, así que intentemos entender qué necesitas expresar aquí. ¿Cuáles son tus requisitos de seguridad? ¿Cuál es tu SLA? ¿Te afecta la latencia? Y así sucesivamente. Déjame darte un ejemplo. Así que si piensas en la latencia, por ejemplo, si estás trabajando en, no sé, un sistema financiero que trata con el mercado de valores, definitivamente la latencia importa. No puedes diseñar algo que tenga muchos saltos entre la red para aumentar la latencia. Probablemente necesites pensar en co-localizar ciertas cosas. Y hay algunos estudios de caso interesantes que muestran que para cosas específicas donde la latencia es obligatoria, necesitamos diseñar las cosas de manera diferente.

Mientras pienso en otro requisito, como por ejemplo, la disponibilidad, necesitas pensar en cuántas noches deseas. Porque la realidad es que diseñar algo con, no sé, tres noches de disponibilidad, significa que vas a tener más o menos una hora de posible tiempo de inactividad dentro de tu sistema. ¿Es aceptable o no? Y si no lo es, necesitas pensar en usar una estrategia multi-regional. Así que esas decisiones o características arquitectónicas que necesitas implementar dentro del sistema son obligatorias para entender porque de lo contrario no puedes diseñar adecuadamente tu sistema. Hay ciertas cosas que se filtrarán inmediatamente cuando tengas claridad sobre tus características arquitectónicas.

Ahora, la otra cosa cuando has hecho eso es entender cómo podrías modularizar tu sistema. Así que hay diferentes técnicas en arquitectura, ¿verdad? Así que podemos comenzar con monolito, monolito modular, o microservicios, o incluso una arquitectura basada en servicios. Y todos ellos no son ni correctos ni incorrectos. Necesitamos detener esta pelea pensando, oh sí, los microservicios no son geniales por esta razón, esa razón, esa razón, o el monolito es del pasado. Hay situaciones donde necesitas optimizar, por ejemplo, para recuperar, reunir comentarios rápidamente de tus usuarios. Y tal vez un monolito podría ser la respuesta. Hay otras situaciones donde tu contexto nos dice que necesitas tener múltiples equipos trabajando juntos, pero no pueden depender siempre unos de otros. Así que quieres reducir las dependencias externas. Y por lo tanto, para expresar eso, podrías usar una arquitectura de microservicios.

Así que cuando piensas en cuán granular quieres ir, y eso no es solo para el diseño de la arquitectura, también podría ser a nivel de código, comienza a pensar en cuál es la tasa de cambio de una característica específica. Si tienes una característica, por ejemplo, que sabes que tiene una alta tasa de cambio al principio porque necesitas construir desde cero, pero luego van a cambiar una o dos veces al año. Así que el para es mantener las luces encendidas en esta característica. Entonces probablemente incluso puedes permitirte co-localizar más, mientras que por el otro lado, si tienes algo que cambia muy a menudo, podrías necesitar pensar muy bien en la forma en que encapsulas tu servicio. Así que puedes cambiar de manera independiente, reduciendo, no eliminando las dependencias externas y comenzar a, digamos, trabajar más en iteraciones rápidas. Y como puedes ver ahora, la idea de que tengo un monolito modular o microservicios no suma demasiado porque no tienes que, digamos, seguir un camino específico. Y cuando decides una cosa, solo usas ese camino. Tiene que ser, digamos, ligeramente más fluido.

Y eso nos lleva al siguiente consejo. Sé pragmático y no dogmático. Porque te doy este ejemplo. Así que imagina que estás trabajando en un sistema que es, por diseño, una arquitectura impulsada por eventos. Así que hay un servicio que ves en la parte superior que se comunica a través de un evento a un sistema que está enviando correos electrónicos y SMS y notificaciones push a todos tus clientes. Ahora, cuando piensas en la implementación de este servicio, puedes tener un poco de computación, contenedor, serverless, donde quieras. Y luego almacenas en una base de datos cuando necesitas notificar a este usuario. Y tal vez ahora puedes decidir que a través de una técnica que ciertas bases de datos tienen que se llama CDC, puedes activar cuando, digamos, un registro expira o cambia y comenzar a activar un evento específico para decir, OK, envía la notificación push o mejor envía un correo electrónico. Ahora, si piensas en eso, el compromiso aquí sería que estoy aprovechando más la infraestructura y yo, como desarrollador, tengo mucho tiempo libre para hacer algo más. Esa podría ser una decisión que quieras tomar en este caso, ¿verdad? Pero al mismo tiempo, ¿qué pasa con la escala? Así que si tengo como 100 mensajes, está bien. Así que envío como 100 mensajes y luego almacenaré 100 registros en una base de datos. Y luego para CDC, enviaré 100 veces esta información a un tercero o a otro servicio para enviar la notificación push o el correo electrónico. Pero, ¿y si tengo 10 millones? Y ahora empieza a complicarse un poco más. Así que necesito repensar mi sistema.

Si tengo 10 millones, significa que probablemente puedo mirar cómo puedo optimizar costos, pero al mismo tiempo tener los mismos beneficios. Porque si envías una notificación push al final del día, si envías al principio de la hora o 10 minutos tarde, nadie se quejará en ciertos casos, obviamente, si hay ciertos escenarios que lo necesitan. Pero supongamos que no es este caso. Y luego puedes comenzar a pensar en, por ejemplo, usar un cron job. Y luego cada 10 minutos tomas la última, no sé, una cierta cantidad de mensajes que necesitas enviar y luego comienzas a enviar. Ahora, ¿cuál es el desafío, sin embargo? ¿Eso? Sí, probablemente la infraestructura será más barata. Pero al mismo tiempo, tus costos comienzan a aumentar porque necesitas escribir el código, mantener el código, actualizar el código y así sucesivamente.

No eres un recurso libre. Y cuando piensas como arquitecto, necesitas pensar de manera holística sobre el plan. Ambos enfoques pueden funcionar. Pero el contexto guiará tu decisión.

Ahora, lo otro en lo que necesitas pensar, incluso en el ejemplo anterior, nuestro cambio en una situación como esa sería mínimo porque queremos tener una mentalidad evolutiva cuando estamos diseñando nuestro sistema. Las únicas dos constantes en la arquitectura son los cambios y los compromisos. Y la parte divertida para mí es que muy a menudo escuché, oh, sí, porque siempre lo hemos hecho de esta manera en ciertos equipos.

Pero, desafortunadamente, no puedes luchar contra eso. Necesitas abrazar esto porque esto es lo que la empresa quiere tener. Y necesitamos pensar en nuestros usuarios, nuestros clientes, porque esa es la única prioridad. Nuestros usuarios son las personas que básicamente están comprando. No les importa si tienes una arquitectura basada en autoservicio detrás de escena o un monolito. Lo que les importa es que pueden realizar una tarea específica. Y, por lo tanto, tu trabajo no es construir el sistema perfecto. No estamos aquí solo para usar la tecnología más asombrosa de todas, sino para ayudar a nuestro cliente a alcanzar un objetivo específico. Y aquí está el acto de equilibrio que necesitamos hacer cuando pensamos como arquitecto.

¿Entonces, cuál es la visión a largo plazo? ¿Cuáles son las necesidades inmediatas? Hay ciertas situaciones que me han sucedido varias veces donde, por ejemplo, yo tuve que integrar e importar un montón de más o menos medio millón de usuarios de una plataforma a otra plataforma. Ahora podríamos hacer las cosas bien o podemos hacer, digamos, el camino inmediato y rápido. Y optamos por el camino rápido por una razón, había una restricción clave, había un plazo para el comienzo de la temporada de fútbol y luego sorpresa, no puedes moverlo. Y por lo tanto, sí, negocié con el negocio que haríamos la victoria rápida. Pero al mismo tiempo, justo después comenzamos a trabajar en la implementación a largo plazo, porque esas son las cosas con las que necesitas lidiar con compromisos, como dijimos antes.

Y muy a menudo, cuando tomas este tipo de decisiones, necesitas adoptar una mentalidad ágil. Así que toma la mejor decisión que puedas en el último momento responsable. Y puedo garantizarte que si te quedas en modo de procrastinación, comenzando a pensar o necesitas reunir más información de la que realmente necesitas, vas a caer en un agujero de conejo que no va a mover demasiado la decisión final. Cuando tengas suficiente, puedes comenzar a cambiar. Y si usas una mentalidad evolutiva, puedes evolucionar con el tiempo.

Por lo tanto, como desarrollador o líder técnico, lo que necesitas hacer para mí, para pensar como un arquitecto, son tres cosas. Así que la primera es que necesitas tener una gran comprensión de tu dominio. Al final del día, estás trabajando dentro de tu dominio. Pero también necesitas entender a tus consumidores, eso es algo que no se ve muy a menudo. ¿Qué quieren? ¿Qué tipo de nuevas características están construyendo? ¿Quieren que diseñe una API? Cosas mejores como esas. Y finalmente, necesitas tener una comprensión más amplia del sistema. Si comienzas hoy en una nueva empresa y quieres comenzar a entender tu sistema yendo en esta dirección, porque cuando tienes una idea holística del sistema, puedes tomar mejores decisiones dentro de tu dominio. Pero no tienes que apresurarte en eso. Necesitas dominar primero lo que está más cerca de ti y luego tomas, digamos, una visión más holística paso a paso.

Entonces, las otras cosas importantes que cada arquitecto debería tener es comunicación. Pero no solo eso. Inclusión y documentación. Esas tres cosas para mí están en el núcleo de las habilidades arquitectónicas.

En los días en que no tenía el aire, pero mi barba no era tan blanca, la comunicación se llamaba una habilidad blanda. Pero gran spoiler, ya no es así porque la realidad es que si no puedes comunicar cómo puedes influir en el diseño de un sistema específico, para mí, la comunicación es una habilidad fundamental.

Cuando era VP de arquitectura, una de las cosas clave que decía a mi equipo es que el 70 por ciento de su tiempo, deberían crear puentes con los equipos y empatía con los equipos para entender cómo funcionan las cosas. Y en cambio, el 30 por ciento del tiempo, deberían ser técnicos porque su rol de arquitecto no es solo escribir código o, digamos, pensar en sí mismos o en cómo aplicar el siguiente patrón, es entender el aspecto sociotécnico que está básicamente detrás de cada sistema que existe.

Por lo tanto, necesitas entender cómo cambiar tu lenguaje en consecuencia. Si eres un tech lead o eres un líder en un lado del equipo, la forma en que estás hablando con tus compañeros y la forma en que hablas con el C-suite para comunicar exactamente el mismo mensaje tiene que ser diferente. El C-suite no espera tener demasiado jerga técnica. Pero lo que esperan es que entiendan el valor comercial. Así que tu rol como líder es cambiar de marcha y transformar lo que es, digamos, una implementación técnica en algo que el negocio pueda entender. Y eso te permitirá ser un comunicador más efectivo.

Pero más importante, serás, digamos, un activo para tu empresa. Ahora, la otra cosa que necesitas recordar cuando hablas con tus compañeros es que no tienes que proporcionar siempre una solución. Necesitas compartir tu razonamiento porque para llegar a una cierta decisión, pasas por ciertos pasos y tienes un cierto trasfondo que otras personas pueden no tener y probablemente no tendrán. Pero si eres capaz de decir, OK, en lugar de decir esta es la solución, punto, comienzas a decir, OK, si hacemos esto de esta manera y luego hacemos eso de esa manera y luego hacemos eso de esa manera, llegamos a la misma solución. Sí, toma un poco más de tiempo, pero todos estarán a bordo y todos te apoyarán. Más importante, pueden conectarse al viaje o tu tren de pensamientos adecuadamente para aumentar tu decisión final.

Las cuatro actividades en las que necesitas pensar cuando piensas en documentación y en el tren de pensamiento y cosas así son. Así que primero, registro de decisiones arquitectónicas, escríbelo, porque cuando escribes, tu cerebro comienza a conectar y a entender mejor el espacio del problema y el espacio de la solución. Por lo tanto, escribir por qué se tomaron ciertas decisiones. Las solicitudes de comentarios son perfectas para comunicarte con tus compañeros y también con otros equipos, los consumidores que mencionamos antes, para evolucionar tu sistema. Los diagramas de secuencia, los encontré súper útiles cuando hablas con equipos, especialmente si eres un tech lead o lo que sea, porque son claros y al grano y describen una porción del sistema con mucho detalle. Luego puedes usar otro tipo de diagramas como el modelo C4. Por ejemplo, soy un gran fan de describir el sistema de extremo a extremo desde el más alto nivel hasta el nivel más profundo. Y por último, pero no menos importante, ya no hay excusa para no entender la arquitectura como código. Así que cosas como Merrimel JS, por ejemplo, son un gran activo para diseñar diagramas a través del código. Así que te animo a dominar estas cosas porque eso te permitirá incluir no solo a las personas que tienen voz, sino también a las personas que pueden tener una voz, pero son introvertidas o son personas que no están acostumbradas a desempeñarse muy bien frente a otras personas.

Quizás debido a la falta de antigüedad o cosas personales. Y en su lugar, si permites que todos y democratizas básicamente la posibilidad de proporcionar sabiduría y la voz que podrás, gracias a estos enfoques de comunicación asincrónica.

Finalmente, mi undécimo consejo es enfocarte en lo que realmente importa. Un día mi CTO me dijo, recuerda, Luca, todo está en llamas todo el tiempo. Y desde entonces, lo tengo grabado en mi cabeza y nunca lo olvido porque esa es la realidad. No puedes distinguir cada fuego, pero necesitas entender dónde reside el verdadero valor. Por lo tanto, si eres capaz de entender, OK, cómo puedo mover mejor las necesidades del negocio si hago esto o si hago aquello. Es básicamente tu rol cuando piensas como un arquitecto, porque la realidad es que todos tienen algo que no funciona, pero no todo es importante para la empresa.

Recuerda, al principio, cuando hablaba sobre la categorización de diseño impulsado por el dominio de los subdominios. Así que el soporte central que es tu guía que te ayudará a enfocarte en lo que realmente importa. Por lo tanto, no tengas miedo de crear deuda técnica que sea estratégica. Así que diciendo y he hecho eso muchas veces, esta parte, sí, estoy bien con que seamos improvisados allí. Pero esta parte tiene que estar extremadamente pulida, tiene que funcionar porque el valor comercial es diferente.

Finalmente, las mejores arquitecturas no son las que. Detente aquí, esta es la última diapositiva, disculpa por eso. Empiezo de nuevo. Finalmente, recuerda que las mejores arquitecturas son las que son adaptativas, no las que duran para siempre. Eso es todo lo que tengo. Espero que disfrutes y que lleves algunos de estos consejos contigo en tu próximo proyecto y disfrutes el resto de la conferencia. Espero que haya sido útil y no dudes en contactarme en cualquier momento.